WhatsApp Messages Eavesdropping

Posted in Valnurability on January 10, 2014 by keizer

whatsapplogo

Logging into WhatsApp on a new device currently works as follows:

  • The phone posts its phone number to a HTTPS URL to request an authentication code,
  • the phone receives an authentication code in the text message,
  • the authentication code is used, again over HTTPS, to obtain a password.

These passwords are quite long and never visible to the user, making them hard to steal from a phone.

Authentication Overview

With the password, the client can log in to a XMPP-like server. For this it uses the custom SASL mechanism WAUTH-1. To log in with the phone number 1234567890, the following happens (this is only an XML representation of the protocol)

  • The client sends:
    <auth xmlns=”urn:ietf:params:xml:ns:xmpp-sasl” user=”1234567890” mechanism=”WAUTH-1″ />
  • The server responds with a some challenge (here ABCDEFGHIJKLMNOP):
    <challenge xmlns=”urn:ietf:params:xml:ns:xmpp-sasl”> ABCDEFGHIJKLMNOP</challenge>
  • To respond to the challenge, the client generates a key using PBKDF2 with the user’s password, the challenge data as the salt and SHA1 as the hash function. It only uses 16 iterations of PBKDF2, which is a little low these days, but we know the password is quite long and random so this does not concern me greatly. 20 bytes from the PBKDF2 result are used as a key for RC4, which is used to encrypt and MAC 1234567890 || ABCDEFGHIJKLMNOP || UNIX timestamp:
    <response xmlns=”urn:ietf:params:xml:ns:xmpp-sasl”>XXXXXXXXXXXX</response>
  • From now on, every message is encrypted and MACed (using HMAC-SHA1) using this key.

Mistake #1: The same encryption key in both directions

How RC4 is supposed to work? RC4 is a PRNG that generates a stream of bytes, which are XORed with the plaintext that is to be encrypted. By XORing the ciphertext with the same stream, the plaintext is recovered.

So,  (A ^ X) ^ (B ^ X) = A ^ B

In other words: if we have two messages encrypted with the same RC4 key, we can cancel the key stream out!

As WhatsApp uses the same key for the incoming and the outgoing RC4 stream, we know that ciphertext byte i on the incoming stream XORed with ciphertext byte i on the outgoing stream will be equal to XORing plaintext byte i on the incoming stream with plaintext byte i of the outgoing stream. By XORing this with either of the plaintext bytes, we can uncover the other byte.

This does not directly reveal all bytes, but in many cases it will work: the first couple of messages exchanged are easy to predict from the information that is sent in plain. All messages still have a common structure, despite the binary encoding: for example, every stanza starts with 0xF8. Even if a byte is not known fully, sometimes it can be known that it must be alphanumeric or an integer in a specific range, which can give some information about the other byte.

Mistake #2: The same HMAC key in both directions

The purpose of a MAC is to authenticate messages. But a MAC by itself is not enough to detect all forms of tampering: an attacker could drop specific messages, swap them or even transmit them back to the sender. TLS counters this by including a sequence number in the plaintext of every message and by using a different key for the HMAC for messages from the server to the client and for messages from the client to the server. WhatsApp does not use such a sequence counter and it reuses the key used for RC4 for the HMAC.

When an attacker retransmits, swaps or drops messages the receiver can not notice that, except for the fact that the decryption of the message is unlikely to be a valid binary-XMPP message. However, by transmitting a message back to the sender at exactly the same place in the RC4 stream as it was originally transmitted will make it decrypt properly.

Conclusion

You should assume that anyone who is able to eavesdrop on your WhatsApp connection is capable of decrypting your messages, given enough effort. You should consider all your previous WhatsApp conversations compromised. There is nothing a WhatsApp user can do about this but except to stop using it until the developers can update it.

There are many pitfalls when developing a streaming encryption protocol. Considering they don’t know how to use a XOR correctly, maybe the WhatsApp developers should stop trying to do this themselves and accept the solution that has been reviewed, updated and fixed for more than 15 years, like TLS.

Android PoC

Decompiling this turned into a pile of garbarge. All strings are obfuscated so it’s very hard to determine which class is doing what. It appears to use some crypto API as references to certain elliptic curves and AES. This is likely Bouncy Castle, which doesn’t mean they actually use ECC or AES.

So on to the Android Emulator, where it turns out it is not following the authentication procedure as described in my previous post. The mechanism is still called WSAUTH-1, but the initial <auth> contains 45 bytes of data now:

<auth user=”1234567890″ xmlns=”urn:ietf:params:xml:ns:xmpp-sasl” mechanism=”WAUTH-1″> XXXXXXXXXXXX</auth>

