New tool: GmtCheck. Where does this Android App or applet come from?

Monday, February 10, 2014

 There are millions of malicious applets (JAR files) and Android apps (APK files) out there. Have you ever wondered where do they come from? Which country? At least, which is its time zone? In forensics, it may be interesting to check if this malicious app is made in Russia, Brazil, China, India or United States. Let's see how.

The files inside the ZIP files

APK (Android apps) and applets (Java programs) are all the same format: a variation of a zip file. This means they share most of the PKzip specifications. When you zip a file, the "modification time" attribute of each file is stored inside the zip file. If you want to check, just open a zip file with any unzip tool.

The way zip files store files' time is quite funny, and we will talk about it in some other post. The interesting part is that the time they store is the hour and date of the system they are compiled in. There are also files created just when the file is compiled with the system time associated. So, the system time of the creator is stored in files like the manifest (.mf), and some other. But, no "offset" is given with it. So, with this data by itself, we can't tell which is the APK or JAR creator's time zone. A file inside the zip modified or created at 23:45, means nothing by itself. 23:45 in which country?
Modification time in files inside an APK

Signed files and certificates

Some applets are signed, so they can escape from the Java sandbox and attack users. APK files are always signed, because Goolge Play and Android says they have to. When they are signed, a certificate is added inside zip files. This certificate is a PKCS structure in the META-INF folder. Inside there's a RSA or DSA file (between others). Certificates may be self-signed. This is free and attackers do not have to prove to anyone who they are.

Attackers and certificates

Certificate date... "Valid from..."
Attackers hate CA signed certificates, but they love (and they have to use) self signed certificates. Because the can be disposal. They can create a self-signed certificate ad-hoc for an app and never use it again. For example, Eclipse and other platforms helps you creating an ad-hoc certificate when compiling an APK file, as a last step to upload it to Google Play.

Certificates store the date when they were creatd in a field. And here is the trick. They store it in UTC time, no matter what the system time is. Here is a certificate's creation time and date in UTC time in "YYMMDDHHMMSSZ" format. Last Z corresponds to "zulu time" which is UTC or, practically, GMT+0 time zone.

ASN.1 view of a certificate date
As a funny thing, if the certificate contains a date further than 2049, they use generalized time format, which is the basically the same but with four digit year: YYYYMMDDHHMMSSZ.

Putting it all toghether

So we have the system time of the creator, and the GMT+0 time. We just have to assume files and certificate were created almost at the same time to make the math and calculate the time zone offset.

If a manifest or signature file is created at system time 16:00, Jan 1st 2014, and certificate UTC time is 15:00, Jan 1st 2014, assuming they were created at the exact same moment... we can say (unless the attacker changed its system time) that the attacker lives in GMT+1.

UTC Time - ZIPs file... gets the offset and thus, time zone (map from timeanddate.com)
The tool that makes it all for you

We have created a tool that calculates this for you. Just reads a .jar file (apk or applet) and, if signed:

* Will try to extract UTC time from the certificate.
* Will try to read the modification time of the last file created (usually signature file under META-INF folder).
* Will do the math and tell you which time zone the developer lives in, assuming certificate creation and compilation have been done at the very same moment.

Here are some examples:


A fraudulent app from Spain

Malware from U.S.A

Fake app from Hong Kong

This APK is a fake of an Indian app, Teen Patti poker
The tool is available in Python and a compiled C# .NET version. They both may be downloaded from http://elevenpaths.com/downloads/gmtcheck.zip


We encourage you to use it.
Sergio de los Santos
ssantos@11paths.com

Detailed guides for Latch installation in Wordpress, Joomla, Drupal, PrestaShop and RoundCube

Wednesday, February 5, 2014

We are working hard in Eleven Paths for next Mobile Word Congress in Barcelona, in late February. We have updated our official apps for Android, iPhone and Windows Phone with new features, languages and much more to come. But right now, we really want you as an administrator to try Latch in your website, CMS, platform or webmail system. We have written some detailed guides for administrators, so you can check how easy to install Latch is.

