wroot – ^(hack|tweak|pwn|secur)ing$

Enumerating Android installed applications without special permissions

29.04.2013 (9:14 pm) – Filed under: Mobile :: by Jan Seidl ::

Sometimes I took some random Android app I’ve recently installed on my phone and start performing some tests on it. It’s not uncommon to see unauthenticated API requests, plaintext HTTP communication and some obfuscation logic or hardcoded credentials rammed down at client code. As I use to say in my SCADA talks,

“everything that is ‘new’ is prone to ‘newbie’ mistakes”

This is not different for mobile development. The urge for delivery and the hype of start-ups and its fast-paced deployment philosophy usually results on developments with little to no attention to security.

Well, today I was reversing one of those applications. I won’t disclose the name of it for obvious reasons so don’t ask. I started simply by jacking up ProxyDroid to Burp and started to use the app normally.

Then I saw something on Burp that made me REALLY concerned.

That prick was spying on me! So I got a little mad and decided to rip the apk open and take a look at the code to see how that was being done.

As I rolled my eyes through the code seeking the “competitor mining” code, I was getting some usual juice like finding that all of the requests were unauthenticated that could lead to almost complete data extraction from partners, customers and transactions, scary!

And then I found it! Consider the following snippet from the app:

So it seems that any app can call getInstalledPackages from the PackageManager class on Android SDK and enumerate all you installed apps? Yes, this is true.

And there’s more! According to the documentation:

A List of PackageInfo objects, one for each package that is installed on the device. In the unlikely case of there being no installed packages, an empty list is returned. If flag GET_UNINSTALLED_PACKAGES is set, a list of all applications including those deleted with DONT_DELETE_DATA (partially installed apps with data directory) will be returned.

So any app can also return apps you uninstalled!

But Jan, how bad is this?

Well, basically I don’t like anything tracking me and that’s why I make extensive use of privacy tools when I’m online, so I don’t like either any app phoning-home with the list of apps I have.

In the case above, this company was using this in order to collect market data from competitors and payments gateway. As many may think this is “part of the business” I think this is not also wrong and offending as this capability of the Android System really should have its own permission.

For me, as there is no system-defined permission for reading installed apps, this is clearly a case of “it’s not a bug, it’s a feature” that is really creepy.

UPDATE: Comments from Zigurd on Hacker News

I’ve submitted this post to Hacker News and an user raised some interesting questions that I’ll post below and comment on them:

Package names weren’t made to be private

There are a few rationales one could cite for this:
One could probably obtain the package names of all the apps out there, so, as long as package names can be used to access components in Android, this is information that could be extracted by trial and error anyway.

I totally agree on “package names weren’t designed to be private”. As I cited this is a feature not a bug but I think it should. Not that the package name should be a secret but you shouldn’t be able to retrieve the installed ones from the user system.

The impact doesn’t pose a threat

On the other hand, everything you can do with this knowledge is controlled by sandboxing and permissions, so having this knowledge doesn’t give you anything beyond what you could have with a good guess.
Lastly, one would have to reinvent package naming around names that cannot be guessed. To sum it up, package names weren’t designed to be private, and retrofitting privacy to package names is hard.

I disagree with “everything you can do with this knowledge is controlled by sandboxing and permissions, so having this knowledge doesn’t give you anything beyond what you could have with a good guess.” because this information can be used to later push application-specific ads or even try to present the user with data in order to make him click on an ad or link and get exposed.

There are several ways on enumerating (guessing) installed packages

I agree there is a privacy concern, however, if you took away that method in the package manager, you could still try invoking, say, standard methods in components in packages and guess their names.
The developers’ domain names are public, so there is no way to prevent guessing parts of package names in Android and probably no way to prevent guessing complete package names.
Let’s take a use case: I want to secretly check if you have banking apps installed. I can install them and discover their package names. Then I can make a malicious app that checks if some component of those apps exists, by checking for an intent filter match, for example. Then I present you with a targeted phishing attack that looks like those apps’ screens. You didn’t need to enumerate all installed packages to do that.

I get this point and I do agree that are diferrent ways on enumerating apps but you need to do some guessing. The evil part I think is that you can enumerate ALL apps without need to guessing.

There are legitimate uses for enumerating all the packages

There are legitimate uses for enumerating all the packages. I’ve used it for a plug-in architecture for an app that enables 3rd party plug-ins.

