The whole MitB core was written in Javascript and the actions performed to make the fraudulent transaction are the following:

• When the user goes to the accounts details screen the information (account number, type of account and balance) of all of them are grabbed and sent to the malicious server in a serialized array:

  ["maxCheck" = ["name" = "MY_ACCOUNT_NAME",
                 "check" = "MY_ACCOUNT_NUMBER",
                 "sum" = $$$],
   "allChecks" = [ 0 = ["name" = "MY_ACCOUNT_NAME",
                        "check" = "MY_ACCOUNT_NUMBER",
                        "sum" = $$$]
                 ]
  ]

   

• From all the possible accounts it's chosen like preferred the one with more money (maxCheck array).

After the Jailbreakme PDF vulnerability explanation I'm gonna publish the proof of concept of the same vulnerability for Foxit Reader. This is a patched vuln for this product so I suppose there will be no problem with that. Like I said, we can use a 116-bytes shellcode without the necessity of another exploiting stage, so I've modified this calc.exe shellcode for this PoC.

This exploit generates a PDF file which can be used against Foxit Reader in Windows XP and Windows Vista.  This is functional only for the latest versions of Foxit Reader but it's very easy to modify it for other ones (there is an example in the exploit for the 3.0). You can find the python script in the Exploits section or directly here. Enjoy it!! ;)

After decoding the stream of the object 13 we can see the following bytes (talking about this file):

• VERIFY CHV (20): PIN authentication.
• SELECT (A4): selection of the file we want to work with.
• GET RESPONSE (C0): read the response data.
• READ RECORD (B2): read the specified record.

La página a la que redirigía el iframe contenía a su vez otros dos iframes:

<iframe g1g="321" src="xd/pdf.pdf" l="56" height="31" width="13">
<iframe g1g="321" src="xd/sNode.php" l="56" height="31" width="13">

The evolution continues. Some days ago a new ZeuS binary appeared with the version number 1.3.0.26. This new development is an attempt to improve the stealth techniques used to date, as stated in one of the TODO files found some time ago. After just a quick look, one can notice the following changes:

• When it's executed and the system isn't infected yet, it copies itself in the directory %SystemRoot%/system32, but with a different filename in each execution. Also it gets the basic file information from the %SystemRoot%/system32/ntdll.dll file (creation, last access and modification dates).

• If it finds a previous ZeuS version installed it deletes the binary, leaves and shows the hidden files in the next reboot. To give an idea of the situation, one of the latest samples with sdra64.exe as executable filename is the 1.2.12 one.

• Apparently the configuration and data files are not stored on disk anymore but they're exclusively stored in memory.

In the S21sec blog we have been talking some time ago about our dear friend, almost one more colleague: ZeuS. It is a malware with more than 3 years of life which continues changing and evolving to hide itself better and making the fraud more efficient. But what we maybe have not mentioned yet is how to know if our little friend is here, spying all our movements and reporting all of this to its parents, because sometimes the AV software is not so effective as we expect.

There are several evidences in its different versions which mean that we are infected with ZeuS:

• Filesystem

ZeuS leaves a trace in the filesystem when it's installed in the computer, but it hides and blocks all the files it creates, avoiding that a normal user can see and delete them. The solution to find these files is using antirootkit software which will show us the hidden files.

I'm gonna stop writing about actions in PDFs to begin with the filters that can be applied to the stream objects. An stream object is composed by a dictionary followed by the real content between the words stream and endstream. Within this dictionary are defined the stream properties like size, filters to apply in order to decode/decompress it or the file name in the case of the stream is located in an external file.
 

As you suppose, a way to hide information in a PDF file is applying to it one or more filters in order to avoid identifying it easily and putting it hard to extract the real content. In fact this is an usual technique in most of the malicious files that try to exploit some of the latest vulnerabilities.

As I mentioned some time ago we wan perform several actions with a PDF file. One of them is application execution, which we can use on different platforms like Windows, Unix or Mac.In order to check the potential of this functionality I'm going to modify a basic PDF. First of all we must include an action trigger, when we open the document, for example. For this task we have to put an /OpenAction element in the document catalog, pointing to an object that will be the /Launch action which will execute the desired application. The action object can include the following elements:

Before I continue with the different actions we can perform within a PDF file I'm gonna create a simple PDF file which we can modify easily. If you open a PDF with any text editor you'll see a lot of objects and elements that can confuse you a bit. In order to avoid this let's make a PDF document from scratch with a text editor, without all the unnecessary elements.

We must begin knowing which of the PDF elements are obligatory and must be present in our file. I've written some weeks ago about the physic and logic structure of these types of documents so I'll only enumerate what we'll need:

The PDF format is becoming more and more (in)famous due to the lately published vulnerabilities in Adobe products allowing the execution of arbitrary code in the system. Now I don't want to write about these malicious files but I'll do it in future posts.

After the brief comments about the objects we can find in a document of this type and its physic and logic structure I'm going to follow with the actions that can be executed in background. The PDF files aren't static documents but it's possible to specify some kind of programming depending on the user actions. This is where the security problem arises and that becomes a simple PDF in a potential malcode with high probabilities of being executed.

A PDF action is a dictionary object which can contain the following elements:

• /Type: it's optional and it's used to specify the object type of the dictionary. In this case it's Action.
   
• /S: it's an obligatory element that defines the type of the action we want to do.
   
• /Next: it's optional too and specifies the next action or actions to be executed.

Some months ago in the Black Hat Europe, Eric Filiol gave a talk about the functionalities of the PDF format. Filiol said that thanks to some features a simple PDF could become malcode executing the attacker instructions. Besides this, the exploitation of vulnerabilities in this type of documents is more and more usual nowadays. This is why I'm going to write about the basics of the PDF structure and how it works internally. Maybe this can be boring but I promise you that next posts about this subject will be more practical;) To make it more enjoyable you can open a PDF file in a text or hexadecimal editor and take a look at what I mention in the next paragraphs.

A PDF file consist of multiple objects connected between them. This objects can belong to one type from eight possible values: boolean, integer and real numbers, text strings, names, arrays, dictionaries, streams and nulls. Apart of the "known" types, names are a kind of tag for the different elements that compose an object, dictionaries, delimited by "<<" and ">>", are a collection of pairs key-value, and streams, delimited by "stream" and "endstream", are bytes sequences, an information flow that the PDF readers can read incrementally, unlike the normal text strings. All the objects can be declared as indirect objects, assigning them an id to be referenced in any part of the file. This type of objects are delimited by the words "obj" and "endobj".

The physic structure of a PDF file is divided in header, body, cross references table and trailer: