#HackerKast 39: MLB Astros Hacked By Cardinals, Duqu 2.0, More Ad Blocking News and RIP Microsoft Ask Toolbar

Hey everybody and welcome to another week in Internet Security. Robert and I were trying our best to stay above water with Tropical Storm Bill hitting Southern Texas while Jeremiah was making us jealous with his palm trees and blue skies in Hawaii. I’ll remember that one Jer…

Back on topic, our first story was some shameless self promotion of Jeremiah talking about eSecurityPlanet doing a story on the Top 20 Influencers in the security industry. He happened to make the list himself but there are a lot of other notable names on there with links to lots of good research going on. Notably for me was our friend Dan Goodin who is a journalist that we link to a lot in HackerKast and is the first to cover many security news stories. Kudos to all.

Next, some news broke right before we started recording that was super interesting about some MLB teams getting into the hacking space. Turns out a former employee of the Houston Astros who left and now works for the St. Louis Cardinals never had his access turned off and was leveraging his old credentials. The Astros have some high-end scouting data that was put together with some cutting edge “Moneyball” style metrics that the Cardinals wanted their hands on. The FBI has been brought in to investigate this, how far this incident went and to prosecute those at fault.

We moved on from the baseball hack and into a security company admitting getting hacked with Kaspersky coming out and talking about Duqu 2.0. Robert touched on this and what made it interesting was that Duqu is almost certainly developed by a nation state due to some evidence reported on about it. The other major interesting tidbit about this is Duqu at some point, stole a valid Foxconn SSL certificate which allowed the malware to bypass a lot of first lines of defense. By using a valid cert, Duqu wouldn’t trip many of the alarms that normal malware would have upon entering a network. Robert also mentioned that in light of this, Foxconn should probably be doing some forensics and incident response into figuring out how their certificate was stolen.

Couldn’t make it out of another HackerKast without talking about one of our favorite topics, ad blocking. There was an article this week in Wired which discusses the differences in ad blocking on desktop platforms and mobile devices. Since browser extensions have become so prevalent and are cutting into the wallets of certain advertisers, *cough*Google*cough, there is a movement towards pushing users to use specific apps for content that they’d like to digest. Robert’s discusses an example with CNN where it would push users to use the CNN mobile app where they control the content fully and there would be no such thing as ad blocking.

Staying on the ad topic, Microsoft put out a research paper about serving web ads locally from your own computer. Think of this as a super cache which would have some implications on bandwidth, load time, ad blocking, and some malware related consequences. The major motivation here is almost certainly avoiding ad blocking since the ads are not loading dynamically from the web. Jer made the joke of hoping that chmod 000 being a thing for that folder.

Lastly we finish off with a Dan Goodin story with a witty title of “Ding Dong, the witch is dead” referring to Microsoft finally bringing the hammer down on the Ask toolbar. Microsoft’s malware team and suite of software including Microsoft Security Essentials will now flag the Ask Toolbar, most notably bundled with Oracle products by default such as Java, as unwanted software. The criteria of this flagging is software that includes “unwanted behavior, delivery of unwanted advertising, and a loss of user’s privacy”. The other speculation we made was that this would save Microsoft millions of dollars in customer service calls of how to remove it from Internet Explorer from unsavvy users who accidentally installed it. We all smell lawsuits on the horizon and will be an interesting one to watch.

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


20 Top Security Influencers
Cardinals Face F.B.I. Inquiry in Hacking of Astros’ Network
The Duqu 2.0 hackers used a Legitimate digital certificate from Foxconn in the Kaspersky attack.
Apple’s Support for Ad Blocking will Upend How the Web Works
A Microsoft Research paper considers serving web-ads from your own computer
Ding dong, the witch is dead: Microsoft AV gets tough on Ask Toolbar

Notable stories this week that didn’t make the cut:
FBI seizes Computers Involved in Massive Celeb Nude Leak
Report: Hack of government employee records discovered by product demo
Catching Up on the OPM Breach
Bing to Start Encrypting Search Traffic
LastPass Hacked – Email Addresses and Password Reminders and More Compromised
Stealing Money from the Internet’s ATMs or Paying for a Bottle of Macallan
Using the Redis Vulnerability to Patch Itself

#HackerKast 38: Pulse tests .gov sites, China hacked US government, DuckDuckGo, NSA Quantum Insert attacks and Google finds Ad Blocking annoying

Hey All! Welcome to another HackerKast! I’m back whether you like it or not.

