Category Archives: Tools and Applications

Complexity and Storage Slow Attackers Down

Back in 2013, WhiteHat founder Jeremiah Grossman forgot an important password, and Jeremi Gosney of Stricture Consulting Group helped him crack it. Gosney knows password cracking, and he’s up for a challenge, but he knew it’d be futile trying to crack the leaked Ashley Madison passwords. Dean Pierce gave it a shot, and Ars Technica provides some context.

Ashley Madison made mistakes, but password storage wasn’t one of them. This is what came of Pierce’s efforts:

After five days, he was able to crack only 4,007 of the weakest passwords, which comes to just 0.0668 percent of the six million passwords in his pool.

It’s like Jeremiah said after his difficult experience:

Interestingly, in living out this nightmare, I learned A LOT I didn’t know about password cracking, storage, and complexity. I’ve come to appreciate why password storage is ever so much more important than password complexity. If you don’t know how your password is stored, then all you really can depend upon is complexity. This might be common knowledge to password and crypto pros, but for the average InfoSec or Web Security expert, I highly doubt it.

Imagine the average person that doesn’t even work in IT! Logging in to a website feels simpler than it is. It feels like, “The website checked my password, and now I’m logged in.”

Actually, “being logged in” means that the server gave your browser a secret number, AND your browser includes that number every time it makes a request, AND the server has a table of which number goes with which person, AND the server sends you the right stuff based on who you are. Usernames and passwords have to do with whether the server gives your browser the secret number in the first place.

It’s natural to assume that “checking your password” means that the server knows your password, and it compares it to what you typed in the login form. By now, everyone has heard that they’re supposed to have an impossible-to-remember password, but the reasons aren’t usually explained – people have their own problems besides the finer points of PBKDF2 vs. bcrypt).

If you’ve never had to think about it, it’s also natural to assume that hackers guessing your password are literally trying to log in as you. Even professional programmers can make that assumption, when password storage is outside their area of expertise. Our clients’ developers sometimes object to findings about password complexity or other brute force issues because they throttle login attempts, lock accounts after 3 incorrect guesses, etc. If that were true, hackers would be greatly limited by how long it takes to make each request over the network. Account lockouts are probably enough to discourage a person’s acquaintances, but they aren’t a protection against offline password cracking.

Password complexity requirements (include mixed case, include numbers, include symbols) are there to protect you once an organization has already been compromised (like Ashley Madison). In that scenario, password complexity is what you can do to help yourself. Proper password storage is what the organization can do. The key to that is in what exactly “checking your password” means.

When the server receives your login attempt, it runs your password through something called a hash function. When you set your password, the server ran your password through the hash function and stored the result, not your password. The server should only keep the password long enough to run it through the hash function. The difference between secure and insecure password storage is in the choice of hash function.

If your enemy is using brute force against you and trying every single thing, your best bet is to slow them down. That’s the thinking behind account lockouts and the design of functions like bcrypt. Running data through a hash function might be fast or slow, depending on the hash function. They have many applications. You can use them to confirm that large files haven’t been corrupted, and for that purpose it’s good for them to be fast. SHA256 would be a hash function suitable for that.

A common mistake is using a deliberately fast hash function, when a deliberately slow one is appropriate. Password storage is an unusual situation where we want the computation to be as slow and inefficient as practicable.

In the case of hackers who’ve compromised an account database, they have a table of usernames and strings like “$2a$10$N9qo8uLOickgx2ZMRZoMyeIjZAgcfl7p92ldGxad68LJZdL17lhWy”. Cracking the password means that they make a guess, run it through the hash function, and get the same string. If you use a complicated password, they have to try more passwords. That’s what you can do to slow them down. What organizations can do is to choose a hash function that makes each individual check very time-consuming. It’s cryptography, so big numbers are involved. The “only” thing protecting the passwords of Ashley Madison users is that trying a fraction of the possible passwords is too time-consuming to be practical.

Consumers have all the necessary information to read about password storage best practices and pressure companies to use those practices. At least one website is devoted to the cause. It’s interesting that computers are forcing ordinary people to think about these things, and not just spies.

Conspiracy Theory and the Internet of Things

I came across this article about smart devices on Alternet, which tells us that “we are far from a digital Orwellian nightmare.” We’re told that worrying about smart televisions, smart phones, and smart meters is for “conspiracy theorists.”

It’s a great case study in not having a security mindset.

This is what David Petraeus said about the Internet of Things at the In-Q-Tel CEO summit in 2012, while he was head of the CIA:

Items of interest will be located, identified, monitored, and remotely controlled through technologies such as radio-frequency identification, sensor networks, tiny embedded servers, and energy harvesters—all connected to the next-generation Internet using abundant, low cost, and high-power computing—the latter now going to cloud computing, in many areas greater and greater supercomputing, and, ultimately, heading to quantum computing.

In practice, these technologies could lead to rapid integration of data from closed societies and provide near-continuous, persistent monitoring of virtually anywhere we choose. “Transformational” is an overused word, but I do believe it properly applies to these technologies, particularly to their effect on clandestine tradecraft. Taken together, these developments change our notions of secrecy and create innumerable challenges—as well as opportunities.