After this message the server replies with an encrypted response (ABCDEFGHIJKLMNOP)

The first hint that this is still RC4 is that encrypted messages are of different lengths: a block cipher would require padding and would result in messages of exactly the block size.

45 bytes is also exactly the length of the data in the SASL   <response>. So lets try and repeat the same trick:

  • The plaintext of the XXXXXXXXXXXX block is still 1234567890 || nonce || UNIX time (1234567890 was the phone number, wich is still included in plain). We do not know what the nonce is in this case, but we do know 1234567890. So we could try to make a guess for the timestamp, but lets keep it simple.
  • Calculate (X[i] ^ 1[i]) ^ A[i] (ignoring the HMAC bytes) and the result is (in hex):
    F8 0E BE C3 FC 0A 31 33 38 31 32
  • As mentioned earlier, all stanzas in WhatsApp’s binary encoding start with 0xF8. The last 5 bytes are 13812in ASCII, which looks suspiciously much like the 't' attribute of the <success> message (a UNIX timestamp). The 0xBE refers to the string success in WhatsApp’s encoding.

This is very unlikely to be a coincidence, which proves that the latest version of the Android client is vulnerable.

But where did that RC4 key come from?

Apparently the server is able to generate the RC4 key using no nonce or key exchange with the client. The key is also different on each login, as otherwise the first couple of ciphertext bytes in the <auth> would always be the same.

We can suspect that the key only depends on the password, but new password is obtained during every login. The client makes an HTTPS request to WhatsApp before the fake-XMPP connection is made and yowsup-cli has a flag that will send your password to the server, which will give you a new one if the password was correct.

Conclusion

You should assume that anyone who is able to eavesdrop on your WhatsApp connection is capable of decrypting your messages, given enough effort. You should consider all your previous WhatsApp conversations compromised. There is nothing a WhatsApp user can do about this but except to stop using it until the developers can update it.

There are many pitfalls when developing a streaming encryption protocol. Considering they don’t know how to use a XOR correctly, maybe the WhatsApp developers should stop trying to do this themselves and accept the solution that has been reviewed, updated and fixed for more than 15 years, like TLS.

Thanks to : xnyhps’ blog

Google Chromecast – released yesterday, hacked today

Posted in Exploits with tags , , on July 29, 2013 by keizer

ScreenShot212

On Wednesday, July 24th Google launched the Chromecast. As soon as the source code hit GTV Hacker began their audit. Within a short period of time they had multiple items to look at for when their devices arrived. Then they received their Chromecasts the following day and were able to confirm that one of the bugs existed in the build Chromecast shipped with. From that point on they began building what you are now seeing as our public release package.

Exploit Package:

GTV Hacker Chromecast exploit package will modify the system to spawn a root shell on port 23. This will allow researchers to better investigate the environment as well as give developers a chance to build and test software on their Chromecasts. For the normal user this release will probably be of no use, for the rest of the community this is just the first step in opening up what has just been a mysterious stick up to this point. GTV Hacker hope that following this release the community will have the tools they need to improve on the shortfalls of this device and make better use of the hardware.

File:Chromecast dirty side1.jpgIs it really ChromeOS?

No, it’s not. GTV Hacker had a lot of internal discussion on this, and have concluded that it’s more Android than ChromeOS. To be specific, it’s actually a modified Google TV release, but with all of the Bionic / Dalvik stripped out and replaced with a single binary for Chromecast. Since the Marvell DE3005 SOC running this is a single core variant of the 88DE3100, most of the Google TV code was reused. So, although it’s not going to let you install an APK or anything, its origins: the bootloader, kernel, init scripts, binaries, are all from the Google TV.

ScreenShot213

How does the exploit work?

Lucky for GTV Hacker, Google was kind enough to GPL the bootloader source code for the device. So they could identify the exact flaw that allows us to boot the unsigned kernel. By holding down the single button, while powering the device, the Chromecast boots into USB boot mode. USB boot mode looks for a signed image at 0×1000 on the USB drive. When found, the image is passed to the internal crypto hardware to be verified, but after this process the return code is never checked! Therefore, they could execute any code at will.

ret = VerifyImage((unsigned int)k_buff, cpu_img_siz, (unsigned int)k_buff);

The example above shows the call made to verify the image, the value stored in ret is never actually verified to ensure that the call to “VerifyImage” succeeded. From that, they were able to execute our own kernel. Hilariously, this was harder to do than our initial analysis of exploitation suggested. This was due to the USB booted kernel needing extra modifications to allow us to modify /system as well as a few other tweaks. GTV Hacker then built a custom ramdisk which, when started, began the process of modifying the system by performing the following steps:

  • Mount the USB drive plugged in to the chromecast.
  • Erase the /system partition (mtd3).
  • Write the new custom system image.
  • Reboot.