Gave a quick rundown of my Europe trip before jumping into the news and we started with one of my favorite stories we’ve covered in a while. This one was about a project called Pulse which grabbed every .gov site it could get its hands on and ran an SSL Labs tester on it (hat tip to the awesome Ivan Ristic). Pulse then takes all the results and puts them in a very nice sortable table that, with one click, reveals pages and pages of government agencies with “F” grade scores. An “F” basically means they are vulnerable in at least 1 way to a major SSL flaw like POODLE or Heartbleed. Jeremiah tied this in to another story of an order in the government that mandates all websites are to be compliant with up to date SSL/TLS standards in the next year and a half or risk being taken offline.

Next, the story we couldn’t avoid, it is being reported that hackers from China stole over 4 million records from our government’s personnel office network. These records detail tons of information about current and past government employees. Some of the scariest pieces of info stolen are the results of secret clearance data which dives deep into the personal lives of people applying for secret or above clearances. Speculations have been made theorizing that this could be used to blackmail and flip people into working for foreign entities.

After getting off on a tangent about all that, Robert talked about the next story of some new DuckDuckGo features. Seems they are adding a whole suite of crypto related search features that are pretty neat, including generating strong passwords, identifying hashing algorithms, hashing things for you, and last but not least, searching for known plaintext of hashes. If you have some hashed passwords from a dump that you got your hands on, you can type the hash into DuckDuckGo and ask it to search known previously cracked hashes to see if its on the list. Who needs your own rainbow table anyway?

Screen Shot 2015-06-11 at 12.04.49 PM

Robert continues with a serious deep dive into a story about detecting the NSA’s complex Quantum Insert attacks. This topic has whole blog posts dedicated to itself if you’re interested in what it is and how the NSA is using it. It could be easy enough to create a piece of code to sit on your computer and look for anomalies in your packets consistent with this type of Insert attack to detect if you’re being MiTM’ed in this way.

The last complete tangent we went off on was about Ad Blocking which is a subject near and dear to our hearts. The story in question was detailing how popular Ad Blocking software is getting and how Google is feeling about this. A notable quote from Google’s CEO about this basically states that Ad Blocking is used to block “annoying” ads so in order to make it less popular is to make less annoying ads. We all got a laugh about how “annoying” malware, user tracking, loss of privacy, bandwidth usage, power consumption, etc. all are.

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

SSLLabs per .gov site
Chinese hackers breach federal government’s personnel office
DuckDuckGo Crypto Hacks
How to detect NSAs Complex Quantum Insert Attacks
Google’s Larry Page was asked whether he was worried about the rise of ad blockers — here’s what he said
Adblocking And The End Of Big Advertising

Notable stories this week that didn’t make the cut:
Apple’s Tim Cook Delivers Blistering Speech On Encryption, Privacy
Good luck USA, China and Russia Promise Not To Hack Each-Other
SourceForge Has Now Seized Nmap Project Account
Hijacking Whatsapp Accounts
SEA Hacks army.mil
U.S. Army public website compromised
Sony Hack Movie in the Works from Oscar-Nominated Team (Exclusive)
Twitter Shuts Down Political Transparency Tool Politwoops
FBI official: Companies should help us ‘prevent encryption above all else’

The Well-Rounded Engineer

I am not a security industry luminary. In fact, prior to WhiteHat I had never worked in security. The closest I came was a consulting project using Perl::Critic for Security Audits in 2012. It was static analysis trying to uncover XSS and SQLi vulnerabilities in large, legacy Perl applications — toy compared to what Eric Sheridan and his team do here at WhiteHat.

I was recruited by WhiteHat in 2012 for my front-end development experience. At that point I considered myself an expert at web development. What I learned here is how much I still have to learn! My first Hacker Kombat was enlightening. Here I am, having built web applications professionally for fifteen years, and in a competition designed to break into web applications I have no skills.

Working at WhiteHat, in the security industry, fundamentally changed my approach to building software. Security is now a front-of-mind aspect of designing software for me. Like many difficult disciplines I had a shallow understanding. I knew a little about threat modeling, vulnerabilities, and attack vectors. I didn’t realize how deep and complex software security was until I was in the middle of it (and I should be completely honest, there is still so much I don’t know). This experience has made me a better engineer, a more well-rounded engineer.

Seek more experiences

Every engineer should have the opportunity to dive deep into security. Keeping an application secure, and its data safe, is a complicated mix of preparation and probability. True appreciation for its difficulty is best accrued through experience. Reading about it isn’t enough. Studying won’t provide the same benefit as lived experience.

