Merry Christmas to all white, gray and blackhats…
As it is always popular to give away homemade christmas packets (perhaps limited to grandparents and parents only), the virtual world shouldn’t be any different. So from all of us to all you… here is our own homemade christmas tree packet.
Merry Christmas!
Annual status report
We’ve finally managed to compile our annual status report for 2008. Much of the information in it have previously been published as entries on our blog. But some of the details regarding what type of tools we’re using and what kind of systems we’re running, and especially perhaps our lessons learned and changes to the organization are all new stuff. As the report unfortunately states, we’ve not been able to get our GDH-2 node operational. This is by no means a technical issue, but rather as a result of limit time and various practicalities. Malicious VoIP, malicious PDFs, SSH brute force attacks, SQL-injection and executables obfuscated as JPEG are some of the highlighted cases in the report.
The complete report can be found here: annual_status_report_2008.txt
Looking at some SQL-injection attacks
By using the techniques described in mkrakvik‘s post, I’ve been looking at the results of quite a few of the different SQL-injection (and XSS attacks) successfully performed against norwegian and danish servers.
The attacks have several common properties:
- injects a javascript to the attacked page
- the script is obfuscated
- the scripts loads several iframes and other scripts
- the end exploits are ActiveX, .swf or .pdf attacks
The javascripts
The javascripts are usually pointing to a russian or chinese server. They are obfuscated in different ways. Some simply use url-encoding of the actual script combined with unescape() and eval(), while others use complex encryption functions including long encrypted strings that are decrypted by shifting parts of the string and combining parts in different ways.
The first script usually loads several different other scripts from servers, often contacted by IP. Many of these servers are probably zombies, and a lot of the servers were no longer serving any scripts (the zombies may have been cleaned out). The attackers were using scripts from several different servers, in case one of their zombies go down. So it’s basically a “hacker cluster” for availability.
End exploits
The end scripts usually contain several different attacks. I’ve seen scripts trying to exploit up to ten different activeX-components, and many of the scripts use both activeX and flash (.swf) attacks.
One of the attacks (gcounter.cn) had two activeX attacks downloading two .exe files, two flash files and one pdf. The first .exe files was detected by 22/36 vendors at virustotal.com. The other four files had a lot lower ratios. One of the flash movies was not detected at all. This attack was also analyzed by Morten Kråkvik, and he created this interesting picture. His full post is available in norwegian here: Malware og drive-by exploits
Another attack (found on among others yahoo-union.cn and www.jmlrmg.com) had six different flash movies for IE and six for firefox, yielding a total of 12 flash movies for different versions of flash. They were on average detected by 3/36 of the antivirus vendors on virustotal. I reuploaded one of the flash files three weeks after the initial upload, and it’s now detected by 13/36 vendors: virustotal analysis
Protecting your browser and your web site users
- Keep your web sites free of SQL-injection and XSS exploits – OWASP has some good resources for SQL-injection and XSS mitigation
- Focus on security during the entire development projects – not just at the end or the beginning
- Allow your developers to take security trainings. Security can only be achieved through collaborative effort – it’s not the responsibility of a single person
- Keep up to date on all web browser, web browser plugin and OS patches.
- Keep your antivirus up to date (some of the exploits I found were “old” and detected by most of the vendors)
- Don’t visit links you get in emails, social networks or on IM without verifying that they are actually from the person they claim to be.
- Consider using the noscript-plugin if you are an advanced firefox user
VoIP attacks are escalating
There has been numerous VoIP attacks from very different sources the latest months. In this article we will go through attacks towards two different companies in Norway. I will explain how they did it and how you can protect yourself against it.
Who was the attackers?
The attackers IP adresses:
- 124.217.230.238
- 124.217.230.225
- 213.130.74.70
- 213.130.74.72
The first two IP adresses belongs to “Piradius” network in Malaysia.
The second two IP addresses belongs to a VoIP company in Bulgaria, www.iconnectbg.net. These people has not been successful with their actions, but they had about 1000 SIP INVITES while trying to get through.
There was also some port scannings on port 5060 from an American IP, so we contacted the firm and it was most likely a break-in on the local servers.
The attackers business models
There seems to have been to way to make money. One way was to directly use it as an outbound gateway. This is quite risky since you have an existing business to protect.
The other way was to sell these minutes to another provider. One company specializing in discovering and making the gateway ready, then selling this access to prepaid phone card providers.
There are several others, like calling expensive numbers in other countries and then charging the terminating fees.
How did they find the VoIP gateways
The Piradius network (or the people hiring place in this network) did their port scanning from 124.217.252.238. First they search just for open ports, port 5060 (UDP and TCP!) and 1720 (h323). If you have a Cisco PSTN gateway, remember that the Cisco gateways can do both SIP UDP/TCP and H323. The first machine tried all different numbers similar to this.525551690000.
Example:
- 00525551690000
- 000=23525551690000
- 00100525551690000
They tried a lot of different variations of this, and after a while they went over to a brute force way, just counting their way upwards
- 26100525551690000
- 26200525551690000
- 26300525551690000
- 26400525551690000
The always used caller ID 5199362832664 on all calls. They probably had an Asterisk on the other phone number, noticing when it rang and which gateway that then had been used.
What was configured wrong?
One of the customers with an Asterisk had included the “outbound” context to the SIP provider within the reach for the inbound context. Calls coming in and there were no matching numbers internally was routed out to the SIP provider. This is such a bad idea…
Another customer had a Cisco gateway. Cisco gateways just routes VoIP traffic the same as IP based on the dial-peers. It was configured properly with dial-peers but not with the correct access lists. The Cisco just needs 1 dial-peer configured to bounce traffic like this.
The motives
These two attacks were directed to get free calling. The calls were going to expensive countries like Cuba and Jamaica. There has been no directly breach on the system with username/passwords to gain access and get information. The objectives were to send free telephony traffic through the unsecured PBXs.
How to protect your VoIP equipment
- Always have a firewall or session border controller (SBC is just a specialized VoIP firewall) between you and the Internet.
- Limit your access to your VoIP servers from the rest of the world
- Do not let inbound contexts in Asterisk have access to outbound.
- Be careful with dial-in features and get a new dial-tone based on a password.
- Update the software regularly.
- Use VPN tunnels to protect the VoIP traffic going over the Internet
- Use SIP TLS and SRTP if possible (we are waiting on hardware manufacturers here as well)
- Shutdown all services on equipment that is not in use. Example H323 on a Cisco gateway used only for SIP
Talk about data analysis
We did a talk about data analysis at the annual ISF conference (IT-sikkerhetsforum). The conference gathered around 200 attendees from all over Norway and was held at the Strømstad Choice hotel in Sweden. The conference has typically been hosted in Norway, but this year it was hosted in our neighbor country and the total number of attendees was record high. It has to be the “tax-free” store at the border, or the Honeynet Project talk?
The slides are available here (in Norwegian).
UPDATE: Slides has been translated to English. English slides here
Analysing malicious PDF documents and shellcode
It’s time for another video-post, and this time we’re going to look at a malicious PDF document attempting to exploit a known vulnerability in the Collab.collectEmailInfo() function. We’re going to show how you can extract the shellcode and perform some static code analysis using tools like HT and IDA Pro.
Click on image to show video (opens in new window)
For references, here are the tools used in the video:
Hope you’ll find it useful! :)
Daemonlogger 1.1
Marty just released version 1.1 of daemonlogger. In addition to a small bug fix, it now includes the missing functionality I wrote about in the previous post; ring buffer activation based on disk utilization. The new option -M takes a percentage value as argument. The value specify the percentage of disk utilization you want before the ring buffer gets activated. Here is an example where old log files are deleted when there is only 2% of free space left:
daemonlogger -i eth0 -d -l /var/log/pcap -S 0 -t 1h -M 98 -r
Get it at: http://www.snort.org/users/roesch/code/daemonlogger-1.1.0.tar.gz
Daemonlogger Patch
I’ve been using Daemonlogger now for some time, and really like this compact yet highly functional packet capture tool from Marty Roesch (mr. Snort himself). It’s libpcap based and has some nice features like log-&-replay, log rotation and ring-buffer. Features that are missing in the tcpdump implementation I used prior to Daemonlogger.
In many situations I like to use the -t option to partition the log files based on time, e.g. -t 1h to get one pcap file each hour (aligned on the hour). Also, I usually create a dedicated disk partition for pcap storage. In these situations I think Daemonlogger doesn’t quite “cut the mustard”. It’s missing an easy way to have it utilize most of the dedicated disk space and rotating the pcap files based on time intervals whilst maintaining an active ring-buffer. Of course, you may use the -s option to rotate based on the size of the log file (in bytes) and also set a count limit with -m. But, as I mentioned, I’m more of a time guy.
This is why I made a small patch to Daemonlogger which implements the missing feature. The added option (-x) lets you specify the amount of free space you want to have on the disk where the pcap files are stored.
daemonlogger -i eth0 -d -l /var/log/pcap -S 0 -t 1h -x 500 -r
In the above example, daemonlogger sniffs on eth0 interface, runs in daemon mode, logs to /var/log/pcap with a max snap length and creates a new file every hour on the hour. When there is less than 500 MiB of free space on the disk device that holds /var/log/pcap, the ring-buffer will activate and delete the oldest file in that directory.
Download file: daemonlogger.honeynor.patch
Disclamer: I’m by no means an experienced C-programmer, so you’re on your own pal if you apply this patch :)
Size Definitely Matters
Following up on some of the SSH brute force attack data we’ve previously presented, here are some statistics on the length of the passwords used in the attacks we’ve observed during the last six months. The graph below shows the number of attacks for passwords ranging from 1 to 20 characters in length.
Not surprisingly, most of the attacks are targeting passwords in the range 4-8 characters. Notice the significant drop after 8 characters, this is probably due to the fact that a lot of systems still enforces an 8-character upper limit. Another reason could be related to human laziness in selecting the lowest amount of characters allowed by the policy, which in all most every case sets the lower limit to 6, 7 or 8 characters. Most policies also defines the recommended length equal to the lower limit. Restricting the length of the password to an upper limit of 6-8 characters is fortunately no longer the case for modern operating systems, but as lower limits and recommendations are still kept at this length, it will be the main target for brute force attacks.
So, if your password is longer than 8 characters, you are dodging a whole lot of attacks. Of course, to gain a higher level of security, length is not the only factor to consider. It is essential that the password complies with a case sensitive alphanumeric character policy. Using special characters as well, such as underscore and slashes would further increase the password space.
As a side note, of the approximately 1.5 million attacks in this data set, 1408 attacks used passwords with more than 20 characters. Topping the statistics are 4 attacks that used a 122-character password, but using only numbers and lots of spaces it does not constitute a good password, if it indeed is an actual password. The longest password-looking string recorded is the following; mt13hzxwUXu8PsT6KYExvLu5zgGEpC0vtmhVjg7KIWknhzfCalwVinh3rqyh7Ui We apologize if we’ve just now made your password public :)
Obfuscating downloads
Previously this year, we came across a downloader (win32.exe) that is making some effort in hiding its traffic. The downloader is making GET requests to files, such as search.jpg, winlogon.jpg, tibs.jpg and tool.jpg. Using tools like chaosreader and foremost to extract the files, you would find out that these files indeed are valid images (like the one shown to the left in this post).
However, if we look more closely, we find that these files has something more interesting appended past the JPG data. Below is a short video showing what’s inside winlogon.jpg.
This downloader was found on hightstats dot net, which, at that time, resolved to 88.255.90.252 (AbdAllah Internet, TR) – whose netblock is very well known for its malicious hosting. At the time of this writing, the domain resolves to 66.246.229.81 (Net Access Corporation, US) and is still serving these files. We’ve also seen this kind of obfuscation before, then with the image of a green frog – McAfee has mentioned this on their blog.
Now, what winlogon.jpg (..or the executable inside it) did, was to install BraveSentry, a rogue anti-virus/spyware product that claims to have found malware on your system in order to trick you to purchase their product.
This is not a new obfuscation technique, but it seems to be a characteristic for this group of spyware creators, that are pushing these rogue security programs.
