Okay. Without any further ado, we've got a short talk. This is a 20‑minute talk. Jaime
Sanchez talking about building an Android IDS on the network level. Jaime, take it away.
Thank you. Hi. Hello, everybody. As you say, my name
is Jaime Sanchez. I'm going to do this talk about building an Android IDS on network level.
I work for security for about ten years. I work for very national, international companies
as a specialist and advisor. In my free time, I enjoy doing research on security. And I
work as an independent consultant. I'm from Spain. I talk in other conference in Spain
like Root.com, in Paris, in the arsenal of Black Hat, and maybe you can meet with me
in DerbyCon on activity. Well, I got a proper handover today. I'm going
to tell you a story. I don't know what happened last night. It's my first time in Vegas. Today,
I wake up, I was married with two strippers. No, don't laugh. Don't blame vodka. I know
the reason for this. Just blame aliens. I'm sure they forced me to drink. I'm from Spain.
I don't like partying. So ‑‑ you know us. So we have 20 minutes before I get with
my lawyers to get divorced. So ‑‑ . . . . . . . . . . . . . . . . . . . . . .
. Let's get down to business. The reason for this conference is Android has great
micro share. Being popular is not always a good thing because as the mobile device
grows, so the researchers are looking for a new model. And there are over 100 million
Android devices, from last year, and half the market share of nearly 50.50 million Android
percent. And there are several techniques that are used to detect malware and detect
attacks for mobile phones. But there is ‑‑ I haven't seen any open‑source tool to detect
and create patterns to locate this kind of attacks. So we have in the last years, we
have seen several exploits like the USSD exploit, several vulnerabilities for WebKit. There
is a meter for Android. So I had to deal with this and I tried to make my first approach
to solve this and I took my Android mobile phone and I make a VPA channel with my computer.
So I was trying to analyze all the traffic passing through my device. I launched this
on my computer to detect suspicious traffic and I could also use tools like TCP
dump.
I would make all the analysis on the forensic. I could. But ‑‑ well, this kind of IDS
sucks, man. I have several problems because I have to take the traffic from my ‑‑ from
my mobile phone to my computer. That's a waste of bandwidth. I couldn't act like an IPS.
I could detect all the attacks. I could detect all malware. But that was just after it happened.
So that has no sense for me.
And there are a lot of signatures for a snort. There are signatures for MRG threats, but
they are not so related with Android. So the other pack important is that we don't
have any real time notification for the user. So the user doesn't even know if an attack
is happening or is infected by malware or anything.
So I continued with my life. I made a problem called OS fuller that is a practical approach
to defeat remote fields. And the problem with OS fuller is that you are gonna have way also
fingerprinted. It's for active fingerprinted. And it takes advantage of a special target
of IP tables called Q. And that's where I came with the idea of how to solve this problem.
With this tool I was able to modify in real time all the traffic that was passing through
my computer. So I found a problem that is the packets I want to capture are in kernel
space. So the kernel is inside the kernel space and I couldn't take that packets to modify in
real time before the computer has it. I have to work in user space. So I have my own virtual
memory and I have no other option. So for this approach to work, let me show you a little bit
of the travel of the packets from the network card to the application. I call it how I made
your packets.
So the first thing, when the kernel takes a packet, put it inside a process. The first
one is taken directly from the network interface card and put inside a buffer. And then it
goes to with a software or hardware, IRQ, calls the CPU, letting him know that there
is a new packet. But the special thing here is that before it gets processed, we have
to pass through the change of IP tables. I'm sorry. You're not going to be able to
see it. Everyone knows the typical target destination. But here is the special thing
I found to make my ideas and my tools. Just after the IP tables, the packet gets through
the IP layer, TCP layer. It has some checks on the headers. And then the kernel put inside
the application and to the corresponding socket. So as I told you, we have several
targets for IP tables.
You know, you can accept packets. You can drop the packet. You can let the remote computer
know that you have dropped the packet. But there is a special one. It is called queue.
That means pass the packet from kernel space to user space. So a little of theory is that
this queue delegates the decision of packets from kernel space to user space. So in user
space, you must have a listener that takes care of every packet. That's because you have
the issue.
You have to accept it. You can drop it. But you can modify in real time before it gets
into the TCP IP stack. You have to be very fast because if the queue gets full, all the
other packets that you receive will be dropped.
So for summary, I'm capable of processing all incoming and all going traffic inside
my device.
I made my tool.
I have to do some proof of concept for Android. So I thought I was able to make a tool like
this.
If I'm able to issue a verdict for every packet, maybe I'm not also acting like an IDS.
I'm acting too like an IPS.
So the release of my tool was impaired. Then I moved to C. Then I moved to Python. Then
I moved to C again. So hookers are putting in this technology again. And then I get to
Android.
IDS. This Android IDS is a first approach to create an open source software that it's
a network IDS and network IDS that has to perform a real traffic analysis and packet
logging on the internet protocol. It's some features and things. Like you said, it's like
protocol searching, protocol analysis, content matching and content searching. It would be
great if you were capable of hooking to the syscalls of the device and working on this
because you can reduce the amount of false positives. But there is some problems finding
the address of the table. There is ‑‑ there are differences between the different versions
of Android kernel. So this is something I have to work on. So the architecture of the IDS
should be a sensor and should be a server. The sensor is installed inside the IDS. The
Android mobile device and run without human interaction. It's responsible for analyzing
traffic. It should send some push message to the mobile device so the user can know if it's
having an attack or installed malware. So I've done this with an application you will see
that's called Notify My Android with the IP and realtime notifications. So it reports
through the login server if you want. You can do it by syslog. You can create your own
IP and tunnel. And it should do some custom reactive actions like dropping the packet,
adding new rules to the AP tables or as we will see. And very important is that it should
impose minimal overhead to the device. On the other side, we'll find the ‑‑ we'll
find the server. The server is a Linux box. It's only responsible for taking all the traffic.
It should send the signatures, the updated signatures to the device. It should send the
data to the device and store the events in the database. Another feature is that we can do
the statistical analysis of the packets in the server instead in the mobile device because of
the power of the computer. And we can use any CM or whatever you want to add the IP reputation
and correlation for the attacks. So the first thing I have to do was protocol analysis. It's
my day by day.
So the anomalous packets, you know, there are some packets that do not conform to the
standards or have several errors in the headers. And most of the devices in the network will
almost drop them. This kind of packets you can find in denial of service attack, in scans,
in worms, in virus. And several of them have some anomalies because of programming with
raw sockets. So as an example, you can see now that there is a TCP IP packet. And you can
see it has several flags activated. This packet, this kind of packet belongs to a network
scanner and should be dropped. And it should be reported to the server.
So as I told you, I have a tool. It was called . It was for defeating active and passive
fingerprinting. So the first thing I have to do is like putting all my code because my tool was
working okay.
So I was trying to detect and drop packets from well‑known tools. In this case, it's
16 proofs, TCP, ADP, and ICMP. And I will show you how it gets ‑‑ how it detects the
attack. In this case, you're seeing that we are connected to the mobile. We have to have the
device rooted because we need to access to the IP table.
In this case, we are launching the ADS. It's in login mode. You can see that there are ‑‑ it's
logging almost every packet that has come to the mobile device. And if you see, when it
finished ‑‑ now, the end map has detected that it has like a Linux box, 2.6 or 3.0. In
this case, we have only logged all the attacks. It has a notification that says, oh, it's
disabled to stop the demo. And in this case, what we are going to do is to use the ADS to
pull this kind of fingerprinting. And we have to activate it. And it's in drop mode. So every
packet is being dropped. It's being reported to the central server. And it's sending full
packets to the attacker. You have seen now, it's a Sony Ericsson telephone. It's based on
Linux 2.4. It's based on Linux 2.5. It's based on Linux 2.6. It's based on Linux 2.7. It's based on
Linux 2.4. But it works with any other signature. I have to work on the ‑‑ on this release.
And now you can see that through the notify my Android, you have like the two alerts. One is for
logging. You have been scanned. And the second one is that we have put the ADS in drop mode and
it's pulling the scans. So the next thing I have to take care was pattern matching. I don't
work for NSA, so I have to work by myself to capture all the traffic. And the next thing I
have to do is look for a fixed sequence of bytes inside almost every packet. This is a problem
because some of the ‑‑ some of the attacks are related to a well‑known port. And we have to
inspect almost every packet. We can have some false positives. This can be solved by using
stateful packet matching. But I'm still working on it, too, because I want to search for a
pattern through very ‑‑ through several packets. And it's the only way to make it work.
So another thing I have to deal with was the signatures. There are some signatures from
emerging threats for Android. And I have to run a script to convert that rule from snort to our
format. In this case, it's only called snort rules. And it can only, as we have seen,
we can only search for a specific pattern in every ‑‑ for a specific string in every packet.
We can only ‑‑ we can only search for a specific pattern in every ‑‑ for a specific string in
every packet. We should work with pre‑processor. We should analyze all the flow. But still
working on it. Some of the things, the exploits we have seen is the U.S.S.D. code. The U.S.S.D.
code is a code that is entering into your phone to perform some actions. It's used by the network
providers to give the users some access to some service like call forwarding and functions.
It's very simple. It links the browser to the phone application. That means that when you get
into the web application and you have this code, the phone, without human interaction, will show
you the telephone application. So this exploit was published one year or so ago. And we have
several web signatures. So this is the U.S.S.D. code. This is the U.S.S.D. code. This is the
uito. This is an Android security code. It detects the pay loss. In this case, I have to
cut it down. It detected a WebKit code exploit, an Android browser mode crash. You can detect
the pay loss. You can detect almost everything that you want. The last thing I wanted to deal
with was the malware. There are a lot of malware for Android. Almost every malware has a pattern.
I have searched in this case is the SMS send. You can download it from here and get an
And when you get downloaded, it connects to the command and control server.
You can find the string that it's using to connect to the remote server.
And the string to find the packets is the RQ.PHP.
We could just do those proofs and we can do everything.
If we have the pattern the malware is using, we can detect almost every malware we have.
And it's not only detecting it, we can drop all the traffic that it's sending.
On the other side, we have the Meterpreter, I thought you know.
It's an extensible payload for Metasploit.
It communicates over a stager socket and it has some features like command history, some
channels and mode.
So now there is an Android version.
What I have done.
Is creating a package for Android.
Installing inside my own system.
And try to detect all the traffic that it's having.
So the processor is the same.
We have to get inside our device.
We have to be root.
And we should launch the script.
In this video, there is no ‑‑ we can see how was the software installed.
But there are some problems.
There are several methods for signing this kind of malware.
And it will only have to take a listening socket for Metasploit and just connect it
back from the Android device.
So now we're waiting until the socket gets open.
And when it does, what we're going to see is just connect and see if we can detect all
the traffic that's passing.
So just push the button and we have found it.
We can see that there is several commands that it sent from the metadata to get the
system information and so.
And we have several commands.
We are running it one by one.
And when you decode the channel, it's very easy to find which command is being executed.
And the fun thing is that I couldn't have done a push up concept now.
But you can use some kind of honeypot because you are able to modify the packet in realtime.
So if you can infect it, you can fool the attacker, too.
You can show whatever directory you want.
You can send it pictures when it's asking for the welcome list.
Or you can send it any audio file when it's trying to attach to the microphone.
In this case, you see that it's very simple.
You have all the commands.
But not only are we going to log this.
We have only ‑‑ we are only ‑‑ we are able to drop the packets, too.
In this case, I'm not going to drop all the session.
You see that it's working.
And what I want to do is only drop the packets related with the web cam.
So now you can see that there is no way to access to the web cam and the IDS is plugging
all the traffic.
So with this, that's the way I found to create an IDS.
You don't have to depend on ‑‑
You can do it by your own.
And the only thing you have to work is in having a great signature database to work
with this.
Because Android devices are the next target for attackers.
So that's it.
Thank you.