LinkedIn founder Reid Hoffman writes about the tour of duty framework for collecting experiences. In his model, if motivated employees “signed up for a 2–4 year tour of duty and made an important contribution to some part of the business, Reid and the company would help advance their careers, preferably in the form of another tour of duty at LinkedIn.” I strongly recommend engineers follow this approach to their career. In the case of LinkedIn it worked well for the company, too. They “got an engaged employee who worked to achieve tangible results for LinkedIn. The employee transformed [their] career by enhancing [their] portfolio of skills and experiences.”

My recommended experiences

Security is only one facet of a well-rounded engineer’s experience. Here are a few areas where I recommend gaining additional experience if you haven’t already:


Work on your user interfaces, or go work for a design company. Building software with a design-first approach will break your brain as a developer. You will gain empathy for the experience of the real people interacting with your creations. You’ll see their pain, and you’ll want to make it better. Further reading on this topic: The User Experience Team of One by Leah Buley.


Working for a consulting agency or being an independent consultant are excellent ways to learn about this. Another method is a tour of duty in field engineering, customer success, or sales engineering. Consulting will train you to ask a lot of questions for greater understanding, avoid over-promising, and how to iterate quickly with customers. Further reading on this topic: The Secrets of Consulting by Gerald M. Weinberg.


The guiding principal behind DevOps is if you build it, you run it. Every engineering team should be able to deploy, manage, and scale their software. Spend some time with your production operations team. Automate something that’s done manually. If your application isn’t yet a 12 factor app this is a great opportunity to attempt to make it cloud ready and run on a platform designed for scale. Further reading on this topic: The Phoenix Project by Gene Kim.

Strive to be well-rounded

As a web application developer the spectre of the full-stack developer is all around me. The pressure to have deep experience in every architectural layer is heavy. This isn’t really possible, and as an industry we’re coming to grips with that. I would recommend we focus, as engineers, on being well-rounded. We ought to attain familiarity and working knowledge of new facets of software development through the procurement of experiences.

#HackerKast 37: More router hacking, StegoSploit, XSS Polyglot and Columbia Casualty Insurance refuses to pay Cottage Health

One more lonely week without Matt Johansen as Jeremiah and I have braved another HackerKast on our own. Thankfully we were comforted by some very interesting stories. Most of them were technical but one of them was around insurance.

First up was about router hacking – one of Jer and my favorite topics. It turns out someone has been automating intranet hacking using the browser to attack various different SOHO routers and firewalls. This is neat because it’s actually in the wild, being used. It attempts various passwords, and ultimately tries to re-write DNS or route users to another location. Pretty nasty. I had a brief conversation with NoScript’s author, Giorgio Maone who is considering writing Application Boundary Enforcement into a stand-alone plugin.

Then we talked about two stories, StegoSploit and something called XSS Polyglot. They’re different takes on the same issue. If you need to do some hosting of content on another domain for some reason (typically payloads) you can do so in an image or using Flash. Both are great articles and they both do a pretty good job of breaking CSP in certain implementations.

Lastly we talked about an insurance provider called Columbia Casualty Insurance who refuses to pay out Cottage Health due to lax security. Namely, Cottage Health allegedly failed to do the things their policy required of them. If you don’t do what you say you’re doing, it’s hard to see why they would be obligated to pay out. Either way, it’s an interesting case, and probably the first of many to come.


An Exploit Kit Dedicated to CSRF
StegoSploit – Metasploit in an SVG image
Using Ads To Bypass CSP
Insurer Cites Lax Security in Challenge to Cottage Health Claim

Notable stories this week that didn’t make the cut:
Disconnect.Me Files Antitrust Case Against Google In Europe Over Banned Anti-Malware Android App
The Efficacy of Google’s Privacy Extension
AppSec USA: Full List of Accepted Talks
Criminals use IRS website to steal data on 104,000 people
Weaponizing code: America’s quest to control the exploit market
The Security Issue of Blockchaininfos and Android
Thousands of Websites Block Congress in Protest of NSA Surveillance and this Naked campagin
SourceForge Grabs Gimp For Windows And Wraps It With AdWare
I Fooled Millions Into Thinking Chocolate Helps Weight
AdBlock Wins in Court Twice in Weeks
Ross Ulbricht Pleads For Leniency
CareFirst Breached
St. Louis Federal Reserve Had DNS Hijacked
LaZagne – Password Recovery Tool
How Many Million BIOSes Would You Like To Infect
Facebook Supports PGP
Airbus confirms software brought down A400M transport plane

