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

Adobe has just disclosed that one of their servers has been hacked

While their investigations are still ongoing, Adobe has shared a few details on what they believe could have been accessed and obtained in the hack — and it’s a big one.

From what Adobe has shared so far, it sounds like the hackers had access to encrypted data for as many as 2.9 million customers. While Adobe stresses that the data is encrypted and that they “do not believe the attackers removed decrypted credit or debit card numbers”, that data — encrypted or not — is definitely notsomething they want out in the wild.

Adobe has yet to disclose how that data was encrypted, so it’s currently unclear just how secure it is.

Meanwhile, it also appears that the hackers may have been able to access the source code for at least three of Adobe’s products: Acrobat, ColdFusion, and ColdFusion Builder. This goes hand in hand with a report from Brian Krebs this morning, who noted that he and a fellow researcher had discovered at least 40GB of Adobe source code available on a hacking group’s private server.

Beyond the obvious business implications of having your otherwise locked down source code floating around in the wild, there are potentially massive security concerns here. Once you’ve got the source code for an application in hand, it becomes much easier to dig up the stealthy lil’ security screw ups that might otherwise go unnoticed. Combine this new potential for big zero-day exploits with the many,many millions of Adobe Acrobat (Adobe’s official PDF reader) installs around the world, and this all starts to get pretty worrisome.

Exclusive : New Touch ID hack allows hacker to unlock an iPhone by multiple fingerprints

The Iranian group defeated the very basic phenomenon of an iPhone Fingerprinting scanner, which allows them to unlock an iPhone device with multiple Fingerprints.

                                           

Apple‘s iPhone 5s, was launched just available in stores two weeks before with a new feature of biometrics-based security system called "Touch ID", that involves analyzing a user’s fingerprint and using that to unlock the phone.

Apple launched the technology that it promises will better protect devices from criminals and snoopers seeking access. With this you can purchase things from the iTunes App Store. Basically, you can now use it in place of your password.

"Fingerprint is one of the best passcodes in the world. It's always with you, and no two are exactly alike," according to the Apple's website.

Last week Germany Hackers showed that how they were able to deceive Apple’s latest security feature into believing they’re someone they’re not, using a well-honed technique for creating a latex copy of someone's fingerprint. Another interesting fact is that, Touch ID is not only designed to scan the fingerprints of your fingers, it works with various human body parts and appendages which are also not fingers.

An Iranian group of iPhone Geeks from Tehran running a blog i.e. "i-Phone.ir" contacted 'The Hacker News' with another awesome Touch ID hack, shown that how they defeated the very basic phenomenon of Fingerprinting scanner i.e. "No two Fingerprints are exactly alike".

According to Apple, the chance that Touch ID will misread a finger is 1 in 50,000 , this is because Touch ID is not designed to capture the fingerprint in strict mode. It scans the fingerprint on a very high-resolution (2400 dpi), to get and match the partial parts of an impression for faster unlocking.

If the iPhone is not able to scan the thumb impression in the strict mode to be unique, there is a possibility that out of 1000 thumb impressions iPhone's Touch ID system can count 2-3 impressions as of the same person.

It could be a feature only if 5 different keys (fingers) are of the same person, but here we have 5 different people with the same key (finger), absolutely Touch ID is not a family key system that should work for Dad-Mom-sister and elder brother. it worked successfully for both and many times on latest IOS firmware 7.0.2 and iPhone users will not receive any patch soon for this.