GSoC Mentoring Organization
We are excited to announce that the Honeynet Project has been selected by Google to be a mentoring organization for their annual Google Summer of Code project. Our team of volunteers is very excited about this and look forward to working with and helping mentor students around the world about honeypot technologies. To learn more about the different projects you can work with us on, please take a moment to review our IDEAS PAGE. If you will be submitting an application, your best chance to be selected is to take your time and review and understand the project involved before submitting the application. If you need any additional information or want to ask us questions, you can get in touch by email or on IRC (#gsoc-honeynet on irc.freenode.net).
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
Capture-HPC 2.1
The Honeynet Project and School of Mathematics, Statistics and Computer Science at Victoria University of Wellington, New Zealand are excited to announce the release of Capture-HPC v2.1.
Capture-HPC is a computer security product that allows anyone to: investigate client-side computer attacks; security researchers to find and study malicious servers; virus and malware researchers to collect malware pushed by malicious servers; network administrators to monitor their systems for client-side attacks; and web site operators to monitor their web sites for unauthorized modifications with client-side attack code.
The new version have a 500% increase in performance over the previous version, which should be greatly appreciated by those already familiar with the tool. Besides malware and unauthorized state changes, Capture-HPC now collects network traffic for all client/server interactions. In addition, Capture-HPC now reports statistics about the performance of the system allowing operators to monitor and tune the Capture-HPC system during operation. Introduction of a client plug-in framework.. This framework allows third-party developers to include client applications that are currently not supported by Capture-HPC. A Safari browser plug-in that makes use of this feature is provided with the 2.1 version of Capture-HPC adding support for this browser and demonstrating the capabilities of this framework. In addition, a wide range of browsers, office applications, and media players are supported by Capture-HPC.
Welcome to our new site
Our primary web server was changed today to a more powerful machine, and we decided to do a full re-installation of the OS and all the services running. So it was quite natural to also get a new solution for our web site, now running on WordPress. As it’s described on the “about” page, the Honeynet Project has recently undergone a major re-structuring with disposing of the old “Research Alliance”. Honeynor has now become The Honeynet Project – Norwegian Chapter. The complete listing of all chapters can be found on this page. There will be a diagram of the new organization out on the honeynet.org website soon.
