Archive for the Encryption Category

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

Advertisements

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.

Clear-Text Passwords in your environment?

Posted in Encryption, Valnurability on March 29, 2012 by keizer

Do you keep the password to your bank on a note posted to your computer?

No? So why would you Do you keep the password to your bank on a note posted to your computer? No? So why would you keep your DB/server/application passwords exposed in the environment??? Well, that is a problem that concerns us all… and it is also against common regulations… so all you need to do is DELETE them!!!! or, in case you need them after all – ENCRYPT them! (and don’t use MD5 or SHA1.) How will you find them… that is the real question here… OK, so especially for that, i created a script (attached) to run on linux environment (currently, this is the only OS supported, if you need to run on a different environment please contact me) all you need to do, is copy the script to the directory you want to be the “root” for the search. then execute the script to get the manual, basically it looks like that: keep your DB/server/application passwords exposed in the environment???

Well, that is a problem that concerns us all… and it is also against common regulations… so all you need to do is DELETE them!!!! or, in case you need them after all – ENCRYPT them! (and don’t use MD5 or SHA1.)

How will you find them? that is the real question here…
OK, so especially for that, I created a script to run on linux environment (currently, this is the only OS supported, if you need to run on a different environment please contact me)

all you need to do, is copy the script (attached) to the directory you want to be the “root” for the search.
Then execute the script to get the manual, basically it looks like that:

Now, lets run it with the default list of strings to look for, using the -d argument, and this is what we’ll get:

You can also run it with a file path to get the list from the file, while each line in the file represent the string to look for. so executing ./findpass pass.list will use the list inside ./pass.list

Using the -p argument will prompt to receive input of passwords from the user:

and the -i for interactive mode:

That’s all for now, if you have any ideas, suggestions, features
if you found bugs (you must be wrong!) or you want any customization, please contact me!

Download script from >> HERE <<

SALT

Posted in Application, Encryption, JAVA on January 26, 2012 by keizer

salt

Hashing – Using SALT properly

Technically, the salt should be unique. The point of the salt is to be individual for each hashed password. The best way to do it is using a random selection with an unpredictable random generator, preferably within a salt space large enough to make collisions improbable (two instances using the same salt value).

Well, sometime it is tempting to try to create a salt from some data which is “presumably unique”, such as the user ID, but it is WRONG! here is why:

1. If you use for example the user ID, an attacker can just pre create a tables for user IDs 1 to 9999 – since a user ID is unique only per system but not worldwide.

2. The same applies to the username: there is one “root” per Unix system, but there are many roots in the world – a rainbow table for “root” could be applied to millions of systems and thus probably have been generated already. Worse yet, there are also many “bob”s and “john”s, and their passwords could be quite weak.

3. Sometimes, users change their password. For each new password, a new salt must be selected – otherwise, an attacker obtained the hash of the old password and the hash of the new could try to attack both simultaneously.

Here is an example for how to use salt:

import java.security.MessageDigest;

public byte[] getHash(String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-256”);
digest.reset();
digest.update(salt);
return digest.digest(password.getBytes(“UTF-8”));
}

To slow down the computation it is recommended to iterate the hash operation n times. While hashing the password n times does slow down hashing for both attackers and typical users, typical users don’t really notice it being that hashing is such a small percentage of their total time interacting with the system. On the other hand, an attacker trying to crack passwords spends nearly 100% of their time hashing so hashing n times gives the appearance of slowing the attacker down by a factor of n while not noticeably affecting the typical user.
The stored password looks like this : Hash(hash(hash(hash(……….hash(password||salt)))))))))))))))

and the implementations should be as follows:


import java.security.*;

public byte[] getHash(int iterationNb, String password, byte[] salt) {
MessageDigest digest = MessageDigest.getInstance(“SHA-1”);
digest.reset();
digest.update(salt);
byte[] input = digest.digest(password.getBytes(“UTF-8”));
for (int i = 0; i < iterationNb; i++) {
digest.reset();
input = digest.digest(input);
}
return input;
}

Thanks also to: OWASP

The BEAST – SSL Crack

Posted in Application, Encryption, Malware, Network Security, Valnurability on October 24, 2011 by keizer

Researchers have discovered a serious weakness in virtually all websites protected by the secure sockets layer protocol that allows attackers to silently decrypt data that’s passing between a webserver and an end-user browser.

The vulnerability resides in versions 1.0 and earlier of TLS, or transport layer security, the successor to the secure sockets layer technology that serves as the internet’s foundation of trust. Although versions 1.1 and 1.2 of TLS aren’t susceptible, they remain almost entirely unsupported in browsers and websites alike, making encrypted transactions on PayPal, GMail, and just about every other website vulnerable to eavesdropping by hackers who are able to control the connection between the end user and the website he’s visiting.

