Citibank UK number was target for a “lawnmower” telephone attack today!
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.
INVITE sip:00442075005000@x SIP/2.0
Via: SIP/2.0/UDP 217.23.7.47:58585;branch=z9hG4bKaergjerugroijrgrg
To: <sip:x>
From: <sip:217.23.7.47:58585>;tag=Zerogij34
Call-ID: 213948958-34384780214-384748@217.23.7.47
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:sip@217.23.7.47:58585;transport=udp>
Allow: INVITE,ACK,OPTIONS,BYE,CANCEL,NOTIFY,REFER,MESSAGE
Content-Type: application/sdp
Content-Length: 520
Session-Expires: 3600;
Allow-Events: refer..
v=0
o=sip 2147483647 1 IN IP4 1.1.1.1
s=sip
c=IN IP4 1.1.1.1
t=0 0
m=audio 29784 RTP/AVP 8 0 4 18 18 18 18 96 3 98
a=rtpmap:96 telephone-event/8000
a=sendrecva=ptime:20
a=rtpmap:18 G729AB/8000
a=rtpmap:18 G729B/8000
a=rtpmap:18 G729A/8000
a=rtpmap:18 G729/8000
a=rtpmap:4 G723
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….
Honeypots and privacy
Even though Norway is not a member of the EU, many directives do still apply to us, and if they don’t, they still can provide useful insight. For instance, article 5 of the Directive 2002/58/EC of the European Parliament and of the Council concerning the processing of personal data and the protection of privacy in the electronic communications sector (Directive on privacy and electronic communications) [1] states;
Member states shall [..] prohibit listening, tapping, storage or other kinds of interception or surveillance of communications and the related traffic data by persons other than users [..]“
On a general basis one may emphasize that the end user (the receiving or sending party of the electronic communications) can always do whatever he/she wants to with the data being received (or sent). That includes logging the traffic data or recording the contents. The privacy regulation only sets limits to these actions when they are being performed by third parties.
The EU directive mentioned above may be interpreted in a way that the right to record one’s own traffic (and to participate in electronic communications) is assumed to be such a basic right that it doesn’t even need to be explicitly granted. One should be much more concerned about unauthorized third parties tapping the communications.
A reader pointed out to us that the Finnish legislation 516/2008 section 8 [2] is much more explicit in this regard:
“The sender and intended recipient of a message are entitled to handle their own messages and the identification data associated with these messages [..]“.
If you’re running a honeypot, that makes you a second party of (“unicast”) electronic communication, thus giving you all the rights of the participant. One could also argue that you are the in fact the intended recipient of that communication. It was the attacker that initiated the conversation; you didn’t fool him to do anything nor did you lure him to initiate the traffic under the false pretext. The honeypot is passively waiting for someone to first probe for any of its services and then start recording when it’s being attacked, most likely by a person wanting illegitimate access to this machine.
1. http://europa.eu/eur-lex/pri/en/oj/dat/2002/l_201/l_20120020731en00370047.pdf
2. http://www.finlex.fi/en/laki/kaannokset/2004/en20040516.pdf
Comments on the Aftenposten article
On Friday 26th of June Norwegian newspaper Aftenposten published a two-page article about honeypots. The article expressed concerns about the ethical and legal aspects of the technology. We are happy to see that media is concerned about security and privacy issues on the Internet. Unfortunately the article contained some mistakes and misconceptions which we would like to clarify.
Research organization
The Honeynet Project is an international, non-profit (501c3) research organization dedicated to improving the security of the Internet at no cost to the public. As mentioned on the Honeynet project web site[1], our vision is: To learn the tools, tactics and motives involved in computer and network attacks, and share the lessons learned.
We raise awareness of the threats and vulnerabilities that exist in the Internet today. Many individuals and organizations do not realize they are a target, nor understand who is attacking them, how, or why. We provide this information so people can better understand they are a target, and understand the basic measures they can take to mitigate these threats. For those who are already aware and concerned, we provide details to better secure and defend your resources. Historically, information about attackers has been limited to the tools they use. We provide critical additional information, such as their motives in attacking, how they communicate, when they attack systems and their actions after compromising a system. And for organizations interested in continuing their own research about cyber threats, we provide the tools and techniques we have developed. As an example, the Honeynet project was involved in reducing the effect of Conficker, which among others attacked the Norwegian Police, by providing tools and information [2].
Honeypots
A honeypot is a computer designed to be attacked. Most honeypots are built the the same way as computers used all over the world. The only difference is with a honeypot, there are no valid users nor any use for the system, no one should be interacting with it. Just like any computer at work or at home, a honeypot will log the IP address of any system that attempts to connect to it. To gain access to the system, an attacker must break into the system. The concept is similar to a locked door on an empty house. No one should be coming in or out. The only way an individual can enter is by breaking the lock.
Jon Bing and Georg Apenes expressed concerns that innocent users would enter the honeypots and thus have their actions logged. The honeypots are however never advertised to users. There is absolutely no process involved in the deployment of our honeypots which actively entices or lures anyone to enter the honeypot. You cannot find them through google or any other service. The only way to find them, is to actively probe and scan for them, and this is exactly what attackers do. In addition, there are no legitimate accounts on the system, the only way an attacker can get access is attack the system, the same way a criminal would have to break a lock on a door.
In the article, Bing compared honeypots to building a new street and setting up surveillance cameras in the whole area, without the visitors knowing that the information is stored and analyzed. This analogy is incorrect. An innocent user can easily walk into the wrong street. But to have their actions logged by a honeypot, the user has to find and attack the honeypot, they have to break the lock. So a better analogy would be that a honeypot was a building with a locked door in a back alley and surveillance cameras inside. If someone found the door, and broke into the building, then they would monitored by these cameras. In addition, the goal was not to arrest the perpetrator, but rather to learn how he broke into the house, and what he did once inside. The intention would be to use the knowledge to build safer homes and design better locks in the future.
Donations
Another issue raised by the journalist, was our donations, especially by Telenor and Lyse. Yes, it is correct that those two companies have helped us with both hardware and access to the Internet, and in similar ways, so has other companies as well. But in no cases do these companies receive special treatment or information. All information (as long as it doesn’t compromise ongoing research) are shared with the public at no cost.
In agreement with Aftenposten, we are publishing a translated version of the article.
The Honeynet Project, Norwegian chapter will contact the Norwegian Data Inspectorate and Jon Bing to explain the topic in detail. The Honeynet Project, Norwegian Chapter can of course not operate if we are considered unethical or on the edge of the law.
Notice: We have removed the page “Information in Norwegian” due to possible misunderstandings when English words and expressions had inadequately been translated to Norwegian. It will be replaced with a new fact-sheet about The Honeynet Project.
The Honeynet Project press contact is lance.spitzner@honeynet.org
2. http://en.wikipedia.org/wiki/Conficker#Removal_and_detection
Country Lookup
We’re pleased to announce a new service; CC2ASN – Country Lookup. This service will provide you with AS-numbers, IPv4 and IPv6 prefixes belonging to a specific country. The data is all based on publicly available information from the five RIRs in the world; ARIN, RIPE NCC, APNIC, LACNIC and AfriNIC. The database is updated once every day.
As input to this service, use ISO-3166-1 alpha-2 country codes (more info). Note that in addition to the ISO defined codes, the following two codes are also used when dealing with multi-regional networks; AP (asia-pacific) and EU (european union).
You may access the data either through the web-interface, or via your command line interface. A standard whois client can be used when the result set is “not too large”. The preferred way is to use a raw socket tool, like netcat. Here are some examples illustrating both ways:
whois -h atari.honeynor.no no
whois -h atari.honeynor.no ipv4 ke
echo "all us" | nc atari.honeynor.no 43
The first will list all AS-numbers registered for Norway, while the second example will list all IPv4 prefixes for Kenya. The last line uses netcat to fetch everything (ASN, IPv4 and IPv6) registered for USA (this query will fail when using a standard whois client).
For more information, please read the documentation (There are some caveats to be aware of, and more alternatives to download this data. It’s all in the docs).
Using Nmap to scan for Conficker
As a result of the latest KYE paper (Containing Conficker), many of the scanner tools out there have implemented (or are in the process of doing so) the method presented in chapter 5 of the paper, which explains basically how you may remotely scan a machine, and have the machine tell you whether or not Conficker has compromised the system. The method works for all current Conficker variants and is indiscriminate of the infection vector!
Nmap was one of the first tools to implement this. Lets try it out!
Download the latest development release from http://download.insecure.org/nmap-dist/ (at the time of writing: 4.85BETA6) and the usual configure, make, sudo make install should to the trick, but in case you run into compile- or run-time errors you may want to check out this page. (If you face run-time complaints about openssl, you should follow this link). There’s also binaries available for Windows and OSX.
The following is an example of a basic scan for conficker
nmap -sC -PN -d -p445 --script=smb-check-vulns \
--script-args=safe=1 192.168.1.1
For large-scale scans, you may invoke nmap with some optimisations parameters as recommended here.
nmap -sC -PN -d -p445 -n -T4 --min-hostgroup 256 \
--min-parallelism 64 --script=smb-check-vulns \
--script-args=safe=1 10.0.0.0/8
In addition to the no-ping (PN) and port specific scan (p) we added no-dns-resolution (n), more aggressive timing controls (T) and parallel scanning with group of 256 hosts (with at least 64 simultaneously). The two latter parameters may be tuned even further for increased performance. The recommendation is to maintain a 4:1 ratio between the two values, and keep the upper limit to 4096/1024.
Using safe=1 as an argument sent to the script, the MS08-067 vulnerability is not really checked. Using unsafe=1 and it will be checked, however be aware of a possibility that the vulnerable server service may crash.
Here are some examples of the output from the script smb-check-vulns (with MS08-067 check enabled):
| MS08-067: LIKELY VULNERABLE (host stopped responding) | Conficker: Likely INFECTED | MS08-067: FIXED | Conficker: Likely CLEAN
…So, scan your network now, while it’s still possible.
Fighting Back!
Yesterday, The Honeynet Project released a brand new Know-Your-Enemy (KYE) paper titled; Containing Conficker. Previous papers about the Conficker variants (like SRI’s analysis) have focused on explaining the inner workings of the malware. The KYE paper, on the other hand, proposes new ideas on how to identify, mitigate and remove Conficker from compromised hosts.
The paper contains a wealth of excellent information and actionable intelligence for both security analysts and network/system engineers trying to defend against the vexing issue that is; Conficker. Together with the paper, a series of different open source tools have also been released:
- Domain Name Generation Tool – Downatool2
- Memory Disinfectant – conficker_mem_killer.exe
- File and Registry Detector – regnfile.exe
- Conficker Remote Scanner – scs.exe
- Nonficker Vaccination Tool – nonficker.zip
The collection page includes the source code for all these tools and also Nebula-generated Snort signatures for Conficker.
Here is the link to the paper again, in case you missed it: PDF.
How to get the password from any SIP user-agent!
This is really, really, really bad!
If I know the IP address of your SIP User-Agent and your extension, I can get your password. Not true? Here is how Sandro and I did it! Sandro Gauci also has a tool (voippack for Canvas) which automates the whole process, you can watch the video here!
The master plan:
- Check up on the Internet which ISPs are delivering VoIP. Check RIPE for their IP ranges. Scan them for SIP devices.
- Get the extensions they are using (or their ranges of usernames (e.g phone numbers, then do brute force on these ranges on each IP)
- Send an INVITE to the correct extension and the phone will ring. When the user hangs-up, we have the password.
The details:
We make the phone send a PROXY AUTHENTICATION when the SIP UserAgent sends the BYE message. We answer with “407 Proxy authorization required” and then the SIP UserAgent actually answers this with the password in a MD5 hash.
The problem
- The SIP stack is not connected to the IP Stack. Why is the SIP User Agent answering on SIP messages from other IPS than the SIP Registrar it is connected to? There should be automatically a rule saying “all SIP messages from other servers than what I’ve registered to = drop them!”
- Why does the User Agent blindly answer a challenge on the BYE message. Just send it a “407″ and the SIP UA answers with the password…
Units tested (and we managed to get the password)
- Linksys SPA2102
- Grandstream GXV3000 (latest firmware)
- AVM Fritz 7270 (firmware December 2008)
The units that will be tested further:
- Polycom
- Thompson ST2030
- Snom
How to protect yourself (for users)
- Make sure your VoIP provider has credit limits! You don’t want to get a huge phone bill!
- Report any unusual phone calls or strange behavior!
How to protect yourself (for VoIP providers)
- Protect your SIP user-agents! This is hard with the Fritz units
which is normally used as a router - Have very long SIP passwords and use all characters that is possible! (#¤%” and others)
- Change the SIP password regularly
- Run VoIP honeypots to detect scans in your area
How serious do you think this is? Write your comments now!
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).
A closer look at encrypted Javascripts
Some of our team members came across an infected website redirecting to an exploit site at fuadrenal.com. As usual, the exploit site returned an obfuscated Javascript.
However, beneath the first layer of obfuscation, there was an implementation of RSA PKCS#1 (Public key cryptography) and a variant of a stream cipher, the alleged RC4.
I’m no crypto expert, but after comparing this RC4-like function with other RC4-based algorithms, it looks like this could be a CipherSaber implementation. Below is a pretty-printed part of the function (comment were added by me):
As already mentioned, the CipherSaber algorithm is based on the stream cipher algorithm RC4. RC4 encrypts its content by xor’ing using a keystream which is derived by a secret key. In CipherSaber, this key is created by appending an initialization vector (IV) to the actual key (as show in the image above).
Now, when the first stage of this script is executed, a 53 bytes secret key is randomly generated and stored in an internal variable called ‘oil’.
Next, the secret key is encrypted using RSA and a public key that is hard coded in the script. The output is converted to a hex-string and used as a parameter for the URL leading to the next stage. The next stages are loaded by calling the appendChild()-function for the document object, and thus preserving the current state of RC4.
On the server side, the hex-string will be decrypted and therefor have access to the randomly generated secret key of CipherSaber. The server then returns a CipherSaber-encrypted script, using the hex-string itself as the IV.
Since the client is preserving the RC4-state, it is able to decrypt the second stage Javascript. This script checks for potentially vulnerable ActiveX-components/plugins in the client browser. Specifically, it checks the versions for Flash, PDF and MDAC (in my case, using an MSIE user-agent).
The results of the version check is reported back to the server by RSA-encrypting it, and using the resulting hex-string as a part of the next-stage URL. Again, the next stage is loaded by calling the appendChild()-function.
Not surprisingly, the server returns an encrypted chunk of code that needs to be decrypted using CipherSaber. This code contains suitable exploit code based on the version information gathered from the previous stage. Finally, if the exploit is successful, an URL parameter is generated by RSA-encrypting a few exploit-parameters, which leads to the malware payload itself.
For a graphical overview of the stages involved, click on the image below:
Obfuscated Javascripts are obviously getting more advanced. In this case, it is very difficult to do an “offline” decryption of the code (e.g. by analyzing pcaps), as the keys are randomly generated and the encryption pretty strong. In addition, the exploit site only accepts a single attempt per ip address (I guess there’s an expiration, though), which doesn’t help the case.
However, these scripts has to be readable to browsers – which means anyone can read them, one way or another :)
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!