Note: /system is squashfs as opposed to normally seen EXT4/YAFFS2.

The system image installed from our package is a copy of the original with a modified /bin/clear_crash_counter binary. This binary was modified to perform its original action as well as spawn a telnet server as root.

After the above process, the only modification to the device is done to spawn a root shell. No update mitigations are performed which means that theoretically, an update could be pushed at any moment patching our exploit. Even with that knowledge, having an internal look at the device is priceless and they hope that the community will be able to leverage this bug in time.

Downloads and instructions for exploitation can be found on their wiki at: GTVHacker Wiki: Google Chromecast

Rooting SIM cards

Posted in Encryption, Mobile, Network Security, Valnurability with tags , , on July 23, 2013 by keizer

SIM cards are the de facto trust anchor of mobile devices worldwide. The cards protect the mobile identity of subscribers, associate devices with phone numbers, and increasingly store payment credentials, for example in NFC-enabled phones with mobile wallets.

With over seven billion cards in active use, SIMs may well be the most widely used security token in the world. Through over-the-air (OTA) updates deployed via SMS, the cards are even extensible through custom Java software. While this extensibility is rarely used so far, its existence already poses a critical hacking risk.

Cracking SIM update keys. OTA commands, such as software updates, are cryptographically-secured SMS messages, which are delivered directly to the SIM. While the option exists to use state-of-the-art AES or the somewhat outdated 3DES algorithm for OTA, many (if not most) SIM cards still rely on the 70s-era DES cipher. DES keys were shown to be crackable within days using FPGA clusters, but they can also be recovered much faster by leveraging rainbow tables similar to those that made GSM’s A5/1 cipher breakable by anyone.

To derive a DES OTA key, an attacker starts by sending a binary SMS to a target device. The SIM does not execute the improperly signed OTA command, but does in many cases respond to the attacker with an error code carrying a cryptographic signature, once again sent over binary SMS. A rainbow table resolves this plaintext-signature tuple to a 56-bit DES key within two minutes on a standard computer.

Deploying SIM malware. The cracked DES key enables an attacker to send properly signed binary SMS, which download Java applets onto the SIM. Applets are allowed to send SMS, change voicemail numbers, and query the phone location, among many other predefined functions. These capabilities alone provide plenty of potential for abuse.

In principle, the Java virtual machine should assure that each Java applet only accesses the predefined interfaces. The Java sandbox implementations of at least two major SIM card vendors, however, are not secure: A Java applet can break out of its realm and access the rest of the card. This allows for remote cloning of possibly millions of SIM cards including their mobile identity (IMSI, Ki) as well as payment credentials stored on the card.

Defenses. The risk of remote SIM exploitation can be mitigated on three layers:

  1. Better SIM cards. Cards need to use state-of-art cryptography with sufficiently long keys, should not disclose signed plaintexts to attackers, and must implement secure Java virtual machines. While some cards already come close to this objective, the years needed to replace vulnerable legacy cards warrant supplementary defenses.
  2. Handset SMS firewall. One additional protection layer could be anchored in handsets: Each user should be allowed to decide which sources of binary SMS to trust and which others to discard. An SMS firewall on the phone would also address other abuse scenarios including “silent SMS.”
  3. In-network SMS filtering. Remote attackers rely on mobile networks to deliver binary SMS to and from victim phones. Such SMS should only be allowed from a few known sources, but most networks have not implemented such filtering yet. “Home routing” is furthermore needed to increase the protection coverage to customers when roaming. This would also provide long-requested protection from remote tracking.

Thanks to: Security Research Labs who published this!

This research will be presented at BlackHat on Jul 31st and at the OHM hacking camp on Aug 3rd 2013

Uncovering Android Master Key – 99% of devices are vulnerable!

Posted in Encryption, Malware, Mobile, Valnurability with tags , , , on July 4, 2013 by keizer
 

The Bluebox Security research team –  recently discovered a vulnerability in Android’s security model that allows a hacker to modify APK code without breaking an application’s cryptographic signature, to turn any legitimate application into a malicious Trojan, completely unnoticed by the app store, the phone, or the end user. The implications are huge! This vulnerability, around at least since the release of Android 1.6 (codename: “Donut” ), could affect any Android phone released in the last 4 years1 – or nearly 900 million devices2– and depending on the type of application, a hacker can exploit the vulnerability for anything from data theft to creation of a mobile botnet.

