(Not only) Android malware analysis

Mathematics, objective truth and why 2+2=4 and not 2+2=5

noreply@blogger.com (Unknown) — Fri, 07 Aug 2020 17:00:00 +0000

There's a discussion on Twitter about the result of the arithmetic operation 2+2. It all started with James Lindsay who made a snarky remark to illustrate the point that there's The Objective Truth which is not a societal construct:

2+2=4: A perspective in white, Western mathematics that marginalizes other possible values.

Twitter users don't seem to be a fan of James Lindsay and wanted to prove him wrong by finding a way to "prove" that 2+2=5 and that everything is a societal construct. You can read Lindsay summary of the issue here, but first stay with me for a while. Full disclosure: I did not know who James Lindsay was until this whole Twitter storm.

This Twitter discussion, when you remove the facade of sarcasm, anger and spite, goes to the very core of mathematics - something I'm familiar with and very passionate about. So let me take you on a journey through crumbling foundations of mathematics and how they were rebuilt (or rather plastered together so they don't look like they are crumbling). I promise I will only talk science and I won't talk about politics and society until the very last section.

Do numbers exist?

When I was studying mathematics I had a class which started with the professor asking me this:

- Do you believe that real numbers exist?

I thought about it for a while and answered no.

- Good, this means that you're a sensible person. Do you believe that rational numbers exist?
- Not really, no.
- Great. Do integers exist?
- No...
- Do natural numbers exist?
- Oh, yes, for sure.

- ... and I thought you were a sensible person. Maybe you'll come round one day.

The professor knew very well that I love discussing foundations of mathematics and I knew that he liked to ask questions which sounded simple, but were in fact very complex.

This tongue-in-cheek discussion may seem odd on the surface, but it does sum up most of the 20th century advances in the foundations of mathematics and goes very deep into the understanding of the inner workings of science. Let's talk about that.

The barbers

The very first observation which shattered the foundations of mathematics was Russel's paradox. At the beginning of the 20th century it was generally assumed that you can construct a set out of every statement with one free variable, e.g. "set of all giraffes" (i.e. set of all x for which x is a giraffe) is a good definition of a set.

Russel's paradox is a set R that contains all the sets which are not members of themselves. Does the set R contain itself? If set R contained itself it wouldn't be a member of R. If the set R does not contain itself it's a member of R and thus contains itself. So the set R cannot exist. Hence, not every statement with one free variable defines a set and there have to be some rules on what defines a set and what doesn't.

This fairly simple explanation had a very profound implications for mathematics: if we cannot get the idea of a set right how can we talk about numbers and arithmetic and algebra and topology and... you get the picture. It has even wider implications for logic itself: not every statement can (and should) have a logical value. You can rephrase the Russel's paradox as:

A barber cuts hair of people only if they don't cut their own hair. Does this barber cut their own hair?

The axiomatic theory

This gave raise to the axiomatic set theory (and type theory, but I'll save that for another time). Even earlier than that Peano introduced a set of axioms that govern the number theory. So clearly the solution to the naive, intuitive approach to mathematics was to have a clearly defined, non-controversial set of statements which will be considered explicitly true (i.e. axioms) and rules by which we derive other true statements from these axioms (i.e. mathematical logic).

Peano proposed the following axioms ("successor" in this context mean simply "the next natural number" - although that has to actually be proven from the axioms):

0 is a natural number.
Every natural number has a successor which is also a natural number.
0 is not the successor of any natural number.
If the successor of x equals the successor of y, then x equals y.
The axiom of induction: If a statement is true of 0, and if the truth of that statement for a number implies its truth for the successor of that number, then the statement is true for every natural number.

Some of the axioms are indeed non-controversial (2,3 and 4). However, the very first one proves to be somewhat controversial to this day. Even Peano, in the very first edition of his work, had an axiom that stated "1 is a natural number", which he later changed.

I did a poll to see whether people on Twitter think about the first axiom (should it be 0 or 1) and my followers seem to have very strong opinions on that subject.

In general it doesn't really matter for Peano axioms (apart from cosmetics) whether we will include 0 or not. The resulting model of natural numbers stays the same (of course, you have to exclude 0 in one of the resulting models to show that they are the same). 0 or 1 is just a token, a graphical sign for the first natural number. However, it does show that even the simplest axioms are not non-controversial and are not "objectively, intuitively true".

I didn't say anything about the axiom number 5 - in my opinion the most controversial of all of them. It refers to "a statement" and the truth of that statement. This leads us to the solution of the barber paradox and the meaning of truth in mathematics.

The orders of logic

The statement about the barbers doesn't have a logical value - it cannot be true and it cannot be false. One idea to deal with this is to consider this statement invalid, because it references itself - when you see the word "people" it applies to "barber", so the statement says something about it's own truth value.

In order for a statement to have a truth value it cannot reference itself. It can reference other statements and then we call this a second-order logic. For example a statement "0 is not the successor of any natural number" is a first-order logic statement. However, the axiom number 5 starts with "if a statement..." so it's a second-order logic statement, because it references to statements.

In order to break the circular reference a second-order logic statement may only reference the first-order statements and not the second-order statements. In the barber example it would mean that the reference to "people" didn't include the barber and then we can assign a logical value to it.

As you can see here what is considered a "statement with a logical value" gets pretty messy the closer you look.

The reason for axiom number 5 being controversial is that if we assume all of the Peano axioms we admit that even something as simple as arithmetic needs second-order logic. There are ways around that, but, again, that may be a good story for another time.

The Gödel incompleteness theorem

The Gödel incompleteness theorem stroke a final blow to the foundations already weakened by Russel and is my personal favourite theorem in all of mathematics. It states that no matter what axioms you accept as the foundation of natural numbers there will always be a statement which you won't be able to prove. Mathematician call this an incomplete system - it doesn't assign a truth value to all statements. Gödel says that every interesting system is incomplete.

The implication here is that you cannot create a perfect set of axioms - not only that the Peano ones aren't perfect, but no other ones will ever be perfect. Let that sink in for a while before we move to the second theorem - and yes, there is a second part.

While completeness means that all the statements have a truth value assigned to them, consistency means that every statement has at most one truth value - or, to put it in other words, there is no statement that is both true and false. Incomplete systems are not interesting to mathematicians - if you can prove that one statement is both false and true the whole logical reasoning collapses pretty quickly.

Second Gödel's theorem says that you cannot prove that a system is complete within that system. So you cannot prove that the Peano axioms don't lead you to a paradoxical statements within Peano axioms. You have to go outside that system. The search for a perfect, all encompassing system collapsed even more now.

OK, but this is just a theory(TM)

So your first reaction may be the same as the reaction of people who first heard about the Gödel theorems - the statements that this theorem talks about are probably not interesting from a mathematical perspective. The theorem may be true, but it's not practical in every day work.

Furthermore, if an unprovable statement comes up we can use our intuition and "objective truth" to figure out if it's true or not and add it to the axioms, should we need that statement. All is fine. I'm not a psychologist but I believe this reasoning is called denial.

Anyway, this status quo (again, denial) remained for a very short while. All was fine until the continuum hypothesis entered the stage. The continuum hypothesis is a fairly easy to explain statement. You may know that there's more real numbers than natural numbers. The number of real numbers is called continuum and the number of natural numbers is called aleph zero. The continuum hypothesis states that there's no set which has a size in between aleph zero and continuum.

Even simpler: there is no set which has more elements than there are natural numbers (or integers or rational numbers - they all have the same number of elements) and less elements than there are real numbers. Fairly simple. Also fairly unprovable (in the current axiomatic set theory). Also no human intuition as to whether it's "objectively true" or not. No analogue to real world that can give us any intuition.

So... that's it. You should feel defeated by now and question the existence of the "objective truth". If you don't please continue to the next section.

What about computer science?

Some of you may say: ok, but you know, continuum hypothesis is not something that changes my day-to-day life. If you're reading this there's a very high chance that you're a software developer or software developer-adjacent. If you are you may think that you're able to write a software which does anything you want and you shouldn't think about Gödel, continuum hypothesis and all that because it's just theoretical stuff.

My immediate response to it is: you're still in denial. Don't worry though, I also have a longer response.

Using a very similar method to Gödel's you can prove that you are not able to write a computer program which, for any given code in your favourite programming language, is able to decide if that program will stop or run indefinitely. To put it even more simply: you're (you, the human) not able to decide for every given code in any programming language if it will stop or run forever.

Now your reaction may be: wait, but if I just write printf surely I'm able to say it will stop. Yes, but the whole point is that you're not able to do it for every program. My favourite example of this is now spoiled thanks to Andrew Wiles, but let's assume that we all live in the 1980s for a moment and that the Fermat's Last Theorem is still unproved.

Fermat's Last Theorem is this: for every n>2 there are no positive integers a,b and c such that:

aⁿ + bⁿ = cⁿ

You can probably very easily write a computer program that will iterate over the values for a,b,c and n and check if the equation is true or not. Will this computer program ever stop? It will only stop if the Fermat's Last Theorem is false. Today we know that it will run indefinitely, but would you say the same thing in 1980s?

Of course, this is an imperfect example since Fermat's Last Theorem turned out to be provable (although there was a dispute on whether it may be unprovable), but it shows the complexity of deciding the halting problem even for very obvious and small computer programmes.

What about physics?

You may also be a physicists and say: this whole thing is interesting, but I'm a physicist so I'm not interested in either the continuum hypothesis or the halting problem or undecidable problems. I'm interested in figuring out how the universe works! I don't have a problem with a definition of "truth". I can use the non-fuzzy parts of mathematics.

My immediate response to it is: you're kind of right, but you're also in denial and by now you should know better. Don't worry though, I also have a longer response for you too!

Take a look at this actual theorem called the Banach-Tarski theorem:

Given a solid ball in 3‑dimensional space, there exists a decomposition of the ball into a finite number of disjoint subsets, which can then be put back together in a different way to yield two identical copies of the original ball.

To put it in ever simpler terms: you can divide the ball in a couple of parts and then put them back together to make two identical balls. You can multiply balls. To infinity.

If you're a physicist you probably know that it cannot be done in the real world - conservation of mass, along with many other laws of the universe, forbids it. However, it is true in mathematics. So how does this happen?

Well, the most straightforward explanation is that the three dimensional space used in mathematics is not the same as the one in the real world. It's not surprising, since the three dimensional mathematical space doesn't really have a concept of an atom or any other discrete particle.

So there is a mathematical theorem about the fundamental physical model - space - that is not really true in physics. At least not true in any practical sense and contrary to some of the physical laws. That would seem to suggest that there's a disconnect between "physical (i.e. practical, measurable) truth" and the "mathematical truth" even though physics uses mathematics for its research. I hope that gets you out of your denial.

What does it all have to do with objective truth and 2+2?

WARNING: this is where the more more opinionated part starts.

There seems to be no wide-reaching, Objective Truth in mathematics. There will never be one. There is truth within the constraints of a specific model. This model tries to correspond to reality as much as possible but it will never be intuitively or objectively true, because the very foundations - axioms - cannot be intuitively true and, what is even worse, even if they were, they wouldn't be able to prove everything. It will always escape the reality in some sense.

However, we all agreed on a set of rules and a set of facts from which we create the wonderful, messy, complex, sometimes frustrating world of numbers, sets, functions, arrows (I believe the alternative name for "arrows" is "category theory"?) and more. This is not bad, as long as we know that what we construct in mathematics is just that - our own constructions based on our own, flawed, imperfect intuition and perception.

To stir the whole objective truth mess a bit more mathematicians often play around with models that may be non-intuitive (e.g. non-Euclidean geometry) just so that they may see what interesting theories and properties arise. That brings us back to 2+2=4.

Summary

When it comes to a statement "0 is a natural number" there seems to be disagreement on how we want to model it and people are challenging either approach by presenting their opinions. Opinion is being the key word here - there is no objective truth to that statement, just arguments one way or the other.

When it comes to the continuum hypothesis it's even less clear - we don't have good idea how our brain wants to model the continuum hypothesis. That's ok though - we know that our models have to be incomplete and are based on how our brain perceives the world, which sometimes fails us.

This is, at least to me, the core of the issue - 2+2 is equal to 4 not because it's The Objective Truth, but because it's how our human brains want to model the world around us and because no one has a good reason to challenge it. If you ask me why we cannot say that 2+2=5 I ask you back "what additional interesting information would that provide?" If the answer is "none" let's stick to 2+2=4.

Just in case you were wondering, after all these years, I moved from my firm "yes, of course natural numbers exist" position to "maybe they do, maybe they don't, but it's fun to play with them". Maybe I'll come round one day.

Side note to the whole blog post

What I talk about here is basically a whole century of mathematics condensed into one small blog post. I didn't touch on other solutions to many of the problems presented here: multi-value logic, type theory, non-Peano arithmetic, Church-Turing-Deutsch principle, Tarski's definition of truth and many, many other ideas that were created during that time. What I presented to you is a condensed version of the mainstream, which doesn't show you the nuance, but hopefully scratches the surface enough for you, dear reader, to look through that scratch and discover the weird, wonderful world beneath it.

Also, if you enjoyed this blog post and want to here more about the foundations of mathematics and computer science let me know on Twitter (@maldr0id).

Environmently friendly reverse engineering

noreply@blogger.com (Unknown) — Sun, 25 Feb 2018 22:29:00 +0000

When I moved to my new apartment I discovered a lot of old, mostly networking-related, equipment that I was meaning to either sell or throw out, but I never got to it. Recently I also bought an Arduino and decided to learn something about a lower level of reverse engineering (e.g. the CTF binaries from RHme 2). This two things combined mean it's time for some router reverse engineering!

A word of warning: before I started playing with low level RE I didn't know anything about electronics. If you have some experience with hardware hacking, this post may be a bit too basic.

Typing random numbers into a search bar

My victim is the Edimax EW-7206APg wireless router. The very first thing to do is to remove the screws and look around the PCB (yes, I know that the lighting is horrible).

As you can see there's a huge chip in the middle of the board and some additional smaller ones to the left and next to the Ethernet port. They all have markings, so obviously my first instinct was to find their datasheets. The chips are:

RTL8186 - system-on-a-chip (SoC) with integrated 32-bit MIPS core (aka "cpu")
PSC A2V64S40CTP - 64 Mb SDRAM chip (aka "memory")
MX29LV160CBTI70G - 2MB flash memory (aka "flash")
RTL8201CP - single-chip, single-port 10/100M fast Ethernet phyceiver (coincidentally, if you wonder what "phyceiver" is Wikipedia article prominently features a picture of this exact chip)
TS6121CX - 10/100 Base-T Ethernet isolation transformer

Multimetering UART

Nothing too unusual, but we now know where are the cpu, flash and memory chips. Next, there are four pins that look suspiciously like UART - a serial interface used to debug PCBs. Fortunately the pins are soldered on so I can just connect cables to them. There are four pins, so the first order of business is to decide which pin does what. The possibilities are:

TX - used to send data
RX - used to receive data
GND - ground
Vcc - power

Now, in order to find those all you need is a multimeter or a cheap logic analyser.

Let's start with a multimeter and use it as a (very) poor-man oscilloscope. First of all, GND is fairly easy to find. If the multimeter supports continuity measurements, you have to find ground near the DC connector - this is were one of the probes will be attached. Second probe goes to every pin and when the multimeter shows continuity you have your ground. Once you have GND, connect your ground probe to it and a second probe to one of the remaining pins. Set your multimeter to voltage measurement. All other pins have the following, different, characteristics:

Vcc - will be a constant voltage, around 3.3V in the case of this router.
TX - will be pulled up (= Vcc) with occasional changes in the voltage. Even my cheap multimeter was fast enough to show those changes.
RX - will be "floating", which means that the current will be close to 0V, but not exactly 0V. Either way, it's the only pin with a pretty low voltage all the time.

If you want to use logic analyser, you can get a very cheap one (~10 quid) and connect it to the open source sigrok software suite. Once you set up all four channels you'll get something like this:

Now it's fairly obvious what is going on:

D0 is Vcc (always 1)
D1 is RX (mostly 0)
D2 is GND (always 0)
D3 is TX (some data is being transmitted)

Serial console straight out of hacker movies

We have all that information so it's time to connect router to the UART-USB cable (or just go for an overkill and use Arduino for it). The last thing left is the baud rate. I wanted to use logic analyser to figure it out, but after a failed attempt I just went with a "Numberwang"-style "guess the baud rate" game until I saw something in the console that looked like text. If you don't want to play, the answer is 38400.

Anyhow, by using the wonderful picocom tool I was able to read the serial port and, after a boot sequence, I was welcomed with this rather nice looking screen (colour scheme was chosen by me to enhance the hacking factor).

Bad news is that the usual username/password combinations didn't work. I didn't want to download a firmware and disassemble it, because that would be cheating, instead I wanted to see if I can get the correct credentials from the router itself.

Before that rather lovely screen there was a booting sequence, which could be interrupted by pressing the escape key. When I did I was welcomed with a following prompt:

---Escape booting by user

<RealTek>

Hmmm... some kind of shell. Typing "help" revealed a list of commands, but without any explanation:

HELP (?) : Print this help message
D <Address> <Len>
EW <Address> <Value1> <Value2>...
EH <Address> <Value1> <Value2>...
EB <Address> <Value1> <Value2>...
EC <Address> <Value1> <Length>...
CMP: CMP <dst><src><length>
IPCONFIG:<TargetAddress>
J: Jump to <TargetAddress>
FLW: FLW <dst><src><length>
FLR: FLR <dst><src><length>
LOADADDR: <Load Address>
AUTOBURN: 0/1

After a bit of Internet searching I found a command line reference for the RealTek bootloader. Two particularly interesting commands are:

D <Address> <Len> - print the "Len" bytes starting at "Address" as a hexdump
FLR <dst><src><length> - read "length" bytes from flash memory starting from "src" and copy them to RAM starting at "dst"

Now, these two commands can be used to read the whole flash memory. From the flash memory datasheet we know that it holds 2MB, which is further confirmed by the log message during the boot process:

Found 1 x 2M Byte MXIC MX29LV160AB at 0xbe000000

We also know where to write the flash memory:

Jump to image start=0x80300000...

TFTP and a firmware dump

This is all fine, but parsing a hexdump is not my favourite thing to do. There's another hidden feature of the RealTek bootloader: tftp get. Bootloader uses a tftp protocol to get a new firmware image. You can just send it using the PUT command. However, it also supports the GET command so that you can download a firmware image. How convenient! When the tftp IP is set up using the IPCONFIG command GET results in the following lines in the serial console:

File Start: 80300000,length=00000000

**TFTP GET File test.bin,Size 00000000 Byte
-
*TFTP Client Download Success! File Size = 00000000 Bytes
.Success!

So the downloaded file will start from the 80300000 offset in the memory. Now the only thing left is to load flash into that offset:

FLR 80300000 0 200000

Another tftp get and we get the firmware dump. The only thing to remember is to switch the tftp mode to binary. Otherwise you will lose a couple of hours trying to debug the Edimax firmware file format and wanting to throw your laptop out of the window...

Now we just use binwalk with very useful -Mre options to extract everything from the firmware image. Binwalk output on the dump file shows this:

DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
5424 0x1530 CRC32 polynomial table, big endian
6816 0x1AA0 gzip compressed data, maximum compression, from Unix, last modified: 2005-06-06 03:22:10
65536 0x10000 CSYS header, big endian, size: 65536
93204 0x16C14 gzip compressed data, maximum compression, from Unix, last modified: 2006-04-24 04:18:31
738779 0xB45DB Zlib compressed data, best compression
1005933 0xF596D Zlib compressed data, best compression
1030794 0xFBA8A Zlib compressed data, best compression
1058027 0x1024EB Zlib compressed data, best compression

If you compare it to the firmware updates, you can see that there's a section right before 0x10000 that doesn't appear in updates. Just a quick look at strings in that part confirms that it's the RealTek bootloader. Then you have the squashfs file system at 0x16C14.

A simple grep through everything extracted with "User Name" as argument will find only one file on that file system:

squashfs-root/bin/setup

So this is probably the file where we can find the serial console (or rather Busybox) credentials. When you enter a wrong login/password you get this message:

Hence the first thing to do will be to find that set of strings in the binary and cross reference it with the code. The code at 0x400838 is the one responsible for creating this very nice message. Following the cross references it's easy to see that 0x400CF8 is the subroutine responsible for validating user name and password.

Now, I'm not well versed in the MIPS instruction set, but fortunately it's a rather simple one. The most important parts of the subroutine are:

0x00400d40 addiu a3, a3, 0x7a00 ; "super"
0x00400d44 lb v0, (a3)
...

0x00400d50 sb v0, 0x20(sp)
...
0x00400db4 addiu a1, sp, 0x20
0x00400db8 addiu a2, zero, 5
0x00400dbc lw t9, -0x7ed4(gp)
0x00400dc0 jalr t9

First v0 holds the super string (that's what's at the 0x7a00 lower bytes address). Then a subroutine is called with parameters a0 (= the value entered as "User Name"), a1 (= "super") and a2 (= 5). That subroutine just does a simple comparison between a2 characters of the first two arguments. This way we have the proper "User Name".

The password part is the really fun part. If we follow all other calls to that string compare function we will find three more: two that compare the password part to "go" and one that compares it to "linux". This is done presumably to "obfuscate" the password so that it doesn't show up when you run the strings command on the binary. Additionally there's this check before all the string compare calls (v1 contains a string that user entered as "Password"):

0x00400de8 addiu v0, zero, 0x40 ; '@'
0x00400dec addiu a1, sp, 0x18
0x00400df0 beq v1, v0, 0x400e2c

Your homework is to patch the password given all this information ;)

