Hacking Facebook Passwords like changing your own Password

Hacker found a way to hack and change your password like, just he used to change his own password. Confused ? Recently Facebook fix a very critical vulnerability on the tip of 'Sow Ching Shiong', an independent vulnerability researcher. Flaw allows anyone to reset the password of any Facebook user without knowing his last password.

At Facebook, there is an option for compromised accounts at "https://www.facebook.com/hacked" , where Facebook ask one to change his password for further protection. This compromised account recovery page, will redirect you to another page at "https://www.facebook.com/checkpoint/checkpointme?f=[userid]&r=web_hacked" .

Researcher notice that the URL of the page having a parameter called "f" which represents your user ID and replacing the user ID with victim's user ID allow him to get into next page where attacker can reset the password of victim without knowing his last password.

Hacking Facebook Account with just a text message

Can you ever imagine that a single text message is enough to hack any Facebook account without user interaction or without using any other malicious stuff like Trojans, phishing, keylogger etc. ?

Today we are going to explain you that how a UK based Security Researcher, "fin1te" is able to hack any Facebook account within a minute by doing one SMS.

Because 90% of us are Facebook user too, so we know that there is an option of linking your mobile number with your account, which allows you to receive Facebook account updates via SMS directly to your mobile and also you can login into your account using that linked number rather than your email address or username

According to hacker, the loophole was in phone number linking process, or in technical terms, at file /ajax/settings/mobile/confirm_phone.php

This particular webpage works in background when user submit his phone number and verification code, sent by Facebook to mobile. That submission form having two main parameters, one for verification code, and second isprofile_id, which is the account to link the number to.

As attacker, follow these steps to execute hack:

 

1. Change value of profile_id to the Victim's profile_id value by tampering the parameters.
2. Send the letter F to 32665, which is Facebook’s SMS shortcode in the UK. You will receive an 8 character verification code back.

3. Enter that code in the box or as confirmation_code parameter value and Submit the form.

Facebook will accept that confirmation code and attacker's mobile number will be linked to victim's Facebook profile.

In next step hacker just need to go to Forgot password option and initiate the password reset request against of victim's account.

Attacker now can get password recovery code to his own mobile number which is linked to victim's account using above steps. Enter the code and Reset the password!

Facebook no longer accepting the profile_id parameter from the user end after receiving the bug report from the hacker.

Unauthorized Access Backdoor found in D-Link router Firmware Code

A number of D-Link routers reportedly have an issue that makes them susceptible to unauthorized backdoor access.

The researcher Craig, specialized on the embedded device hacking - demonstrated the presence of a backdoor within some DLink routers that allows an attacker to access the administration web interface of network devices without any authentication and view/change its settings.

He found the backdoor inside the firmware v1.13 for the DIR-100 revA. Craig found and extracted the SquashFS file system loading firmware’s web server file system (/bin/webs) into IDA.

Giving a look at the string listing, the Craig's attention was captured by a modified version of thttpd, the thttpd-alphanetworks/2.23, implemented to provide the rights to the administrative interface for the router. 

The library is written by Alphanetworks, a spin-off company of D-Link, analyzing it Craig found many custom functions characterized by a name starting with suffix “alpha” including the alpha_auth_check. 

The function is invoked to parse http request in the phase of authentication.

"We can see that alpha_auth_check is passed one argument (whatever is stored in register $s2); if alpha_auth_check returns -1 (0xFFFFFFFF), the code jumps to the end of alpha_httpd_parse_request, otherwise it continues processing the request." 

Analyzing the parameters passed to the function the researcher was able to reconstruct the authentication flow, the function parses the requested URL and check if it contains the strings “graphic/” or “public/”. “graphic/” or “public/” are sub-directories under the device’s web directory, if the requested URL contains one of them the request is passed without authentication.

Another intriguing detail has been found by Craig that by changing the user-agent in a web browser to “xmlset_roodkcableoj28840ybtide,” a user could bypass the security on the device and get online or control the higher functions of the router.

Craig decided to search the code “xmlset_roodkcableoj28840ybtide” on Google and discovered traces of it only in one Russian forum post from a few years ago. Going deep in its analysis Craig was able to piece together the body of the alpha_auth_check:

int alpha_auth_check(struct http_request_t *request)

{

if(strstr(request->url, "graphic/") ||

strstr(request->url, "public/") ||

strcmp(request->user_agent, "xmlset_roodkcableoj28840ybtide") == 0)

{

return AUTH_OK;

}

else

{

// These arguments are probably user/pass or session info

if(check_login(request->0xC, request->0xE0) != 0)

{

return AUTH_OK;

}

}

return AUTH_FAIL;

}

Try to read the string xmlset_roodkcableoj28840ybtide backwards .... It appears as "Edit by 04882 Joel backdoor", very cool.

The worrying part about this vulnerability is how it can be exploited. Anyone connected to the router, whether it's through Ethernet or Wi-Fi, can simply set their browser's user agent string to a specific codeword and then attempt to access the web configuration panel.