At the Ekoparty security conference in Buenos Aires later this week, researchers Thai Duong and Juliano Rizzo plan to demonstrate proof-of-concept code called BEAST, which is short for Browser Exploit Against SSL/TLS. The stealthy piece of JavaScript works with a network sniffer to decrypt encrypted cookies a targeted website uses to grant access to restricted user accounts. The exploit works even against sites that use HSTS, or HTTP Strict Transport Security, which prevents certain pages from loading unless they’re protected by SSL.

The demo will decrypt an authentication cookie used to access a PayPal account, Duong said. Two days after this article was first published, Google released a developer version of its Chrome browser designed to thwart the attack. Update here.
Like a cryptographic Trojan horse

The attack is the latest to expose serious fractures in the system that virtually all online entities use to protect data from being intercepted over insecure networks and to prove their website is authentic rather than an easily counterfeited impostor. Over the past few years, Moxie Marlinspike and other researchers have documented ways of obtaining digital certificates that trick the system into validating sites that can’t be trusted.

Earlier this month, attackers obtained digital credentials for Google.com and at least a dozen other sites after breaching the security of disgraced certificate authority DigiNotar. The forgeries were then used to spy on people in Iran accessing protected GMail servers.

By contrast, Duong and Rizzo say they’ve figured out a way to defeat SSL by breaking the underlying encryption it uses to prevent sensitive data from being read by people eavesdropping on an address protected by the HTTPs prefix.

“BEAST is different than most published attacks against HTTPS,” Duong wrote in an email. “While other attacks focus on the authenticity property of SSL, BEAST attacks the confidentiality of the protocol. As far as we know, BEAST implements the first attack that actually decrypts HTTPS requests.”

Duong and Rizzo are the same researchers who last year released a point-and-click tool that exposes encrypted data and executes arbitrary code on websites that use a widely used development framework. The underlying “cryptographic padding oracle” exploited in that attack isn’t an issue in their current research.

Instead, BEAST carries out what’s known as a plaintext-recovery attack that exploits a vulnerability in TLS that has long been regarded as mainly a theoretical weakness. During the encryption process, the protocol scrambles block after block of data using the previous encrypted block. It has long been theorized that attackers can manipulate the process to make educated guesses about the contents of the plaintext blocks.

If the attacker’s guess is correct, the block cipher will receive the same input for a new block as for an old block, producing an identical ciphertext.

At the moment, BEAST requires about two seconds to decrypt each byte of an encrypted cookie. That means authentication cookies of 1,000 to 2,000 characters long will still take a minimum of a half hour for their PayPal attack to work. Nonetheless, the technique poses a threat to millions of websites that use earlier versions of TLS, particularly in light of Duong and Rizzo’s claim that this time can be drastically shortened.

In an email sent shortly after this article was published, Rizzo said refinements made over the past few days have reduced the time required to under 10 minutes.

“BEAST is like a cryptographic Trojan horse – an attacker slips a bit of JavaScript into your browser, and the JavaScript collaborates with a network sniffer to undermine your HTTPS connection,” Trevor Perrin, an independent security researcher, wrote in an email. “If the attack works as quickly and widely as they claim it’s a legitimate threat.”

from theregister.co.uk

TDL4 – Super Bot

Posted in Application, Encryption, Malware, Network Security on July 18, 2011 by keizer

The TDSSs

The malware detected by Kaspersky Anti-Virus as TDSS is the most sophisticated threat today. TDSS uses a range of methods to evade signature, heuristic, and proactive detection, and uses encryption to facilitate communication between its bots and the botnet command and control center. TDSS also has a powerful rootkit component, which allows it to conceal the presence of any other types of malware in the system.

Its creator calls this program TDL. Since it first appeared in 2008, malware writers have been perfecting their creation little by little. By 2010, the latest version was TDL-3, which was discussed in depth in an article published in August 2010.

The creators of TDSS did not sell their program until the end of 2010. In December, when analyzing a TDSS sample, we discovered something odd: a TDL-3 encrypted disk contained modules of another malicious program, SHIZ.

TDL-3 encrypted disk with SHIZ modules

At that time, a new affiliate program specializing in search engine redirects had just emerged on the Internet; it belonged to the creators of SHIZ, but used TDL-3.

The changes that had been made to the TDL-3 configuration and the emergence of a new affiliate marketing program point to the sale of TDL-3 source code to cybercriminals who had previously been engaged in the development of SHIZ malware.

Why did the creators of TDL decide to sell source code of the third version of their program? The fact is that by this time, TDL-4 had already come out. The cybercriminals most likely considered the changes in version 4 to be significant enough that they wouldn’t have to worry about competition from those who bought TDL-3.

