Grey bar Blue bar
Share this:

Thu, 7 Jul 2011

House of Cards

In light of recent mass hacks (HBGary, Sony, Nintendo, etc) one would have thought that collectively, companies would take notice and at least be slightly more aware of the potential implications vulnerabilities in public-facing services could have.

The problem appears to be that these hacks, and indeed hackers, aren't that technically superior and more often than not, take advantage of simple flaws. Some flaws, like SQL injection, provide so much access on their own that a fairly grim attack scenario can be painted. However, often attackers don't require such extravagant flaws to gain access. Chained attacks utilising "low risk" attacks can be far more deadly than a single flaw.

We had an interesting scenario recently which demonstrated this. This is one example of how we use these minor flaws to gain access, and also show how the house of cards can fall quite spectacularly when basic security principles are not adhered to. We were on a fairly bread and butter security assessment; perform an analysis of the target (a large multinational) and determine where their weaknesses were from an unauthenticated perspective. Increasingly, we advise against unauthenticated assessments as we feel we can offer more value when you assume the shell is already cracked, but this was a special case.

The web application was good; it soon became clear that the developers had followed guidelines for the development of secure applications and ensured that common attacks were indeed handled in a suitable manner. What they didn't do, however, was apply a stringent hardening process to the server itself, and as the platitude goes "security is only as good as the weakest link."

  1. First blood was nothing more than a simple directory indexing misconfiguration that allowed our analysts to browse the directories unauthenticated. Within these, files containing sensitive information such as usernames and passwords and internal IP addressing schemes were uncovered.
  2. Next, a popular administrative package was found with the administrator username pre-populated and after a very brief brute-force attempt, a weak password was discovered. This gave the analyst complete administrative access to one of the minor portals.
  3. Inside was a well-organised list of servers, user names, passwords and comments about each service and server. With minimal effort, a menu of pwnage-possibilities were presented. The assessment was immediately stopped and a conference call arranged with the security team at the client to inform them of the situation. A detailed email (crypted) was sent to the team that showed the path of attack and end result.
What happened next was nothing short of unbelievable.

The analyst had already obtained all administrative user names and passwords (stored in a database with no protection at all) and had logged into a number to confirm access. My email, now forwarded in the clear, was sent to all involved with a stern "fix it". Since we had access to the mailboxes, we saw an admin send the reply: "..have changed the password. Ask them to check if the password is strong now, there's no way they can get in now."

Yes, the password was indeed strong and certainly constructed in a recommended manner, but the administrator's account was already compromised and we were monitoring communications. This wasn't an appropriate response, it's a bit like using AV to clean a virus from a box, post-infection, instead of rebuilding it. Some data mining through multiple unencrypted mailboxes provided numerous credentials for other servers inside the network. We could pivot through the internal network to our hearts content, while monitoring their comms to make sure our supply line wasn't under threat.

Takeaway I: Once an attacker is inside the perimeter, trying to control intruder access at the perimeter is a game you've already lost. i.e. Blocking the path in, doesn't mean you've blocked the paths in use.

Starting with a simple directory listing flaw, one that Nessus rates as a "low" risk, the house of cards fell at an alarming rate. Security isn't about looking only at the high risks, because attackers won't limit themselves the same way.

Tue, 17 May 2011

Hacking by Numbers: Bootcamp Edition

Salut à tous,

It's that time of the year again and like every year, we'll once again be running our ever-popular "BOOTCAMP EDITION" at the BlackHat Briefings in Las Vegas this July-August. This course is part of our established Hacking by Numbers series. BUT, this year, only the name remains the same. We are slaving away at making this course cutting edge, providing you with a hands-on hacking experience on the latest operating systems, application frameworks and programming languages utilizing the latest tools and techniques. Gone are the days of IIS 5.0, Windows XP and we truly understand that [ed: for Bootcamp, maybe... Combat certainly contains an OS older than Win95].

SensePost's Bootcamp edition will provide you with two days of insight into the hacking world. The course is designed to keep a balance between theoretical knowledge & practical experience. Anyone can read a whitepaper about SQL Injection but unless you've exploited it against a real-world application and owned it completely, it all tastes too bland. The Bootcamp spices up the pwning experience.