While the risk to the individual and the enterprise is great (a malicious app can access individual data, or gain entry into an enterprise), this risk is compounded when you consider applications developed by the device manufacturers (e.g. HTC, Samsung, Motorola, LG) or third-parties that work in cooperation with the device manufacturer (e.g. Cisco with AnyConnect VPN) – that are granted special elevated privileges within Android – specifically System UID access.

Installation of a Trojan application from the device manufacturer can grant the application full access to Android system and all applications (and their data) currently installed. The application then not only has the ability to read arbitrary application data on the device (email, SMS messages, documents, etc.), retrieve all stored account & service passwords, it can essentially take over the normal functioning of the phone and control any function thereof (make arbitrary phone calls, send arbitrary SMS messages, turn on the camera, and record calls). Finally, and most unsettling, is the potential for a hacker to take advantage of the always-on, always-connected, and always-moving (therefore hard-to-detect) nature of these “zombie” mobile devices to create a botnet.

How it works:

The vulnerability involves discrepancies in how Android applications are cryptographically verified & installed, allowing for APK code modification without breaking the cryptographic signature.

All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application – essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.

Details of Android security bug 8219321 were responsibly disclosed through Bluebox Security’s close relationship with Google in February 2013. It’s up to device manufacturers to produce and release firmware updates for mobile devices (and furthermore for users to install these updates). The availability of these updates will widely vary depending upon the manufacturer and model in question.

The screenshot below demonstrates that Bluebox Security has been able to modify an Android device manufacturer’s application to the level that we now have access to any (and all) permissions on the device. In this case, we have modified the system-level software information about this device to include the name “Bluebox” in the Baseband Version string (a value normally controlled & configured by the system firmware).

Screenshot of HTC Phone After Exploit

exploit

Recommendations

  • Device owners should be extra cautious in identifying the publisher of the app they want to download.
  • Enterprises with BYOD implementations should use this news to prompt all users to update their devices, and to highlight the importance of keeping their devices updated.
  • IT should see this vulnerability as another driver to move beyond just device management to focus on deep device integrity checking and securing corporate data.

Thanks Bluebox Security

Skype? Microsoft reads everything you write!

Posted in Application, Encryption, Network Security, Valnurability with tags , , on May 23, 2013 by keizer

Thanks goes to The-H, for their original post @ h-online.com

Anyone who uses Skype has consented to the company reading everything they write. The H’s associates in Germany at heise Security have now discovered that the Microsoft subsidiary does in fact make use of this privilege in practice. Shortly after sending HTTPS URLs over the instant messaging service, those URLs receive an unannounced visit from Microsoft HQ in Redmond.

A reader informed heise Security that he had observed some unusual network traffic following a Skype instant messaging conversation. The server indicated a potential replay attack. It turned out that an IP address which traced back to Microsoft had accessed the HTTPS URLs previously transmitted over Skype. Heise Security then reproduced the events by sending two test HTTPS URLs, one containing login information and one pointing to a private cloud-based file-sharing service. A few hours after their Skype messages, they observed the following in the server log:

65.52.100.214 - - [30/Apr/2013:19:28:32 +0200]
"HEAD /.../login.html?user=tbtest&password=geheim HTTP/1.1"

the source...
The access is coming from systems which clearly belong to Microsoft.      source: utrace

Source: Utrace They too had received visits to each of the HTTPS URLs transmitted over Skype from an IP address registered to Microsoft in Redmond. URLs pointing to encrypted web pages frequently contain unique session data or other confidential information. HTTP URLs, by contrast, were not accessed. In visiting these pages, Microsoft made use of both the login information and the specially created URL for a private cloud-based file-sharing service.

In response to an enquiry from heise Security, Skype referred them to a passage from its data protection policy:

“Skype may use automated scanning within Instant Messages and SMS to (a) identify suspected spam and/or (b) identify URLs that have been previously flagged as spam, fraud, or phishing links.”

A spokesman for the company confirmed that it scans messages to filter out spam and phishing websites. This explanation does not appear to fit the facts, however. Spam and phishing sites are not usually found on HTTPS pages. By contrast, Skype leaves the more commonly affected HTTP URLs, containing no information on ownership, untouched. Skype also sends head requests which merely fetches administrative information relating to the server. To check a site for spam or phishing, Skype would need to examine its content.

Back in January, civil rights groups sent an open letter to Microsoft questioning the security of Skype communication since the takeover. The groups behind the letter, which included the Electronic Frontier Foundation and Reporters without Borders expressed concern that the restructuring resulting from the takeover meant that Skype would have to comply with US laws on eavesdropping and would therefore have to permit government agencies and secret services to access Skype communications.

