Nytro Posted July 24, 2012 Report Posted July 24, 2012 [h=3]Android DNS Poisoning: Randomness gone bad (CVE-2012-2808)[/h] Recently we discovered a very interesting vulnerability in Android’s DNS resolver, a weakness in its pseudo-random number generator (PRNG), which makes DNS poisoning attacks feasible. DNS poisoning attacks endanger the confidentiality and integrity of the target victim’s machine. For instance, DNS poisoning can be used to steal the victim’s cookies, or tamper with weak applications’ update mechanisms in order to execute malicious code. The official advisory with full details can be found here. This blog post summarizes the advisory. A very short background on DNS poisoning Each DNS request holds a unique identifier (‘nonce’) which consists of an attribute called ‘TXID’ and the UDP source port. They both combine to a 32bit value. Ideally these 32 bits are random. In order to conduct a DNS poisoning attack, an attacker must be able to inject a forged response before the legitimate one arrives from the server. The forged response must include the correct nonce (that the attacker must correctly guess), otherwise it is dropped by the resolver. If the nonce is a 32bit random value, an attack takes years to succeed (in average). Not that feasible! But with every bit of randomness we are able to reduce from the nonce, the expected time drops by a factor of two. How does android resolve DNS? The code that is in charge of the DNS resolution can be found under Android’s libc implementation (aka ‘bionic’). Android provides source port and TXID randomization by calling the function res_randomid , which returns a 16bit integer: 1: u_int 2: res_randomid(void) { 3: struct timeval now; 4: 5: gettimeofday(&now, NULL); 6: return (0xffff & (now.tv_sec ^ now.tv_usec ^ getpid())); 7: }It can be seen that the returned value is a XOR operation of the fraction of the current time in microseconds, the current time in seconds and the process ID. This method is used twice in close succession in order to produce the TXID and source port values. The dominant factor which makes this value hard to predict is the microseconds fraction. Why is it vulnerable? Remember that the res_randomid function is used twice, once for the TXID, and once for the source port. The Achilles' heel and the crux of the attack is the fact that there two subsequent calls to the res_random_id function in a very short time. Since res_random_id is a function of the current time, the TXID and source port values become very much correlated to each other: given that the attacker guessed correctly one value, probability is high that the other value would be also guessed correctly. This means that instead of 32 random bits, you get much less. In fact, our research shows that in some environments, the 32 bits contain less than 21 random ones. The expected time for a successful attack is brought down from years to minutes! The attack is feasible regardless of whether or not the attacker knows the process ID. See our whitepaper for the complete analysis. Take a look at the following capture: Let’s examine some source port, TXID couples and verify if there is any correlation: It can be seen even to the naked eye that the TXID and source port values are not that different. Remember that ideally each of them is chosen out of 65536 values. Why should you care? What is the impact? As usual, DNS poisoning attacks may endanger the integrity and confidentiality of the attacked system. For example, in Android, the Browser app can be attacked in order to steal the victim's cookies of a domain of the attacker's choice. In case the attacker manages to lure the victim to browse a web page controlled by him/her, the attacker can use JavaScript in order to start resolving non-existing sub-domains. Upon success, a sub-domain points to the attacker's IP, which enables the latter to steal wildcard cookies of the attacked domain, and even insert ones (see this for more details on the impact of subdomain poisoning). In addition, a malicious app may instantiate the Browser app on the attacker's malicious web-page. If the attacker knows the process ID (for example, a malicious app can access that information), the expected time for a successful attack can be reduced, as explained in the whitepaper. A video demo of the attack How was the issue fixed? The random sample is now taken from /dev/urandom which should have enough entropy when the call is made. Which versions are vulnerable? Android 4.0.4 and below Which versions are non-vulnerable? Android 4.1.1 Disclosed by: Roee Hay and Roi Saltzman Disclosure timeline 07/24/2012 Public disclosure 06/05/2012 Issue confirmed by Android Security Team and patch provided to partners 05/21/2012 Disclosed to Android Security Team by Roee Hay and Roi Saltzman Posted by Roee Hay on July 24, 2012Sursa: IBM Application Security Insider: Android DNS Poisoning: Randomness gone bad (CVE-2012-2808) Quote
Nytro Posted August 3, 2012 Author Report Posted August 3, 2012 [h=3]CVE-2012-2808 : Android 4.0.4 DNS poisoning vulnerability Exposed[/h]Posted On 7/25/2012 12:19:00 PM By THN Security Analyst Android's DNS resolver is vulnerable to DNS poisoning due to weak randomness in its implementation. Researchers Roee Hay & Roi Saltzman from IBM Application Security Research Group demonstrate that how an attacker can successfully guess the nonce of the DNS request with a probability thatis su cient for a feasible attack. Android version 4.0.4 and below are Vulnerable to this bug.Weakness in its pseudo-random number generator (PRNG), which makes DNS poisoning attacks feasible. DNS poisoning attacks may endanger the integrity and con dentiality of the attacked system. For example, in Android, the Browser app can be attacked in order to steal the victim's cookies of a domain of the attacker's choice. If the attacker manages to lure the victim to browse to a web page controlled by him/her, the attacker can use JavaScript, to start resolving non-existing sub-domains.Upon success, a sub-domain points to the attacker's IP, which enables the latter to steal wild card cookies of the attacked domain, and even set cookies. In addition, a malicious app instantiate the Browser app on the attacker's malicious web-page. If the attacker knows the PID (for example, a malicious app can access that information), the attack expected time can be reduced furthermore.Vulnerability dubbed as "CVE-2012-2808" Android 4.1.1 has been released, and patches are available on AOSP. The random sample is now pulled from /dev/urandom, which should have adequate entropy by the time network activity occurs. Sursa: CVE-2012-2808 : Android 4.0.4 DNS poisoning vulnerability Exposed | The Hacker News Quote
