Archive Page 2

JAVA Mobile Malware #1

Hi guys,

today I will focus on a JAVA mobile malware (md5 is: 7e92d280472ca426aff1c20fbeb8d2db).

It is spread as jar, containing a class with an attractive name. The jar contains three files:

  • a java class (the malware engine);
  • an icon image (it is used in order to be attractive..);
  • an inf file (it is used to extract sms information).

The following is the class code after the usage of jd. I report only relevant parts:

LoadData:

This method is used to read the inf file in order to fill smsnumber and smstext fields. It uses the first byte of the inf file to know how many sms should be sent.

InputStreamString:

This method is used to read user-defined strings from the inf file.

SendSMS:

This method is used to send the crafted sms.

Focus on inf:

As we can see, the malware uses the inf file to extract information such as: sms number and text. Let’s take a look at this file to understand its format:


Question: have you noticed anything wrong in this format ? Before proceeding, please focus on inf format and the three methods reported above.

Answer: It seems that we have a programming bug or a bad-edited inf file. In fact, the malware will try to send 0x10 (16) sms by using this inf, but it has information only for 8 sms. Maybe this is a mistake of the malware author, or someone else has wrongly edited this file.

I hope you have enjoyed this article… see you soon ;]

Advertisements

JAVA Exploit Kit Malware #1

This is my first blog post of the new year. New year new target!
I am going to analyze a JAVA exploit kit malware, the md5 is: 8d499308df04932ed1b58a78417d6fb9.

Since our target is a jar, containing three class files, we try to get more information about it by using a java decompiler (i.e. jd).

After decompilation, we have a java package that contains three classes:

  • C1. AppletX.java
  • C2. LoaderX.java
  • C3. PayloadX.java


C1. AppletX.java


Here we have an Applet subclass that mainly does three things:

  1. It deserializes a serialized object;
  2. It grabs a couple of information via applet parameters: data and cc;
  3. It plays with a custom class loader named: LoaderX.

The most interesting part is the serialized object obviously.
Do you have any idea about the usage of the serialized object in the above code ?

Well, I will lead you to the right answer. Please just focus on the above AppletX code. If you pay attention to the above code, you can see the initialization of localObject, it is located just above the if test. But we can’t see any sort of explicit initialization for LoaderX.instance. In fact the initialization lies in the deserialization routine… nice eh ?

Here is a visual recap:

Let’s examine the custom class loader now.


C2. LoaderX.java

Here is the custom loader, I will report only the relevant parts. We have a custom class loader that inherits from the Java ClassLoader class.

The custom class loader (LoaderX) sets the “instance” static field to “this“, in order to be not garbage collected. This trick allows LoaderX to be used further after the deserialization. In fact it is required in order to use the following method:

The bootstrapPayload method above does the following things:

  1. It loads the payload class (PayloadX), by setting the ProtectionDomain;
  2. It sets data and cc parameters for the PayloadX class and then instantiates the PayloadX object.

As we can see, this custom class loader (LoaderX) is used to exploit a Java Runtime Environment (JRE) vulnerability, which is reported here.

Well, we have finished playing with the LoaderX class, let’s play with the PayloadX class now :]


C3. PayloadX.java

I will summarize the behaviour of this class with the following schema:


It uses data parameter and cc parameter as follow:

  • data: points to a malicious site where it will find one or more malwares to download.
  • cc: indicates the number of malwares to download. By default “null” means one.

So suppose that data is: malicious.x/mw and cc is: 3.
The above method will download (and execute) the three malwares located at:

  • malicious.x/mw0
  • malicious.x/mw1
  • malicious.x/mw2

into the system temporary directory of the victim system. Each downloaded file will be an EXE file with a random number as name.


Final Notes.

This jar is a pre-built kit that allows to infect victim systems with custom malwares, by exploiting a well known JRE vulnerability. This kit is thought to be embedded into malicious webpages and customized by using data and cc applet parameters to control its behaviour.

It’s all.. I hope you have enjoyed the reading.

Alla prossima ;]

Blog Restyling

To celebrate the new year we have changed our blog theme in order to improve its usability… we hope that you enjoy the new theme.

– ratsoul & swirl

Another Python PDF Parser

(edit): updated screenshots 😉

It’s not a full PDF parser, I just needed to extract streams and javascript from a pdf so it has few options :

  1. list objects
  2. extract all streams
  3. extract javascript
  4. dump object

1. list all objects

2. extract streams

you will found one file named: sample_stream-9-0.txt in you dir.

3. extract javascript

check the directory and you’ll find a file named: sample_js-2-0.txt