And I also agree with you that there are legitimate uses for that, as you have for sending/receiving SMS, but my point is: Users should be warned that this app is attempting to do that so they can judge where to install it or no, as you have for all other sensitive information.

I’m really happy on having this article bringing up this discussion because it’s an example of how even to minor issues, the security concerns should be evaluated.

New version of GoldenEye WebServer DoS tool released

26.03.2013 (6:58 pm) – Filed under: Penetration Testing :: by Jan Seidl ::

After the hackers 2 hackers conference talk last year, some people contacted me about known Python performance issues regarding the use of threads related to the GIL.

Indeed the threading wasn’t performing well due the nature of GIL so I’ve rewritten the code to support Python’s multiprocessing module. It’s a tad faster but I haven’t tested it exhaustively so if you feel the inner-beta-tester in you, let me know!

The download is available as always at the github project page at https://github.com/jseidl/GoldenEye and you can read more about the tool at the project page at this blog.

Please test it (ON YOUR OWN RESOURCES!!) and let me know your thoughts!

Fixing ‘guake can not init’ and buggy tab titles on Backtrack 5 R3

04.12.2012 (9:29 am) – Filed under: Systems Administration :: by Jan Seidl ::

Hi Folks, I’m a heavy Guake Terminal user and I just installed the latest Backtrack 5 revision (R3) and installed Guake on it. I was surprised when I tried to start by getting the message:

“Guake can not init!\n\nGconf Error.\nHave you installed guake.schemas properly?”

Long story short, it seems that the package bundled with this version of Backtrack (and maybe others) have a bug into the debian package file/script that installs the guake.schemas file into an erroneous location (/usr/etc/gconf/schemas/).

The location should be /etc/gconf/schemas/guake.schemas. You’ll have to mkdir this schemas directory under /etc/gconf and mv or ln -s this file there. Problem solved.

This solution was found here.

Buggy tab titles

Other thing that annoys me a LOT is that some versions (0.4.1 and maybe older ones) of Guake have a bug in the tab titles setting mechanism. It simply goes blank and you’re left with a blank title when you try to change it.

