The task of sniffing traffic from an app on Android x86 ranges from trivial, to very complicated. The difference comes down to the various anti-sniffing techniques employed by the app and or the Android OS itself. This guide will walk you through the process starting with the most trivial scenario, all the way to the most complex.
Scenario 1: ProxyDroid
Before diving into
the complexities of sniffing encrypted HTTPs traffic, it’s always
good to do a sanity check to make sure that the packets are flowing
ProxyDroid app on Android. In case you are wondering why not use
built in proxy settings, it’s because some apps ignore the built
in proxy setting. By using ProxyDroid, it eliminates the guesswork
and every single request is proxied
Set host and
port in ProxyDroid to match settings in BurpSuite
traffic, it should be successful
traffic will fail at this point, but you should at least see
connection attempt errors showing up in BurpSuite event log. Those
prove that it’s trying. See Scenario 2 on how to fix this.
Scenario 2: Simple HTTPs
When the application
established HTTPs connection, the minimum it needs is a valid SSL
certificate to prevent man in the middle attacks. By installing
BurpSuite root certificate on Android, most applications will accept
BurpSuite proxy as a trustworthy server.
install it depend on exact Android version and sometimes the
certificate has to be converted from der format to cer
traffic in BurpSuite
If it works,
If you get
other errors try Scenario 3
Scenario 3: HTTPs protected with pinning
aren’t satisfied with any old valid certificate, they are pinned to
a specific certificate. Luckily there is a way to bypass this
Android: Install frida-server on Android in /data/local/tmp
Android: Run frida-server -l IPofAndroid (ex. 192.168.1.100)
Windows: Run frida-ps -aiH IpofAndoid to find out application identifier ex: com.company.myapp
Windows: download bypass.js into current directory
Windows: frida -H IpofAndroid -f com.company.myapp -l bypass.js –no-pause (this will start the app)
Windows: Watch HTTPs requests come in in plain text into BurpSuite, if you’re still gettting errors, especially “Remote host terminated the handshake” in BurpSuite and “CERTIFICATE_VERIFY_FAILED: self signed certificate in certificate chain” in logcat chances are you need to go deeper and look at Scenario 4 (if the app is build on Flutter)
Scenario 4: HTTPs inside Flutter
Android: find /data/ | grep libflutter.so
Android: upload for analysis in Ghidra
Ghidra: search for “ssl_client” string
Ghidra: from here find the function that contains “ssl_client”,“ssl_server” and takes long,long,char* as it’s 3 arguments. In my version I had a single match, so I there was no trial and error required to narrow things down.
Ghidra: get the function’s signature by copying the first several bytes
Most modern apps rely on SSL pinning to make sniffing SSL traffic through proxy more difficult. This is great security-in-depth practice, but it’s a real pain when trying to inspect app’s traffic as a part of vulnerability assessment or penetration test. Luckily there if Frida.
With increased security, it’s getting trickier to intercept HTTPs traffic send by Android Apps. For that reason most methods rely on rooting Android. But what to do when you don’t have a rooted Android on hand?
Use Android Emulator from Android Studio:
Go to “Settings->Wireless & Networks->More”
Go to “Cellular Network Settings”
Go to “Access Point Names”
Edit Proxy and Port fields
Install root cert from BurpSuite or whatever tool you are using to intercept the traffic
I noticed that all 60 out of 60 popular Windows anti-virus and anti-malware solutions do not catch the simplest keylogger.
For the test I created a windows application using the popular UserActivityHook.cs library. It took me about 30 minutes of mostly copy and pasting. I didn’t have to obfuscate the nature of my program nor did I have to pack it’s binary contents. The program runs as plain user – it doesn’t need privilege escalation either. In other words, it is very dangerous. I scanned the executable through virustotal as well as few popular anti-virus and anti-malware programs on various workstations locally and they all passed the keylogger as 100% ok.
This doesn’t illustrate my hacking abilities (I used none). What this does illustrate is the poor state of anti-malware and anti-virus tools at the moment. No matter what the marketing materials tell you, the only protection these tools offer you is against specific white-listed instances of malware. For any other attack you’re on your own.
I couldn’t believe my eyes, either, so I decided to dig deeper.
Why was this so easy?
To understand that let’s dig into the various detection methods antivirus programs have at their disposal (thanks Wikipedia) and why each method fails
Signature-based detection: is the most common method. To identify viruses and other malware, the antivirus engine compares the contents of a file to its database of known malware signatures. Since this malware is new, there is nothing to compare to. This is also another reason why I’m not posting the keylogger for everyone to download. Days after I release it, it will get picked up by one of the many anti-malware teams and a signature will be made out of it in a hurry. I don’t want to be tagged as distributing malware down the road. This approach is mediocre, but it’s not good enough – definitely not as good as the various vendors would have you believe. It’s trivial to bypass the anti-malware scan if you spend 30 minutes making your own. Even if you copy and paste bunch of stuff together. On the other hand if you’re using someone else’s tool it will get picked up as malware sooner or later.
Heuristic based detection: is generally used together with signature-based detection. It detects malware based on characteristics typically used in known malware code. I was kind of rooting for the anti-malware programs to catch it based on heuristics, if they can’t catch my test, how are they catching the keyloggers that others are trying to use against me? Sadly none did. This is most likely due to the fact that the Windows security architecture allows keylogging as a very routine function that is used by many legitimate applications. In particular the keylogger depends on GetKeyboardState API call that’s used for many other benign reasons by other applications. I still think if the anti-virus companies tried harder, they could catch this based on heuristics. Currently they obviously don’t.
Behavioural-based detection: is similar to heuristic-based detection and used also in Intrusion Detection System. The main difference is that, instead of characteristics hardcoded in the malware code itself, it is based on the behavioural fingerprint of the malware at run-time. Clearly, this technique is able to detect (known or unknown) malware only after they have starting doing their malicious actions. Once again anti-malware products didn’t live up to this promise. They could have noticed the writes to disk milliseconds after each key press – they didn’t. Then again, it is tricky. There are lot of legitimate programs out there that do write to disk after key strokes and they aren’t key loggers.
Data mining techniques: are one of the latest approach applied in malware detection. Data mining and machine learning algorithms are used to try to classify the behaviour of a file (as either malicious or benign) given a series of file features, that are extracted from the file itself. Data mining should have been a no-brainer for an anti-malware tool. I was doing all sorts of suspicious stuff in my code and not hiding it one bit. I guess we have to wait until this matures a bit, but given how miserably the other methods failed, I’m not holding my breath for that.
So…. this sucks. How do you protect myself then? Right now, you probably can’t. Anti-malware companies have to step up and detect these kind of things. Be skeptical, just because you see 57 green check marks on virus total, doesn’t mean it’s safe. And no, don’t stop using your anti-virus, virustotal or whatever else you have. Even if anti-virus is 90% effective. That’s better than 0% without it.
Guess what the dll of the core application is called. By default it will be called the same name as the ASP.NET project created by the programmer. Other than taking a guess based on the name of the web site, often it’s possible to determine the name by browsing HTML source or by triggering errors.
Download the main dll by requesting the following URL: http://domain.com/bin/application.dll
Once you’ve got the .dll downloaded you can decompile it using ILSpy or your own favorite reversing tool. If you’re lucky, you may find hardcoded passwords. If not, you can now look for SQL and Linq injection opportunities that the source code is likely to reveal.
Most IIS installations restrict access to /bin/ folder by default, but I’ve noticed that for some reason, some don’t. One way to block this attack is by adding a hidden segment “bin”.
I found at least one Linux system running Apache with Mono that was vulnerable. Linux is not immune, if anything I’d say it’s more likely to allow this attack.
Every time I hack or crack something, I face a tough ethical dilemma. I wonder, am I hurting people’s security and privacy by doing this? When I improve the code that is designed to simplify the cloning of RFID access cards, am I helping the society? Am I helping criminals break into buildings? When I write a tutorial that explains “how to hack in”, am I helping the society? Or am I helping the criminals send phishing spam?
To untangle this, let’s start with definitions. White hat hacker is defined as someone who improves security, while a black hat hacker is defined as someone who harms security. This isn’t very helpful. Whose security are we talking about? Is a hacker working for a government security organization considered white hat or black hat? After all, they are improving *their* organization’s security. Are our guys the white guys, while “the other” guys are black hat? And how do we define harm or benefit? Is a hacker who releases info about 0-day exploit causing harm, or benefit? It seems these definitions shift the ethics off to another level avoiding the deeper philosophical implications.
Here is a more useful definition:
White hat hacker: Hacker who shares their tools and knowledge in a public and open manner for the purpose of enabling everyone to gain privacy and control.
Black hat hacker: Hacker who secretively guards their tools and knowledge for the purpose of relinquishing privacy and control from others.
This definition allows us to ask us another interesting question. What would happen if majority of hackers were white hat? What would happen if majority of hackers were black hat?
Black Hat Majority:
Information security is in a very bleak state. Black hats have all kinds of back doors, and everyday users can only throw up their arms and say “privacy is dead”, “liberty is dead”, “I do not have control over my devices – others do”. This is a state we are in now.
White Hat Majority:
Information security is in a good state. Published exploit is a defensible exploit. Black hats still have the fringes to operate in. However, overall, every day users are fairly certain that they have the control over their systems and that they are not just puppets within a system controlled by others.
This makes it easy for me to say: I’m proud to be a white hat hacker. I’m also proud to be on the right side of the race between the two sides.
I hope this makes others who have been on the sidelines, wondering what’s the right thing to do, jump right in.
I’ve been playing with my new proxmark3. It works great for HID cards, but ioProx code is still in its infancy. I made some improvements to it based on analysis by marshmellow:
Better accuracy: You no longer have to worry about centering your fob on the antenna or scan it repeatedly to get a “good” reading. Now you can just hold it in your fingers to scan. Before this update I was averaging 10 – 70% accuracy depending on how I held the fob. This version is pretty much 100% – I haven’t had a bad scan yet.
Correct decoding of human readable XSF number: Previous version had a bug that displayed the wrong unique code and the wrong facility IDs.
Download the binary firmware (including source code patch if you want to build it yourself) .
There is still more work to be done. For example, there appears to be CRC or checksum near the end – it’s still a mystery.
When reversing applications it’s useful to see what’s happening under the hood. Up until now I’ve either had to bring out OllyDbg and dive into assembly or rely on a high level tool like Systernals Process Monitor. I’m fond of strace on Linux, but when I searched for “strace for Windows” resulted in tools that were not very reliable. That was couple of years ago.
Today I stumbled on these two API monitors that do exactly what I need on Windows:
As you can tell from the source code, the mechanism is very easy:
Split file into bytes
Loop through the bytes (currentByte and previousByte)
X axis is 0 – 255 (currentByte)
Y axis is 0 – 255 (previousbyte)
Plot intersections of X and Y
The technical name for this is digraph. Doing this in 3D or 4D would require a very similar process.
Below are screenshots of some of the files that I visualized.
Note how everything is in the upper left corner. That’s because bulk of plain text is ASCII bytes 32 (space) to 126 (~)
Some similarities to a text file in terms of well defined patterns except that binary file won’t be restricted to below byte 127.
Notice the shades of gray.
This was about 32 MB file. If I had a bigger file that was even more random I would expect the entire screen to fill white. Any pattern visible here is a tale tale to a lack of randomness (or a small sample)