you can further inspect objects using the dump command, let’s try it on the object containing the javascript (2 0) :

you can download the tool here

and that’s it 😉

PDF Exploit Malware #2 :: Carrier

This time our pdf exploit malware has md5 1c60c948c901b7aa86b3e40a478948b2.
At this moment, virustotal.com reports this sample as “no result“… nice 😉

I named this one “Carrier” (name taken from the Starcraft series).
You will soon discover the reason of this choice.

In order to grab some information, please open it with a text editor.

We can notice only one big stream compressed with zlib. So select the blob and decompress with zlib. We logically split the given javascript code in three parts.

Part I.

We can see a function that removes a toy obfuscation, by simply replacing “!#” (and “\n” if you want) with the string “”.

So after replacing the above string, we have the plain javascript code of this block.

Part II.

At the end of the obfuscated block, we can see a small javascript code:

This is the brain of the whole code. It decides which exploit to use by the reader version number.

Part III.

Well now we jump back to the javascript code with the toy obfuscation (Part I).

After deobfuscating the code, we can easily walk into the javascript. We have four functions. Let’s see one by one.

F1: printd.

It exploits a vulnerability related to the util.printd() method.

F2: emailinfo.

It exploits a vulnerability related to the Collab.collectEmailInfo() method.

F3: util_printf.

It exploits a vulnerability related to the util.printf() method.

F4: geticon.

It exploits a vulnerability related to the Collab.getIcon() method.

Put all Together.

All of the exploits (related to known bugs) use the same shellcode that downloads a malware from the following website:

At this moment this website is online and it is possible to download the malware,
the md5 of the malware is: D37B3145882007E3D4DF2104C3A07948.

Conclusions.

Time to say some final words. This pdf exploit malware has only a toy obfuscation but it carries four exploits, for various versions of Adobe Reader. I will give you a recap picture of the “Carrier” as a last gift (click to enlarge)…

I hope you have enjoyed this new trip into the pdf bug-land.

See you soon 😉

PDF Exploit Malware #1

Today we take a look at a pdf exploit malware (md5 is 1cf1128b9190d7344c200e1e944d7abf).

First of all let’s open the pdf file with a text editor and dig into it:

rawpdf

As we can see from the object definition, we have a stream compressed with zlib:

rawpdf1
We can code a small python script that will do all the dirty work (decompress and make code readable) for us.

The following is our stream after decompression:

f1

The above javascript code, retrieves the second stream located in the first page of the pdf file and handles this stream.

To locate the second stream, it uses the syncAnnotScan method in order to scan all the annotations in the document and then it uses getAnnots to retrieve the list of annotation and then picks up the first one, our second stream.  For details about javascript/acrobat, please take a look here.

It decodes this stream by replacing (using a global replacement ‘z’ with ‘%’) with the regexp “/z/g,’%’” so it calls unescape and finally it calls eval.

Our uncompressed stream fixed is (click on the following images to enlarge):

f2p1f2p2

Ok, let’s have fun with this joyful and clear javascript function 😦

The first parameter (FfVKaBvcfE3268e) is set to 0 and the second one (JJ140q) is obviously an encoded code string. As we can see, this function handles the encoded code string (full dump here) in order to deobfuscate the code itself. The code is another javascript, as we can see from the eval (eval(n__YJ78gI18RI)) call at the end of this second function.

At the beginning of the function, we have an anti-debug trick:

f2callee

This trick is discussed here. It uses its own javascript code (by using the arguments.callee) as the key to deobfuscate the code string discussed above.

If we take a closer look at this function, we can notice that the key is built only by using the number chars into this function code. Here is a small python script that extracts the key:

key = ""

for i in range(0, len(data)):
 if data[i] >= '0' and data[i] <= '9':
  key += data[i]

print key

Let’s look at the final functions (we just focus on the relevant parts).

First of all, the exploit is related to an old version of Adobe Reader as we can see in the following snippet:

Another interesting part is this function in which it handles the shellcode:

We can obtain the website which it connects to download the malware from the shellcode:

At this time this website seems to be offline, so no further analysis can be done on the downloaded malware.

The exploit used is related to an old vulnerability that is reported here.

Ok that’s all… see you next post 🙂

Riddle #1

Here is a little riddle for you… no more then 30 seconds to answer 🙂

 mov ecx, 0Ch
 mov dl, 1h
 mov dh, 1h
 L:
  xchg dh, dl
  add dl, dh
  movzx eax, dl
  loop L

Try to figure out what the code above is intended for, and let me know…

Enjoy 😉

p.s. Are you thinking about a bug? Well, it’s not a bug.