In late 2010, Vyacheslav Rusakov wrote a piece on the latest version of the TDSS rootkit focusing on how it works within the operating system. This article will take a closer look at how TDL-4 communicates with the network and uploads data to the botnet, which numbered over 4.5 million infected computers at the time of writing.

Yet another affiliate program

The way in which the new version of TDL works hasn’t changed so much as how it is spread – via affiliates. As before, affiliate programs offer a TDL distribution client that checks the version of the operating system on a victim machine and then downloads TDL-4 to the computer.

Affiliates spreading TDL

Affiliates receive between $20 to $200 for every 1,000 installations of TDL, depending on the location of the victim computer. Affiliates can use any installation method they choose. Most often, TDL is planted on adult content sites, bootleg websites, and video and file storage services.

The changes in TDL-4 affected practically all components of the malware and its activity on the web to some extent or other. The malware writers extended the program functionality, changed the algorithm used to encrypt the communication protocol between bots and the botnet command and control servers, and attempted to ensure they had access to infected computers even in cases where the botnet control centers are shut down. The owners of TDL are essentially trying to create an ‘indestructible’ botnet that is protected against attacks, competitors, and antivirus companies.

The ‘indestructible’ botnet

Encrypted network connections

One of the key changes in TDL-4 compared to previous versions is an updated algorithm encrypting the protocol used for communication between infected computers and botnet command and control servers. The cybercriminals replaced RC4 with their own encryption algorithm using XOR swaps and operations. The domain names to which connections are made and the bsh parameter from the cfg.ini file are used as encryption keys.

Readers may recall that one of the distinguishing features of malware from the TDSS family is a configuration file containing descriptions of the key parameters used by various modules to maintain activity logs and communications with command and control servers.

Example of configuration file content

Compared to version 3, there are only negligible changes to the format of the configuration file. The main addition is the bsh parameter, an identifier which identifies the copy of the malware, and which is provided by the command and control sever the first time the bot connects. This identifier acts as one of the encryption keys for subsequent connections to the command and control server.

Part of the code modified to work with the TDL-4 protocol.

Upon protocol initialization, a swap table is created for the bot’s outgoing HTTP requests. This table is activated with two keys: the domain name of the botnet command and control server, and the bsh parameter. The source request is encrypted and then converted to base64. Random strings in base64 are prepended and appended to the received message. Once ready, the request is sent to the server using HTTPS.

The new protocol encryption algorithm for communications between the botnet control center and infected machines ensures that the botnet will run smoothly, while protecting infected computers from network traffic analysis, and blocking attempts of other cybercriminals to take control of the botnet.

An antivirus of its own

Just like Sinowal, TDL-4 is a bootkit, which means that it infects the MBR in order to launch itself, thus ensuring that malicious code will run prior to operating system start. This is a classic method used by downloaders which ensures a longer malware lifecycle and makes it less visible to most security programs.

TDL nimbly hides both itself and the malicious programs that it downloads from antivirus products. To prevent other malicious programs not associated with TDL from attracting the attention of users of the infected machine, TDL-4 can now delete them. Not all of them, of course, just the most common.

TDSS module code which searches the system registry for other malicious programs

TDSS contains code to remove approximately 20 malicious programs, including Gbot, ZeuS, Clishmic, Optima, etc. TDSS scans the registry, searches for specific file names, blacklists the addresses of the command and control centers of other botnets and prevents victim machines from contacting them.

This ‘antivirus’ actually helps TDSS; on the one hand, it fights cybercrime competition, while on the other hand it protects TDSS and associated malware against undesirable interactions that could be caused by other malware on the infected machine.

Which malicious programs does TDL-4 itself download? Since the beginning of this year, the botnet has installed nearly 30 additional malicious programs, including fake antivirus programs, adware, and the Pushdo spambot.

TDSS downloads

Notably, TDL-4 doesn’t delete itself following installation of other malware, and can at any time use the r.dll module to delete malware it has downloaded.

Command and control server statistics

Despite the steps taken by cybercriminals to protect the command and control centers, knowing the protocol TDL-4 uses to communicate with servers makes it possible to create specially crafted requests and obtain statistics on the number of infected computers. Kaspersky Lab’s analysis of the data identified three different MySQL databases located in Moldova, Lithuania, and the USA, all of which supported used proxy servers to support the botnet.

According to these databases, in just the first three months of 2011 alone, TDL-4 infected 4,524,488 computers around the world.

 
Distribution of TDL-4 infected computers by country

Nearly one-third of all infected computers are in the United States. Going on the prices quoted by affiliate programs, this number of infected computers in the US is worth $250,000, a sum which presumably made its way to the creators of TDSS. Remarkably, there are no Russian users in the statistics. This may be explained by the fact that affiliate marketing programs do not offer payment for infecting computers located in Russia.