Difference between revisions of "Pentest"

From YobiWiki
Jump to navigation Jump to search
Line 154: Line 154:
 
443/tcp open skype2
  
443/tcp open skype2
 
</pre>
  
</pre>
  +
Subtilities: when we get a TCP Reset, compare the TTL with a TCP SYN-ACK to see if it comes from the target or a previous filtering gateway...
  +
<br>And when a ICMP host unreachable is replied, if it took more than a normal RTT, it means the gateway really tried to reach the machine on the local ethernet but its ARP requests faced a timeout, while an immediate response indicates a filter...
   
 
====UDP====
  
====UDP====

Revision as of 21:09, 24 March 2008

Intro

Well a large subject...
You'll not find a howto here, more a checklist.
So why such a page?
Because I'm not doing pentests that often so when it happens, it's a bit unstructured.
Because I'm reading MISC HS 1 (in french) and I want to make some scrapbooking.
So I'll try to write down anything I do on that matter since now, starting with this HS1 and laying down everything I'm thinking about given my past experiences...
Note that a pentest doesn't imply going through *all* the steps described here, it depends what is the starting point, the surface of attack, the primary target, etc (looking on Google will not (better not!!) help you if you're assessing an internal network from inside)

Logging

  • Write down what we've found, how and when
  • Consider just writing what you did no matter what you found, especially when it's about grabbing bits after bits on various search engines, you don't want to redo several times the same query or to forget about trying this new juicy bit in one of your favorite search engines ;-)
  • You can end up with quite a lot of infos, especially e.g. when pentesting as an insider...
    • A (protected) wiki page sounds nice but confidentiality requires sometimes stronger measures such as a local encrypted deposit (cf MiscCrypto)
    • The results could be divided into several files:
      • a TRACE, with all the possible infos, too long to be read but you know you can find back your info here
      • a TRACEDIR, for the various tools which generate generous outputs, consider also saving a summary of the juicy bits in your TRACE & REPORT
      • a REPORT, with the most interesting facts, probably divided into results on the target and results as side-effects because you'll never stop just because it's a bit out-of-focus ;-) (I audited the frontdoor as you asked but btw did you know the wall is in paper?)
      • a TODO, with the parts you found that are calling for further investigation, pentesting is a lot about searching a tree and backtracking once you explored one branch as far as you could (technically or logistically if you've a deadline & priorities...)

Collecting information

This section is valid also for other domains than pure pentest, e.g. find a maximum of information on the person who bought a domain name under a pseudo...

website

  • postal address, about us,...
  • robots.txt
  • WayBack machine
    http://web.archive.org/web/*/http://www.example.com from [1]
  • Google cache
    http://209.85.135.104/search?q=cache:http://www.example.com
  • Coralize
    http://www.example.com.nyud.net from [2]
  • traceroute
    • CLI: traceroute / tcptraceroute
    • http://www.dnsstuff.com/tools/tracert.ch?ip=http://www.example.com from [3]
  • Other online DNS tools
  • whois
    • CLI: whois / whois 11.22.33.44 / whois -B 11.22.33.44
    • http://whois.webhosting.info/example.com from [4]
    • http://www.networksolutions.com/whois/results.jsp?domain=example.com from [5]
  • Reverse IP
    • CLI: host / host -t NS / host -t MX / host -t PTR 44.33.22.11.in-addr.arpa
    • Getting all known domains, not just reverse lookup:
      Interesting for co-hosted websites, to find if the same admin is managing other sites... -> whois etc on them
      • http://whois.webhosting.info/11.22.33.44 from [6]
      • http://search.msn.com/results.aspx?q=ip:11.22.33.44 from [7]
      • RIPE whois textual search to see if the contacts have registered other IP ranges
    • Try other IPs of the same range
  • Subdomains
    • http://searchdns.netcraft.com/?host=*.example.com from [8]
    • Google: site:example.com -inurl:www.example.com
    • cf also below in DNS section

Search engines

  • Big list of the top 100 alternative search engines, see also [9]
  • Alexa: traffic ranking & other infos
  • Google + site: / inurl: / intext: / filetype: / -polluting_keyword / &num=100 / etc
    • wget / lynx -dump & awk / sed / grep
    • combined: (filetype:xls | filetype:doc | filetype:pdf) & check metadata of docs as well
    • cf Google FAQ about supported filetypes
  • Example requests to find emails:
    • lynx -dump "http://www.google.com/search?q=site:example.com+intext:@example.com&num=100" |\
      sed -n 's/@example.com/& /p' | grep -o -e '[.[:alnum:]]\+@example.com' | sort -u
    • site:example.com intext:"@example.com"
    • site:example.com intext:"mailto:"
    • site:example.com "Internal Server Error"
    • site:example.com (filetype:xls | filetype:doc | filetype:txt) mail
    • site:example.com filetype:csv mail address
    • site:example.com filetype:mdb inurl:email
    • site:example.com intitle:index.of inbox dbx
    • site:example.com filetype:wab wab
    • site:example.com filetype:reg reg intext:"internet account manager"
    • site:example.com filetype:pst inurl:"outlook.pst"

Finance

People

Other key people

Misc resources

Mapping the network

DNS

From the few domain names we got during the collect of informations, get their IP 

host www.example.com

Then query whois to know the full IP range and its owner 

whois [-B] 11.22.33.44

We get also the handler "nic-hdl" which can be used in turn to see if other ranges are administred by the same people: 

whois -i pn <nic-hdl>

We can brute-force a reverse-lookup on the IP range to see if there are other relevant domain names: 

for ((i=1;i!=255;i++)); do dig -x 11.22.33.$i|\
   grep -v '^;'|\
   awk '/PTR/{sub(/\.$/,"",$5);print $5}';done

For each identified domain name, see what say the TLDs: 

dig NS com
dig NS example.com @a.gtld-servers.net.

Cross-check with the whois results 

whois example.com

We can try a zone transfer on the target NS, who knows, maybe one will allow it... 

dig @<authoritative_dns_server> example.com axfr

This is also to be tested on subdomains as well...

If no transfer was possible we can try a dictionary approach: 

for i in ns ns0 ns1 mx mx0 gw gw0 gw-0 db data \
         www www0 mail exchange ftp dialup ecommerce \
         forum smtp smtphost cvs vpn lotus webmail \
         websphere private priv8 pop pop3 imap proxy secret; do 
   host $i.example.com
done 2>/dev/null

See also txdns for automating even more aggressive scans

Scans

TCP

nmap FQDN_or_IP/range...
     -PN: skip ping
     -sS/sT/sA/sW/sM: TCP SYN/Connect()/ACK/Window/Maimon scans
     -sN/sF/sX: TCP Null, FIN, and Xmas scans
     -p 111-222: port range
     -sV: Probe open ports to determine service/version info
     -O: Enable OS detection (needs to be root)
     -T[0-5]: Set timing template (higher is faster)
     -A: Enables OS detection and Version detection, Script scanning and Traceroute
etc. see man page

Example: massive SYN scan on all TCP ports: 

nmap -sS -PN -A -oA scan_result 11.22.33.44/24 -p 1-65535

It can help to set the source port to 20 (ftp-data) to avoid some filters as well as to try FIN or XMAS scans

Example: strange response on port 443? Maybe skype... yes! 

nmap --script=skype_v2-version.nse 192.168.0.1
Starting Nmap 4.53 ( http://insecure.org ) at 2008-03-24 20:30 CET
Interesting ports on 192.168.0.1:
 [...]
443/tcp open  skype2

Subtilities: when we get a TCP Reset, compare the TTL with a TCP SYN-ACK to see if it comes from the target or a previous filtering gateway...
And when a ICMP host unreachable is replied, if it took more than a normal RTT, it means the gateway really tried to reach the machine on the local ethernet but its ARP requests faced a timeout, while an immediate response indicates a filter...

UDP

TCP ports reply to SYN with SYN ACK if open but UDP ports usually don't reply unless no service is running or unless we talk to the (unknown) application. Here nmap will reply open|filtered when it doesn't get an answer: 

# nmap -sU 11.22.33.44

Combining with -sV can help detecting the underneath application (but it's much slower)

Using UDP source ports 53, 67, 68, 69 or 123 may help bypassing some firewalls.

Example to scan for DNS servers with scapy: 

# scapy
Welcome to Scapy (v1.1.1 / -)
>>> res,unans = sr(IP(dst="192.168.0.1/24")/UDP()/DNS(qd=DNSQR(qname="www.google.com")))
[...]
>>> res.show()
0000 IP / UDP / DNS Qry "www.google.com"  ==> IP / UDP / DNS Ans "www.l.google.com."

See also unicorn for other scans with applicative payload

RPC

If TCP/UDP port 111 is open, we can query the portmapper: 

$ rpcinfo -p 11.22.33.44

TODO

  • snmp
  • Wi-Fi
    • kismet
    • detecting quickly the rogue APs via ARP replay & sniffing the internal network at same time, etc
    • breaking WEP, WPA
    • admin access on the APs
Retrieved from "https://wiki.yobi.be/index.php?title=Pentest&oldid=4052"