In-Q-Tel is a venture capital firm that invests “with the sole purpose of delivering these cutting-edge technologies to IC [intelligence community] end users quickly and efficiently.” Quickly means 3 years, for their purposes.

It’s been more than 3 years since Petraeus made those remarks. “Is the CIA meeting its stated goals?” is a fair question. Evil space lizards are an absurd conspiracy theory, for comparison.

Smart Televisions

The concerns are confidently dismissed:

Digital Trends points out that smart televisions aren’t “always listening” as they are being portrayed in the media. In fact, such televisions are asleep most of the time, and are only awaken [sic] when they hear a pre-programmed phrase like “Hi, TV.” So, any conversation you may be having before waking the television is not captured or reported. In fact, when the television is listening, it informs the user it is in this mode by beeping and displaying a microphone icon. And when the television enters into listening mode, it doesn’t comprehend anything except a catalog of pre-programmed, executable commands.

Mistaken assumption: gadgets work as intended.

Here’s a Washington Post story from 2013:

The FBI has been able to covertly activate a computer’s camera — without triggering the light that lets users know it is recording — for several years, and has used that technique mainly in terrorism cases or the most serious criminal investigations, said Marcus Thomas, former assistant director of the FBI’s Operational Technology Division in Quantico, now on the advisory board of Subsentio, a firm that helps telecommunications carriers comply with federal wiretap statutes.

Logically speaking, how does the smart TV know it’s heard a pre-programmed phrase? The microphone must be on so that ambient sounds and the pre-programmed phrases can be compared. We already know the device can transmit data over the internet. The issue is whether or not data can be transmitted at the wrong time, to the wrong people. What if there was a simple bug that kept the microphone from shutting off, once it’s turned on? That would be analogous to insufficient session expiration in a web app, which is pretty common.

The author admits that voice data is being sent to servers advanced enough to detect regional dialects. A low-profile third party contractor has the ability to know whether someone with a different accent is in your living room:

With smart televisions, some information, like IP address and other stored data may be transmitted as well. According to Samsung, its speech recognition technology can also be used to better recognize regional dialects and accents and other things to enhance the user experience. To do all these things, smart television makers like Samsung must employ third-party applications and servers to help them decipher the information it takes in, but this information is encrypted during transmission and not retained or for sale, at least according to the company’s privacy policy.

Can we trust that the encryption is done correctly, and nobody’s stolen the keys? Can we trust that the third parties doing natural language processing haven’t been compromised?

Smart Phones

The Alternet piece has an anecdote of someone telling the author to “Never plug your phone in at a public place; they’ll steal all your information.” Someone can be technically unsophisticated but have the right intuitions. The man doesn’t understand that his phone broadcasts radio waves into the environment, so he has an inaccurate mental model of the threat. He knows that there is a threat.

Then this passage:

A few months back, a series of videos were posted to YouTube and Facebook claiming that the stickers affixed to cellphone batteries are transmitters used for data collection and spying. The initial video showed a man peeling a Near Field Communication transmitter off the wrapper on his Samsung Galaxy S4 battery. The person speaking on the video claims this “chip” allows personal information, such as photographs, text messages, videos and emails to be shared with nearby devices and “the company.” He recommended that the sticker be removed from the phone’s battery….

And that sticker isn’t some nefarious implant the phone manufacturer uses to spy on you; it’s nothing more than a coil antenna to facilitate NFC transmission. If you peel this sticker from your battery, it will compromise your smartphone and likely render it useless for apps that use NFC, like Apple Pay and Google Wallet.

As Ars Technica put it in 2012:

By exploiting multiple security weakness in the industry standard known as Near Field Communication, smartphone hacker Charlie Miller can take control of handsets made by Samsung and Nokia. The attack works by putting the phone a few centimeters away from a quarter-sized chip, or touching it to another NFC-enabled phone. Code on the attacker-controlled chip or handset is beamed to the target phone over the air, then opens malicious files or webpages that exploit known vulnerabilities in a document reader or browser, or in some cases in the operating system itself.

Here, the author didn’t imagine a scenario where a someone might get a malicious device within a few centimeters of his phone. “Can I borrow your phone?” “Place all items from your pockets in the tray before stepping through the security checkpoint.” “Scan this barcode for free stuff!”

Smart Meters

Finally, the Alternet piece has this to say about smart meters:

In recent years, privacy activists have targeted smart meters, saying they collect detailed data about energy consumption. These conspiracy theorists are known to flood public utility commission meetings, claiming that smart meters can do a lot of sneaky things like transmit the television shows they watch, the appliances they use, the music they listen to, the websites they visit and their electronic banking use. They believe smart meters are the ultimate spying tool, making the electrical grid and the utilities that run it the ultimate spies.

Again, people can have the right intuitions about things without being technical specialists. That doesn’t mean their concerns are absurd:

The SmartMeters feature digital displays, rather than the spinning-usage wheels seen on older electromagnetic models. They track how much energy is used and when, and transmit that data directly to PG&E. This eliminates the need for paid meter readers, since the utility can immediately access customers’ usage records remotely and, theoretically, find out whether they are consuming, say, exactly 2,000 watts for exactly 12 hours a day.