Finally, after entering proper credentials we get a Busybox shell:

# sh

BusyBox v1.00-pre8 (2005.11.23-10:23+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.

P.S. If you want to try the software reverse engineering part yourself, you can download a firmware from the Edimax website. Then just follow along with the blog post starting at the binwalk command.

How one company implemented (almost) whole OWASP Top 10

noreply@blogger.com (Unknown) — Sat, 26 Mar 2016 13:30:00 +0000

During one of my talks I was presenting OWASP Top 10 to students, who were interested in software development. One of them said that OWASP Top 10 is irrelevant in today's world, because there are frameworks with built-in security safeguards and everyone uses them. Unfortunately, I didn't have any real-world examples prepared and couldn't provide them on the spot. Not long after I received a spam message with an ad for some new auction portal. Out of curiosity I went there (if you check links in your spam folder you may end up with some interesting findings, right?) and looked around.

To my horror, the more I clicked the more vulnerable the portal seemed. I was able to find so many problems with it, that I dismissed it as a failed attempt at building a website made by a single developer, who wanted to play in "the big game". Some time after that event I received a spam for different auction portal, which had the same problems. Soon enough, with a help from my friend, I found the company (JMLNet) that - oh, really - sold and deployed this auction portal. It was a product and was sold for a price ranging between 150 to 350 euros. Not much, and I guess you get what you pay for.

The problems

First thing I did was to search for something. So I wrote the word "test", clicked on "search" and to my amusement this was the link that I was sent to:

That base64-encoded parameter looks interesting, doesn't it? It decodes to:

AND (p.tytul LIKE '%test%')

Which is a part of an SQL query. Well, this probably (I didn't test it of course) means that we have the master of all SQL injections - basically, a free access to the database. (btw. did you notice the space at the beginning of the decoded SQL? ;)

At this point I decided to click some more and just go through a website to see if there are any other obvious security problems. Mind you, I wasn't even trying to find them, I was acting like a normal user. Sure enough, this came along:

As you can see the message displayed on the website and the "info" value are the same. Coincidence? No, not all. In fact whatever was in the "info" value was copied over to the website and rendered in HTML. Like, a message that user isn't logged in (as above) or a javascript that send cookies to the malicious C&C server. All of that was one click away for a regular user.

So, I decided to create an account. When I clicked on a link I got redirected to this website:

Again, we see the base64 encryption of what seems to be a redirect address. Of course, you can put any address you want in there. Why does it matter? Let's assume that a person receives a link saying: "Want to buy this thing? Just log in using the link below:". Being a watchful user, he spots that indeed link is directing to the auction portal website. He goes in, log in (successfully) and get redirected to a phishing website which looks just like the login website but says "your password is wrongt". Being used to mistype the password user tries again and gives credentials to the phishing website. This kind of error is called "open redirect".

OK, now we've registered, logged in and we've got a session cookie. How does it look like, you may wonder? Here it is:

user_id:username:MD5(password)

What's wrong with it, you may ask? Well, first of all it doesn't have a session identifier. Just by stealing this cookie you may login whenever you want and stay logged in for as long as you want. Second thing is that the MD5 hash (MD5...) is not salted. Hence, guessing the password may be very easy. The fact that this cookie is sent with every request makes it easier to steal the hash of the password. Well, but you don't even need the password, do you? You can just log in using the password MD5. You probably don't even have to send POST login request to brute force password. Just try doing GET requests using different cookies and see if you're logged in.

Now let's get to the final and the most worrisome error. After creating a profile, user could upload his or her photo. This photo was saved on the server and available under the following name:

MD5(file_contents) + . + original file extension

Turns out that you can upload a file with any extension. For example, ".php". This means that you have an arbitrary code execution on the server side.

Responsible disclosure

After finding all of that I decided to contact the developer. Here's the timeline for responsible disclosure:

27.12.2015 – first contact, mentioned multiple vulnerabilities
28.12.2015 – response asking for details, unsuccessful attempt at the PGP key exchange
28.12.2015 – detailed information about the vulnerabilities
29.12.2015 – JMLNet decides that they can fix the vulnerabilities and I can publish the description "at the end of January"
05.02.2016 – I ask about the deadline and whether or not I can publish, no response
11.02.2016 – I ask again, no response given

They released an update, but some of their clients still are vulnerable.

Oh, did I mention that they didn't use HTTPS at all? ;)

Three short cyberstories + bonus scam

noreply@blogger.com (Unknown) — Wed, 30 Dec 2015 11:30:00 +0000

Since we are in the holiday season, let me share three small cybersecurity related stories, which you can read by the fireplace with a hot cocoa in hand and laptop on your lap. Enjoy!

The one where I don't (really) know my password

My laptop shut down unexpectedly and didn't want to boot ever again, not even when asked nicely. Since it was only few months after the purchase, I decided to send it back to the shop for repairs. Now, you have to know something about me that might surprise you, as it's coming from a cybersecurity professional. I'm a little bit paranoid. So, I decided to disconnect the hard drive and take it out from my laptop before sending it in. My paranoia also led me to create a long and complex firmware password for my drive. This is the point where all of my problems started, but I haven't realized it up until that unfortunate day.

I first tried to connect the hard drive to my old computer. BIOS prompt popped up asking me for my password. Hey, that's a good sign, right? However, it turned out that for one reason or another, person developing BIOS decided that the user could only enter 8 characters in the password field. No more. After entering the ninth character computer let out an angry beep, presumably warning me that it won't allow a longer password. But my password had more characters! I decided to abandon that way and try another computer. Maybe the BIOS developer there was a bit more flexible on the password length.

I found a second computer and indeed, this time the BIOS had a longer password entry field. I enter my password and lo and behold it did not work. I tried again - still the same error message. I didn't want to become a definition of insanity, so I decided to ask for help. My colleague advised me to try and unlock the drive using an hdparm tool. So I happily tried (highly EXPERIMENTAL) hdparm option to unlock the hard drive and I entered my password again, this time in plain text as an hdparm parameter. It didn't work. I mean, come on, I see that I didn't make any mistake in the password, it's there on the monitor!

I browsed the Internet a little and found out that some older HDDs (though definitely not mine) lowercased the password before using it. I decided to give it a try, because all other ways failed and I just wanted to get access to the hard drive. I put in my password, all in lowercase, and finally it worked! So, apparently, another BIOS software engineer decided that she will lowercase the password before passing it to the hard drive. You know, to reduce the bruteforcing complexity. Just for fun...

The one where someone is tracking me (and it's not paranoia)

I went to the Paris Google office for Botconf. If you're feeling jealous, you should - it was a great conference. I took with me my company's laptop with our Enterprise VPN Solution(TM) client installed. If you're wondering why I didn't take my computer, you've put too much rum in your hot cocoa and you're not paying attention. Organizers provided us with a WiFi Internet. As you may now know, I'm a little bit paranoid. Almost immediately after connecting to the WiFi I also connected to the VPN and I was happily browsing the Internet.

At some point one of my friends decided to send me a file using Google Drive. I clicked on it and it downloaded almost instantly. At first, that didn't surprise me. After all, I was in the Google office, they should have a fast link to the Google Drive, right? Then I noticed something odd - Google (as in their services, not the actual people) seemed to know that I'm in Paris. How could that be? I was using VPN after all and my company was in a whole other country.

Now, the incredible connection speed to Google Drive started to feel a bit odd. My company definitely didn't have such a high speed connection. I decided to dig a little deeper. After a while, it turned out that the WiFi DHCP server has assigned two public IP addresses to my laptop - one for IPv4 and one for IPv6. Furthermore, I was connecting to Google services using the IPv6 protocol. Which, as it turned out, Enterprise VPN Solution (TM) did not support. Hence, my IPv6 traffic was leaking from the VPN connection. This explained all of the weird stuff that was happening.

What is disturbing here is that you cannot simply tell which of the sites you're browsing are using IPv6 and which of them are using IPv4. Surprisingly, Android VPN client (from the same company) didn't have that problem. It simply turned off the IPv6 altogether.

I informed our administrator about the traffic leak and his answer was that "it's not a leak, since you can turn off IPv6" and "you don't know what you're saying". To which one of my friends responded: "password leak also isn't a leak, because you can always change password, right?"

The one where my new intercom becomes smarter

I've heard a lot of stories of accidental hacking of different IoT things: TVs, Blu-ray players etc. However, my story is about a different accidental hacking. I hacked my apartment's intercom by not being in my apartment when the repairman came. It was as simple as that.

My apartment building has an intercom. A standard one, without any fancy video cameras, iris scans or whatever is in right now. It just lets you call any apartment, transmit voice and let someone in. You also can open the doors by typing a special code on the main unit. However, the old intercom tended to break really frequently. At some point, all of the apartment owners got together and decided it's high time to replace the old intercom system with a new one. You know, a top-of-the-line, but still in budget.

Few days after this decision, a technician came and replaced the main unit and also wanted to replace all of the receivers. However, he couldn't replace mine, because I simply wasn't at home. When I came back I noticed that my receiver was behaving weirdly. I could listen on to every single conversation happening on the intercom. No matter who was speaking, I could hear it. While I could hear conversations, I could not open the door. Repairman was so nice to leave his number on a card near my door, so I could call him at my earliest convenience. Which I of course did.

When he came I asked him why I could hear every conversation. He replied: "yeah, this is just a stupid analog receiver, it works like that. This new one is a smart one, it has electronics inside that pick up a correct caller and you only hear conversations addressed to you." So, instead of having an old, analog PBX-like solution, where all of the calls were switched to the right caller in the main unit, we now have a new and smart solution, where the main unit does nothing and the receiver decides whether to pick up the call or not. That's called the future...

BONUS: Paris scam with Louvre in the background

During the last day of my stay in Paris, I decided to sit on a bench, which had a beautiful view of the Louvre and to finish reading the "Spam Nation" by Brian Krebs (I highly recommend it if you haven't read it yet). So, I went through Jardin des Tuileries and sat opposite the Louvre pyramid. I took out my Kindle and a bottle of water from my backpack and sat admiring the stunning architecture. Then, out of nowhere, a young girl came to me asking if I speak English. I replied that I do and she asked me, using her broken English, to sign a petition. I decided not to. Despite her many, many appeals.

I started reading and a second young girl came to me and the conversation repeated itself. I firmly, but kindly refused to sign anything she had and I got back to the book. I started to immerse myself in the world of Russian pharma-spam when the third girl came to me and, again, asked me if I speak English and if I can sign a petition. OK, I now had enough. Three girls asked me to sign a petition during 10 minutes. I politely declined, again, and started to pack my things. Then the fourth girl came to me, as I was packing my stuff, to ask me the same set of questions.

By now it was clear to me that it was some kind of scam. I was curious as to what this scam actually entails and where is the actual scamming part. So, I looked it up and apparently, young girls come to foreigners and ask them to sign some paper. Then, when someone signs it, they say that they just agreed to pay 10 Euros to help poor children or for some other made up cause. Since you provided your name and country of residency, you are now obliged to pay. People apparently do pay the money. Otherwise, if they start to put up a fight, the girl distracts you and her "helper" tries to steal your wallet. So, apart from being interrupted in the middle of an enticing read, you could also get scammed out of you money and documents.

Using World War II techniques to fight ransomware

noreply@blogger.com (Unknown) — Tue, 22 Sep 2015 09:30:00 +0000

The best way to fight crypto-ransomware is to have backups. But what if you make backups once a month, but want to decrypt all of the new or modified files? Is it possible? Sometimes...

Recently, I had a lot of encounters with cryptography. Additionally, this year marks the 70th anniversary of the end of the Second World War. Rather unusually, this two facts combined can help us fight ransomware. We will also learn something about different kinds of ciphers and their weaknesses.

Some versions of the crypto-ransomware use streaming cipher (usually RC4) to encrypt the files found on the victim's machine. However, they make a serious mistake that would get them in trouble if they were working in the Nazi's communication department. But first, let me tell you something about the idea behind the streaming ciphers.

Most symmetric streaming ciphers are using on the same idea. Based on the password provided by the user, encryption/decryption algorithm creates a keystream. It is a constant, pseudo-randomly generated stream of characters that will be used to encrypt the file. Next, that keystream is combined with the plaintext using the XOR operation. This operation has one very interesting property - it is self-inverting, which means that for every byte (or bit) x XOR x will be equal to zero. And zero is a neutral element of the XOR operation.

After all of this math talk, have a look at the example. P1, P2, ..., Pn is a plaintext, C1, C2, ..., Cn is the ciphertext and K1, K2, ..., Kn is the keystream.

P1 XOR K1 = C1

P2 XOR K2 = C2

...

Pn XOR Kn = Cn

Now, because x XOR x = 0 and x XOR 0 = x you can see that the following is true:

P1 = P1 XOR K1 XOR K1 = C1 XOR K1

P2 = P2 XOR K2 XOR K2 = C2 XOR K2

...

Pn = Pn XOR Kn XOR Kn = Cn XOR Kn

So, if we XOR the ciphertext with the keystream, we receive a plaintext. However, there is also one other interesting property, which is shown below:

P1 XOR C1 = P1 XOR (P1 XOR K1) = K1

P2 XOR C2 = P2 XOR (P2 XOR K2) = K2

...

Pn XOR Cn = Pn XOR (Pn XOR Kn) = Kn

But, if you know both the plaintext and the ciphertext, you can easily recreate a keystream. What is more, if you use the same keystream twice to encrypt two plaintexts P and P', we get:

C1 XOR C'1 = (P1 XOR K1) XOR (P'1 XOR K1) = P1 XOR P'1

C2 XOR C'2 = (P2 XOR K2) XOR (P'2 XOR K2) = P2 XOR P'2

...

Cn XOR C'n = (Pn XOR Kn) XOR (P'n XOR Kn) = Pn XOR P'n

OK, but what does it have to do with the World War II? Well, Nazis used a streaming cipher to encode some of the messages. Operators where ordered NOT to use the same keystream twice, because if the allies knew one of the messages (P) they could easily recreate the second one, because it's simply C XOR C' XOR P. Of course, some of the operators did disobey this order.

Some of the ransomware samples also did not obey this order. So, if ransomware encrypts every file with the same password and uses e.g. RC4, you can take one of the files in your backup, XOR it with the encrypted version and you'll have a keystream. With this keystream, you can decrypt all other files. Including the ones that were not present in your original backup.

What if you don't have any backup to work with? You could still take some of the original Windows files (e.g. wallpapers, sample pictures etc.) and XOR them with the encrypted version and get the keystream that will allow you to decrypt all other files.

Of course, this is not a method that can be used always or for every ransomware. But it works. Trust me.

P.S. This is the Computerphile video that inspired this post: https://www.youtube.com/watch?v=yxx3Bkmv3ck.

KLM's "We'll keep you grounded" Programme

noreply@blogger.com (Unknown) — Mon, 27 Jul 2015 09:00:00 +0000

If you're travelling by plane often, I'll bet at some point your flight got cancelled. However, have you ever:

Had an un-cancelled flight?
Had a flight cancelled, because of your power of bilocation?
Had a customer service done via Twitter, but it still feels like it was done by fax?
Was asked for a screenshot of a printed boarding pass?
Had a ticket issued so badly by the airline that you have to go to check-in desk, so that the agent could sort it out?
Had a flight where, after 3h delay and subsequent 1.5h in the plane on the ground, they didn't get any catering, because there wasn't enough time?
Was asked to go to see the downtown, presumably just so that the Transfer Desk queue would disperse?
Had all this problems during one trip?

If so, where did you travel via KLM?

Let's start from the beginning. I was supposed to have a simple itinerary: Warsaw to Amsterdam, then non-stop to Seattle. The same, but in reverse, for return. When I checked in I provided my e-mail address and my actual phone number. This was for use e.g. in an event of flight cancellation, get change or delay. Warsaw to Amsterdam was a peaceful and pretty run-of-the-mill kind of flight. I arrived in Amsterdam, I believe even few minutes before the plan. I get off the plane and I see that my flight has been delayed... 11.5 hours. But it still says "proceed to gate D1".

If you've been in the Schiphol airport and were travelling to the US, you probably now that this gate is actually a immigration pre-check. So I go through with the check and the nice gentleman informs me that my flight is severely delayed and I should go to gate and see if they have any other flights. So I go to the gate. There, a lady from Delta says that we should all go to the transfer desk. Just so you can visualize it, it took me 30 minutes to walk from the airplane to the D1 gate, then to the real gate, then to transfer desk. All while I could just go from the airplane to the transfer desk in a couple of minutes.

Anyhow, it was a good cardio exercise for every passenger. I'm sure the 60-something lady walking alongside me would agree with that. Then a very nice KLM lady tells me that I should hit Amsterdam and be in the airport 2 hours before the delayed time. And she tells that to everyone. Go, see the city, don't stay here! Since I've never been to Amsterdam I went at 10:30 to "see the city". I also had to contact my hotel in Seattle to notify them about the delay.

Amsterdam is a really interesting city. Nice museums and a lot of wonderful architecture. However, after a couple of hours it started raining. Not much, but I didn't have an umbrella with me, so I decided to go to the airport early. And now the fun begins. I go through security with my boarding pass for the delayed flight. I just say that it's from a delayed flight. However, the flight is not on the departures list. So I go to the transfer desk (15 minute walk) and the nice lady over there says that my flight got cancelled in the morning and it was never supposed to leave with this long delay. She was very curious as to where did we get the delayed information from. Apparently a lot of passengers are coming up every few minutes asking for a departure time for a flight to Seattle.

She rebooked my tickets for the next day. Now I was travelling to Detroit first, and from there to Seattle. I had to contact the Seattle hotel again and ask them to change reservation dates. They were so nice that they did it for free! However, I still needed a place to stay in Amsterdam. But fear not! You just have to take another 15 minute walk to the baggage claim area, because the transfer desk cannot book you a hotel, they only have a button that can rebook your ticket.

Walking to the baggage claim I was thinking about the nice 60-something lady and how she managed to walk the whole airport... again. Another KLM lady at the baggage claim arranged a night and meals in the hotel for me. I lost a day in Seattle, but gained a day in Amsterdam. So up until now it has been a pretty normal story, with just little quirks. Like the fact that I had to go to immigration pre-check again the next day.

In Detroit I had little precious time for transfer. So I went to the transfer desk to get my boarding pass, because the agent in Amsterdam was unable to print one, for whatever reason. So she prints a boarding pass, strikes out some information and scribbles something in the middle of it. I run to a gate and my boarding pass does not work. She tries it again and gets a red light again. So I say that I'm from a cancelled flight and they let me in. Just like that. Wow, that was... weird and unexpected. Anyhow, I'm on the flight.

But the actual Monty Python-level absurdities began when I wanted to check-in for my return flight. I logged in and wanted to see when can I make my online check-in. Instead I saw a red box with "Important information" that my Amsterdam to Warsaw got cancelled. And it advised me to contact the customer support. Since their support was an international number, and I didn't feel like leaving my kidney in the US to cover the roaming fees, I decided to go and take alternate route. I saw that they do a customer support over Twitter. Yes, really. And the answer time is about 20 minutes! Well, that's somewhat fast considering the volume of people that they have to talk to.

What I didn't expect was that 20 minutes does not apply to Direct Messages. There you have to multiply that time by two. You know, because other people cannot check the reply times on your DM. That's why I had to do a part of it publicly and, unfortunately, you had to witness it. But, what is even more surprising, is that they reply in 40-50 minutes EVERY SINGLE TIME. So it looks like this (not an actual conversation):

Hello, I have a problem with my flight

(40 minutes later) Hello! What's your problem?

My flight got cancelled for no apparent reason.

(50 minutes later) Hello! Can you provide us with a booking reference?

It's ABCD123.

(45 minutes later) Hello! We'll look into this.

(5 hours later) Hello! Thank you for your patience. The problem is solved.

As you can imagine this is really frustrating. Especially if your flight got cancelled for no apparent reason and you don't know what to do. I also logged in to my Flying Blue account (frequent flyer program for Skyteam). I wasn't expecting what I saw there: they thought I missed my flight to Seattle. You know, that I'm still in Detroit.

So I contact them via DM on Twitter and tell them about the Flying Blue and cancellation. They ask me to elaborate, because, and get this, they think that they cancelled my Amsterdam to Warsaw, because I missed my flight from Detroit to Seattle. Read it again. Just to let it sink in.

After 5 hours since my explanation (during which KLM website went from 22 minutes to we answer every question in 18 minutes), they were able to reissue my ticket. They didn't provide any reason for cancellation, nothing. Just said "you can now check-in online".

Which I couldn't. Because the check-in system told me "You cannot check-in for that flight online, use an automated kiosk at the airport". And I still hadn't had any Flying Blue miles for my Detroit to Seattle flight. So I write to them again and they tell me to send a screenshot of a a boarding pass that their agent printed for me at the transfer desk in Detroit. I think the customer support representative never wanted to work in the customer support. Instead, they wanted to be a lumberjack...

Next day, I go to Seattle airport and try to check-in using kiosk. It says "Go and see an agent". So I go to the agent, which tries to check me in using the same kiosk. It shows the same message. I'm instructed to go to the "Special services" desk. The very nice lady from Delta tells me that my reservation is odd and she'll try to sort it out. Couple of minutes goes by and I have both my boarding passes in my hand and I'm ready to fly home. I thought this will be the end of it. Nope.

I arrive in Amsterdam and there's a pouring rain. Weather is just horrible. So, of course, my flight got delayed. 1 hour passes by. It got delayed again. Second hour passes by. And it got delayed again. After 3 hours they say they'll start boarding in a couple of minutes. However, they are also unloading our bags. We can see it from the window. To my amazement, they really did start boarding after few minutes.

When the boarding was complete, our pilot informed us that we are waiting for our bags to be loaded. Yep, the same bags that were unloaded just before boarding and were sitting just besides our plane. However, the crew was nice enough and offered us a cookie. I didn't know that this is all that they will offer. After spending just 1.5 hours in the plane on the ground waiting for our bags to be loaded again, we were finally departing. Mind you, 1.5 hour is also the time of the flight.

In the air, crew informed us that they will be no food served today. Not even for purchase. I guess they didn't have time to load it on board. If I knew it, I would take my cookie. When we finally landed in Warsaw (and besides, KLM, in English it's "Warsaw" not "Warschau" at least since 1945) I was just hoping that they didn't lost my luggage. After all, that's all that was left for them to screw up...

