Have a keen interest on scanning over 12000 IP's a week for vulnerabilities? Excited about the thought of assessing over 100 web applications for common vulnerabilities? If so, an exciting, as well as demanding, position has become available within the Managed Vulnerability Scanning (MVS) team at SensePost.

Job Title: Vulnerability Management Analyst

Salary Range: Industry standard, commensurate with experience

Location: Johannesburg/Pretoria, South Africa

We are looking for a talented person to join our MVS team to help manage the technology that makes up our Broadview suite and, more importantly, finding vulnerabilities, interpreting the results and manually verifying them. We are after talented people with a broad skill set to join our growing team of consultants. Our BroadView suite of products consists of our extensive vulnerability scanning engine, which looks at both the network-layer and the application layer, as well as our extensive DNS footprinting technologies.

The role of the Vulnerability Management Analyst will possess the following skills:

• Be able to multitask and meet client deadlines. We want a person that thinks 'I can do that!'


• Possess excellent written and oral communication skills. Being able to understand a vulnerability and explain it to business leaders is a must.


• A working knowledge of enterprise vulnerability management products and remedial work flow


• A broad knowledge of most common enterprise technologies and operating systems


• A passion for security and technology

Some additional conditions:

• A post graduate degree or infosec certification would be beneficial, however, showing us you have the passion and skills also helps


• This job requires some after-hours and weekend commitments (we try to keep this to a minimum)


• Bonus points for knowledge of sed, awk and python, ok even ruby.


• PCI-QSA is desired but not required

Impress us with your skills by sending an email to jobs@sensepost.com and lets take it from there.

SensePost is an equal opportunity partner.

On a recent engagement, we were tasked with trying to gain access to the network via a phishing attack (specifically phishing only). In preparation for the attack, I wanted to see what software they were running, to see if Vlad and I could target them in a more intelligent fashion. As this technique worked well, I thought this was a neat trick worth sharing.

First off the approach was to perform some footprinting to see if I could find their likely Internet breakout. While I found the likely range (it had their mail server in it) I couldn't find the exact IP they were being NAT'ed to. Not wanting to stop there, I tried out Vlad's Skype IP disclosure trick, which worked like a charm. What's cool about this approach is that it gives you both the internal and external IP of the user (so you can confirm they are connected to their internal network if you have another internal IP leak). You don't even need to be "friends", you can just search for people who list the company in their details, or do some more advanced OSINT to find Skype IDs of employees.

Once I had that IP, I went on a hunt for web logs that had been indexed by a search engine, that contained hits from that IP. My thinking was that I run into indexed Apache or IIS logs fairly often when googling for IPs or the like, so maybe some of these contained the external NAT IP of the target organisation. It took a fair bit of search term fiddling, but in the end I found 14 unique hits from their organisation semi-complete with User Agent information (some were partially obscured).

This provided me with the following stats:

Operating System Win XP 8 Win 7 32 3 Win 7 64 3

Browser IE 8 8 IE 6 3 IE 7 1 IE 9 1

Combination Win 7 IE 8 4 Win XP IE 8 4 Win XP IE 6 3 Win 7 IE 9 1 Win XP IE 7 1

Granted, it could be that the same machine was present in multiple logs and the stats are skewed, but they are a large enough organisation that I thought the chances were low, especially as most of the sites who's logs I found were pretty niche. As validation of these results, later, once we had penetrated through to the internal network, it was clear that they had a big user base in regional offices still on Win XP and IE6, and a big user base at corporate offices who had been migrated to Windows 7 with IE8.

Unfortunately, the UserAgent didn't make it clear whether they had Acrobat or Java or what versions they were at. We thought of using some JavaScript to do such detection, but were under a time constraint, and went with trying to pwn them instead, with the thinking that if it doesn't work, we could retarget and at least get some debugging information.