That’s a problem, because usage patterns like that are telltale signs of indoor marijuana grow operations, which will often run air or water filtration systems round the clock, but leave grow lights turned on for half the day to simulate the sun, according to the Silicon Valley Americans for Safe Access, a cannabis users’ advocacy group.

What’s to stop PG&E from sharing this sensitive information with law enforcement? SmartMeters “pose a direct privacy threat to patients who … grow their own medicine,” says Lauren Vasquez, Silicon Valley ASA’s interim director. “The power company may report suspected pot growers to police, or the police may demand that PG&E turn over customer records.”

Even if you’re not doing anything ambiguously legal, the first thing that you do when you get home is probably turning the lights on. Different appliances use different amounts of power. By reporting power consumption at higher intervals, smart meters can give away a lot about what’s going on in a house.


That’s not the same as what you were watching on TV, but the content of phone conversations isn’t all that’s interesting about them, either.

It’s hard to trust things.

Security Pictures

Security pictures are being used in a multitude of web applications to apply an extra step in securing the login process. However, are these security pictures being used properly? Could the use of security pictures actually aid hackers? Such questions passed through my mind when testing an application’s login process that relied on security pictures to provide an extra layer of security.

I was performing a business logic assessment for an insurance application that used security pictures as part of its login process, but something seemed off. The first step was to enter your username; if the username was found in the database then you would be presented with your security picture e.g. a dog, cat, iguana. If the username was not in the database then a message saying that you haven’t setup your security picture yet was displayed. Besides the clear potential for a brute force attack on usernames, there was another vulnerability hiding – you could view other users’ security pictures just by guessing the usernames in the first step.

Before I started to dwell into how should I classify the possible vulnerability in my assessment, I had to do some quick research in a couple of topics: what are security pictures used for? And, how do other applications use them effectively?

I always wondered what extra security the picture added. How could a picture of an iguana I chose protect me from danger at all? Or add an extra layer of security when I log in? Security pictures are mainly used to protect users from phishing attacks. For example, if an attacker tries to reproduce a banking login screen, a target user who is accustomed to see an iguana picture before entering his or her password would pause for a moment, then notice that something is not right since Iggy isn’t there anymore. The absence of a security picture produces that mental pause causing the user in most cases to not enter their password.

After finding about the true purpose of security pictures, I had to see how other applications use them in a less broken way. So I visited my bank’s website, entered my username, but instead of having my security picture displayed right away I was asked to answer my security question. Once the secret answer was entered my security picture would be displayed on top of the password input field. This approach to use a security picture was secure.

What seemed off in the beginning was the fact that because attackers can get users security pictures with a brute force attack, they can go a step further into phishing and use the security pictures of target users to create an even stronger phishing attack. This enhanced phishing attack would reassure the victim that they are in the right website because their security picture is there as usual.

Now that is clear that the finding was indeed a vulnerability, I had to think about how to classify it and what score to award. I classified it as Abuse of Functionality since WhiteHat Security defines Abuse of Functionality as:

“Abuse of Functionality is an attack technique that uses a web site’s own features and functionality to attack itself or others. Abuse of Functionality can be described as the abuse of an application’s intended functionality to perform an undesirable outcome. These attacks have varied results such as consuming resources, circumventing access controls, or leaking information. The potential and level of abuse will vary from web site to web site and application to application. Abuse of functionality attacks are often a combination of other attack types and/or utilize other attack vectors.”

In this case an attacker could use the application’s own authentication functionality to attack other users by combining the results of a brute force attack and the security pictures to create a powerful phishing attack. For the scores I have chosen to use Impact and Likelihood, which are given low, medium, and high values. Impact determines the potential damage a vulnerability inflicts and Likelihood estimates how likely it is for the vulnerability to be exploited. In terms of Likelihood, I would rate this a medium because it is very time consuming to setup a phishing attack and you will have to perform a brute force attack first to obtain valid usernames, then pick from the usernames the specific victims to attack; As for Impact, I would categorize this as high because once the phishing attack is sent the victim would most likely lose his or her credentials.

Security pictures can indeed help you add an extra layer of security to your application’s login process. However, put on your black hat for a moment and think how could a hacker use your own security against the application? As presented here, sometimes the medicine can be worse than the disease.

Why is Passive Mixed Content so serious?

One of the most important tools in web security is Transport Layer Security (TLS). It not only protects sensitive information during transit, but also verifies that the content has not been modified. The user can be confident that content delivered via HTTPS is exactly what the website sent. The user can exchange sensitive information with the website, secure in the knowledge that it won’t be altered or intercepted. However, this increase in security comes with an increased overhead cost. It is tempting to be concerned only about encryption and ignore the necessity to validate on both ends, but any resources that are called on a secure page should be similarly protected, not just the ones containing secret content.

Most web security professionals agree that active content — JavaScript, Flash, etc. — should only be sourced in via HTTPS. After all, an attacker can use a Man-in-the-Middle attack to replace non-secure content on the fly. This is clearly a security risk. Active content has access to the content of the Document Object Model (DOM), and the means to exfiltrate that data. Any attack that is possible with Cross-Site Scripting is also achievable using active mixed content.

