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

Part of the problem Microsoft bumped into with Vista, was hordes of people who had grown too attached to XP.. It seems they learnt their lesson (and found a cheap way to maintain backward compatability without having to keep legacy code forever). [XP with SP3 as a virtual-pc virtual machine within Windows 7]

We thought we had problems classifying client side bugs that required user intervention (remote? local?), what happens when a remote in XP-SP3 allows one to execute code in the Windows7 machine through local VM breakout? (indeed a new acronym is needed in anticipation: RAXPLVMB??)

We've been busying ourselves with the PCI DSS in one way or another for more than a year now here at SensePost. Its been a frustrating exercise of mixed messages, politics, tokenism, mixed in with a healthy dose of mixed feelings about what the standard offers and whether that's good for anyone at all. Now, finally, we're accredited to do this that and the other under the standard so we feel its time to start speaking our minds on the subject.

First stop: Las Vegas.

We've agreed with Black Hat to present a course called 'Hacking By Numbers - PCI Edition' at this year's show. As you know the PCI DSS is having a huge impact on the security industry. One effect its had is to make annual penetration tests mandatory in some segments and thereby spawn a whole new class of off-the-shelf penetration testers. As SensePost now has both the ASV and QSA accreditations our idea was to offer a pentesting course for people performing tests for the purpose of PCI certification. The approach would be present a *technical* course for beginner penetration testers that focuses on the approach and priorities required by the PCI standard. We want to add some theory about the standard itself and where/how penetration testing fits in.

Beyond just teaching what a 'compliant' penetration test is, this course will focus on teaching real-world Internet attacks focused on really compromising cardholder information. We've even given the course a byline: "Hacking By Numbers PCI Edition - Hack like you mean it".

/charl

aka.. Someone put the hurtski on Kaspersky..

The Twitters (via XSSniper and others) and the Interwebs were ablaze with news on a SQL Injection vulnerability that was exploited on AV vendor Kaspersky's site. Detail of the attack can be found here.

It's interesting that SQL Injection (though as old as the proverbial hills) is still such a major issue. In fact, I have it on good authority that the bulk of PCI-related compromises are still as a result of SQL Injection...

In our own work, we see this all over the show.

Also interesting is the fact that the DB in use by Kaspersky is MySQL - so much for the "I don't use MSSQL, I have x database with magical pixie dust SQL Injection protection - what me worry?" argument...

Once again, security one-oh-one...if you aren't *effectively* validating user input, you're going to get bitten some time...

/nick

ED* From the shameless self promotion department:

haroon and Marco have just finished their chapters in an upcoming book dedicated to SQL Injection. We will post more details here when its available. (the book aims to give SQL Injection thorough coverage from OR 1=1 to some of the insanity demo'd at BlackHat last year..)

The recent widespread carnage caused by the Conficker worm is astounding, but is also comforting, in a strange way.

It has been a good few years since the world saw a worm outbreak of this magnitude. Indeed, since the Code Red, Slammer and Blaster days, things have been fairly quiet on the Interwebs front.

As a community, it seems we very quickly forgot the pains caused by these collective strains of evil. Many people proclaimed the end of issues of that particular bent, whether it be as a result of prolific post-worm hastily induced reaction buying of preventative technologies and their relatives, or whether more faith was placed in software vendors preventing easily "wormable" holes in their software.

Needless to say, Conficker turned those theories a little on their head. Wikipedia notes on the impact of the worm gleaned from various sources seem to say it all:

-snip-

The New York Times reported that Conficker had infected 9 million PCs by 22 January 2009, while The Guardian estimated 3.5 million infected PCs. By 16 January 2009, antivirus software vendor F-Secure reported that Conficker had infected almost 9 million PCs. As of January 26 2009, Conficker had infected more than 15 million computers, *making it one of the most widespread infections in recent times*.

-snip-

We saw similar turmoil when a large organization in South Africa was hit incredibly hard by this worm, and was struggling to resolve the resulting chaos, even with the assistance of their security software vendors. Thankfully, it all ended happily for them, as the issue was resolved, but it's plain to see where this could go wrong and affect many organizations similarly.

I did mention up front that I found this all to be comforting (granted, this may be a slightly twisted viewpoint, but it really is how I feel about it). The reason I find this comforting is that perhaps as a collective, we needed a fresh wake-up call. They say that complacency kills, and I know that many organizations have become rather complacent of late...

Consider how Conficker works and spreads - missing patches leading to RPC-based buffer overflows in the Microsoft Server Service, brute-force attacks on weak passwords, spreading through file shares...hold on...does this sound at all familiar? Aren't these issues all addressed by basic security best practices 1 oh 1?

Organizations that had adopted reasonably robust internal security measures - hardening and patching policies, internal security assessments, solid internal vulnerability and compliance management solutions - they would have smiled through the Conficker onslaught..

I don't only say this because we play squarely in the assessment and vulnerability management spaces - I say this because the same steps that would have protected against Code Red, Slammer, Blaster and friends, would have protected against Conficker... best practice 1 oh 1..

I guess every now and then, we all need a reminder of just how essential the basics that we all tend to overlook actually are :>

/nick