#HackerKast 36: Moose Router Worm, Adult Friend Finder male users hacked, Firefox and advertising, WHS Stats Report, and IRS Data Breach

It was just Jeremiah and me again today, as Matt is shamelessly galavanting around Europe at various security conferences (I think it’s safe to hate him for it, isn’t it?). But we had a ton of interesting stories this week to cover and didn’t have much time to do it.

The first up was the Moose Router Worm – similar to the Internet Census Project, it used default usernames and passwords to compromise remote routers. We don’t know how many routers were compromised but it was a lot, I’m sure. Jer seems to think that routers shouldn’t even have this feature at all – and I’m inclined to agree.

It was a bad week for Adult Friend Finder, but an even worse week for their users, who had user account data stolen and published on the Internet. The data dump was incomplete and only comprised about 300M worth of data. Also, interestingly enough, it seemed to contain only data from the male users, which implies that it’s probably more about who is most easily blackmailed and less about what the actual adversaries have.

Next up we discussed Firefox and their rather strange move to build an advertising platform into the browser. Their reasoning is complicated, but it seems to revolve around a mix of making money and doing right by their users – except I don’t recall a user ever asking for this. Meanwhile one of Mozilla’s own employees wrote up a great paper on how users with ad blocking and privacy protection can save up to 40% bandwidth and page load time on the top Alexa sites. Shortly after, that same employee promptly left the company under somewhat mysterious circumstances.

Then we covered the stats report. You’ll have to download it to see for yourself, but there are a great number of interesting findings in there. For instance it appears to refute the idea of a best practice. There just doesn’t seem to be any one security factor that will prevent people from being hackable. Maybe they work in some combination, but not in a vacuum. Check it out.

Lastly, we briefly touched on the IRS data breech (if you can call it that) where north of 100k people’s tax data were stolen. This is almost certainly the result of stealing user data through something like Zeus or other public places and combining data to attempt to log in as the user. Jer’s point couldn’t be more clear – Social Security Numbers aren’t a good password, stop using them. If you are, you’re site is hackable.

That’s it for the week, I hope you enjoyed it! We’ll be back next week. Rate, subscribe, and give us feedback on things you’d like us to cover.

Moose Router Worm
Adult Friend Finder Compromised
Firefox Will Soon Get Sponsored Suggested Tiles Based On Your Browsing History
Tracking Protection for Firefox at Web 2.0 Security and Privacy 2015
Website Security Statistics Report 2015
100k+ Tax Records Breached from the IRS

Notable stories this week that didn’t make the cut:
Android Chrome ARC Welder
Chrome Extension Transmits Information Via Sound
Phuctor – RSA Super Collider
Two Diablo III players stole virtual armor and gold — and got prosecuted IRL
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 1
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 2
New Cyber Security Legislation On Export of Cyber Weapons (Wassenaar) article 3
FCC Warns Internet Providers That They’re On the Hook For User Privacy
Adblock Browser for Android
Hacking Starbucks for unlimited coffee
Logjam Attack against the TLS Protocol article 1
Logjam Attack against the TLS Protocol article 2
Specially Crafted Message Crashes iPhones article 1
Specially Crafted Message Crashes iPhones article 2
40% of Docker Images Are Vulnerable to High Severity CVEs

WhiteHat Website Security Statistics Report: From Detection to Correction

While web security used to be a reactionary afterthought, it has evolved to become a necessity for organizations that wish to conduct online business safely. Companies have switched from playing defense to playing offense in a game that is still difficult to win. In an effort to change the game, WhiteHat Security has been publishing its Website Security Statistics Report since 2006 in the hope of helping organizations improve web security before they become victim to an attack.

After several editions, this is by far the most data rich, educational, insightful and useful application security report I have ever read. I may be biased, but I believe this report is unique: something special and different that is an essential read for application security professionals. In creating this report, I have learned more about what works and what doesn’t work than I have learned doing anything else in my many years of working in application security. I am extremely confident that our readers will appreciate what we have created for them.

In this year’s report, we examine the activities of real-world application security programs along with the most prevalent vulnerabilities based on data collected from more than 30,000 websites under WhiteHat Sentinel management. From there, we can then determine how many vulnerabilities get fixed, the average time it takes to fix them, and how every application security program can measurably improve. Our research provides insights into how organizations can better determine which security metric to improve upon.