Anecdotally, and to give the story an ending, it turned out that BlackHole and Metasploit's Browser AutoPwn were a bust, even our customised stuff got nailed by Forefront when the stager tried to inject it's payload at runtime, but an internal tool we use for launching modified meterpreter payloads worked like a charm (although, periodically died on Win7 64bit, so I'd recommend using reverse-http, you can restart sessions, and firing up a backup session to restart the other with).

We were asked to contribute an article to PenTest magazine, and chose to write up an introductory how-to on footprinting. We've republished it here for those interested.

Network foot printing is, perhaps, the first active step in the reconnaissance phase of an external network security engagement. This phase is often highly automated with little human interaction as the techniques appear, at first glance, to be easily applied in a general fashion across a broad range of targets. As a security analyst, footprinting is also one of the most enjoyable parts of my job as I attempt to outperform the automatons; it is all about finding that one target that everybody forgot about or did not even know they had, that one old IIS 5 webserver that is not used, but not powered off.

With this article I am going to share some of the steps, tips and tricks that pentesters and hackers alike use when starting on a engagement.

Approach

As with most things in life having a good approach to a problem will yield better results and overtime as your approach is refined you will consume less time while getting better results. By following a methodology, your footprinting will become more repeatable and thus reliable. A basic footprining methodology covers reconnaissance, DNS mining, various information services (e.g. whois, Robtex, routes), network registration information and active steps such as SSL host enumeration.

While the temptation exists to merely feed a domain name into a tool or script and take the output as your completed footprint, this will not yield a passable footprint for two reasons. Firstly, a single tool will not have access to all the disparate information sources that one should consult, and secondly the footprinting process is inherently iterative and continuous. A footprint is almost never complete; instead, a fork of the footprint data provides the best current view of the target, but the information could change tomorrow as new sites are brought online, or old sites are taken offline. As a new piece of data is found that could expand the footprint, a new iteration of the footprinting process triggers with that datum as the seed, and the results are combined with all discovered information.

Know your target

The very first thing to do is to get to know your target organisation. What they do, who they do it for, who does it for them, where they do it from - both online and in the kinetic world, what community or charity work they are involved in. This will give you an insight into what type of network/infrastructure you can expect. Reading public announcements, financial reports and any other documents published on or by the organisation might also yield interesting results. Any organisation that must publish regular reports (e.g. listed companies), provide a treasure trove of information for understanding the target's core business units, corporate hierarchy and lines of business. All these become very useful when selecting targets.

Dumpster diving, if you are up for it and have physical access to the target, means sifting through trash to get useful information, but in recent times social media can provide us with even more. Sites like LinkedIn, Facebook and Twitter can provide you with lists of employees and projects that the organisation is involved with and perhaps even information about third party products and suppliers that are in use.

One should even keep an eye out for evidence of previous breaches or loss of credentials. It has become common place for hackers to post information about security breaches on sites like pastebin.com. The most likely evidence would be credentials in the form of corporate emails and passwords being reused on unrelated sites that are hacked, and have their user databases uploaded. In addition, developers use sites like Pastebin to share code, ideas and patches, and if you are lucky you might just find a little snippet of code sitting out in the open on Pastebin, that will give you the edge.

DNS

“The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network.” — WikiPedia

In a nutshell, DNS is used to convert computer names to their numeric addresses.

Start by enumerating every possible domain owned by the target. This is where the information from the initial reconnaissance phase comes in handy, as the target's website will likely point to external domains of interest and also help you guess at possible names. With a list of most discovered domains in hand, move on to a TLD (Top level domain) expand. TLDs are the highest level subdomains in DNS; .com, .net, .za, .mobi are all examples of TLDs (The Mozilla Organization maintains a list of TLDs https://wiki.mozilla.org/TLD_List).

In the next step, we take a discovered discovered domain and check to see if there are any other domains with the same name, but with a different TLD. For example, if the target has the domain victim.com, test whether the domains victim.net, victim.info, victim.org etc. exist and if they exist check to see if they are owned by our target organization. To determine whether a domain exists or not, one should examine the SOA (start of authority) DNS record for the domain. Using commands like nslookup under Microsoft Windows or the dig/host commands under most of the *nix family will reveal SOA records.

Using dig, “dig zonetransfer.me soa”.

?

Figure 1: Using dig to get the SOA (Start of authority) record for a domain

If, by verifying the SOA, it is confirmed that the domain exists, then the next step is to track down who it belongs to. At this point the whois service is called upon. ‘Whois' is simply a registry that contains the information of the owner of a domain. Note that it is not entirely reliable and certainly not consistent. The following very simple query “whois zonetransfer.me” provides us with the owner of the domain “zonetransfer.me” detail.

Figure 2: Using whois to get the domain owner detail

After finding domains, running them through a TLD expansion and verifying their whois information, it is time to track down hosts. First we need to get the NS or name server records for the domains. Again using “dig zonetransfer.me ns” returns a list of all the name servers used by this domain. In many cases the name server will not be part of the target's network and is often out-of-scope, but they will still be used in the next step.

DNS yields much interesting information, but the default methods for extracting information from foreign servers effectively relies on a brute force. However, DNS supports a trick where all DNS information for a zone can be downloaded if the server allows it, and this is called a “zone transfer”. When enabled, they are extremely useful as they negate the need for guessing or brute-forcing; sadly they are commonly disabled. Still, given the usefulness of zone transfers it is always worth testing for. Zone transfers should be performed against all the name servers that are specified in the NS records of a domain as the data contained in each name server should be the same, but the security configuration might be different. Using dig, the following command will attempt to perform a zone transfer “dig axfr @ns12.zoneedit.com zonetransfer.me”

Figure 3: Performing a zone transfer using dig

As mentioned previously, zone transfers are not that common. When we cannot download the zone file, there are a couple of other tricks that might work. One is to brute force or guess host names: by using a long list of common hostnames one can test for names such as “fw.victim.com”, “intranet.victim.com”, “mail.victim.com” and so on. The names can be commonly seen hostnames, generated names when computers are assigned numeric or algorithmic names, or from sets of related names such as characters from a book series. When brute forcing DNS, be sure to check the following DNS records: CNAME, A and AAAA. Again this is easy using a tool like dig. “dig www.google.com a” produces the DNS configuration for www.google.com, note that the hostname www.google.com actually has multiple DNS entries, one CNAME record, and multiple A records. Looking at the IP addresses it is clear that there are several different hosts (2 in the screenshot below).

Figure 4: Using dig to get the a record for a host entry

Doing this manually seems easy and quick, (and it is) but if we want to brute force or guess many host names, then this will take too long. Of course, it is easy enough to script these commands to automate the process; however there are existing tools written specifically for this purpose. One of the most popular tools, Fierce, is a perl script written by RSnake (http://ha.ckers.org/fierce/), which is easy to use and has many useful functions. Additionally, there are tools like Paterva's Maltego and SensePost's Yeti (a tool I wrote) which provide graphical tools for this purpose.

If we happen to have a list of IP addresses or IP netblocks of the target, then a further DNS trick is to convert the addresses into hostnames using reverse lookups to get the PTR record entry. This is useful since reverse records are easily brute forced in IPv4. Bear in mind that DNS does not require a PTR record (reverse entry) or that entries in the reverse zone must match entries in the forward zone. But the result can give you an idea of whether the host is a shared host, owned and hosted by the company or just remote hosted.

To test once more, try using dig, “dig 104.66.194.173.in-addr.arpa ptr”. While this too can be easily automated, the previously mentioned tools will also handle PTR records.

Search engines:

DNS interrogation and mining forms the bulk foot printing, but thanks to modern search engines like Google and Bing, finding targets has become much easier.

Apart from the normal searching for your target, as you would do in your initial phase, you can actually use the data that you discovered during the course of the DNS mining to try and get further information using search engines. Bing from Microsoft provides us with two really useful search operators: “ip:” and “site:”. When using the “ip:” operator, Bing will return a list of hosts that it has indexed that resolve to the IP address that you have specified. Alternatively the “site:” operator when used with a domain name, will return a list of host names that have been indexed by the search engine and belong to the domain specified. Quick and easy, and Bing also provides you with a very simple free API that you can use to automate these searches.

Address mapping

All this fuss with DNS is important, but it is only useful insofar as they lead us to addresses. The next step is discovering where the target exists within the IP address space. Luckily useful tools and resources exist to help us uncover these ranges, by automating a combination of manual techniques such as whois querying, traceroute and netblock calculators. In the previous section the whois tool was used to get the domain owner information. The same tool can be used to discover the ownership/assignment details of a specific IP address. Let's take www.facebook.com; one of the IP addresses that it resolves to is 69.63.190.10. “whois 69.63.190.10” produces the following output.

Figure 5: Getting the netblock and owner using whois

From the whois output we get really useful information. First is a netblock range 69.63.176.0-69.63.190.255 as well as the owner of this net block, namely Facebook, Inc. In this case we are lucky and the netblock is registered to facebook, but often you will only get the network service provider to which the netblock is allocated to. In that case, you will have to query the service provider in order to gain more info about the specific netblock. Online resources can also be very useful, for example ARIN (American Registry for Internet Numbers) or any of the other regional registries (RIPE, AfriNIC, APNIC and LACNIC) provides a reverse whois search interface where one can search for organisation names and other terms, even performing wild card searches. Giving Facebook a second look, we try a search on the reverse whois interface found at http://whois.arin.net/ with the term “facebook”, and get a list of five additional network ranges.

Figure 6: Search results for ARIN reverse whois

SSL Certificates

Lastly, we turn to SSL. SSL may be more familiar as a “protection” against nasty eavesdroppers and men-in-the-middle, but it is useful for footprinters. How? It is really simple actually, one of the security checks performed by browsers when deciding on the validity of a SSL certificate is whether the Common Name contained in the certificate matches the DNS name of the host requested from the browser. How does this help? Say a list of IP addresses has been produced; the next step would be to perform a reverse lookup of all these addresses. However, if no reverse entry is present and Bing has no record of the IP, then some creativity is called for. If an HTTPS website is hosted on that address then simply browse to that IP address and, when presented with the invalid certificate error, message, look for the “real” host name.

Figure 7: Firefox reporting the common name contained in a SSL certificate for a host

Again, this is something that is easily automated, so we have included a module in Yeti to actually do this for you.

Conclusion

Foot printing might at first glance appear to be simple and mundane, but the more you do it, the more you will realise that very few organisations have a handle on exactly what they have and what they present to the Internet. As the Internet and networks evolve so will the way companies and organisations use it, and so will their footprint. A year-old footprint could be hopelessly outdated, and ongoing footprinting helps organisations maintain a current view of their threat landscape.

With the ongoing move away from local infrastructure to hosted infrastructure, the footprint expands, spreads and grows, and so will our quest to find as much as possible.

After several months of dedicated ... uh dedication, our new network footprinting tool is being made available to the masses.

It's called Yeti and it is a cross-platform, Java application. It's predecessor, BidiBlah, was only available on Windows platforms and hopefully with Yeti we can now offer Internet intelligence gathering to everyone.

So what does Yeti do:

• Top level domain expansion (tld expand)
• Forward lookups (mx,ns,a,cname and zone transfers)
• Reverse lookups (ptr records)
• Cert Extraction (getting the common name, and domain from ssl certificates)
• Bing IP/Site searches
• Report exports to xls format

We invite you all to visit the Yeti community blog and to participate in either testing the tool or just to add comments. Usage instructions can be found on the spyeti blogspot.

In particular we would like to point you to a recent post where we explain our reasoning for continued investment in developing and maintaining footprinting technology.

With the blog, we would like to muster up more of a community feel to our software, and create movement in the footprinting field. Recent successes in the field of Internet intelligence is compelling evidence that this field is untapped.

Yeti is released as Freeware without access to the source.

The plan is to in future maintain both a community freeware edition and a commercial edition.

The intertubes have been humming lately around a certain NTP feature to gather lists of NTP servers' clients and it naturally grabbed our attention. The humming was started by HD Moore recently where he revealed that it is possible to query NTP servers to get lists of addresses and using the information for fun and profit. He also mentioned that he will be releasing a paper describing all this and how he can create a sizable DDOS using NTP, without giving too much detail about it.

Some quick research into NTP(from ww.ntp.org) revealed that NTP servers allow you to perform a bunch of commands that are secondary to time keeping. You can easily play with these using the ntpdc client program eg. 'ntpdc target.ntp.server'. Some of these commands include:

• listpeers - List the peers(NTP servers) for the time server
• showpeer - Give time keeping info about a specific peer time server
• peers - List peers and some basic time keeping info
• sysstats - Info regarding ntp daemon itself
• many more...

A lesser known command, that we will be focusing on, is called 'monlist' which via the ntpdc program's help is described as 'display data the server's monitor routines have collected'. Not what one might expect from a diagnostic function which will provide you with the last 600 addresses of clients who accessed the ntp server. Finding this function was relatively quick to do after we started analysing the source code available from www.ntp.org. Later on we discovered that Moore actually released his metasploit plugin for it available here

Playing around: So, this command allows you to get the last 600 IPs that make requests to a NTP server (well, sortof). The ntpdc program is limited to 400 IPs and because of that limitation we whipped up a util for everyone to play with and modify which is attached. The information gathered using this method (as far as we can see) is not worth much except for being interesting. And very interesting in deed as we have noted towards the end of this post. We proceeded to examine the South African time servers since we depend on them and since we are always interested in the South African Internet and security landscape. One can get a list of (some) South African NTP servers at time.org.za which we used for this post. All except 3 or so allow the monlist command. Using Maltego we added all the servers from time.org.za and ran the script as a local transform on them which produced these:

These two images are different views of the NTP servers and their clients from one run. In the first image you can clearly see each NTP server(centers of those circles) with its unique clients forming a circle around it. The clients that query from more than one of the servers you can see as the mush in the center of the image. The second image shows which clients use more than one ntp server in a slightly more visible manner. The larger the sphere the more servers the clients get their time from. One can also see which NTP servers are more secluded. As Moore mentioned, NTP servers will divulge even their internal network clients. This is also the case with some major NTP servers in South Africa. Some are showing tens of private IPs which for some individuals/companies may be a serious information leak.

Have data, what now? The most immediate application of this method will probably be more revealing footprinting exercises. For example:

• Certain devices are pre-configured to use a certain ntp server, which one can query to find all those devices
• Certain products are pre-configured in a similar fashion, eg. Ubuntu
• NTP servers could leak internal network details and possible one of their other addresses(IPV6 or another network if multihomed).
• IPs that will never show up in customary rDNS and fDNS queries may now suddenly pop up

Bandwidth implications: So we know that a busy server's ‘client cache' will have 600 entries and wireshark tells us that each result packet is 468 bytes (IP+UDP+NTP). Each result packet only contains 6 results so one is looking at +- 45kbytes of data for each request packet of 220 bytes (IP+UDP+NTP). The NTP server will just dump the data so you will need a sizeable down-link to catch all 100 UDP packets. Moore mentioned that he has developed a technique to create a 30 gigabit/sec DDOS which is not easy to defend against. Our bet is that spoofing the source address of the monlist request may be a way for creating a DDOS attack.

Have tool, will play nicely Attached are the monlist query script written in Python and the Maltego graph used in the example above. Just run ‘python ntp_monlist.py target_server' and wait 7-10 seconds(With default timeout and tries). If you dont receive close to 600 addresses then either your connection is too slow or the target server is not busy/popular enough. The script can act as a local transform for Maltego by changing the OUTPUT_FORMAT variable close to the top. You will need to set the speed/accuracy <---> #results slider to the far right for all results. If anyone has an idea on how to use this info better please drop a comment below.

Files: ntp_monlist za_time_servers