Right now, we have plugins (linked to their GitHub repository) for: WordpressJoomlaRedminePrestaShop, Drupal 6 & 7.Net Log inOpenVPNSSHRoundCubeSquirrelMailMoodle...
    And we are preparing step by step guides for all of them, so you as an administrator can offer Latch to your users and protect them. Here they are uploaded to SlideShare, but you can download them if you want. More to come soon!



    Latch installation guide for Wordpress from elevenpaths



    Latch installation guide for Roundcube from elevenpaths



    Latch installation guide for PrestaShop from elevenpaths



    Latch installation guide for Joomla  from elevenpaths



    Latch installation guide for Drupal 7  from elevenpaths



    Latch installation guide for Drupal 6 from elevenpaths

    Information leakages found in Google and Yahoo! (found with FaasT)

    Monday, February 3, 2014

    A few weeks ago, Manuel Fernández, developer and security auditor in Eleven Paths, found some DS_Store files served by some Google URLs while testing FaasT. Google awarded the discovery with a mention in its Hall of Fame. We have found as well some files with certain sensitive information in Yahoo! servers, but they never answered our call. What did we find exactly? and, was it important?

    We already know that when a company or pentesting team is running a pentest, all details available are important. The way they put them all together makes the different between a test with a big success  and a moderate one.

    During our tests with FaasT (to check if it could find something else in very exposed web pages like google.com, Yahoo!, apple.com...) we found some interesting data.

    Google.es with DS_Store available on their servers
    Thanks to FaasT, we found lots of .DS_Store files inside the search engine server. A DS_Store file may have internal paths inside, from the system of the user manipulating the web, dates, and new URLs that may be helpful for going further with the pentest.

    FaasT identifies this kind of mistakes and shows them in detail inside its web interface. Persistent pentesting will allow to detect, between many other things, this configuration mistakes that implies lowering security level, feedback for the pentest, and open new ways... so adding up all this details empowers and completes the test.

    When this leakage was detected in Google, we tried the DS_Store plugin in FaasT against the URL where they were detected, and we got an interesting list of new resources from them. In the figure below, there is an example as how FaasT shows elements found inside a .DS_Store file exposed in an URL. In this case, applied to our domain demofaast.elevenpaths.com and where new paths to PNG files can be found inside .DS_Store file.

    Example of how internal information inside in a DS_store file is shown with FaasT interface
    When analyzing Google .DS_Store files, we got the following information:
    • More than 40 new paths, storing data about Google GSA (Google Search Appliance) where the infrastructure, API documentation, or configuration was detailed.
    • More than 30 new PDF documents, not all of them publicly available.
    •  Some other .DS_Store files.
    • Some other HTML resources.
    Once Google was informed, the files were quickly removed and placed us in its Hall of Fame as a recognition for the little help improving their security.

    Yahoo! case

    This case is much more simple. We found some SVN files with very interesting information in them, inside a domain related with ads in Yahoo!. This is a snapshot with what we found in different paths inside the domain.

    Sensitive information in tw.adspecs.yahoo.com
    More sensitive information in tw.adspecs.yahoo.com
    Fundamentally, there were two URLs.


    Where you could find links to some files, like http://tw.adspecs.yahoo.com/tc/adspec_ppt/tw_chi/SynAd.zip

    From the text files themselves, following information was available (maybe obsolete, but interesting in any case for a pentest):
    • ssh user for svn.corp.yahoo.com (martinso)
    • svn user: (martinso)
    • an internal domain: svn.corp.yahoo.com
    • internal path:  /yahoo/adtech/asia/apac/adspecs/tc/adspec_ppt/tw_chi
    May days later after notifying Yahoo!, they removed the content. We never had an answer from them.

    Pablo González
    pablo.gonzalez@11paths.com