The controversy begins when the discussion turns to passive content — images, videos, etc. It may be difficult to imagine how an attacker could inflict anything worse than mild annoyance by replacing such content. There are two attack scenarios which are commonly cited.

An unsophisticated attacker could, perhaps, damage the reputation of a company by including offensive or illegal content. However, the attack would only be effective while the attacker maintains a privileged position on the network. If the user moves to a different Wi-Fi network, the attacker is out of the loop. It would be easy to demonstrate to the press or law enforcement that the company is not responsible, so the impact would be negligible.
If a particular browser’s image parsing process is vulnerable, a highly sophisticated attacker can deliver a specially crafted, malformed file using a passive mixed content vulnerability. In this case, the delivery method is incidental, and the vulnerability lies with the client, rather than the server. This attack requires advanced intelligence about the specific target’s browser, and an un-patched or unreported vulnerability in that specific browser, so the threat is negligible.
However, there is an attack scenario that requires little technical sophistication, yet may result in a complete account takeover. First, assume the attacker has established a privileged position in the network by spoofing a public Wi-Fi access point. The attacker can now return any response to non-encrypted requests coming over the air. From this position, the attacker can return a 302 “Found” temporary redirect to a non-encrypted request for the passive content on the target site. The location header for this request is a resource under their control, configured to respond with a 401 “Unauthorized” response containing a WWW-Authenticate header with a value of Basic realm=”Please confirm your credentials.” The user’s browser will halt loading the page and display an authentication prompt. Some percentage of users will inevitably enter their credentials, which will be submitted directly to the attacker. Even worse, this attack can be automated and generalized to such a degree that an attacker could use commodity hardware to set up a fake Wi-Fi hotspot in a public place and harvest passwords from any number of sites.

Protecting against this attack is relatively simple. For users, be very suspicious of any unexpected login prompts, especially if it doesn’t look like part of the website. For developers, source in all resources using HTTPS on every secure page.

#HackerKast 40: OPM Breach, Sourcepoint, AdBlock Plus, NSA and AV software, Adobe Flash, Chrome Listens In via Computer Mic

Hey Everybody! Welcome to our 40th HackerKast! Thanks for listening as always and lets get to the news!

Our first story to chat about this week was news bubbling up still about the recent OPM breach. This time, the news outlets are latching on to the fact that data encryption wouldn’t have helped them in this case. Jeremiah poses the question “Is this true? And if so, when does it protect you?” Robert and I go back and forth a bit about layers of protection and how encryption in this regard will only help with host layer issues. Some other ideas come up about data restrictions being put upon the database queries as they are taking place so that the crown jewels can’t be stolen via one simple hole.

Next, we moved on to a story Robert was drooling over about Google’s new pet project company, Sourcepoint, which exists to stop ad blocking. Apparently they originally launched to detect when ads are being modified, which was apparently an issue in the SEO world. However, the way the tech worked, monitoring the DOM allowed them to pivot a bit to detect ad blocking by users. This could be leveraged to stop the user from blocking, or could alert the user and ask really nicely for them not to block ads which could be harming some sites’ revenue. We then all made the comparison here that the modern age of ads looks a lot like the age of Anti-Virus with the whole cat and mouse game of writing signatures to catch which domains are serving ads.

On the topic of ad blockers, AdBlock Plus added a feature which would allow enterprise level IT admins to roll out the browser plugin to an entire company. We need to remind people that AdBlock Plus also is the ad blocker on the market that will allow ads that pay them to be whitelisted. This means the more computers their software is on, the more they can ask to be whitelisted.

Jer couldn’t wait to talk about this next story about the NSA reverse engineering AV software. He starts by giving us all a quick history lesson of his interest in AV being the ironic attack vector for hackers to get into systems. The current story is about a recently leaked Snowden document that outlined an NSA program which reversed AV software — including Kaspersky — to utilize it to track and monitor users. Not a good week for Kaspersky coming off the heels of Duqu 2.0 recently.

Our transition from one virus propagator to another here brings us to our next story: Adobe Flash. The initial story that made our list was Brian Krebs talking about detoxing from Flash for 30 days with it completely removed from his system. He gives some good advice about disabling flash, removing it altogether, or enabling click to play. While editing this story though, he had to add a note at the top which proved his point that the day it was published there was an out-of-band Zero-Day patch Adobe released this week. The Zero-Day was identified by some ridiculously named FireEye report of an attack being used in Singapore from a Chinese hacking group they call APT3. We have a good conversation about Flash and what a huge target it’s been and what a nightmare it is to get users to update.

The icing on our cake to go back to ragging on Google is a story that hit the privacy community this week of Chrome listening to you via your computer microphone. For some reason, the initial group they decided to test this with was Chromium users on Debian who noticed the silent update start to log this audio information. Apparently there is some legitimate purpose behind this, like saying “Hi Google” to your computer and giving it voice commands. They then send this audio to their servers to do analysis to improve their service. They double, triple, super duper promise they aren’t logging it or sharing the audio. We went off on a tangent here on how awful of an idea this is. I brought up how we’ve got a nice diagram from the NSA showing how they strip HTTPS at the Google layer to monitor users so it really doesn’t matter if they log or store it if the NSA can just snoop on the wire there. Who knows where this is going to go, but now you might have an always on microphone in your house.