TL;DR: if you want to fly with KLM, consider Ryanair instead. Same quality, but cheaper!

By the way, did you notice that they didn't use my phone number or e-mail for notifications even once during that whole ordeal?

Epilogue

I didn't get any miles for my Seattle to Amsterdam flight, because, again, they think I missed it. However, according to them, I didn't miss the flight from Amsterdam to Warsaw that followed it. I sent them the boarding pass. They replied after 9 hours. They asked for my full name. As is printed on the boarding pass...

KLM also thanked me for telling them not to use standard reply templates.

Crystalline Cipher and cryptography snakeoil

noreply@blogger.com (Unknown) — Mon, 25 May 2015 20:23:00 +0000

Martijn Grooten on Twitter (with his signature sarcastic undertone) posed a weekend challenge for anyone interested in cryptography: have fun with Crystalline Cipher and show that it is fundamentally broken. Now, I've met with Martijn only once, but from that meeting I gathered that he really loves mathematics, at least as much as I do, and has a great understanding of cryptography. This whole business with Crystalline started off with the discussion on irtf.org, when the cipher author was convincing everyone that he discovered the best cipher in the world. But to Martijn, mailing list members and me the cipher has a smell of snakeoil. Since this weekend turned out to be rather free for me, I decided to have a go at cryptoanalysis.