In summary, The H and heise Security believe that, having consented to Microsoft using all data transmitted over the service pretty much however it likes, all Skype users should assume that this will actually happen and that the company is not going to reveal what exactly it gets up to with this data.

Pool Party!

Posted in Application, Mobile with tags , , , on January 29, 2013 by keizer

Pool Party

A new social pool game by nitako – pool party was recently released to the mobiles (iphone and android)- letting you play pool against Facebook users, using turns.

It is actually a pretty cool game, I played it (normally) for about 2 weeks… getting better and better. I must say, once you get how it works, its pretty easy to score the balls. As you earn more and more coins, you want play on larger pots. And that’s what I did… Now, you probably know the saying “Don’t put all your eggs in one basket”, so I did :\ – playing with all my coins against one dude, which turned out to be better then then I expected, which led me to lose all my coins!

This is when I lost my temper… after all the time & effort I put in this game, I left with nothing! It’s time to use my profession skills for something truly important! let’s try and get more coins… and fast!

So I started digging in the application’s traffic… changing the amount of coins, pots, cash… every variable that held an amount of coins, I changed it… but nothing!

Until I found a way… which,  to my disappointment, includes taking others’ coins 😦 oh well… its not real money 🙂

and this is how it works:

Play a game, until you win (it doesn’t matter on what amount you’re playing on)  and the game ends – catch the requests. One of them will look like this (notice the tableData=) :

org_req

Copy the part from the tableData= to the end of the request – which should say: result=EightSank – and paste it into a notepad or any other text editor.  Next time you’re playing with someone, just after hitting the ball – intercept the requests (using any proxy application), and when you see the requests that holds the tableData – replace it with the text you saved, which represents the insertion of the 8 ball, which indicates that you have won. 

Now, let’s see it in action:

1. I have 12,250 coins:

before

2. Oh, it’s my turn,  so I’ll just turn the requests interception ON :

ur_turn

3. After hitting the ball (it doesn’t matter what actually happens in the game), I find the request we discussed earlier and replaced the tableData part. Which in this case saying result=TurnOver (guess not…:))

tamper24. With the EightSank tableData – I saved from one of my (many) victories:

tamper3

5. Its magic! most of the balls are still on the table, but it says clearlyYou Cleared the table ! the game ends with a pot of $200 :

cleared

6. Voilà! I now have 12,350 coins (Of course, I invested 100 myself, so the actual profit is, in this case, 100$)…

after

If you liked that post, and you want me to find you fast& easy ways to earn coins – comment with the name of the iphone game you want, and I’ll do my best.

Cheers!

New Zero-Day Java Exploit

Posted in JAVA, Malware with tags , , on January 13, 2013 by keizer

After Julia Wolf, Darien Kindlund, and James Bennett from FireEye, in their post: Happy New Year from new Java Zero-day, observed that a Java security bypass zero-day vulnerability (CVE-2013-0422) has been actively exploited in the wild starting Jan. 2. They have been able to reproduce the attack in-house with the latest Java 7 update (Java 7 update 10) on Windows.

Some initial landing pages are actually hosted on a popular file-sharing website. Eventually the landing pages redirect to several different domains hosting exploits and malware.

ScreenShot079
The malware will download an executable file from a remote server and execute it by exploiting the vulnerability. Though the malware is designed for Windows only, the vulnerability can also be exploited across different browsers and OS platforms.

ScreenShot080

The malware payload is ransomware, commonly known as Tobfy. It retrieves a template from the Web, in this case:
hxxp://<random>.cristmastea.info/get.php — and creates a full screen window demanding payment using some kind of social engineering scheme to scare the victim. Additionally, it disables Windows Safe Mode by deleting values under

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SafeBoot, and it terminates processes like “taskmgr.exe,” “msconfig.exe,” “regedit.exe,” and “cmd.exe” in order to deter the victim from trying to find or disable the malware. Strings such as:
\\xneo\\lock\\Release\\lock.pdb and “Conteneur ActiveX” were found in memory and helped make identification easier.

One more noteworthy finding is that the URLs used to download the template and make callbacks are stored XOR encoded and must be decoded before use. However, it appears the author forgot to call the decode function in the callback thread. This means that the malware is unable to communicate with the attacker. The malware is supposed to make an HTTP request for:
hxxp://<random>.my-files-download.ru/status.php, but instead requests the invalid URL
hxxp://<random>.my-files-download.ru/.ru`utr/qiq. What makes this error even worse for victims is that this callback thread determines whether the victim has paid the fee and is responsible for removing the ransomware from the system. It seems even paying up will do no good in this case!

ScreenShot081
ScreenShot082

ScreenShot083