Thanks for listening! Check us out on iTunes if you want an audio only version to your phone. Subscribe Here
Join the conversation over on Twitter at #HackerKast
or write us directly @jeremiahg, @rsnake, @mattjay


Encryption Would Not Have Helped at OPM Says DHS Official
Former Google Exec Launches Sourcepoint To Stop Ad Blockers
Adblock Plus Rolls Out Mass Deployment For IT Administrators
NSA Has Reverse-Engineered Popular Consumer Anti-Virus Software In Order To Track Users
Operation Clandestine Wolf: Adobe Flash Zero-Day
Krebs month without Adobe Flash Player
Google Chrome Listening In To Your Room Shows The Importance of Privacy Defense In Depth
Just another source on the Chrome listening to you

Notable stories this week that didn’t make the cut:

Heinz QR porn code too saucy for ketchup customer/
Critical Bug Found in Drupal OpenId
The Myth of the Dark Web
How DOJ Gagged Google over Surveillance of Wikileak’s Appelbaum
1,400 Passengers Grounded in Warsaw Due to Airport Hack
DuckDuckGo on CNBC: We’ve grown 600% since NSA surveillance news broke

Magic Hashes

For more than the last decade, PHP programmers have been wrestling with the equals-equals (==) operator. It’s caused a lot of issues. This has a particular implication for password hashes. Password hashes in PHP are base16 encoded and can come in the form of “0e812389…”. The problem is in == comparison the 0e means that if the following characters are all digits the whole string gets treated as a float. This was pointed out five years ago by Gregor Kopf, two years ago by Tyler Borland and Raz0r and again a year ago by Michal Spacek and Jos Wetzels but this technique is making more waves this past week.

Below is a list of hash types that when hashed are ^0+e\d*$ which equates to zero in PHP when magic typing using the “==” operator is applied. That means that when a password hash starts with “0e…” as an example it will always appear to match the below strings, regardless of what they actually are if all of the subsequent characters are digits from “0-9″. The implication is that these magic numbers when hashed are treated as the number “0” and compared against other hashes, the comparison will evaluate to true. Think of “0e…” as being the scientific notation for “0 to the power of some value” and that is always “0”. PHP interprets the string as an Integer.