Mind you, I'm not in any way formally trained in cryptography. I've had two one semester long cryptography courses - one from more mathematical standpoint and the other one from more technical standpoint. The most complex cryptographic thing that I can do is probably doing an RSA encryption using pen, paper and simple calculator. So, I'm not in any way qualified to do cipher assessments and I don't know virtually anything on how to create ciphers. However, putting it the other way: if even I can see problems with a cipher, that means that there's something wrong with it.

Crystalline Cipher - the pitch

In the words of an author:

Cystalline Cipher is an experimental new type of symmetric cipher. Designed to be as secure as a one-time pad, with cipher text randomness approaching (or exceeding) random sources based upon radioactive decay, Crystalline hopes to set a new standard in security.

Well, there are several things wrong with this statements, and let's start with a little bit of history. If you heard about one-time pads just skip the next section (really, just skip it starting from here...).

One-time pads

Is there a cipher that cannot be broken? Some of you may know that the answer to that question is "yes". Nobody can break that cipher, not the NSA, not Five Eyes, not even all of the countries in the world combined. And that cipher is called one-time pad. Basically the idea is that you randomly generate key which is the same length as the plaintext. Then, you combine the key with plaintext using XOR operation (or letter shifting if you're doing it on paper).

Let's analyze this cipher and see what interesting properties it has. If you encrypt any message using a random key of the same length it's pretty easy to show that the result will be a random string. This is the most sought-after property of any cipher: truly random output, which does not (directly) depend on the plaintext. Of course, if you have the key, then you can decrypt the ciphertext. But if you have the wrong key, there isn't a way to know it. You can still try to decrypt a message and end up with a different message then the original. In case of the one-time pad you can end up with ANY message that you want, if you use the right key.

This is what (intuitively) makes this cipher mathematically unbreakable. So, why don't we all just use one-time pad and get rid of RSA, AES, RC4 and all the other ciphers? Because one-time pad is hugely impractical. You have to have key of the same length as the message you want to encode. This means that you have to find a secure way to transfer the key - which is the same length as the message. So, if you have that channel ready at all times, why not just transfer the message using that channel?

Of course you can transfer the key beforehand. Some spy agencies did it. However, then you have to store the copy of that key with you and have it ready for encryption. Which again poses some threat of security violations - someone may steal it from you and decrypt you past messages. And when you try to encrypt file using one-time pad you have to have twice as much storage for it to work. So, that's why we use not perfectly secure, but more practical solutions - AES, RSA and others.

(... to here)

So let's dissect the statements made by the author about the Crystalline cipher. Designed to be as secure as a one-time pad - well, clearly that means that there has to be a mathematical proof of it being unbreakable. Otherwise, it's just cheap marketing talk. These kind of statements always throw me off, because they prove that the author does not have the faintest idea about the profound role of one-time pad in the cryptography - the subject that he tries to represent.

Next statement - cipher text randomness approaching (or exceeding) random sources based upon radioactive decay - does also show that the author doesn't know what's he talking about. We currently believe that radioactive decay is a truly random process, hence you cannot claim that something is "more random" without annoying many physicists.

And now we come to these two statements, which are just hilarious:

Unlike many ciphers, Crystalline operates on an entire file and does not require padding operations or compression.

IMPORTANT SECURITY NOTE: Compress all files first

Not only are they contradictory, but also there is a serious problem with your cipher if you are depended on compressing the data first.

And lastly, I don't even know what this paragraph is about:

Crystalline employs information loss as the basis of its security. This is achieved by shifting the location of data at both a binary and byte level based upon a value provided by the key and salt. As such, the end result is a cipher text that reflects the relationships found in the key and salt, rather than the data. If the key and salt is from a true random source, such as atmospheric noise or quantum fluctuations, then no relationship should be present in the location of bits and bytes in the cipher text. By multiplying the key and salt, information about both sources is also lost.

Crystalline Cipher - the algorithm

It's easy to make fun of marketing and buzzwords (look up "APT"), but let's go into more technical stuff. The algorithm looks rather simple. First you need values called "key", "salt" and "iv". First two are byte strings and the last one is integer. Then the cipher runs a number of "rounds" on plaintext. Each round is composed of two parts. Let's assume that byte(a, i) means i-th byte of string modulo string length.

Part A (bit switch-shuffle part):

For every bit in the plaintext:

Switch (negate) that bit value.
Swap that bit (which is at position i) with a bit whose position is byte(key, i) * byte(salt, i).

Part B (byte shuffling part):

For every byte in the plaintext:

Swap that byte (which is at position i) with a byte whose position is byte(key, i) * byte(salt, i).

And that's all. Number of rounds is determined using some values of key, salt and iv, but let's just assume (for the sake of simplicity) that it's just the iv value. That's an easy exercise to show that this assumption does not weaken the cipher in any way.

Crystalline Cipher - observations and weaknesses

What's the key in this cipher?

The author probably wanted to make "key" variable the actual key. However, if we take a closer look "key" is not used in its original form. Instead, we only use byte(key, i) * byte(salt, i) value, which is the "actual key". It is worth noting that if the length of key and length of salt is the same (as author recommends) the actual key is just a (byte-oriented) multiplication of that values. So there is no need to introduce "salt" value just to confuse the reader (or make it sound more scientific) and we can now assume that we have just a random key, which tells us which file positions to swap.

This key actually has some limitations, which will be discussed later on.

Is permutation a form of encryption?

While this question may be weird at first sight, I've never thought about it before this cipher. Of course permutation can make it harder to read the text, but there's still a lot to infer from a random permutation of plaintext. You can guess the language of the plaintext. You may guess some words, provided that the messages have a constant template, which is the case for many file formats and our e-mails (Hi ..., ... Best regards, My Name). If the cipher is based mainly on permutation (as is the case with this one), there is a lot of information that can easily leak.

But this is just all a hand-waving arguments, let's get to more serious flaws.

The recommended key length: 16 KB + 16 KB

Author recommends key length of 16 KB (for "key") and 16 KB (for "salt"). That's 32 KB in total. Yes, kilobytes. The largest key length in common use today that I was able to find is 4 Kb for RC4. That's 64 times smaller! This key overhead is really significant, especially if you're trying to encrypt small files.

Every key produces different output, right?

One of the most prominent features of one-time pad (or any good cipher) is the fact that different key produces different output. This is in fact really important, because if two (or more) keys produce the same result, we can reduce the key space to brute-force. This means that having a big key size can amount to nothing, because in fact you only have a handful of ciphertexts.

Let's see what the following key will do with the plaintext:

2, 1, 4, 3, 6, 5, 8, 7, 10, 9, ...

So, the first bit will be negated and switch with the second one. Then it will be negated again and will get back at his original position. And so on... So, using that (seemingly proper) key, you'll get the same ciphertext as plaintext - no encryption at all. And, as you can prove yourself, this outcome does not depend on the number of rounds used.

Now, Do you know what will the following actual key will produce?

3, 4, 1, 2, 7, 8, 5, 6, ...

Hmmm... I'm wondering if there is a pattern. Maybe something like this:

Choose any permutation (p1, p2, ..., pn) of values 1, ..., n where n is the (even) key length.
Let the key (k1, k2, ..., kn) be:

k(p2*i) = k(p2*i+1) for i = 1, ..., n/2
k(p2*i+1) = k(p2*i) for i = 1, ..., n/2

Hence, every permutation can produce a key that does nothing to the plaintext. That's at least n!/2^(n/2) keys that will not encrypt the plaintext. Why "at least"? There are other keys that can do that, but I'll leave it as an exercise for you.

What happens over 64KB?

Since the actual key can only tell the algorithm to swap current index with index byte(key, i) * byte(salt, i) < 65,025 so any bit (or byte) after 65,025 can only be swapped with bytes that come before that mark.

Hence every bit over that mark will be negated. If you have odd numbers of rounds, this means that above some mark most of the bits will be negation of the plaintext bits. If you have even number of rounds, above some mark most of the bits will be actual bits of the plaintext. They may be at different places of the ciphertext though. And that leads us to the final question...

Is the ciphertext really, truly random?

The author says it himself:

Thus, randomness in the ciphertext is a very strong indicator of strength in the cipher.

And, as we saw in the previous question, it may not be true. Let's assume that we have really large (e.g. 1 GB) file filled with zeros. Using the observation that we made above, if we use 1 round of cipher, we will get a lot of ones. How much? Well, all of the zeros above 64Kb will get converted to ones, no matter what key we will use. Of course, they can be in a different places in the file, but they still will be ones. That's approximately 99.9992% of the ciphertext filled with ones. That doesn't seem like "random" and certainly not approaching (or exceeding) random sources based upon radioactive decay.

Summary

I've learned a lot playing with that simple and obviously broken cipher. I hope you learned a lot by reading about my journey. I'd like to thank Martijn for the information about that cipher - it was just at the right level for me to learn some cryptoanalysis techniques and see how real ciphers should look like. Bottom line is that Crystalline Cipher looks like it started as a simple shuffle and then author applied patchwork at few steps to answer problems it posed to his cipher. I know that mindset from working on several projects and it is never, ever a good idea.

Anyhow, that's my weekend story for you!

Android malware goes Mono and Lua - part 2 (Ransomware)

noreply@blogger.com (Unknown) — Wed, 13 May 2015 10:00:00 +0000

In my last post I described an interesting malware family that used Mono and Lua virtual machines to obfuscate its behavior. Lately, it has been packed with new features and upgrades, which are meant as a forensic countermeasure. Let's examine these updates and see why this botnet is different from the other Android botnets.

Retrospective: Lua and .NET

But first, let me remind you how this malware is build. Diagram below shows one of the malware main components - SMS Broadcast Receiver.

How does it work exactly? First, a BroadcastReceiver is registered in the AndroidManifest.xml file. This Broadcast Receiver, in its static initialization block, registers an n_OnReceive function from a native library, libmonodroid.so, using a function call presented below.

This call specifies the .NET function call which will be used for n_OnReceive (Z.Core.SMSReceiver), library which will be loaded (Leader.dll) and some other parameters. The Leader.dll is then loaded from libmonodroid_bundle_app.so, which contains a bunch of gzipped DLLs written for Monodroid VM.

So, essentially Broadcast Receiver code is passed on from Java to Mono. But that's not all! This call is then passed to the Lua Script called "onSMS". This Lua script is run on the KopiLua VM. But this, and many other similar Lua scripts are not bundled with the APK. They are downloaded from the C&C and cached in a structure List<LuaScript>. They are not saved in the phone's file filesystem, instead they are downloaded each time the service (or phone) is restarted. This is different from the previous version which used Virtual File System to store Lua scripts.

You can see the Lua caching and calling mechanism in the screenshot below.

This approach - downloading Lua scripts from C&C - allows for a maximum flexibility and almost instantaneous change in attacker's goals. He can send Premium SMS or steal online banking OTP or do anything really, easier than when using standard RAT or backdoor.

Retrospective: network communication

This malware uses a special protocol over HTTP to communicate with the C&C server. In the Z.Core.Packets package (or whatever it's called in .NET) we can see several classes:

These classes are responsible for creation of the messages that are then sent to the C&C server as a body of POST request. Each packet has an ID (which maps to a command) and then some parameters, if the command requires it. Supported commands are:

1 - registration with IMEI and two countries (both values hardcoded to "111")
2 - bootstrap packet with AES key and IV, bot id
3 - script packet with answer token, script content and md5 checksum
4 - echo packet with token and text
5 - SMS received packets with message text and phone number
6 - Contacts packet with a number of contacts and list of name and phone number pairs
256 - get task packet with token
12 - task done packet with token
19 - set variable packet with variable name and value, used to set variables in Shared Preferences
28 - version data packet with token and version data

What are tokens? Well, they are used to identify the bot.

What does the typical communication look like? First, you have to register. You do this by sending registration packet (id = 1). In response, you'll get a XOR key. You have to randomly generate AES key and IV and send them to C&C encrypted with this XOR key. Now, all the following communication will be encrypted using this random AES key saved in the Share Preferences like so:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>
<map>
<string name="id">8683</string>
<string name="token">516c9d8a-95f4-4552-b549-abb398ec1a7c</string>
<string name="registered">OKAY</string>
<string name="adm">trux</string>
<string name="aesIV">H2DIQX2WW7qgU0nOyhf/LqN0EZCXtBcr5roevejKSVo=</string>
<string name="aesKey">18f7cyFDKPn3pdxRQCpT61C0U7qK8BnUkc/FaFvW7DI=</string>
<string name="lckd">false</string>
</map>

As you can see we have bot id, token, registration status, Device Administrator status, AES IV and key (base64 encoded) and locked (ransomware) status. This last parameter will be described below.

Attack scenario

Every sample pretended to be some kind of popular app, like Skype or Twitter. Current version, after accepting the Device Admin privileges, uninstalls its shortcut. Then, we are only left with service running in the background. This service displays, after some time, notification shown below.

For those of you, who don't speak Russian, this means "New Licence Agreement". When you click on it, this bogus licence agreement is shown:

If you scroll all the way down and click on "Accept" you are asked to provide your credit card details:

So I was hit with a simple social engineering attack. There are layouts prepared for other types of social engineering attacks designed for banking apps or Chrome browser, but I was unable to invoke them and since this relies heavily on the C&C communication it may be hard to analyze them.

However, as I mentioned before, we can imagine all sorts of attack with such a flexible architecture. What other attacks, you may ask. I'm glad to show them to you.

New features

Newest sample can also lock your phone and demand ransom to be paid by sending funds to a prepaid phone number. This is done by displaying to you the following, rather nice looking, information:

It says that because you viewed child pornography and bestiality you have to pay a fine of 500 rubles (~ 10 USD).

Technicalities are rather similar to other simple lockers: it periodically invokes the activity displaying the lock information and wants to irritate user so much that he will pay the fine. It's all implemented in the Mono code, snippet of which is shown below.

Another new "feature" is the fact that application has disabled logging mechanism, which makes it harder to analyze, but you can still enable this feature. If you can recompile .NET code. On Android.

And finally there is the casino. This malicious app goes to the casino website, presumably only to generate traffic and ad revenue. The code of the Activity that visits the website is shown below.

In conclusion, this is one of the most advanced Android botnets and it's really packed with different features and allows the attackers for the easier control of the phone than most other Android RATs. It also uses interesting code obfuscation techniques, which makes analyzing it a (fun) challenge!

Android malware goes Mono (.NET) and Lua!

noreply@blogger.com (Unknown) — Thu, 26 Mar 2015 11:00:00 +0000

In December I attended a (really great!) Botconf 2014 conference. During that conferece I gave a lightning talk about an interesting Android malware sample that (presumably) used Lua and Mono (hence, .NET) as a way of obfuscation. Very recently @tbiehn Tweeted to me a solution for a problem that I run into during the analysis. So now, below, you can find details about the weird Lua/.NET/Java Android sample.

It says "Please wait, loading data"

Quick overview

It starts fairly innocent, with an app called Metrics.Me and it has a pretty standard malware permissions, as can be seen on a screenshot below. It uses a VKontakte icon, probably to pose as a kind of social media app. The main and only screen of this app is shown above.

Let's start with the usual place: the SMSReceiver. And now things get a little complicated. There are a lot of references to the "monodroid". It turns out that this is actually a Mono (.NET) implementation in Android. So, presumably, this is written in Mono. There are also some references to the Runtime.register native functions (shown below). How does it all work?

The register function accepts three parameters: first one is the string defining the DLL and .NET class which will be used to load the native functions. In this example Metrics is the DLL name and Z.Core.SMSReceiver is the class. Second parameter is the class to which this functions will be applied, in this case it's the same class, namely SMSReceiver. Last parameter is a string which defines a mapping between a .NET function and the native function declaration in the class.

And if you look at the sample, all of the classes in z.core package use this .NET class loading methods.

Mono and the mkbundle

So, first you need to register a method using the native-implemented Runtime class, which is a part of the Monodroid native library. In this way you can almost transparently use the .NET code in your Android app. However, if a DLL file on Android is still a little too transparent for you, you can go a little further with the obfuscation. Just use the mkbundle tool! It's a tool that combines all of the DLL files to a native .so library, e.g. for ARM processor. This is usually called libmonodroid_bundle_app.so and contains gziped DLLs (all of them) with their appropriate file names. You can see it by disoplaying the exports of the .so file, as pictured below.

As you can see there is a mono_mkbundle_init export and a couple of exports called assembly_data_ which are just gziped DLLs. So, you probably want to extract them. You don't have to do it manually now! You can use my script to extract all of the files, as I did. So now we have files and we can look at them and see what this malware does.

.NET code & Lua

For the .NET code I used a free dotPeek decompiler, which I cannot recommend enough. You can see the onReceive method below and experience the weird cognitive dissonance by reading a .NET code using Android libraries.

And when you dig a little deeper, you can find a very interesting sets of functions. Like for example the GetScriptFromServer function which does the following.

Crafts a specific HTTP POST body content, which contains, among others, a token and MD5 checksum.
Sends the request to hxxp://109.73.170.147/news/news.php (PHP - now we have even more programming languages!). Although the https is not used, the request body is encrypted using AES.
Depending on the response code it either downloads or uploads a Lua (yes, Lua) script.
The script above is then executed on the Lua interpreter implemented in the Mono environment on the Android platform. Just let it sink for a while.

Function is presented on the screenshot below. AES key and IV mentioned above are actually generated randomly and exchange on the first contact with the C&C server. This registration process goes like this:

Bot sends a device ID included in it's registration packet to the server.
C&C responds with the confirmation and includes a XOR key.
Bot generates (randomly) AES key and IV and sends them (XORed) to the C&C server.
C&C server acknowledges the key and IV. This parameters will be used in any future communication.

But the anti-reversing techniques go even deeper. Actually, the Broadcast Receiver source code was delivered by the server so there is no way to actually get to know the code once the server is down. Hence, I cannot really say what was done once the SMS was received. The same goes for the boot Receiver.

But wait, there's more. Have you ever heard about the Virtual File System? Of course you have! However, this VFS is just a simple interface that makes directories more available. Nothing really fancy there. However, it looks like it was just a placeholder and may be evolving in the next versions of this malware.

Summary

This app is one of the more sophisticated Android malicious apps on the market. Author went to great lengths to obfuscate the code and even used some anti-forensic measures. It has some unique capabilities (like the fact the the Broadcast Receiver code is actually kept on the server... in Lua). And you have to admit that running Lua on top of Mono on Android is pretty impressive.

After I typed this post I discovered a framework called Xamarin which lets developers write apps in C# for the three most common mobile platforms: Windows, Android and iOS. There are some artifacts named "Xamarin" in the sample, but the C# code looks like it was created for Android platform (the use of native Android functions and concepts, mix of the Java and C# code). If anyone is more familiar with Xamarin please have a look yourself to see if this is indeed a Xamarin app. Although I think this is highly unlikely. But if that turns out to be true maybe you can find a Windows or iOS version of this malware? Cross-platform would make it even more interesting.

And if you managed to read this post to the end, I have a little easter egg for you. Below is one of the package names in the sample.

Thanks, Obama

Porno-locker - nice icon, not so nice functions

noreply@blogger.com (Unknown) — Tue, 03 Mar 2015 10:30:00 +0000

Recently @PaulWebSec made me look at porn (now, will you risk clicking on that link? ;). Well, at least he advertised it as such, but it turned out to be just another fake Android porn app, which in reality was just a ransomware. It even has a kind of NSFW icon, but you have to get the sample to see it for yourself.

Anyhow, let's have a look at the code. It uses a lot of interesting permissions: camera, call log, contacts, Internet (of course), location and so on. It also has a bunch of activities, one of which is affectingly called TerrifyActivity.

Overview

When we start the app, AndroidManifest says it will start an Activity called MainActivity. And by looking at it it does nothing. Absolutely nothing, apart from creating some variables. Actually, the startup code is in the MainApplication class. This, in turn, starts the MainService3 class. A WakeLock is also put in place - to make sure that the device is on. We are asked whether we will allow this app to be Device Admin. It does not use any polices, it just wants to be the Device Admin so we won't be able to uninstall it using pm uninstall command.

This locker also can use Camera - class b takes a picture and saves it as fastness.jpg. Then, by using code in class h this picture can be downloaded by any website loaded to WebView via exposed JavascriptInterface. What this means is that the attacker can easily obtain a picture of the victim using Javascript. Interesting functionality.

Class e is responsible for the device locking. It implements three listeners: View.OnClickListener, View.OnKeyListener, View.OnTouchListener. Each of them is responsible for intercepting different event and making sure that the lock screen stays on top. By intercepting this events we cannot change the View and the phone seems locked.

In order to be even more persistent the view has the following flags specified:

FLAG_LAYOUT_IN_SCREEN - take entire screen.
FLAG_FULLSCREEN - hide decorations.
FLAG_SHOW_WHEN_LOCKED - shows a window even when the screen is locked.
FLAG_DISMISS_KEYGUARD - no keyguard.
FLAG_TURN_SCREEN_ON - screen is always on.
FLAG_HARDWARE_ACCELERATED - hardware acceleration. Because, why not?

As you can see this provides an almost kiosk-like mode on your device. Fully locked. Well, you can still kill the process from the adb I guess :) However, there is a slight bug. You cannot scroll the website, because the scrollbar has been disabled. So, you get the message shown above, but you cannot do anything about it.

There is also an interesting BroadcastReceiver called MainReceiver2 that responds to a couple of intents:

This is to make sure that the locker is running, even if we e.g. reboot the phone. A bit aggressive, don't you think?

Other interesting stuff: every time you change your location it is saved in the eloquence.xml shared preferences. Class g is responsible for that and implements a rather interesting Android feature called MessageQueues. Speaking of the shared preferences, here is a small snippet of this file:

<?xml version='1.0' encoding='utf-8' standalone='yes' ?>

<map>

</map>

As you can see names are rather strange. For example mouse and reeling are the location parameters. And, just to top things up, below are the basic device information that are stolen.

Reports are sent in a base64-encoded JSON format. For debugging purposes also stacktraces are sent via this channel. In the end user is presented with a kiosk-like WebView of a website that the attacker has prepared.

Obfuscation

The class net.biologist.a contains all of the "encrypted" strings. This are just base64-decoded string that have been prefixed with some random values. So, first you have to de-base64 and then just start reading them starting from a specific index. All of the decrypted strings, along with their indices in hex and decimal are available here.

Class net.biologist.cf on the other hand is something quite interesting. Most of the functions used in the sample are hidden there and are obfuscated by using a different, meaningless name. For example instead of invoking StringBuilder append method on String, you would call cf.c101(StringBuilder, String). A snippet of this class is presented on the screenshot below.

Class c if also used for obfuscation - some of the strings from a class are even further obfuscated by assigning them to some random members of the c class, as pictured below.

Android Malware Tracker

And now for something completely different. As you may be aware from my Twitter I started a really small project called Android Malware Tracker - amtrckr.info. The idea behind it is that sometimes I encounter a sample that I have already described or is interesting, but I don't have time to take a closer look and I want to put it out there. And that's my way of "putting it out there" and, as a bonus, you get the C&C data. And there even is an API so that you can easily put URLs, IPs or domains on your blacklists. Have fun and if you have some interesting sample you know where to find me.

New iBanking - KitKat SMS bypass done wrong, obfuscation done right

noreply@blogger.com (Unknown) — Fri, 09 Jan 2015 10:00:00 +0000

iBanking malware seems to be on the rise recently. It is not a new malware, it's circulating for more than a year now, but it seems to be the go-to choice for some of the more popular e-banking attacks. It's usually coupled with the PC infection (by some webinject-capable malware), which convinces the user to install either a "specially crafted" banking app, antivirus solution or some other uses trustworty-sounding name.

Anyhow, I recently got my hands on two interesting things: one is the "new" iBanking sample, which tries to fool Android > 4.3 SMS_DELIVER mechanism. The second one is the panel and the builder of the iBanking. Let's have a look, but first a quick recap of iBanking features and modus operandi. We will be looking at this sample.

Templating

iBanking has a dozen of what it calls "templates". Each template is in fact one of the apps that iBanking pretends to be. So you can have a template for a specific bank, a template that makes it look like mobile antivirus and so on. Templates differ slightly in the layout, but mostly in the provided graphics and color scheme, although some of them seem to support specific commands (more on that later on). Dr. Web template is presented on the screenshot below.

Looking at the (leaked) crimeware kit it seems that the buyer has to specify a template that he or she wants. This way if the template gets "burned" the attacker has to buy another one, effectively paying for the same malware twice. If you have any additional (or entirely different) information about the sales tactic, feel free to contact (and/or correct) me.

However, you can still make some personalization when you get the crimeware kit. You can change the hardcoded C&C numbers, HTTP C&C URL and bot ID. All of these changes are done in a curious way. Crimeware kit comes with an app sample that is disassembled (using apktool), then sed is run to replace the variables and then the app is assembled (again using apktool) and signed. Screenshot below illustrates part of that process.

SMS communication

iBanking is certainly one of the most feature-packed Android trojans (although it does not try to decrypt the WhatsApp messages like FinSpy did). If you have a look at the ek class you'll see a list of SMS commands, some of which are:

wipe data - does a factory reset, sent as a last command to prevent device forensic,
sms start <number>/ sms stop - starts and stops SMS forwarding to a specified number,
call start <number> / call stop - starts and stops call forwarding (done using the *21* code),
sms list / call list - send a log of text messages or calls (respectively),
start record / stop record - starts and stops audio recording (using the mic in your phone),
greed - this is unusual. It will display a notification with some text to the user and switch the app main view. It's only for one template and I don't have a sample with that template so I'm not sure what the notification text is and what the purpose of it is.

How does the app know that the command was sent from the attacker and not from the third party? Either because the text message was sent from one of the two hardcoded C&C numbers or the number that previously authenticated itself. Authentication is performed by sending the hardcoded password. This way the attackers can change C&C if they lose the phone number. Clever, huh?

Encryption and obfuscation

The fun part is also the encryption that they use to hide the actual password in the app. Previously the password was stored in plaintext, but now it's encrypted using propriatery algorithm pictured below (can be found in the cD class).

As you can see b is responsible for converting the hex-encoded text to actual bytes. Then, in the last two lines of a, the encrypted message is xored with a keystream made using an "almost" LPRNG, but it includes not only the keystream variable but also the ciphertext byte. All in all, seems like a good effort in cryptography, not a usual xor with a byte.

And there's more! In the same class we have two method declarations that have the same name and same arguments, but differ in the static modifier and the returned type. One is:

public static String a(String paramString)

and the other one is:

public final byte[] a(String paramString)

Surely, Java does not allow for such an abomination, right? That's true, Java doesn't (and don't call me Shirley). When I tried to reproduce this I've got the following error:

error: method a() is already defined in class ...

However, smali is more flexible. After some testing it seems that Dalvik VM takes into account also the returned type. So if you compile the project, then disassemble it using apktool, change method name, build it and run, you can have two methods with the same name and arguments. But you don't have to believe me, I've prepared a MWE and you can have a look for yourself.

Despite my best effort, I cannot seem to invoke the non-static (instance) method. All in all, it's a really good obfuscation that fooled me during this analysis.

SMS_DELIVER

Since Android KitKat (4.4) there is a new approach to handling the text messages. There is a special, designated SMS app and there can be only one. You can of course change it - for example when the attackers try to convince you that you'll be better off with their app. However, if you don't change it you will be notified about every incoming message and every outgoing message will be recorded. This, of course, is a behavior that the criminals do not want, especially when they forward your SMS OTP messages. So they implemented a workaround which is a little... wrong. Let's have a look.

So, if the version number starts with 4.4 then mute the audio. This of course will somehow work - user won't be notified of the incoming message by sound, but there is a problem with the notification bar, which still shows that you received a text message, because it is the newest notification. Apart from that, there is also another problem. It will not work on Android Lollipop, which is 5.0.x version. And 5.0.x does not start with 4.4.

What about the HTTP?

Well, HTTP is really not interesting and is left rather unused. However, I did find two active panels using the mighty powers of the Google search engine, so I wouldn't say it is extinct. One is even in the .ir TLD.

Iran, secret text messages and a toy for a holiday break

noreply@blogger.com (Unknown) — Sun, 21 Dec 2014 22:24:00 +0000

So I recently tweeted about some interesting Android app sample. This app either is or pretends to be an Iranian banking app. I couldn't take a closer look at it (there is a bit of a language problem for me), however it uses the Ansar Bank name and graphics (as you can see on a screenshot below) and also uses a very interesting text messages feature that I was not aware at all.

The curious case of the SMS protocol

Text message protocol is pretty straightforward on the high level: it allows you to send a 140-byte message to the other phone. Wait, I surely meant 160 bytes, right? No, it's a 140 bytes, but it's using a plain 7-bit ASCII encoding without those fancy characters like the one at the beginning of my name. This allows you to send precisely 160 ASCII characters.

As you probably all know, we can send more than 160 characters, but it will be broken into several messages. However, mobile phones seem to be OK with that and let you create a long message and the receiver also can read a one, long message without even noticing the split. How is that possible? SMS protocol specifies something called User Data Headers (UDH for short). These headers are sometimes present at the beginning of the text message and allow to send multipart messages, ringtones or include fancy characters with their pretentious UTF-whatever encoding. There is also a flag bit to indicate whether the message contains these UDH or not.

Let's have a look at the example of multipart message header (taken from here):

05 00 03 5F 02 01

This header would be at the beginning of your text message and, if your phone wasn't so ergonomically designed, it would be rendered as a bunch of characters. First number of the UDH specifies the header length (5 bytes, excluding the length byte). Then there is a header type, in this case meaning that this is a concatenated message. Then there is another length (3 bytes). Then there is one byte message ID, shared among all of the message parts, then the number of message parts and, finally, this part identifier.

Header in the given example means that this is first of 2 messages with "thread" id 5F. So, why am I explaining all of this? Because there is a little known (at least I didn't know about it) feature of the SMS protocol that allows you to specify "port" information. This is used e.g. for the WAP Push messages, which are just plain SMS messages but with a specific UDH. This UDH looks like that:

05 04 03 <destination port (2 bytes)> <originator port (2 bytes)>

The 2-byte values are called "ports" because they are meant to be used to identify a service. Some app in your phone "binds" to a port and listens for all the messages to that port. Another app "binds" to a port and sends SMS from that port to your app - directly. You can also use 00 00 as the originator port if you don't need a specific port.

How are these ports handled on Android?

This is a really good question! First of all on Android they are called "binary SMS" or "data SMS". Apps that want to use them have to have the standard SMS permissions: android.permission.RECEIVE_SMS and android.permission.SEND_SMS. Next, the Broadcast Receiver has to have somewhat different declaration, like the one in the picture below (taken from an Iranian app mentioned previously).

As you can see you have to declare a port and the scheme. Apparently there are two different addressing schemes - one which uses two byte port number and one which uses 4 byte port numbers.

So, I wanted to experiment with it. After some Googling (which is nowadays an equivalent of "Research") I found out the the Android emulator does not handle port messages very well. Or even at all. So I decided to have fun with it using my real phone. My very real phone has Android 4.3 installed and my other test phone has Android 2.3.6. I've sent a binary message to both phones and neither of them displayed it. It just went to the dark hole. No notification, nothing. However, my billing statement showed that I indeed have sent the messages. That's a covert C&C channel for you!

Summing up the features of a new (at least for me) SMS C&C protocol:

Binary text messages received to a custom port are not displayed in any way (not even in a form of notification) - that means no more abortBroadcast() nonsense and no problems with KitKat and above!
They are not saved in the "Sent" folder!
They require the same permissions as "normal" text messages.

So go and have fun with binary text messages during Christmas! If you'd like to experiment with them as I did, I suggest you use the kvarma-android-samples SMSDemo app which I also conveniently compiled and signed just for you! Usual disclaimer: I do not take any responsibility for your phone bill or any other material and non-material damage the app makes to your phone or to you.

Have fun!

CloudAtlas - commercial-grade Android malware

noreply@blogger.com (Unknown) — Mon, 15 Dec 2014 10:00:00 +0000

Few days ago Blue Coat published a whitepaper about so-called "The Inception Framework": a commercial-grade malware used in some more or less targeted attacks. The paper describes the details (with some nice pictures) and outlines an Android app used in this attacks. Because AV companies seem to stick with the "CloudAtlas" name in their signatures for this malware I will use the same name. Let's dive a bit into the most interesting bits, which I haven't seen in the Android malware before.

The "you can't see the log name" trick

First things first: it's a commercial-grade malware and is written as any commercial software would be - one class has a single responsibility, everything is logged and the code looks clean even after the decompilation. If you're a software engineer in a big company you probably recognize the function names presented on the screenshot below (maybe you even use the same names in your project?).

It also uses a simple obfuscation techniques that we got used to. It pretends that it's a "WhatsApp" update, which is a common theme in the commercial-grade malware segment - FinSpy suggested a similar infection vector for its customers. Anyhow, let's start with a log file, which has a really interesting name that I cannot write. Not because I don't want to, but because it's a white character, namely System.getProperty("line.separator"). This, on Android, should be the newline character (\n). Below is the code responsible for the logging and, as you can see, static member b holds the name of the logfile.

The logging mechanism is pretty extensive - it logs every action so the forensic analysis of the infected phone should be a piece of cake.

C&C hosted on the blog

Malware does not seem to use the SMS C&C, it only uses the HTTP. Well, actually it is more complicated then this. It uses a livejournal blogging website with three different blog addresses. These are supposed to look like a legitimate blogging websites (at least according to the Blue Coat whitepaper), but they also contain something extra - a blog-index tag. Malware searches for this tag and its content, as you can see below.

This search returns one or more base64 encoded strings. After the decoding there is also some kind of a custom encryption scheme, some part of which is presented below. If you want to know more see the g, i and c classes in the sample.

This extra tag content provided both the dropzone URL and the commands (or rather "tasks" as it is called in the malware). It should be pointed out that this is a known technique in the Windows malware. Anyhow, very nice feature for an Android malware! I haven't seen it yet.

From what I gathered, apart from the features mentioned in the whitepaper (call and audio recording, location, contacts, text messages etc.), this malware could also load a DEX file downloaded from the C&C server. Another nice feature, right? Also, it has an awful lot of log comments in Hindi. Overall, well-written and somewhat creative malware.

How does the PornDroid (aka Koler) work?

noreply@blogger.com (Unknown) — Mon, 24 Nov 2014 20:33:00 +0000

Recently Kafeine identified a CP ransomware for Android. The idea was the same as with the previously identified one for Windows. Victims were presented with the Child Pornography pictures, their browsing history and their image (snapped from a camera) plus some phone-identifying features. The message said that some FBI/PRISM/NSA or any other entity wants you to pay a "fine" in order to unlock your computer. Pretty standard ransomware, not unlike the one I previously described. But, unlike the one mentioned in previous posts, this one was actually a little more complex. So, if you want a general overview, go to the Kafeine post and I'll present a look under the hood here.

How to do a ransomware?

Well, it's not that easy. As we've seen previously you can just display a message every couple of seconds. We've seen that the previous app used scheduleAtFixedRate function to ensure that the lock message is always displayed. This app also makes sure that it is always visible, but does it using a startActivity at some predefined time. Activity is just a ransomware window. Even if you navigate to some other window, a background service will make sure that the ransmoware is on the top. Take a look at the simple code below that does just that.

That was easy. However, you also have to make sure that you can unlock a phone after user pays the ransom. From what I've seen ransomware cybercriminals make sure that, if the payment was made correctly, your computer or smartphone is unlocked. Previously described app made it by checking the C&C response. This one does it in a different, more interesting way. It exposes a JavaScript API that gives the attacker shell on your phone. Ransom message is just a website, so the attacker can use e.g. AJAX to control your smartphone. JS API is exposed using a JavascriptInterface decorator (or Annotation as it is called in Java) and exposes three methods, as you can see below.

Some tricks

This malware uses also some "encryption" tricks like reversing strings represented as bytes (see below).

It also uses Interfaces extensively so that you will lost a count of what class represents what. This is a really nice obfuscation technique, which is, coincidentally, also the underlying technology for the Java Spring framework. Other nice feature is the fact that if you try to get rid of the application Device Admin privileges, it will lock your phone and display a message confirming the action (see below).

There is also one other obfuscation technique that was not used in this particular sample, but the code is written in such a way that it made me think of a subtle Java based obfuscation. See, when you have Interfaces in Java you can use any class that implements that Interface. You can also use reflection to load that class (so that you don't have those pesky imports). Now, let's assume that you have several implementations of one Interface - as it is usually a case. Now, you start an activity using an Intent and send the appropriate location of the class that implements Interface as that Intent parameter.

Not only that, but you can take it one step further. Instead of simply sending a fully qualified class name, you can send a hash of class name. Then just go trough every class name and compare it with hash. This is a variation of the technique used in Windows malware to load DLLs or DLL functions. The researchers will have no idea which class you are using. However, unlike in the case of Windows malware you still have an Interface to interact with, so you will have those IDE tips and auto-completion. Win-win, right?

How to check for a root access in three ways (plus a C&C demo!)

noreply@blogger.com (Unknown) — Sun, 19 Oct 2014 20:44:00 +0000

Recently I have found a sample of DroidJack, which is somehow the same as Sandrorat described previously. Well, it is probably created by the same author or at least on the same code base. What leads me to that conclusion? Well, see it for yourself in the screenshot below.

How does the DroidJack C&C look like? I've found this little GIF demo in one of the DroidJack ads (if you haven't seen it already this means that you don't follow me on Twitter and you should):

So, the pretty much standard stuff for the more complex Android malware: you can do everything and get a "binder" i.e. program that lets you add DroidJack "features" to the benign apps. What else did the author of DroidJack and Sandrorat made? This app available in Play Store that is a kind of Sandrorat in reverse - you can use a mobile phone to "control" your computer.

Checking for root in three ways

Enough about the authors, let's go to the main point of this post. I find a way that DroidJack checks for the root permissions on the device rather interesting. Important note is that this malware does not depend on the root permissions, it just checks if it has them. And, as you probably know, if you have rooted your phone and you have given root permissions to any suspicious app, you're most certainly fucked.

First way of checking if the phone is rooted is the usual checking of the su availability using which command. Nothing too fancy, as you can see on a screenshot below.

Next up is a not-so-common checking for the Superuser.apk application. Pictured in the screenshot below.

Finally, something that I see for the first time. Checking if the build is signed with test-keys. This is a popular way of signing custom ROMs and, presumably, if you have a custom ROM, you most likely also rooted your phone. While this may be a kind of bet, it's fair to say that it's a safe one.

I'll try to look at this DroidJack sample a little more. Meanwhile, let's play "The Price is Right"! What do you think this piece of malware cost? $20? $50? Surely not over a $100, right? Have a look at the illustrated answer below.

And for that little price it stays with you for the eternity...

WhatsApp with FinSpy?

noreply@blogger.com (Unknown) — Tue, 14 Oct 2014 18:55:00 +0000

I think you heard about the infamous FinSpy by FinFisher. If you haven't it's basically something like a cloud one-way backup app paid by (someone's) taxes (and there's a ~~movie~~ really shitty render!). Anyhow, the mobile version seems old news, as it was unveiled some time ago and even one AV vendor called it nothing new in terms of features. Well, I guess it depends on how you define a feature. But enough of this rant, let's go and see what a commercially made malware looks like.

I've analyzed the newest sample that I could find and it's a couple of months old (md5: d6a3ca6e48512890d013e922307e1593). It has some usual features, like SMS reading and so on, but today let's have a look at one particular feature: WhatsApp eavesdropping. WhatsApp is a very popular messaging app. Probably it was chosen by FinFisher due to its popularity or maybe just because one of the clients requested "support" for it.

But before we begin let me state that this malware is one of the best written malwares I've seen in a long time, in terms of coding. It properly uses Intents, has a nice, commercial-grade class structure with clear responsibilities for each component. It is truly a commercially developed malware and up to the market standard. Nice to see some clean code once in a while. But I guess this is what you should expect from a malware which price starts at 200000 (that's two hundred thousand) Euros.

Decoding WhatsApp

FinSpy can only decode older, .crypt files created by WhatsApp. First, how does it have access to the message database without needing a rooted phone? It's really simple. WhatsApp performs message backups every day. This backups are saved in the /sdcard/WhatsApp/Databases directory (take a look yourself). They are of course encrypted, using AES cipher. New version uses crypt7 extension and a new key derivation algorithm (key is saved in the private app folder). Older version used crypt5 extension and key was derived from the Google account name. Even older version simply used crypt extension and was using... hardcoded key.

The hardcoded key was 4j#e*F9+Ms%|g1~5.3rH!we, and is well-known now (well, at least at some corners of the Net). FinSpy can decode those message databases and the decoding routine is in the com.android.services.WhatsApp.a class, as pictured below (hardcoded key is highlighted).

The decoded file is then saved to the FinSpy folder and analyzed. This is done each time an android.intent.action.MEDIA_SCANNER_FINISHED is received (so presumably there's been a file changed on the SD card).

Let's see whats the analysis made of. First malware creates a "tmp521" + System.currentTimeMillis() + ".dat" file where it stores temporary information and is then renamed according to the similar pattern, but without the "tmp" prefix. It saves time (and timezone information), user id and, of course, the message text itself. The format for it seems to be:

<formatted_time>[TAB]<from_id_or_number>[TAB]<to_id_or_number>[NEWLINE]

It has a nice parsing code, which remembers to add plus (+) before the number, strips the unnecessary "whatsapp.net" from the remote identifier and get user account name from local accounts (because it is not saved in the database). The part that gets the user account name is presented below, the parsing part was to big and boring to include.

So I guess that's it about the FinSpy WhatsApp "support". However, this is not the last time that I will be analyzing this app, as it is packed with interesting code and is, surprisingly, not too obfuscated. The chilling part is that they are really committed to writing malware and reversing the popular apps in order to gain advantage. Perhaps even more chilling is the fact that WhatsApp used to save our messages, almost unencrypted, on the SD card for anyone to see. Well, it has changed now, but maybe FinSpy has been updated too. Who knows...

(Almost) a FUD: another "Porn App", this time Italian

noreply@blogger.com (Unknown) — Sat, 11 Oct 2014 09:59:00 +0000

I like FUDs, because they must show creativity either in packing or in the code. Anyhow, they are almost always interesting to analyze. Recently I came across a "porn" app targeting Italy (md5: 0995aceaeb8e338aff542ab3f1d8dab4). When you run it it displays an ansa.it website, which I guess is a kind of Italian news site. But what it does in the background is really interesting.

Quick look

First off the app is still in the making and let me tell you the author devotes 5 hours a day to make it work! He (or she) is really trying to make it both FUD and powerful and I have to tell you that it starts to shape up with some nifty features. There are still a lot of blanks, which maybe will be filled in in the future. Look at this beautiful icon (remember that it is supposed to be a porn app):

Second up, the strings. They are encrypted using DES encryption in a famous Adobe mode with "Some Key" key. All of the strings seem to be encrypted, even the ones popular in Android apps like "pdus" or "com.android.launcher.action.INSTALL_SHORTCUT" action. And this action is used to create a shortcut on your desktop with the same icon as above.

Some of the telephone info is send to a C&C server located in San Marino (that's new, right?). Below is a list of stolen data.

Now to the interesting parts! It has a kill switch implemented, which activates after some predefined time. Before this time a specified number can send a short message instructing the app to send SMS to another number. This is probably done to facilitate the Premium SMS feature, where the attacker can make money out of paid subscription services. Unfortunately no number was provided in the sample. After the kill switch gets activated the SMS sending features are disabled.

Other interesting functionality is the Hidden Browser. This is an Activity that displays a website in the background using Theme.NoDisplay and excludeFromRecents parameters in the AndroidManifest file, as shown below. As you can see MainActivity uses the same tricks.

This activity can open a website and then, when the page is loaded, open a different URL or execute a piece of JavaScript code by passing the javascript: "protocol" to loadUrl of the WebView. In this, what I believe to be a test sample, executed JavaScript was just a simple redirect. Moreover, at least for now, the executed JavaScript is hardcoded to be a redirect and there is no way to change it other then rebuilding the app.

Hidden Browser is meant to be run using an Intent and has an Extra String called "link" specifying the redirect. The page that is opened up before the redirection was hardcoded to be google.com. Using this Activity you can covertly make the Android visit a specific website.

It also gains persistence using a standard BOOT_COMPLETED Broadcast Receiver.

Summary

Both strings and permissions show that the next implemented feature will be stealing contacts. Let's wait and see how the app will evolve. In the meantime, for all the Blade Runner fans, this is an excerpt from an app certificate:

Issuer

DN: C=IT, ST=Italy, L=Rome, O=Tyrrel Corporation, OU=R&D, CN=Marco Rossi

C: IT

CN: Marco Rossi

L: Rome

O: Tyrrel Corporation

S: Italy

OU: R&D

Android ransomware with a Direct3D DLL

noreply@blogger.com (Unknown) — Fri, 03 Oct 2014 19:10:00 +0000

Recently I came across the Android ransomware sample (sha256: c0cb135eef45bb8e411d47904ce638531d53473729c7752dc43c6d55d5ed86f8). This sample is interesting for a couple of reasons, but there is one truly bizarre property of this APK file. It has a raw file included, which actually was a Direct3D library signed by Microsoft. Why a Windows-based DLL file is included in the APK file is just beyond me. Anyhow, let's get back to business and have a look at the sample and what it does.

Quick look

First things first. The app pretends to be a NFS Hot Pursuit Android game, straight from the EA. Both the app name and the icon look like a legitimate game. However, upon running, it displays a screen with an information that your phone has been blocked due to the fact that the user watched child pornography. The ransomware targets both Russians and Ukrainians and has text in both languages. The code below checks whether the SimCountryIso is equal to "ua" and changes the displayed text accordingly.

The "fine" that has to be paid is equal to either 100 hryvnia (8 dollars!) or 500 ruble (~ 13 USD). The fine has to be paid by either the QIWI VISA WALLET, which is a kind of prepaid wallet popular in Russia or by (and this is the fun part) adding funds to a prepaid phone! There is an instruction included on how to add funds to that phone. This instruction is provided below. I don't know either Ukrainian or Russian, but I used Google Translate and so can you!

1. Найдите ближайший терминал.
2. Подойдите к терминалу и выберете пополнение счета
3. Введите номер телефона +380685815686 и нажмите далее
4. Вставьте деньги в купюроприемник и нажмите оплатить
5. В течении 180 минут после поступления платежа ваш телефон будет разблокирован.
ВНИМАНИЕ: Попытки разблокировать телефон самостоятельно приведут:
К полной блокировке вашего телефона и потери всей важной информации(фотографии, видео, музыка).
Без дальнейшей возможности разблокирования и восстановления данных.

What is also quite interesting is that the number above is provided in plaintext, while the Russian number is encrypted inside the code. So how does the locking actually work? It's plain and simple. First, we set up an ExecutorService and call the scheduleAtFixedRate function. Every second an activity is run. This activity is responsible for displaying the ransom demand above.

The second scheduled task checks a URL address. It does so by sending a randomly generated number with device ID using a GET request. If it receives a 200 response code it sets a "STOPE" flag and the application is harmless. That's the whole "protocol".

As for the persistence methods it just uses the BOOT_COMPLETED intent to start the activity. It also uses a WakeLock to ensure that the user does not switch off the device. The fun part is the use of the ACTION_EXTERNAL_APPLICATIONS_AVAILABLE. It's an Intent, which is broadcast when any new set of packages becomes available, e.g. when user installs an app. This probably prevents user from changing the app context, but it's just a guess.

Summary

As you have seen this app is rather simple. Well, it's very primitive even. However it still is virtually undetected (2 AVs from VirusTotal detected it as of 29 September). This fact, combined with a really low ransom demand, can bring a success to the malware campaign.

Adding funds to a prepaid phone? Really?!

DoSing NFC prepaid cards: The Mailman Attack

noreply@blogger.com (Unknown) — Mon, 29 Sep 2014 11:56:00 +0000

It's time to live up to the blog name - it should not be only about Android after all. Let's talk Near Field Communication (NFC) and payments. NFC is a relatively simple concept. You have a card with a circular wiring, which induces an electric current if it's put in the appropriate magnetic field. This field is created by a reader and the current provides the energy for a Javacard-like microchip.

When it comes to payments, Chip & PIN is a main way to go in Europe. There was a big shift recently - some of the debit (and credit) cards gained NFC communication and with it came a "Chip sans PIN" model for small transactions. This model was also present previously, but used mainly in the parking meters. However, now it has become more and more prevalent and people suddenly became aware that they money might be stolen. Well, it does not really matter that much, the truth is that if the card companies (or banks) can swallow the expenses it is all good. Here I will try to describe two possible attacks on the NFC cards, which are not so obvious. Mind you, this is based on my actual (like in "I have an NFC reader and a stack of NFC payment cards") research, your experience may vary. Mostly because the payments cards aren't a monolithic standard - there are different types of even of Visas and MasterCards, different banks save different information to the chip and so on.

The Mailman Attack, or DoS attack on the prepaid card

First attack is the attack that can be performed by mailman or someone who has a prolonged access (an hour, maybe slightly more) to our mail. Cards usually come via snail mail. Some of the cards need activation before the NFC capabilities are turned on, but others don't. The notorious group that favors the latter approach is the prepaid cards. This results in the simple, yet effective way of rendering the card unusable.

With prepaid cards you usually can't just withdraw money from the ATM. You have to pay for it. So if I would make the card look usable (i.e. no visible marks), but make it unusable, I would make sure that you will have hard time getting back your money. Or even getting back the money you have paid for your card.

In order to prevent the replay attacks, there is an Unpredictable Number (UN for short) generated for every transaction. This number is sent then, by the payment terminal, to the bank, where the bank checks the UN signature. And in order to prevent the pre-play attack, there is a transaction counter (called ATC) implemented. This transaction counter is only 2 bytes - one card can perform up to the 65535 (or so) transactions. After that number it is blocked for ever. The UN is a unsigned 4-byte integer. So you cannot just enumerate all of the UNs and then replay the correct answer to the terminal.

However, transaction counter is incremented when the transaction starts - no matter what the end result will be. So you just have to send "I want to perform transaction" (issue the GET PROCESSING OPTIONS command) and then quit 65535 times. And you effectively block the card for ever. And all of this can be performed wirelessly, without even opening the envelope in which the card is packed (in something like 100 minutes, but it can be performed faster with a dedicated equipment) - hence, The Mailman Attack. And this is how you DoS a credit card.

The "I know you, therefore I'm your bank" attack

Second attack can be performed in the public transport or anywhere when you can come close to the unsuspecting people. Some debit cards, especially Visa, have a very bad habit of leaking too much information trough NFC. MasterCard is somehow more modest in the information it gives - e.g. it does not give the first or last name of the owner. Essentially, the NFC part and the contact parts should be always separated.

Each card has a transaction log. It's basically what you expect - a log of transactions. It's kept on a card in order to determine when you have reached your offline payments limit and the card has to enforce transaction to be performed online. This is done so that you don't have an excessive overdraft on your account. You are allowed to spend a small amount of money without the authorization of your bank. It's faster that way and we know how credit card companies love speed - it gives you less time to think about your purchase. Card just logs all of the transactions and at some point decided that you have spent too much (or made too many offline transactions) and decides to go online. It's then free to clear this log.

But implementing a rolling log of transactions is hard. Well, not hard, just... not worth doing it the proper way. So one of the card companies decided to log all of the transactions - online, offline, contactless, contactfull. And this log is readable via a wireless interface. So now I have a date, amount, currency and, in some rare cases, location of your transaction. Well, this gives me a lot of information - I now if you're rich and if I can mug you in a dark alley.

Next up is first and last name. While MasterCard specification mentions that it is forbidden to share that data via NFC, the other big card company does not have any problems with it. Last piece of the information is of course the card maker, bank name and card number. Well, bank name and card maker are actually encoded in the card number, so that even does not have to be transmitted - card number is enough. Of course the expiration date is also send via NFC.

OK, now that we know what we know we just have to use our charm. Come up to a boy or a girl, bump him (now you have read all of the credit card information) say you're sorry, chat him/her up and get the phone number. Or look it up on some social media site. Anyhow, call your victim and say something like:

- Good morning, I'm calling from <bank_name>. May I speak with <name>, please?

- Are you the owner of the <credit_card_company> card with the number that ends in <last_four_digits>?

- Did you make a transaction on <date> for <amount_of_money>?

Of course, he/she did. We know it.

- Our fraud detection system (patent pending) has flagged this transaction. In order to process it you have to provide us with the three number code at the back of your card. Can you please read it?

And... scene.

Summary

Despite all of the drawbacks, I still use NFC cards. Not that I have a choice of course, but if I had a choice I would still stick with them. They are easy to use, the attacks described above are somewhat impractical and - at least for now - too expensive to pull off. There are arguably easier ways to scam you out of your money. But sometimes it really shouldn't be about the cost of the scam, but about the finesse.

Android malware based on SMS encryption and with KitKat support

noreply@blogger.com (Unknown) — Tue, 23 Sep 2014 21:17:00 +0000

Most of the malware based on the SMS C&C communication channel is not compatible with Android 4.4 KitKat. This is due to the fact that KitKat introduced a concept of one messaging app, which all other apps had to go trough before they send or handle a received text message. This prevented malware from hiding received short messages or sending without saving them in the "Sent" folder.

Well, it wasn't hard to predict that this state of affairs wouldn't last long and that malware authors would eventually catch up. Malware described here not only supports KitKat, but also uses an open-source SMS encryption tool as a basis for its code. Let's have a look at the insides of the new sample (hash: 84e2e9e8430792b583d02d3cc1bf8535) and let's call it SmsSecure, just for the sake of brevity.

Open-source encryption

I have to say that I did lie a bit. Well, I didn't tell the whole truth. Commands sent trough the SMS channel are not encrypted per se. Only the code for secure messaging is used as a basis for this malware, presumably because it supports Android 4.4 out-of-the-box and it is easier to encourage users to install "Secure SMS" application as a main messaging app. It has the same package name, org.thoughtcrime.securesms and hides main portion of its code in the x* (namely xlibs, xservices, xpack, xbroadcast) subpackages. These are responsible e.g. for sending received text messages to the C&C server.

There are two channels of communication: one trough unencrypted text messages and the other one trough POST requests, which body is encrypted using blowfish. So, all of this talk about "encrypted SMS" is just a scam.

Emulator detection and other techniques

What we are used to is that the Android malware increasingly has a code that detects whether it is run on the emulator or not. There are couple of usual checks (e.g. phone model) and a couple of unusual checks illustrated below.

Not that frequent technique is checking for the Network Operator and SIM Operator name. These names are hardcoded in the emulator and are equal to Android.

Another interesting feature is the configuration. Configuration is stored as the Raw Resources, because it is encrypted. Encryption method is Blowfish/CBC (IV="12345678") and the key is stored in the resource cleverly called blfs.key and the configuration is encrypted in two files named in the same cunning way: config.cfg and config1.cfg. However, if you try to just decode the configs using the key provided, you will fail. Key is somewhat "obfuscated" using a byte2hex function outlined below.

It takes every byte in the key file, renders it to a hexstring and then construct a new string of this hexstrings. The function that gets the key limits it size to 50 bytes. So instead of the key:

NfvnkjlnvkjKCNXKDKLFHSKD:LJmdklsXKLNDS:<XObcniuaebkjxbcz

we get:

4e66766e6b6a6c6e766b6a4b434e584b444b4c4648534b443a

Really clever obfuscation technique. After decrypting the configuration files we get two beautiful XMLs:

<?xml version="1.0" encoding="utf-8"?>

<data rid="25"

shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1=""

del_dev="0"

url_main=""

url_data=""

url_sms=""

url_log=""

phone_number="+43676800505476"

download_domain="ttt"

ready_to_bind="0" />

</config>

<?xml version="1.0" encoding="utf-8"?>

          <config>

            <data rid="25" 

                  shnum10="" shtext10="" shnum5="" shtext5="" shnum3="" shtext3="" shnum1="" shtext1="" 

                  del_dev="0" 

                  url_main="" 

                  url_data="" 

                  url_sms=""

                  url_log=""

                  phone_number="15555215554"

                  ready_to_bind="0" />

          </config>

See if you can spot the fake one. Anyhow, that's it for the text-based C&C, but what about the HTTP-based dropzone? Well, there isn't any URL hard coded. The dropzone URL comes via the text command.

SMS commands

Each command is send in a following form (the originating number is completely ignored):

<control_code> <command> <number> <service_code>

Two last values are optional. control_code should be one of the 6-digit predefined codes. service_code is a number to which the logs will be send (as a text messages) and will be updated no matter what the issued command is. What are the possible commands? Well, there are eleven of them, listed below.

START - starts redirecting all text messages to the number (service_code is ignored) by setting the RTB (ready to bind) value to 2 and sending the "Service Started" SMS to the number.
STARTB - starts redirecting all text messages to the number URL (URLs are for some reason called "buffers") by setting the RTB value to 1 and sending the message as above (but via HTTP).
STOP - command complimentary to the START and STARTB commands. Sets the RTB value to 0 and sends "Service stopped" SMS/POST request to the number.
DEL - removes the application. Just like that. But you still have to send the correct control_code. Sends back the "Delete command received" to the number.
SETB - sets what the author calls "Buffers". These are all the URLs needed for the HTTP communications. URLs are set according to the following pattern: number/[1|2|3|4].php. First one is used for a ping-back, second one is a dropzone for the captured messages, third one is for the configuration update and the last one is for the logs (e.g. that some action has started).
CLEARB - clears the "buffers" i.e. the URLs mentioned above.
SETP - sets the phone number that will overwrite any number that comes in the text message. Useful for using the fake number values in the subsequent commands.
CLEARP - reverts the above setting.
CLEAR - does both the CLEARB and CLEARP.
LOCK - set the password for the device to number and locks the device. I don't think this feature is enabled in the mentioned sample, as the sample does not require the Device Admin privileges.
UNLOCK - clears the password and locks the device (which makes it unlockable after the lock above).

The application also supports blocking messages from some numbers. These numbers should be contained in the "filters" variable (separated by the semicolon) and can only be updated via the HTTP or in the starting configs.

Summary

This is a fine example of the malware evolution - now completely compatible with KitKat. It even checks whether you have set it as a main messaging app already and displays a pestering notification if not. It also tries to do some targeting based on the SIM operator (as pictured below). However, this function is never used in the code, as it was probably dropped at some point by the authors. Anyhow, the targeted countries were supposed to be Austria, Russia and Switzerland.

However, my favorite part is how they extensively log everything and use "setted" instead of "set".

Update

@seckle_ch reports that the SmsSecure is used in conjunction with the retefe banking trojan, targeting Austria, Switzerland and Sweden.

Having fun with AndroidManifest.xml

noreply@blogger.com (Unknown) — Mon, 15 Sep 2014 05:36:00 +0000

Before w will get back to Sandrorat let's have some fun. It's weekend after all, or rather it was weekend when I wrote this post. Everyone that ever tried to see the insides of the APK file knows what's an AndroidManifest.xml file is. Some even know that, inside the APK, it's not a real XML, but rather a compressed, binary form of an original XML.

This compressed form was first abused in the Android.OBAD malware. Compressed form of an XML differs with the real XML in at least one key aspect, hidden in the String Pool. Let's have a look at a compressed AndroidManifest.xml file of the previously mentioned Sandrorat sample and see if we can do something interesting with it. If you want to skip directly to the fun part, just ignore the next section.

Binary XML layout

Binary XML file starts with an XML header which is two words long (when I write "word" I mean 4 bytes, because I still live in early 2000s). Below is a hexdump of the Sandrorat AndroidManifest.xml, provided for your convenience. First two bytes are kind of a "magic number" for XML (which is 03 00 and is marked in red). Next two bytes are a header size (which is always 8, marked in green) and next word is the XML size, both in little endian convention (marked in blue). In fact every number in this format sticks to the little endian convention. After that header the actual data starts.

00000000: 03 00 08 00 c8 1c 00 00 01 00 1c 00 ec 0d 00 00

00000010: 41 00 00 00 00 00 00 00 00 00 00 00 20 01 00 00

00000020: 00 00 00 00 00 00 00 00 1a 00 00 00 34 00 00 00

00000030: 52 00 00 00 76 00 00 00 82 00 00 00 9c 00 00 00

00000040: a8 00 00 00 b6 00 00 00 c4 00 00 00 d6 00 00 00

00000050: e8 00 00 00 40 01 00 00 44 01 00 00 56 01 00 00

00000060: 6a 01 00 00 94 01 00 00 9e 01 00 00 b2 01 00 00

Next chunk of the binary XML is the String Pool (magic number is 01 and header size is always 1c). Then file contains the number of strings (marked in orange) and, after some additional data, the table of string offsets starts (purple). Each word is a relative offset to the string data (relative to the end of String Index Table, so first offset will usually be 0). String data uses a simple encoding: first two bytes are the string length and then there is a null-terminated, UTF-16 encoded string. String length is the actual length of the string, not the number of bytes. Just like shown below (in red).

00000120: 34 0c 00 00 80 0c 00 00 0b 00 76 00 65 00 72 00 4.........v.e.r.

00000130: 73 00 69 00 6f 00 6e 00 43 00 6f 00 64 00 65 00 s.i.o.n.C.o.d.e.

00000140: 00 00 0b 00 76 00 65 00 72 00 73 00 69 00 6f 00 ....v.e.r.s.i.o.

00000150: 6e 00 4e 00 61 00 6d 00 65 00 00 00 0d 00 6d 00 n.N.a.m.e.....m.

OK, this was boring and I promised you fun. What comes next is really interesting. It's called Resource Map (magic number 80 01) and contains a table of resource identifiers for some of the strings. Every word is a resource ID for the string. First resource ID is for the first string in the String Pool and so on. So now we have both an actual string data and this string ID. Mapping between resource ID and an actual string is also kept in the public.xml file of the AOSP.

Now, do you think that Android checks the string data if it has a resource ID? Or just simply ignores whatever string data says and just assumes it knows the string content by looking at its ID? If you think it's the latter, you're right.

Trolling the researchers

A quick recap for those of you who skipped the last section. Binary XML sometimes contains both the actual string (e.g. versionName) and its identifier (e.g. 0x0101021c). Android usually does not care about the actual string, if the identifier is present. This was used by the somewhat famous OBAD malware, which made it to extreme and just removed the unnecessary strings. This action lead to this beautiful part of the AndroidManifest file (decoded with an apktool 1.5.2):

As you can see some of the attributes are simply missing. When you run aapt on it, it becomes more clear what happened:

E: receiver (line=47)

A: :(0x01010001)="System" (Raw: "System")

A: :(0x01010003)=".Illlljlj" (Raw: ".Illlljlj")

A: :(0x01010006)="android.permission.BIND_DEVICE_ADMIN" (Raw: "android.permission.BIND_DEVICE_ADMIN")

When you look up the first ID (0x01010001) you find that it means label. We can do so with other resource IDs.

OK, now let's have some fun with it. Removing strings is confusing for researchers, but it is more or less a known technique. Let's move to something more confusing. Just by a simple variable substitution we can get this amazing AndroidManifest snippet, decoded by the apktool 1.5.2:

So, what happened here and why are there two different package names? When we have a look at aapt output we can deduce what happened:

A: android:versionCode(0x0101021b)=(type 0x10)0x1

A: android:versionName="1.0" package(0x0101021c)="com.acme.app" (Raw: "com.acme.app")

A: package="com.zero1.sandrorat" (Raw: "com.zero1.sandrorat")

I just changed the versionName to versionName="1.0" package and 1.0 to com.acme.app (nobody looks at the version name anyhow). While this can be confusing a lot, it still installs without any problems. If your workflow includes apktool + some XML parsing, you may now need to rethink that approach :)

There are endless opportunities for confusion! Change enabled to disabled or readPermission to writePermission!

So now you think: well, this is all fun and games, but I can still use aapt and see what's up. What would happen then when I change versionName to versionName\r? Since you're most probably not redirecting output to file aapt will "perform" a carriage return and you will see an incomplete log:

A: android:versionCode(0x0101021b)=(type 0x10)0x1

(0x0101021c)="com.acme.app" (Raw: "com.acme.app")

It gets even more interesting when you change versionName to versionName\x1b. At least on my terminal this resets the buffer, which makes the begging of the aapt output unreadable.

Breaking things

Trolling can be fun, but let's start breaking things. We won't be breaking anything major. Do you remember when I mentioned that the string should be null-terminated and preceded by it's length? What if we were to manipulate this size?

First, let's try to set size to some very big number. A number bigger than the size of the whole AndroidManifest. This leads to the errors in apktool and aapt. When I tried to install this app, the emulator restarted. So I tried it again, but it restarted again. So it seems that Android tries to read strings, but just doesn't care about it's value.

DO try this at home

Do you have some ideas that you want to try out? Like using the Unicode control characters (e.g. right-to-left mark). Or maybe you just want to make sure that what I'm writing here is true. Either way, you can try it for yourself. I wrote a small PoC tool (available in my github repo). Options are pretty self-explanatory (just run the tool with -h). However, the config file can be a little tricky. Configuration is stored in the config.py and is in the form of a dictionary, like the one outlined below (which produces the two different package entries):

config = {

'Manifest':

{

u'versionName': {'value':

'v\x00e\x00r\x00s\x00i\x00o\x00n\x00N\x00a\x00m\x00e\x00=\x00"\x001\x00.\x000\x00"\x00 \x00p\x00a\x00c\x00k\x00a\x00g\x00e\x00'},

u'1.0': {'value':

'c\x00o\x00m\x00.\x00a\x00c\x00m\x00e\x00.\x00a\x00p\x00p\x00\x00\x00',

'check_resource_id': False}

}

Details of the configuration are in the tool's readme file. Have fun!

UPDATE: Samples for your pleasure

I've started another repo on GitHub, which will be filling with obfuscation samples including the ones mentioned in this and previous post. Enjoy!

Sandroid RAT analysis: Part I - synthetic communication

noreply@blogger.com (Unknown) — Thu, 11 Sep 2014 05:58:00 +0000

My first post is about Sandrorat, a fairly new RAT tool that was prominent for being a part of a Polish spam campaign. The analyzed sample hash is bed05d8eace6a7ebc5dec7141ea4b9cc559f1b2aab8848e2c79df7a79de39b9d. Sample was obtained thanks to The Honeynet Project.

Everything is synthetic

First part will be about a little known synthetic methods and the way Sandrorat uses them to obfuscate the code. This sample declared three different services:

First service is run when either the button on the main app screen is pressed or when the com.zero1.sandrorat.Connector (declaration below) receives a BOOT_COMPLETED intent.

Starting the service by button is somewhat convoluted in such a way that jd-gui + dex2jar combo does not show the actual code. This obfuscation is done by the clever use of synthetic methods. These methods (and classes and variables) are supposed to be created by the Java compiler and only by the Java compiler. They have a specific purpose, which is discussed in this great writeup. However, in this case they are used to hide some of the functionality. Take a look. At first let's go to the onCreate method of the MainActivity (btw: really creative name for the class, right?).

You see that there is a listener put in place in case user clicks on the button. This listener is implemented in the ag class. So let's have a look there.

Well, there seems to be some kind of startService performed, but it's performed on the non-exiting class variable, right? What's up with that? It all starts to come together when we take a look at the smali code (thanks to the apktool). There is actually a variable called a, but it's marked as synthetic and for some reason does not come up in the jd-gui.

.field final synthetic a:Lcom/zero1/sandrorat/MainActivity;

But where is this variable value saved? The answer is: in the constructor. Smali code for the constructor is:

.method constructor <init>(Lcom/zero1/sandrorat/MainActivity;)V
    .locals 0

    iput-object p1, p0, Lcom/zero1/sandrorat/ag;->a:Lcom/zero1/sandrorat/MainActivity;

    invoke-direct {p0}, Ljava/lang/Object;-><init>()V

    return-void
.end method

So, the a variable is actually an instance of the MainActivity class. Since this class extends the Activity class, it also extends a Context class, which means it has a startService method. Now we know what this.a means, but there is no static a method in MainActivity. When we take a look into the smali code we see that it's the same synthetic trick used, but this time it's used to hide a method, not a variable.

.method static synthetic a(Lcom/zero1/sandrorat/MainActivity;)Landroid/content/Intent;
.locals 1

iget-object v0, p0, Lcom/zero1/sandrorat/MainActivity;->c:Landroid/content/Intent;

return-object v0

.end method

This method returns the c variable, which actually is the instance of the Controller class. Now everything makes sense. The only line of code in the onClick method is responsible for running the Controller service. This service is responsible, among other things, for the C&C communication.

It's worth noting that the service responsible for communication is not started automatically, but waits for a user to press a button (or for a phone to restart). This is done to prevent the automatic sandbox from capturing the network traffic.

C&C communication

When we start to browse different classes we eventually come to the class that seems to hold communication parameters. Class is presented below, it has only three static variables.

Educated guess will be that the first and last variables are C&C addresses, and the b variable is a port number. However, it seems that the first two variables are there as a decoy - false domain and port just to obfuscate the real C&C address. First, Sandrorat sends a register message (l class is responsible for this) via HTTP POST to the am.c + "DeviceManager.php?func=registerDevice" URL with a couple of device information and some other parameters. In response it should receive the registered string. Then, again using the synthetic tricks, the actual communication takes place.

Communication is handled by the n class, but the main switch instruction, responsible for the command execution, is in the Controller class private byte[] a(int, java.lang.String) method. Communication is pretty straightforward. First, it sends a HTTP POST to the am.c + "Linker.php?func=getCommand" with a device ID as one of the parameters. It then receives one line with a command or no command at all. This line has a following structure:

<command_number>#<parameters>#<answer_token>

Where <parameters> is a ~ delimited list of strings. Response to each of the commands is made via HTTP POST body to the am.c + "upload.php" URL with a filename parameter, which is composed of the device serial number, answer_token and the .dj string. Then some weird HTTP POST request to the am.c + "Linker.php?func=setResult" is made. I have no idea what is the purpose of this POST request.

Anyhow, that's all for this post, in the next one I will try to explain a couple of commands that Sandrorat can perform. Just a quick sneak peek: 1 is for ping and it always responds with the "Ack" string.

(Not only) Android malware analysis

Mathematics, objective truth and why 2+2=4 and not 2+2=5

Do numbers exist?

The barbers

The axiomatic theory

The orders of logic

The Gödel incompleteness theorem

OK, but this is just a theory(TM)

What about computer science?

What about physics?

What does it all have to do with objective truth and 2+2?

Summary

Side note to the whole blog post

Environmently friendly reverse engineering

Typing random numbers into a search bar

Multimetering UART

Serial console straight out of hacker movies

TFTP and a firmware dump

How one company implemented (almost) whole OWASP Top 10

The problems

Responsible disclosure

Three short cyberstories + bonus scam

The one where I don't (really) know my password

The one where someone is tracking me (and it's not paranoia)

The one where my new intercom becomes smarter

BONUS: Paris scam with Louvre in the background

Using World War II techniques to fight ransomware

KLM's "We'll keep you grounded" Programme

Epilogue

Crystalline Cipher and cryptography snakeoil

Crystalline Cipher - the pitch

One-time pads

(... to here)

Crystalline Cipher - the algorithm

Crystalline Cipher - observations and weaknesses

What's the key in this cipher?

Is permutation a form of encryption?

The recommended key length: 16 KB + 16 KB

Every key produces different output, right?

What happens over 64KB?

Is the ciphertext really, truly random?

Summary

Android malware goes Mono and Lua - part 2 (Ransomware)

Retrospective: Lua and .NET

Retrospective: network communication

Attack scenario

New features

Android malware goes Mono (.NET) and Lua!

Quick overview

Mono and the mkbundle

.NET code & Lua

Summary

Porno-locker - nice icon, not so nice functions

Overview

FLAG_LAYOUT_IN_SCREEN - take entire screen.

FLAG_FULLSCREEN - hide decorations.

FLAG_SHOW_WHEN_LOCKED - shows a window even when the screen is locked.

FLAG_DISMISS_KEYGUARD - no keyguard.

FLAG_TURN_SCREEN_ON - screen is always on.

FLAG_HARDWARE_ACCELERATED - hardware acceleration. Because, why not?

Obfuscation

Android Malware Tracker

New iBanking - KitKat SMS bypass done wrong, obfuscation done right

Templating

SMS communication

Encryption and obfuscation

SMS_DELIVER

What about the HTTP?

Iran, secret text messages and a toy for a holiday break

The curious case of the SMS protocol

How are these ports handled on Android?

CloudAtlas - commercial-grade Android malware

The "you can't see the log name" trick

C&C hosted on the blog

How does the PornDroid (aka Koler) work?

How to do a ransomware?

Some tricks

How to check for a root access in three ways (plus a C&C demo!)

Checking for root in three ways

WhatsApp with FinSpy?