Craig extended the results of its discovery to many other D-Link devices affected by the same backdoor, the author searched for the code present in the HTML pages on the entire Internet with the Shodan. He searched for the word "thttpd-alphanetworks/2.23", the modified version of thttpd, retrieving following search results:

After a series of test Craig concluded that the following D-Link devices are likely affected:

• DIR-100

• DI-524

• DI-524UP

• DI-604S

• DI-604UP

• DI-604+

• TM-G5240

The researcher discovered also that Planex routers, based on the same firmware, are affected by the flaw.

• BRL-04UR

• BRL-04CW

D-Link has confirmed that the flaw exists, but has refused to provide comment on how it was inserted into its products. 'D-Link will be releasing firmware updates to address the security vulnerabilities in affected D-Link routers by the end of October,' a company spokesperson explained.

Cracking 16 Character Strong passwords in less than an hour

The Password serves to protect your financial transactions, your social networking sites, and a host of other nominally secure websites online. People often say, "don't use dictionary words as passwords. They are horribly unsecure", but what if hackers also managed to crack any 16 character password ?

Criminals or trespassers who want to crack into your digital figurative backyard will always find a way. A team of hackers has managed to crack more than 14,800 supposedly random passwords from a list of 16,449 converted into hashes using the MD5 cryptographic hash function.

The problem is the relatively weak method of encrypting passwords called hashing. Hashing takes each user's plain text password and runs it through a one-way mathematical function. This creates a unique string of numbers and letters called the hash.

The article reports that, using a commodity computer with a single AMD Radeon 7970 graphics card, it took him 20 hours to crack 14,734 of the hashes, a 90-percent success rate using Brute force method. Brute-force attacks is when a computer tries every possible combination of characters.

In December it was unveiled by Jeremi Gosney, the founder and CEO of Stricture Consulting Group, that a 25-computer cluster can cracks passwords by making 350 billion guesses per second. It can try every possible word in less than six hours to get plain text passwords from lists of hashed passwords.

Using passwords that contained only numbers, 12 digits long, hackers managed to bruteforce such 312 passwords in 3 minutes.  Anyway password doesn't have to be a word at all. A whole phrase or sentence, a passphrase, offers more security. A correctly chosen passphrase is easy for you to remember but difficult for anyone else to guess.

Also the strongest password in the world isn't secure if you use it for every one of your secure sites. If one site is compromised and hackers are able to crack your password and you've reused it they could then gain access to your details on other websites.

The general public has no control over which hashing process websites use and therefore are at the mercy of an algorithm which they may know nothing about. If you are concerned about security, long passwords are the best defense.

Sim Card Cloning Hack affect 750 millions users around the world

SIM cards are among the most widely-deployed computing platforms with over 7 billion cards in active use. Cracking SIM cards has long been the Holy Grail of hackers because the tiny devices are located in phones and allow operators to identify and authenticate subscribers as they use networks.

A German cryptographer Karsten Nohl, the founder of Security Research Labs claims to have found encryption and software flaws that could affect millions of SIM cards, and allows hackers to remotely gain control of and also clone certain mobile SIM cards.

This is the first hack of its kind in a decade. Nohl will be presenting his findings at the Black Hat security conference this year. He and his team tested close to 1,000 SIM cards for vulnerabilities, exploited by simply sending a hidden SMS.

According to him, Hackers could use compromised SIMs to commit financial crimes or engage in espionage. Once a hacker copies a SIM, it can be used to make calls and send text messages impersonating the owner of the phone.

The exploit only works on SIMs that use an old encryption technology known as DES. DES is used in around three billion mobile SIMs worldwide, of which Nohl estimates 750 million are vulnerable to the attack. 

GSMA, which represents nearly 800 mobile operators, will notify telecommunications regulators and other government agencies in nearly 200 countries about the potential threat and also reach out to hundreds of mobile companies, academics and other industry experts.

Nohl believes that cyber criminals have already found the bug. Now the theoretical details of the vulnerability is out, he expects it would take them at least six months to crack it, by which time the wireless industry will have implemented available fixes.

DNS SPOOFING ATTACK

         DNS spoofing (or DNS cache poisoning) is a computer hacking attack, whereby data is introduced into a Domain Name System (DNS) name server's cache database, causing the name server to return an incorrect IP address, diverting traffic to another computer (often the attacker's).

                      Overview of the Domain Name System

       A domain name system server translates a human readable domain name (such as example.com) into a numerical IP address that is used to route communications between nodes. Normally if the server doesn't know a requested translation it will ask another server, and the process continues recursively. To increase performance, a server will typically remember (cache) these translations for a certain amount of time, so that, if it receives another request for the same translation, it can reply without having to ask the other server again.