We’ve learned that vulnerabilities are plentiful, that they stay open for weeks or months, and that typically only half get fixed. We have become adept at finding vulnerabilities. The next phase is to improve the remediation process. In order to keep up with the increase in vulnerabilities, we need to make the remediation process faster and easier. The amount of time companies are vulnerable to web attacks is much too long – an average of 193 days from the first notification. Increasing the rate at which these vulnerabilities are remediated is the only way to protect users.

The best way to lower the average number of vulnerabilities, speed up time-to-fix, and increase remediation rates is to feed vulnerability results back to development through established bug tracking or mitigation channels. This places application security at the forefront of development and minimizes the need for remediation further down the road. The goal is more secure software, not more security software.

For security to improve, organizations need to set aside the idea of ‘best practices’ and not stop at compliance controls. Multiple parts of the organization must determine which teams should be held accountable for their specific job function. Organizations that don’t hold specific teams accountable have an average remediation rate of 24% versus 33% for companies that do. When you empower those who are also accountable, the organization has a higher likelihood of being effective.

In this year’s edition, the WhiteHat Website Security Statistics Report drives home the point that we now have a very clear understanding of what vulnerabilities are out there. Based on that information, we must create a solid, measurable remediation program to remove those vulnerabilities and increase the safety and security of the web.

To view the full report, click here. I would also invite you to join the conversation on Twitter at #WHStats @whitehatsec.

Logjam: Web Encryption Vulnerability

A team of researchers has released details of a new attack called “Logjam.” This attack, like FREAK, enables a man-in-the-middle attacker to downgrade the connection between the client and the server to an easier-to-break cipher. Many servers support these weaker ciphers, though there is no practical reason to support them. The solution is to simply not support any ciphers that are easy to break. In fact, the browser makers are doing that right now.

The offending ciphers, Export Diffie-Hellman ciphers, can be found in HTTPS, SSH, VPN, mail, and many other servers. This does not, however, mean that you are vulnerable, or that you need to panic. Exploiting this vulnerability requires man-in-the-middle and a high level of sophistication. The real risk is relatively low on this issue compared to Poodle or Heartbleed. You should simply test your TLS endpoints to ensure that they do not support any weak ciphers. If you took this step back when FREAK came out, you are likely already okay.

The specific ciphers to disable for this attack are DHE_EXPORT ciphers (or “EXP-EDH-” ciphers). But go ahead and disable all weak ciphers, while you’re at it.

All WhiteHat Sentinel dynamic testing services (BE, SE, PE, PL, Elite) now report the use of export ciphers as part of reporting on weak ciphers, and specifically call out the ciphers that are a concern for Logjam.

The research team that released the report has also set up a page to test your servers here: https://weakdh.org/sysadmin.html.

Remember that when you test a hostname, you are really testing the TLS endpoint for that connection, which may be a load balancer or firewall, and not your application server.

#Hackerkast 35: Airplane hacking, United bug bounty, and SEA hacks Washington Post

Hey Everyone! It was just Jeremiah Grossman and me today, as Matt Johansen is overseas this week attending various security conferences. So we braved on and did a short one with just three major articles.

First we covered Airplane hacking and a bit of drama that has been unfolding in the mainstream press related to hacking an airplane while on one. Jeremiah made the point that it’s not just illegal it’s also dangerous from a personal safety perspective. Rule number 1 of hacking – don’t hack the airplane while you’re still on it.

Then we discussed a bit about the United bug bounty program that was just announced. Although it’s interesting, it still doesn’t cover the major thing the public is worried about. Learning who is flying is bad, but doing something bad to an airplane is much much worse. And it does beg the question, why does the bounty program not cover the airplane if there are no flaws in airplanes?

Lastly we covered the latest SEA hack of Washington Post by way of their CDN provider, InstartLogic. Jer made the point that hacking InstartLogic is just the canary in the coal mine: it’s the other hacks that you don’t see until a year or two down the road that are really troubling. In some ways, the SEA is doing us a huge favor by letting us know about the issues without causing any real harm in the process.

Airplane Hacking?!?!
United Rewards Bug Bounties with United Miles
SEA hacked Washington Post’s CDN InstartLogic

Notable stories this week that didn’t make the cut:
Firefox is going to Depreciate HTTP
Anti-gay demonstrators advertise gay porn site after their domain expires
Adblockers are immoral vs
Priority of Cnstituencies
Why a Law Firm is Baiting Cops With A Tor Server
VENOM Exploit Against QEMU and Xen Floppy Discs
Safari address-spoofing bug could be used in phishing, malware attacks

