Wed, 31 Mar 2010

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.

Tue, 30 Mar 2010

Ever since Ron Gula's RiskyBusiness talk #142 about their Nessus philosophy, I decided to come out of the closet and share with our readers the work we do in the vulnerability management field. [Ed: If you don't listen to Risky Business then, as we say in South Africa, eish.] Ron explained that with Nessus they aim to give users a tool that can be used for monitoring and auditing - not enforcing. The "sed quis custodiet ipsos custodes" mantra comes to mind. For 9 years now we have been building two vulnerability management solutions named HackRack (for hosted, external scanning) and BroadView (for internal scanning) and it was especially HackRack that has claimed the limelight. The runt of the litter has always been BroadView, but alas (luckily?), no more.

We decided a while ago to invest our new ideas and technology in BroadView, and when that matured and stabilized, use the new BroadView as a base for new HackRack and HackRack PCI services.

And that process is nicely on track.

I mean, just look at this interface. The Blizzards page will allow BV users to get up to date stats about their environment but also allow them to quickly grasp the actual state of affairs on their network. Blizzards are visual sql queries that display averaged or calculated results of vulnerability scans as well as collected attributes. In the example below, one can quickly appreciate the impact of adding a batch of new machines to a scan, and the resulting impact on the New Issue count blizzard.

We don't see BV as just another vulnerability scanner. Its a data collector of note. It does not just scan,it also collects. From every networked device that is probed, attributes are collected that range from regular basic info such as IP addresses and operating system values, to machines without SMS agents and WebDAV directories on HTTP services.

In the weeks and months to come we will share with you the trial and tribulations to eventually bring to light BroadView v4, Final Release. We will share with you our frustration and jubilations in successfully executing intensity scans on virtualised hardware, how to mine for installed software on OS X and appreciating the amazing reduction in bandwidth utilisation by switching from SOAP to Thrift.

Well, I am off to go watch one our guys participate in a televised panel discussion - and at the same time figuring out if there are any advantages in being able to interface BroadView with our Saeco coffee machine ...

Tue, 16 Mar 2010

This past Thursday we received notice that Boogterman & Partners would be a host company for the CANSA Shavathon 2010 taking place on Friday, 05/03/2010. So when I send out an email to everyone at SensePost, little did I know at the time what a huge thing this would turn into. However I really shouldn't be surprised as this is a typical show of how "We Roll"!

I was challenged (as the only girl in the office) to shave my head for CANSA. Well what can I say, the guys really wanted to see me do this because the enthusiasm was amazing! However more importantly we raised R3000.00 for this worthy cause and I was also able to donate my hair (as it met the length criteria) to make a wig and a R100 also goes to CANSA when they sell it. CANSA Shavathon's goal was to raise R10 million and it would seem they have raised over R19 million so far which is brilliant! Showing how supportive South Africans are in general to this worthy cause which makes me proud to be South African!

So all in all this turned out to be one of the most amazing charity runs I have been involved with and definitely worth sacrificing my hair for! I want to send out a special thank you to all the guys that I work with that donated money to this important cause and also a BIG thank you to the guys that came with to support me and also had their heads shaved!

I am truly honored and proud to work for a company like SensePost and even though I am the only girl in the office I wouldn't want to work any where esle :) Just incase you don't believe us.....here are the pictures.

Tue, 9 Mar 2010

BackupExec agent is often among common services found on the internal pen tests. The agent software stores an encrypted "logon account" password in its backend MS SQL database (LoginAccounts table). These accounts include the "system logon account" which is used to run agent services and an optional number of active directory accounts that are used to access resources over the network. The following scenarios can result in access to encrypted passwords:

2- Access to BackupExec installation directory: A daily MS SQL backup job on BEDB database is run by BackupExec and the resulting backup file is stored as data/bedb.bak file under BackupExec installation directory. The backup file containing encrypted passwords can be restored on another system.

Encrypted passwords are 512 bytes long and the agent software decrypts them using bemsdk.dll file. The following C code can be used by to quickly decrypt the ciphers:

The above code has been tested with BackupExec 10.0.5484 (SP5) and should be working with other versions of BackupExec (Source code for the above program, you'll need a copy of the .dll).