The training course starts with basics of hacking, the hacker mindset & methodology and quickly moves on to practicalities of modern hacking attacks. Immediately after brainstorming a security concept, the students are placed in different attacker scenarios which have handy pracsheets to guide you (but not answer sheets to spoonfeed). Competition is good and hence we have a few "capture the flag" practicals that'll provoke you to race against each other to grab that surprise gift.

Our trainers are experienced, patient and well groomed. Having a good sense of humor is a requirement here @SensePost, so you don't have to worry about falling asleep.

So, if you're looking to explore the world of hacking or move from newbie to competent in a great environment, remember:

Course Name: Hacking By Numbers: Bootcamp Edition
Venue: BlackHat Briefings, Caesars Palace Las Vegas, NV
Dates: July 30-31 & August 1-2 2011
Sign up here.

See you there!!!

Wed, 27 Oct 2010

Analysis of a UDP worm


From time to time I like to delve into malware analysis as a pastime and post interesting examples, and recently we received a malware sample that had a low-detection rate. Anti-Virus coverage was 15/43 (35.7%) based on a report and Norman sandbox did not detect any suspicious activity as shown in the report below:

norman sandbox report

Norman sandbox report did not show any registry or network activity. This might be due to the use of virtual CPU or sandbox bypass techniques by the malware. Sunbelt sandbox was down at the time of the analysis.

Dynamic analysis indicated that the malware copies itself to the "application data" directory of the current logged-on user and achieves automatic startup by adding the following registry entry:

  • key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Taskman
  • Value: %AppData%\ygmdrm.exe
It then starts communicating via UDP with the following C&C servers on port number 14000:
The UDP traffic was scrambled and had the following sequence:

Code analysis of the malware resulted in the following findings:

Virtual CPU bypass

Anti-virus programs achieve heuristic detection of unknown malware code by parsing the binary code inside a virtual CPU to detect suspicious pattern (packers, encryptors, etc) and OS activities. Most modern AVs are able to detect and skip "code traps" designed to evade detection, such as time delays, intentional loops and unsupported CPU instructions. However, based on the AV coverage report this malware was able to evade huristic detection in a number of AV products by causing indirect execution delays through crafted calls to GDI functions as shown in the following API call log:

Code injection

The actual malware code is launched after evasive GDI calls. A page of memory is allocated using VirtualAlloc API, 1760 bytes are copied to the newly allocated area and the control is passed to this code with the "call eax" insturction as shown in the following code anippet:
The second stage searches for explorer.exe process and injects its code into it using CreateRemoteThread technique.

Network communications

The first 5 UDP packets were found to be connect request packets (starting with 0x18 command code) and sequence number exchange. The 6th packet with data size of 269 bytes seems interesting and could contain bot commands:

The decryption function was found at offset 0x58be of the second code stage :

The decryption algorithm can be presented by the following formula:

D(buff[n])=buff[n] XOR (buff[n-1]*pow(2,(n-1 AND 3)) where n values range from 1 to data_size-1.

The decrypted buffer contents are not completely readable and contain some metadata inserted at various positions. This indicates that the buffer is also compressed using a byte level compression algorithm. Further debugging reveals a decompression function at offset 0x1118 and decompressed command content is shown in the figure below:

The command instructs the bot to change the startup home page of the victim's browser to "" for a possible SEO campaign.

Other features

Analysis of the text strings in the second stage code indicates that the malware has other capabilities such as:
  1. USB drive infector (via autorun.inf)
  2. Download and execute
  3. Remote Firefox cookie dump
This is cause for concern and warrants a a high risk rating, as opposed to the "low risk" in provided in's report.


Apart from signatures, it's still pretty easy to write malware to bypass A/V heuristic checks, as the GDI calls in this sample showed.

Wed, 31 Mar 2010

'Scraping' our time servers

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 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 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 which we used for this post. All except 3 or so allow the monlist command. Using Maltego we added all the servers from 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 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

Sat, 25 Apr 2009

Virtualization as an answer to backward compatability?

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??)