#HackerKast 34: SOHO Routers hacked, 3d printed ammo, Nazis & child porn, PayPal Remote Code Execution, Dubsmash 2, Twitter CSRF

Hey Everybody! We’re back from our 1 week break due to crazy schedules and even now we are without Jeremiah. Coconuts don’t make great WiFi antennae or something.

Started this episode talking about some Vendors who decided to do some weird, bad stuff this past week. In both stories it seems some security vendors were caught being naughty, starting with Tiversa. They are a security firm that decided it’d be a good idea to extort their own clients by finding a fake vulnerability and asking for money to fix this fake vulnerability. Then Tencent and Qihoo, two different Chinese AV Vendors, were both caught cheating on a certification test about how good their products were.

Moving away from shady vendors and on to shady home wireless routers. Not news to anybody, really: wifi routers you buy off the shelf aren’t quite state of the art when it comes to security. Hence, we see some sort of router hacking story pop up all the time. This time SOHO routers were targeted by the hacking group Anonymous, as per a report from Incapsula. It seems Anonymous saw a good opportunity to exploit these home routers and use them as a botnet, running their DDoS tool for fun and profit. The extremely 1337 H@x0r methodology being used here, which takes many years of cyber security experience and probably a CISSP to exploit, is a default username and password. Try to keep up here, the DEFAULT USERNAME AND PASSWORD out of the box was used to compromise MILLIONS of home routers and turn them into DDoS bots. I’ll just leave that there.

Next, Robert talked about some of the most ridiculous topics we’ve talked about on the podcast. He somehow related 3d printed ammunition to a story about Nazis and child pornography. You see, some court ruled somewhere that the file on the computer that can be used to 3d print bullets is now considered as munitions legally. In related(?) news, there was some Nazi war camp website that got hacked and got child pornography uploaded to it. When child porn is involved, the government immediately must confiscate the computers as evidence which essentially takes the website offline. Robert related the two by saying that you could also upload a 3d printer file which would have the same effect, now that a file can constitute illegal munitions.

In vulnerability disclosure news, PayPal was vulnerable to Remote Code Execution via a 3rd party library they were using. The Java Debug Wire Protocol using Shellifier was leaving port 8000 open on some Paypal servers, which allowed an attacker to gain access remotely — without authenticating — and execute commands. The part we don’t know yet is whether or how much PayPal paid the researcher who disclosed this to them. They’ve been known to pay big bounties in the past.

Robert then covered a fake mobile app called Dubsmash 2 that was uploaded to the Google Play store this week and got wildly popular. Apparently, Dubsmash is a popular app which allows you to lip sync to some songs — but the fraudulent sequel app wouldn’t be nearly as fun. What it did was immediately remove the “Dubsmash” part of the app and replace the icon with a mimic “Settings” icon. The moment a user clicked this icon, the app would generate thousands of pop-unders of porn sites and click on ads. The thought here was they are using this in a pay-per-click fraud scheme to generate earnings for the developer. 500,000 users downloaded the fake app to date.

Lastly, we talked about a CSRF vulnerability disclosed via HackerOne to Twitter about 11 months ago and recently disclosed publicly. This CSRF protection bypass was *very* creative and used a behavior in certain frameworks which treats commas as semicolons. This would allow an attacker to exploit a user by sending them a malicious link which would allow the attacker to use the CSRF token they stole on mobile.twitter.com. Really cool research that I’m glad eventually became public.

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

Tiversa May Have Hacked Its Own Clients To Extort Them
2nd (Tencent and Qihoo) Chinese AV-Vendor Caught Cheating
3-D Printed Gun Lawsuit Starts the War Between Arms Control and Free Speech
Nazi camp website hacked with child porn on anniversary
MySQL Out of Band (2nd Order) Exploitation
Twitter CSRF Bug
PayPal Remote Code Execution (Java Debug Wire Protocol using Shellifier)
Your Smartphone Might Be Watching Porn Behind Your Back
Anonymous accused of running a botnet using thousands of hacked home routers

Notable stories this week that didn’t make the cut:
PHP == Operator Issue
Hack Google Password
Researchers Hijack Teleoperated Surgical Robot
Google PageSpeed Service End of Life
Windows to Kill of Patch Tuesday
PortSwigger Web Security Blog: Burp Suite now reports blind XXE injection
Practical Cache Attacks in JavaScript
25 Members of $15M Carding Gang Arrested
Apple ‘test’ iPad stolen from a Cupertino home: Report
Irate Congressman Gives Cops Easy Rule – Follow The Damned Constitution

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.