When a DNS server has received a false translation and caches it for performance optimization, it is considered poisoned, and it supplies the false data to clients. If a DNS server is poisoned, it may return an incorrect IP address, diverting traffic to another computer (often an attacker's).

Cache poisoning attacks

Normally, a networked computer uses a DNS server provided by the computer user's organization or an Internet service provider (ISP). DNS servers are generally deployed in an organization's network to improve resolution response performance by caching previously obtained query results. Poisoning attacks on a single DNS server can affect the users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable.

To perform a cache poisoning attack, the attacker exploits a flaw in the DNS software. If the server does not correctly validate DNS responses to ensure that they are from an authoritative source (for example by using DNSSEC) the server will end up caching the incorrect entries locally and serve them to other users that make the same request.

This technique can be used to direct users of a website to another site of the attacker's choosing. For example, an attacker spoofs the IP address DNS entries for a target website on a given DNS server, replacing them with the IP address of a server he controls. He then creates files on the server he controls with names matching those on the target server. These files could contain malicious content, such as a computer worm or a computer virus. A user whose computer has referenced the poisoned DNS server would be tricked into accepting content coming from a non-authentic server and unknowingly download malicious content.

Variants

In the following variants, the entries for the server ns.target.example would be poisoned and redirected to the attacker's nameserver at IP address w.x.y.z. These attacks assume that the nameserver for target.example isns.target.example.

To accomplish the attacks, the attacker must force the target DNS server to make a request for a domain controlled by one of the attacker's nameservers.

Prevention and mitigation

Many cache poisoning attacks can be prevented on DNS servers by being less trusting of the information passed to them by other DNS servers, and ignoring any DNS records passed back which are not directly relevant to the query. For example, versions of BIND 9.5.0-P1 and above perform these checks.As stated above, source port randomization for DNS requests, combined with the use of cryptographically-secure random numbers for selecting both the source port and the 16-bit cryptographic nonce, can greatly reduce the probability of successful DNS race attacks.

However routers, firewalls, proxies, and other gateway devices that perform network address translation (NAT), or more specifically, port address translation (PAT), often rewrite source ports in order to track connection state. When modifying source ports, PAT devices typically remove source port randomness implemented by nameservers and stub resolvers.

Secure DNS (DNSSEC) uses cryptographic electronic signatures signed with a trusted public key certificate to determine the authenticity of data. DNSSEC can counter cache poisoning attacks, but as of 2008 was not yet widely deployed. In 2010 DNSSEC was implemented in the Internet root zone servers.Although, some security experts claim with DNSSEC itself, without application-level cryptography, the attacker still can provide fake data.

This kind of attack may also be mitigated at the transport layer or application layer by performing end-to-end validation once a connection is established. A common example of this is the use of Transport Layer Security and digital signatures. For example, by using HTTPS (the secure version of HTTP), users may check whether the server's digital certificate is valid and belongs to a website's expected owner. Similarly, the secure shell remote login program checks digital certificates at endpoints (if known) before proceeding with the session. For applications that download updates automatically, the application can embed a copy of the signing certificate locally and validate the signature stored in the software update against the embedded certificate.

Intelligent Anycast Cache Appliancees from Dell and TCPWave have watchdogs, which ensure that the DNS processes do not get a cache poison by predefining the roots in the watchdogs. Source port randomization via BIND backed up by a non-BIND DNS server software with intelligence blended into the BGP routing protocol mitigates the DNS Anycast cache poisoning attacks from malicious users.

GOOGLE MALAYSIA DEFACED BY PAKISTANI HACKERS

The Google Malaysia domains google.com.my and google.my have been defaced by hackers of the Pakistani Madleets group. This appears to be yet another case of DNS hijacking.

Over the past period, a lot of hacker groups have leveraged DNS poisoning to make it look like high-profile websites have been defaced. Team Madleets is a collective that has often used this technique.

The hackers have clarified on Facebook that the attack is not “the result of any kind of hate.”

“We don't hate anyone, We love all humanity, there is no obvious reason for stamping the tlds. Least the reason is not any kind of hate. Whatever the reason is we can't explain except we love all of you,” they stated.

It’s worth noting that this isn’t the first time when high-profile domains from Malaysia are defaced via DNS hijacking. A few months ago, Bangladeshi hacker Tiger-M@te defaced Microsoft, Dell, Skype, Kaspersky, MSN and Bing domains.

At the time, Malaysian domain registrar MYNIC admitted being breached.

Piercing Through WhatsApp’s Encryption

WhatsApp has been plagued by numerous issues in their security: easily stolen passwords, unencrypted messages and even a website that can change anyone’s status. But that streak is not yet over.

To be clear: this post is not about using IMEI numbers as your password. That issue has been fixed. Logging in 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 the not-really-XMPP server that WhatsApp uses. For this it uses the custom SASL mechanism WAUTH-1. To log in with the phone number XXXXXXXXXXXX, the following happens (I’m showing the XML representation of the protocol, this is not what is actually sent):

• The client sends:

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

  
  
• The server responds with a some challenge (here YYYYYYYYYYYYYYYYYYYY):

  <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">YYYYYYYYYYYYYYYYYYYY</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 XXXXXXXXXXXX || YYYYYYYYYYYYYYYYYYYY || UNIX timestamp:

  <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">ZZZZZZZZZZZZZ</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

Lets recall 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.
However, recall that:

(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.  :)