if (hash('md5','240610708',false) == '0') {
  print "Matched.\n";
if ('0e462097431906509019562988736854' == '0') {
  print "Matched.\n";

What this practically means is that the following “magic” strings are substantially more likely to evaluate to true when hashed given a completely random hash (E.g. a randomly assigned password, nonce, file hash or credential). Likewise if a straight guess of a hash is required the associated hashes are proven to be typed into the float “0” with the “==” comparison operator in PHP, and if another hash in a database also starts with a “0e…” the comparison will evaluate to true. Therefore, the hashes can also be substantially more likely to evaluate to true when compared with a database of hashes, even if they don’t actually match. Many cookies, as an example are simply hashes, and finding a collision becomes much more likely depending on how many valid credentials are in use at the time of test (See: Birthday paradox).

Use Case 1: Use the “Magic” Number below as a password or as a string that you expect to be hashed. When it is compared against the hash of the actual value, and if they both are treated as “0” and therefore evaluated as true, you will be able to log into the account without the valid password. This could be forced to happen in environments where automatic passwords are chosen for users during a forgot password flow and then attempting to log in immediately afterwards, as an example.

Use Case 2: The attacker can simply take the example in the Hash column in the table below and use it as a value. In some cases these values are simply done as a look-up against known values (in memory, or perhaps dumped from a database and compared). By simply submitting the hash value, the magic hash may collide with other hashes which both are treated as “0” and therefore compare to be true. This could be caused to happen

Hash Type

Hash Length

“Magic” Number / String

Magic Hash

Found By
md2 32 505144726 0e015339760548602306096794382326 WhiteHat Security, Inc.
md4 32 48291204 0e266546927425668450445617970135 WhiteHat Security, Inc.
md5 32 240610708 0e462097431906509019562988736854 Michal Spacek
sha1 40 10932435112 0e07766915004133176347055865026311692244 Independently found by Michael A. Cleverly & Michele Spagnuolo & Rogdham
sha224 56
sha256 64
sha384 96
sha512 128
ripemd128 32 315655854 0e251331818775808475952406672980 WhiteHat Security, Inc.
ripemd160 40 20583002034 00e1839085851394356611454660337505469745 Michael A Cleverly
ripemd256 64
ripemd320 80
whirlpool 128
tiger128,3 32 265022640 0e908730200858058999593322639865 WhiteHat Security, Inc.
tiger160,3 40 13181623570 00e4706040169225543861400227305532507173 Michele Spagnuolo
tiger192,3 48
tiger128,4 32 479763000 00e05651056780370631793326323796 WhiteHat Security, Inc.
tiger160,4 40 62241955574 0e69173478833895223726165786906905141502 Michele Spagnuolo
tiger192,4 48
snefru 64
snefru256 64
gost 64
adler32 8 FR 00e00099 WhiteHat Security, Inc.
crc32 8 2332 0e684322 WhiteHat Security, Inc.
crc32b 8 6586 0e817678 WhiteHat Security, Inc.
fnv132 8 2186 0e591528 WhiteHat Security, Inc.
fnv164 16 8338000 0e73845709713699 WhiteHat Security, Inc.
joaat 8 8409 0e074025 WhiteHat Security, Inc.
haval128,3 32 809793630 00e38549671092424173928143648452 WhiteHat Security, Inc.
haval160,3 40 18159983163 0e01697014920826425936632356870426876167 Independently found by Michael Cleverly & Michele Spagnuolo
haval192,3 48 48892056947 0e4868841162506296635201967091461310754872302741 Michael A. Cleverly
haval224,3 56
haval256,3 64
haval128,4 32 71437579 0e316321729023182394301371028665 WhiteHat Security, Inc.
haval160,4 40 12368878794 0e34042599806027333661050958199580964722 Michele Spagnuolo
haval192,4 48
haval224,4 56
haval256,4 64
haval128,5 32 115528287 0e495317064156922585933029613272 WhiteHat Security, Inc.
haval160,5 40 33902688231 00e2521569708250889666329543741175098562 Michele Spagnuolo
haval192,5 48 52888640556 0e9108479697641294204710754930487725109982883677 Michele Spagnuolo
haval224,5 56
haval256,5 64

To find the above, I iterated over a billion hashed integers of each hash type to attempt to find an evaluation that results in true when compared against “0”. If I couldn’t find a match within the billion attempts I moved on to the next hashing algorithm. This technique was inefficient but it was reasonably effective at finding a “Magic” Number/String associated with most hash algorithms with a length of 32 hex characters or less on a single core. The one exception was “adler32″ which is used in zlib compression as an example and required a slightly different tactic. The moral of the story here is for the most part the more bits of entropy in a hash the better defense you will have. Here is the code used I used (adler32 required a lot of special treatment to find a valid hash that didn’t contain special characters):

function hex_decode($string) {
  for ($i=0; $i < strlen($string); $i)  {
    $decoded .= chr(hexdec(substr($string,$i,2)));
    $i = (float)($i)+2;
  return $decoded;
foreach (hash_algos() as $v) {
  $a = 0;
  print "Trying $v\n";
  while (true) {
    if ($a > 1000000000) {
    if ($v === 'adler32') {
      $b = hex_decode($a);
    } else {
      $b = $a;
    $r = hash($v, $b, false);
    if ($r == '0') {
      if(preg_match('/^[\x21-\x7e]*$/', $b)) {
        printf("%-12s %s %s\n", $v, $b, $r);

I didn’t have to just use integers as found in most of the results but it was slightly easier to code. Also, in hindsight it’s also slightly more robust because sometimes people force the passwords to upper or lowercase, and numbers are uneffected by this, so using integers is slightly safer. However, in a practical attack, an attacker might have to find a password that conforms to password requirements (at least one upper case, one lower case, one number and one special character) and also is evaluated into zero when hashed. For example, after 147 million brute force attempts, I found that “Password147186970!” converts to “0e153958235710973524115407854157″ in md5 which would meet that stringent password requirement and still evaluate to zero.

To round this out, we’ve found in testing that a 32 character hash has collisions with this issue in about 1/200,000,000 of random hash tests. That’s thankfully not that often, but it’s often enough that it might be worth trying on a high volume website or one that generates lots of valid credentials. Practically this is rather difficult to do, thankfully, without sending a massive amount of attempts in the most likely instances. Note: there are similar issues with “0x” (hex) and “0o” (octal) as well but those characters do not appear in hashes, so probably less interesting in most cases. It’s also worth mentioning that “==” and “!=” both suffer from the same issue.

Are websites really vulnerable to this attack? Yes, yes, they are. This will surely cause issues across many many different types of code repositories like this and this and this and this to name just a few. Similar confusion could be found in Perl with “==” and “eq”, as well as loosely cast languages like JavaScript as well. (Thanks to Jeremi M Gosney for help thinking this through.) I wouldn’t be surprised to see a lot of CVEs related to this.

Patch: Thankfully the patch is very simple. If you write PHP you’ve probably heard people mention that you should be using triple equals “===”. This is why. All you need to do is change “==” to “===” and “!=” to “!==” respectively to prevent PHP from attempting to guess the variable type (float vs string). Some people have also recommended using the “hash_equals” function.

WhiteHat will now be testing this with both our dynamic scanner and static code analysis for WhiteHat customers. If you want a free check please go here. This is rather easily found using static code analysis looking for comparisons of hashes in PHP. Lastly, if you have some computing horsepower and have any interest in this attack, please consider contributing to any value/hash pairs that we haven’t found samples for yet or for hash algorithms we haven’t yet listed.

#HackerKast 31: RSA San Francisco

We have a special and rare treat this week on HackerKast: Jeremiah, Matt and Robert all together in San Francisco for RSAC. They give a brief overview of some of the interesting conversations and topics they’ve come across.

A recurring topic in conversations with Robert is about how DevOps can improve security and help find vulnerabilities faster. Matt mentions Gauntlt, a cool new project that he contributes to. Gauntlt is a tool that puts security tools into your build-pipeline to test for vulnerabilities before the code goes to production.

Matt also mentions that his buddies at Verizon came out with data showing that people aren’t getting hacked by mobile apps. We haven’t seen large data breaches via mobile apps lead to any financial loss. With the recent surge in mobile use for sensitive data, are these types of data breaches something we should worry about?

On a more pleasant note, Jer was happy to hear that people and companies are realizing the importance of security. Industry leaders are now showing interest in doing application security the right way through a holistic approach.

Also at RSA, Jer talks security guarantees while Matt/Kuskos dive into our Top 10 Web Hacks.

dnstest – Monitor Your DNS for Hijacking

In light of the latest round of attacks against and/or hijacking of DNS, it occurred to me that most people really don’t know what to do about it. More importantly, many companies don’t even notice they’ve been attacked until a customer complains. Especially for smaller companies who may not have as many customers, or only accept comments through a website, they may never know unless they randomly check, or the attacker releases the site and the flood of complaints comes rolling in after the fact.

So I wrote a little tool called “” (yes a Perl script) that can be run out of cron and can monitor one or more hostname-to-IP-address pairs of sites that are critical to you. If anything happens it’ll send you an alert via email. There are other tools that do this or similar things, but it’s another tool in your arsenal; and most importantly dnstest is meant to be very lightweight and simple to use. You can download dnstest here.

Of course this is only the first step. Reacting quickly to the alert simply reduces the outage and the chance of customer complaints or similar damage. If you like it but want it to do something else, go ahead and fork it. Enjoy!

Aviator Going Open Source

One of the most frequent criticisms we’ve heard at WhiteHat Security about Aviator is that it’s not open source. There were a great many reasons why we didn’t start off that way, not the least of which was getting the legal framework in place to allow it, but we also didn’t want our efforts to be distracted by external pressures while we were still slaving away to make the product work at all.

But now that we’ve been running for a little more than a year, we’re ready to turn over the reins to the public. We’re open sourcing Aviator to allow experts to audit the code and also to let industrious developers contribute to it. Yes, we are actually open sourcing the code completely, not just from a visibility perspective.

Why do this? I suspect many people just want to be able to look at the code, and don’t have a need to – or lack the skills to – contribute to it. But we also received some really compelling questions from the people who have an active interest in the Tor community who expressed an interest in using something based on Chromium, and who also know what a huge pain it is to make something work seamlessly. For them, it would be a lot easier to start with a more secure browser that had removed a lot of the Google specific anti-privacy stuff, than to re-invent the wheel. So why not Aviator? Well, after much work with our legal team the limits of licensing are no longer an issue, so now that is now a real possibility. Aviator is now BSD (free as in beer) licensed!

So we hope that people use the browser and make it their own. We won’t be making any additional changes to the browser; Aviator is now entirely community-driven. We’ll still sign the releases, QA them and push them to production, but the code itself will be community-driven. If the community likes Aviator, it will thrive, and now that we have a critical mass of technical users and people who love it, it should be possible for it to survive on its own without much input from WhiteHat.

As an aside, many commercial organizations discontinue support of their products, but they regularly fail to take the step of open sourcing their products. This is how Windows XP dies a slow death in so many enterprises, unpatched, unsupported and dangerously vulnerable. This is how MMORPG video games die or become completely unplayable once the servers are dismantled. We also see SAAS companies discontinue services and allow only a few weeks or months for mass migrations without any easy alternatives in sight. I understand the financial motives behind planned obsolescence, but it’s bad for the ecosystem and bad for the users. This is something the EFF is working to resolve and something I personally feel that all commercial enterprises should do for their users.

If you have any questions or concerns about Aviator, we’d love to hear from you. Hopefully this is the browser “dream come true” that so many people have been asking for, for so long. Thank you all for supporting the project and we hope you have fun with the code. Aviator’s source code can be found here on Github. You don’t need anything to check it out. If you want to commit to it, shoot me an email with your github account name and we’ll hook you up. Go forth! Aviator is yours!

Security Guaranteed: Customers Deserve Nothing Less

WhiteHat Security Sentinel Elite

Ever notice how everything in the information security industry is sold “as is”? No guarantees, no warrantees, no return policies. This provides little peace of mind that any of the billions that are spent every year on security products and services will deliver as advertised. In other words, there is no way of ensuring that what customers purchase truly protects them from getting hacked, breached, or defrauded. And when these security products fail – and I do mean when – customers are left to deal with the mess on their own, letting the vendors completely off the hook. This does not seem fair to me, so I can only imagine how a customer might feel in such a case. What’s worse, any time someone mentions the idea of a security guaranty or warranty, the standard retort is “perfect security is impossible,” “we provide defense-in-depth,” or some other dismissive and ultimately unaccountable response.

Still, the naysayers have a valid point. Given enough time and energy, everything can be hacked, including security products, but this admission does not inspire much confidence in those who buy our warez and whose only fear is getting hacked. We, as an industry, are not doing anything to alleviate that fear. With something as important as information security is today, personally I think customers deserve more assurance. I believe customers should demand accountability from their vendors in particular. I believe the “as is” culture in security is something the industry must move away from. Why? Because if it were incumbent upon vendors to stand by their product(s) we would start to see more push against the status quo and, perhaps, even renewed innovation.

At the core of the issue is bridging the gap between the “nothing-is-perfect” mindset and the business requirements for providing security guarantees.

If you think about it, many other industries already offer guarantees, warrantees, or 100% return policies for less than perfect products. Examples include electronics, clothing, cars, lawn care equipment, and basically anything you buy on Amazon. As we know, all these items have defect rates, yet it doesn’t appear to prevent those sellers from standing behind their products. Perhaps the difference is, unlike most security vendors, these merchants know their product failure rates and replacement costs. This business insight is precisely why they’re willing to reimburse their customers accordingly. Security vendors by contrast tend NOT to know their failure rates, and if they do, they’re likely horrible (anti-virus is a perfect example of this). As such, vendors are unwilling to put their money where their mouth is, the “as is” culture remains, and interests between security vendor and customer are misaligned.

The key then, is knowing the security performance metrics and failure rates (i.e. having enough data on how the bad guys broke in and why the security controls failed) of the products. With this information in hand, offering a security guarantee is not only possible, but essential!

WhiteHat Security is in a unique position to lead the charge away from selling “as is” and towards security guarantees. We can do this, because we have the data and metrics to prove our performance. Other Software-as-a-Service vendors could theoretically do the same, and we encourage them to consider doing so.

For example, at WhiteHat we help our customers protect their websites from getting hacked by identifying vulnerabilities and helping to get them fixed before they’re exploited. If the bad guys are then unable to find and exploit a vulnerability we missed, or if they decide to move on to easier targets, that’s success! Failure, on the other hand, is missing a vulnerability we should have found which results in the website getting hacked. This metric – the product failure rate – is something any self-respecting vulnerability assessment vendor should track very closely. We do, and here’s how we bring it all together:

  1. WhiteHat’s Sentinel scanning platform and the 100+ person army of Web security experts behind it in our Threat Research Center (TRC) tests tens of thousands of websites on a 24x7x365 basis. We’ve been doing this for more than a decade and we have a larger and more accurate website vulnerability data set than anyone else. We know with a fine degree of accuracy what vulnerabilities we are able to identify – and which ones we are not.
  2. We also have data sharing relationships with Verizon (and others) on the incident side of the equation. This is to say we have good visibility into what attack techniques the bad guys are trying and what they’re likely to successfully exploit. This insight helps us focus R&D resources towards the vulnerabilities that matter most.
  3. We also have great working relationships with our customers so that when something unfortunate does occur – which can be anything from something as simple as a ‘missed’ vulnerability, to a site that was no longer being scanned by our solution that contained a vulnerability, all the way to a real breach – we’re in the loop. This is how we can determine whether something we missed and should have found actually results in a breach.

Bottom line: in the past 10+ years of performing countless assessments and identifying millions of vulnerabilities, there have been only a small number of instances in which we missed a vulnerability that we should have found that we know was likely used to cause material harm to our customers. All told, our failure rate is far less than even one percent (<.01%), which is an impressive track record and one that we are quite proud of. I am not familiar with any other software scanning vendor who even claims to know what their failure rate metric is, let alone has the confidence to publicly talk about it. And it is for this reason that we can confidently stand behind our own security guarantee for customers with the new Sentinel Elite.

Introducing: Sentinel Elite

Sentinel Elite is a brand new service line from WhiteHat in which we deploy our best and most comprehensive website vulnerability assessment processes. Sentinel Elite builds on the proven security of WhiteHat Sentinel, which offers the lowest false-positive rate of any web application security solution available as well as more than 10 years of website vulnerability assessment experience. This service, combined with a one-of-a-kind security guarantee from WhiteHat gives customers the confidence in both their purchase decisions as well as the integrity of their websites and data.

Sentinel Elite customers will have access to a dedicated subject matter expert (SME) who expedites communication and response times, as well as coordinates the internal and external activities supporting your applications security program. The SME will also supply prioritized guidance support, so customers know which vulnerabilities to fix first… or not! Customers also receive access to the WhiteHat Limited Platinum Support program, which includes a one-hour SLA, quarterly summaries and exploit reviews, as well as a direct line to our TRC. Sentinel Elite customers must in turn provide us with what we need to do our work, such as giving us valid website credentials and taking action to remediate identified vulnerabilities. Provided everyone does what they are responsible for, our customers can rest assured that their website and critical applications will not be breached. And we are prepared to stand behind that claim.

If it happens that a website covered by Sentinel Elite gets hacked, specifically using a vulnerability we missed and should have found, the customer will be refunded in full. It’s that simple.

We know there will be those in the community who will be skeptical. That’s the nature of our industry and we understand the skepticism. In the past, other security vendors have offered half-hearted or gimmicky guarantees, but that’s not what we’re doing here. We’re serious about web security, we always have been. We envision an industry where outcomes and results matter, a future where all security products come with security guarantees, and most importantly, a future where the vendors’ best interests are in line with their customers’ best interests. How amazing would that be not only for customers but also for the Internet and the world we live, work and do business in? Sentinel Elite is the first of many steps we are taking to make this a reality.

For more information about Sentinel Elite, please click here.