The Honeynet Project

• Giraffe Chapter

Citibank is or has been under a telephone calling attack latest 12 hours. Here I will explain the attack and how it was done.

Have you seen the movie “lawnmower man”, when in the end, all phones rings in the who city? This was the aim for todays attack on Citibank in UK. The attack was simple, but probably effective when it was active. Send SIP INVITE to open SIP gateways and PBXs, who then will actually use the traditional phonesystem (POTS) to call the target. Suddenly you need DoS protection on your traditional POTS lines….

The SIP INVITE looks like this.

Lets walk through the SIP packet and see what info we can get from it:

A quick google search on the tag: Zerogij34 reveals that this attack has been around since at least 6th of August.

The IP (217.23.7.47)from this packet should be located in Portugal but the other attacks originate from both UK and Netherlands.
There is no User-Agent listed, so the packet is very likely crafted from toosl like sipsak or sipp.
The codec list seems real, but they use an obscure address (1.1.1.1) for the RTP. If they would use their own IP address, it could case a small DoS with RTP traffic for every successful call.)The port 29784 is within the range of Cisco units (26 000-32 000)

The other INVITES reveals that the attacker is trying to figure the extension to get a dial-tone:

• INVITE sip:00442075005000@67.170.104.216 SIP/2.0
• INVITE sip:011442075005000@67.170.104.216 SIP/2.0
• INVITE sip:0442075005000@67.170.104.216 SIP/2.0
• INVITE sip:0000442075005000@67.170.104.216 SIP/2.0
• INVITE sip:0011442075005000@67.170.104.216 SIP/2.0
• INVITE sip:900442075005000@67.170.104.216 SIP/2.0
• INVITE sip:9011442075005000@67.170.104.216 SIP/2.0
• INVITE sip:90442075005000@67.170.104.216 SIP/2.0
• INVITE sip:442075005000@67.170.104.216 SIP/2.0
• and several more…

But is this a DoS attack on Citibank? I doubt it. Why call the Citibank on a Sunday 5 a.m.? This is more likely that Citibank has lots of lines and therefore the SIP INVITES does not generate an error (busy or others). The attacker does not hear any ringtone, but he/she should see the 180 Ringing / 180 Session in Progress. Then he or she knows that he could actually get through to the PSTN on this SIP proxy. If it would be a ringing attack, why does the attacker just send one single SIP INVITE through each gateway that actually calls this destination?

The machines with the attacking IP addresses should be put under surveillance to see who connects to these. They are probably just some bots in a larger network, but they need to relay back which gateways actually responded successfully.

Sad to say, but I believe this is only the small beginning….

We are excited to announce the latest chapter coming on Board, the United Arab Emirates Chapter, hosted and formed by aeCERT.  This is the very first Chapter to be joining from the middle-east, we are very excited to have them on board and expect great things from them!

Shucran!

lance

Shown below is a visual of a time series analysis representing malicious activity reported by our 6 most active and reliable SensorNET honeypots. These honeypots have been deployed for between 9 months and 2 years in the Australian IP space. our honeypots are designed to detect malicious network activity in a passive and safe manner, you can read more about the background of our SensorNET here.

CLICK to enlarge.

Each one of these blue dots represents a group of other people's compromised computers attempting to compromise our honeypots in an effort to get it to join a botnet. All of this happens in the background, and does not require any action by the owner of the computer, or even for them to be sitting at the compromised computer.
Some of these attacks come from computers in Australia, and many come from other countries as well. We have done some visual analysis on the location of these attackers in past blogs using geographric heatmaps here and with a tool called Circos here.

While there are a lot of factors involved in malicious activity on the internet. I tried to keep it simple, and this visual does a reasonable job of helping us understand when malicious network activity peaks.

Relatively little activity is seen in the early hours between 3am and 7am. Then we see a substantial, and consistent uptick in activity on every day between 8am and 9am. This may be caused by people turning on infected PC's, which then go and scan for new victims at this time. Throughout the day, activity generally increases, peaking around the middle of the night. The old adage 'beware the midnight hour' seems to be applicable even on the internet (Hence the spooky green bar graph, just for fun).

From our results, it appears just after midnight on Friday and Thursday nights would probably be the most dangerous time for an unattended, insecure computer to be on the Australian internet. Of course there is actually no 'safe' time for such a computer to exist on the Internet, but it is interesting to do this analysis.

Each one of these attacks is preventable by using a proper firewall, good practice, antivirus, and security patches. To avoid contributing to the blue dots on this visual, read AusCERT's advice here on how to best to protect your computers.

Helping to understand our cyber threat environment so that decisions on mitigations/controls are better informed is really one of our key goals, particularly as plans are under-way for the roll-out of the $43 billion Australian National Broadband Network, which will clearly need to consider cyber security as a major stakeholder.

If you have a similar dataset that you are interested in studying in this manner, send me an email at ben@honeynet.org.au

The Dionaea honeypot got more and more mature during the last weeks. As Markus blogged in Iteolih: Miles and More the software is now able to detect shellcode via libemu and generates a nice shellcode profile out of this.

The SMB / DCERPC implementation also got fairly mature and is now able to cope with all packet types and also most caveats and differences of implementations in exploits. As I registered more and more RPC vulnerabilities in the module, it was definitely time to give libemu something to eat! :)

• Giraffe Chapter

Here is a brief introduction on Qebek, answering some questions.

Picviz is a parallel coordinates[1] plotter which enables easy scripting from various input (tcpdump, syslog, iptables logs, apache logs, etc..) to visualize your data and discover interesting results quickly. This way, you can find in million of events malicious things you were not thinking about and that no regex based program would find for you.

[1] http://en.wikipedia.org/wiki/Parallel_coordinates

We got a new milestone due:

10.08.2009

• thread-pool works
• stream recording works
• shellcode detection using libemu works
• shellcode emulation using libemu works
• compiles on linux&openbsd

An exploit taken from a public repository, run against the software, is detected and emulated.

To shorten things, basically all required points are hit with current svn.

So, given the time we just saved, some words about how it works.

• GSoC Project #10 - Develop and Improve the effectiveness of low Interaction Honeypots

Hi all:

       I have finished almost all the coding stuff of Project #1, now you can try out the new PHoneyC with shellcode/heapspray detection here:

http://code.google.com/p/phoneyc/source/browse/phoneyc#phoneyc/branches/phoneyc-honeyjs

        Please feel free to report any bug or suggestion on shellcode/heapspray detection to me.

• Chinese Chapter

Today I make a retrospection on my work on the Glastopf Web Honeypot during the Google Summer of Code Program. My goal was to push forward the development on a Honeypot for an attack vector in web security which is really underestimated in current discussions. The main objectives could be merged into one intention: Increasing our attractiveness and answering every request as close as possible to a real world system. This got achieved with the new PHP file parser and the dynamic Google dork list which we provide for the Google crawler.

Second milestone reached! Honeybrid has now all its functionalities working and it's time for testing. In order to check that everything works efficiently, I deployed a Windows honeypot to receive traffic from five /24 unused subnets during half an hour. Here are the details of this experiment.

Here is a overall diagram of the testing architecture:

(Internet) <=====> [NATing Gateway with Honeybrid] <-------> [Windows Honeypot]

The NATing gateway was configured with the following iptables rules:

• GSoC Project #6 - Develop Hybrid Honeypot Architecture