You’ll have to hack up a Guake file to fix that:

  1. Edit guake.py (on BT5R3 is at /usr/lib/guake/guake.py
  2. Comment out the following code on line 983: dialog.destroy()
  3. Copy that same code (uncommented of course) below the if statement (about line 987)
  4. Save and restart Guake
  5. Enjoy!

This solution was found here.

Well, that’s all for now! Hope that this hint helps someone!

Talking about D/DoS (again) at XVII Semana de Informática (Computer Science Week)

11.11.2012 (12:54 pm) – Filed under: Conferences :: by Jan Seidl ::

I’m speaking at the 17th Computer Science Week at Minas Gerais, Brazil November 24th. I’ll be giving an extended version of my H2HC Talk for Computer Science students at UFV (Universidade Federal de Viçosa / Viçosa Federal University) at Minas Gerais, Brazil.

More at my talk’s summary page on the event website

@UPDATE
It was a great talk! Thanks for everyone that attended! Slides are on my slideshare!

Quick and dirty ngrep credential (username/password) sniffer

31.10.2012 (12:59 am) – Filed under: Penetration Testing :: by Jan Seidl ::

Some time ago I’ve posted a quick (and dirty too!) command-liner using tcpdump to sniff plaintext credentials over the wire.

Now I’ve acomplished the same thing with a shorter regex and ngrep tool.

Where -i is for case-insensitive and -q for more precise output. See man ngrep for additional information.

And the output is as follows:

Hope that helps!

About Hackers 2 Hackers Conference 9th Edition

22.10.2012 (1:22 pm) – Filed under: Conferences :: by Jan Seidl ::

Hi Folks,

This last weekend was my talk on Hackers 2 Hackers Conference 9th Edition @ São Paulo, Brazil. The talk was in portuguese and the slides are available here (download pdf) and here (slideshare).

The subject of the talk was about layer 7 denial of service techniques and tools, using haproxy and socat to create a distributed denial of service from a single node, some XSS payload for DDoS and demonstration of the GoldenEye Mobile tool released today.

I am very happy with the results, with the public’s acceptance and reaction to the material presented and for the cheers from all the good friends and IT professionals from Brazil.

Also, thanks to Utah Networks, the talk was live streamed and recorded and the video can be found on this link or below.

TI Safe, the company that I currently work at, has also published some photos at their Flickr page.

As I promised to the attendees, the code for GoldenEye and GoldenEye Mobile are available at my github page.

Below a demo video of the GoldenEye Mobile tool in a test:

Talk apart, the whole event was AWESOME as usual. Spectacular specially crafted beer, excellent coffee-break, excellent service, excellent infrastructure! Hackers 2 Hackers Conference once again proved why is one of the most incredible confs at Brazil.

Thanks for people at H2HC for accepting the paper and doing such a great event.

I’m speaking at Hackers 2 Hackers Conference 9th edition – 2012 @ São Paulo, Brazil!

28.09.2012 (1:40 pm) – Filed under: Network Security :: by Jan Seidl ::

Hi folks! I’m glad to inform that my paper “Advanced DDoS techniques: Layer 7, load-balancing and mobile tools” was accepted by the 9th Hackers 2 Hackers Conference (H2HC).

The event will take place on October 20-21 and it seems to be another success just like previous editions.

Don’t forget to check the event’s website for full line-up. If you can, enroll and enjoy!

Quick and dirty tcpdump credential (username/password) sniffer

18.06.2012 (6:50 pm) – Filed under: Penetration Testing :: by Jan Seidl ::

I’ve been playing the last months with mobile pentesting within the Android platform. As I’ve been able to setup tcpdump-arm on my android phone, I began fooling around with it. I was trying to cross-compile Dug Song’s dsniff into armle architechture but it was only giving me headaches within the libnet/libnids dependencies and stuff.

So I wrote a quick one-liner to dump potential credentials (username/password) flowing in plaintext over the line:

And it works quite sufficiently:

Its not BY FAR efficient as dsniff, but can help out sometimes!

São Paulo State’s Military Police website (almost) hacked by RFI

22.04.2012 (6:00 pm) – Filed under: Application Security :: by Jan Seidl ::

Today a friend shared me this link which pointed to São Paulo State’s Military Police website and showed a deface-like page with a hacktivist text and a youtube video.

The first thing that came to my eyes was the URL:

‘abrirframes.asp’ is ‘openframes.asp’ and ‘PAGINA=’ is ‘PAGE=’ in Brazilian Portuguese. Say no more.

That’s why I’ve said “almost hacked”. The site that was actually hacked was www.nova89fm.com.br (a Brazilian FM Radio) and not São Paulo State’s Military Police’s.

But São Paulo State’s Military Police website wasn’t clean at all. This ‘PAGINA=’ (or ‘PAGE=’) attribute clearly accepts any URL and this hacked website was ‘tucked-in’ to look like the police website was actually hacked. The proof that any URL can be spoofed is that (it will open a famous brazilian news portal).

This seems to be another action of script-kiddies and defacers (almost the same) using automated tools to call themself ‘hackers’. I’m kinda’ sorry for guys like these.

It would be better to do a decent vulnerability disclosure instead of doing such a lame hack. Those kids.

Terminal auto-lock with zsh and vlock

18.01.2012 (8:33 pm) – Filed under: Hardening :: by Jan Seidl ::

I’m always concerned about leaving terminal sessions open. I’ve used for many and many years the $TMOUT environment variable to close my sessions if idle for N seconds.

Just by exporting the TMOUT variable to the number of desired timeout seconds will close your shell (Bash, Ksh, Zsh and some others).

The following example will timeout in 300 seconds (5 minutes)

I am currently reading the book Secure Coding: Principles & Practices and the authors cited this timeout technique as pretty ineffective since it annoys more than it helps. I was obliged to agree. I got pretty mad with it some good times.

So I started looking for alternatives.

I’ve found a console application called vlock. It should be available on most distro’s repositories.

Just invoke vlock and the terminal session will be locked awaiting the user password to unlock. Pretty nice. Locking is definitely better than killing the session.

So I just started to wonder how to integrate vlock with zsh and after some research I’ve discovered that the shell will only be killed within TMOUT if no trap function for signal ALARM is set.

If you set an ALARM trap function, it will be called instead of killing the session. Perfect.

So I ended up with this in my .zshrc:

And now zsh locks my sessions after 10 minutes. It’s working perfectly even within tmux.

@UPDATE
As the comment from the reader Ehtesh Choudhury we can accomplish that in tmux only by adding to your configuration: