Cloudbleed — Your Credentials Cached In Search Engines

February 24, 2017 by Pedro Umbelino 25 Comments

In case you are still wondering about the SHA-1 being broken and if someone is going to be spending hundreds of thousands of dollars to create a fake Certificate Authority and sniff your ~~OkCupid~~ credentials, don’t worry. Why spend so much money when your credentials are being cached by search engines?… Wait, what?

A serious combination of bugs, dubbed Cloudbleed by [Tavis Ormandy], lead to uninitialized memory being present in the response generated by the reverse proxies and leaked to the requester. Since these reverse proxies are shared between Cloudflare clients, this makes the problem even worst, since random data from random clients was leaking. It’s sort of like Heartbleed for HTTP requests. The seriousness of the issue can be fully appreciated in [Tavis] words:

“The examples we’re finding are so bad, I cancelled some weekend plans to go into the office on Sunday to help build some tools to cleanup. I’ve informed cloudflare what I’m working on. I’m finding private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We’re talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything.”

According to Cloudflare, the leakage can include HTTP headers, chunks of POST data (perhaps containing passwords), JSON for API calls, URI parameters, cookies and other sensitive information used for authentication (such as API keys and OAuth tokens). An HTTP request to a Cloudflare web site that was vulnerable could reveal information from other unrelated Cloudflare sites.

Adding to this problem, search engines and any other bot that roams free on the Internet, could have randomly downloaded this data. Cloudflare released a detailed incident report explaining all the technicalities of what happened and how they fixed it. It was a very quick incident response with initial mitigation in under 47 minutes. The deployment of the fix was also quite fast. Still, while reading the report, a sense that Cloudflare downplayed this issue remains. According to Cloudflare, the earliest date that this problem could have started is 2016-09-22 and the leak went on until 2017-02-18, five months, give or take.

Just to reassure the readers and not be alarmist, there is no evidence of anyone having exploiting what happened. Before public exposure, Cloudflare worked in proximity with search engines companies to ensure memory was scrubbed from search engine caches from a list of 161 domains they had identified. They also report that Cloudflare has searched the web (!), in sites like Pastebin, for signs of leaks and found none.

On the other hand, it might be very well impossible to know for sure if anyone has a chunk of this data cached away somewhere in the aether. It’s impossible to know. What we would really like to know is: does [Tavis] get the t-shirt or not?

SHAttered — SHA-1 Is Broken In

February 23, 2017 by Pedro Umbelino 96 Comments

A team from Google and CWI Amsterdam just announced it: they produced the first SHA-1 hash collision. The attack required over 9,223,372,036,854,775,808 SHA-1 computations, the equivalent processing power as 6,500 years of single-CPU computations and 110 years of single-GPU computations. While this may seem overwhelming, this is a practical attack if you are, lets say, a state-sponsored attacker. Or if you control a large enough botnet. Or if you are just able to spend some serious money on cloud computing. It’s doable. Make no mistake, this is not a brute-force attack, that would take around 12,000,000 single-GPU years to complete.

SHA-1 is a 160bit standard cryptographic hash function that is used for digital signatures and file integrity verification in a wide range of applications, such as digital certificates, PGP/GPG signatures, software updates, backup systems and so forth. It was, a long time ago, proposed as a safe alternative to MD5, known to be faulty since 1996. In 2004 it was shown that MD5 is not collision-resistant and not suitable for applications like SSL certificates or digital signatures. In 2008, a team of researchers demonstrated how to break SSL based on MD5, using 200 Playstations 3.

Early since 2005 theoretical attacks against SHA-1 were known. In 2015 an attack on full SHA-1 was demonstrated (baptized the SHAppening). While this did not directly translate into a collision on the full SHA-1 hash function due to some technical aspects, it undermined the security claims for SHA-1. With this new attack, dubbed SHAttered, the team demonstrated a practical attack on the SHA-1 algorithm, producing two different PDF files with the same checksum.

The full working code will be released in three months, following Google’s vulnerability disclosure policy, and it will allow anyone to create a pair of PDFs that hash to the same SHA-1 sum given two distinct images and some, not yet specified, pre-conditions.

For now, recommendations are to start using SHA-256 or SHA-3 on your software. Chrome browser already warns if a website has SHA-1 certificate, Firefox and the rest of the browsers will surely follow. Meanwhile, as always, tougher times are ahead for legacy systems and IoT like devices.

Friday Hack Chat: Security For IoT

February 22, 2017 by Brian Benchoff 28 Comments

Over the last few weeks, our weekly Hack Chats on hackaday.io have gathered a crowd. This week, we’re talking about the greatest threat humanity has ever faced: toasters with web browsers.

The topic of this week’s Hack Chat is Security for IoT, because someone shut down the Internet with improperly configured webcams.

This chat is hosted by the Big Crypto Team at the University of Pittsburgh. [Wenchen Wang], [Ziyue Sun], [Brandon Contino], and [Nick Albanese] will be taking questions about lightweight devices connected to the Internet. Discussion will include building things that connect to larger networks securely.

The Big Crypto team at UP are thinking about the roadblocks people have to implement security in their projects, and if apathy or ignorance is the main reason security isn’t even considered in the worst IoT offenders.

The Hack Chat is scheduled for Friday, February 24th at noon PST (20:00 GMT).

Here’s How To Take Part:

Our Hack Chats are live community events on the Hackaday.io Hack Chat group messaging.

Log into Hackaday.io, visit that page, and look for the ‘Join this Project’ Button. Once you’re part of the project, the button will change to ‘Team Messaging’, which takes you directly to the Hack Chat.

You don’t have to wait until Friday; join whenever you want and you can see what the community is talking about.

Upcoming Hack Chats

These Hack Chats are becoming very popular, and that’s due in no small part to the excellent lineup of speakers we’ve hosted. Already, we’ve had [Lady Ada], [Sprite_tm], and [bunnie] — engineers, hackers, and developers who are at the apex of their field. We’re not resting on our laurels, though: in a few weeks we’ll be hosting Hack Chats with [Roger Thornton], an engineer with Raspberry Pi, and Fictiv, masters of mechanical manufacturing.

Using SDR To Take Control Of Your Home Security System

February 6, 2017 by Anool Mahidharia 5 Comments

[Dan Englender] was working on implementing a home automation and security system, and while his house was teeming with sensors, they used a proprietary protocol which was not supported by the open source system he was trying to implement. The problem with home automation and security systems is the lack of standardization – or rather, the large number of (often incompatible) standards used to ensure consumers get tied in to one specific system. He has shared the result of his efforts at getting the two to talk to each other via his project decode345.

The result enabled him to receive signals from Honeywell’s 5800 series of wireless products and interface them with OpenHAB — a vendor and technology agnostic open source automation software. OpenHAB offers “bindings” that allow a wide variety of systems and hardware to be integrated. Unfortunately for [Dan], this exhaustive list does not yet include support for the (not very popular) 345MHz protocol used by the Honeywell 5800 system, hence his project. Continue reading “Using SDR To Take Control Of Your Home Security System” →

Popular Printers Pwned In Prodigious Page Prank

February 4, 2017 by Jenny List 40 Comments

A new day dawns, and we have another story involving insecure networked devices. This time it is printers of all makes and descriptions that are causing the panic, as people are finding mystery printouts bearing messages such as this:

“Stackoverflowin has returned to his glory, your printer is part of a botnet, the god has returned“

Well that’s it then, you can’t argue with a deity, especially one who has apparently created a botnet from the world’s printing devices. Printer owners the world over are naturally worried about their unexpected arrival, and have appeared on support forums and the like to express their concern.

We are of course used to taking everything our printers tell us at face value. Low on ink? I hear you, my inanimate reprographic friend! But when our printer tells us it’s part of a botnet perhaps it’s time to have a little think. It is entirely possible that someone could assemble a botnet of compromised printers, but in this case we smell a rat. Only in farcical crime dramas do crooks announce their crimes in such a theatrical fashion, you might say it’s the point of a botnet not to be detected by its host. Reading some of the reports it seems that many of the affected systems have port 9100 open to the world, that’s the standard TCP printer port, so it seems much more likely that someone has written a little script that looks for IP addresses with port 9100 open, and trolls them with this message.

The real message here is one with which we expect Hackaday readers will be very familiar, and which we’ve covered before. Many network connected appliances have scant regard for security, and are a relative push-over for an attacker. The solution is relatively straightforward to those of a technical inclination, be aware of which services the devices is exposing, lock down services such as uPNP and close any open ports on your router. Unfortunately these steps are probably beyond many home users, whose routers remain with their default manufacturer’s settings for their entire lives. It’s a shame our printer troll didn’t add a link to basic router security tips.

If you want to have a little fun, some of the printed pages include an email address for ‘the god’. It would be fun to figure out who this is, right?

33C3: How Can You Trust Your Random Numbers?

February 1, 2017 by Elliot Williams 49 Comments

One of the standout talks at the 33rd Chaos Communications Congress concerned pseudo-random-number generators (PRNGs). [Vladimir Klebanov] (right) and [Felix Dörre] (left) provided a framework for making sure that PRNGs are doing what they should. Along the way, they discovered a flaw in Libgcrypt/GNUPG, which they got fixed. Woot.

Cryptographically secure random numbers actually matter, a lot. If you’re old enough to remember the Debian OpenSSL debacle of 2008, essentially every Internet service was backdoorable due to bad random numbers. So they matter. [Vladimir] makes the case that writing good random number generators is very, very hard. Consequently, it’s very important that their output be tested very, very well.

So how can we test them? [Vladimir] warns against our first instinct, running a statistical test suite like DIEHARD. He points out (correctly) that running any algorithm through a good enough hash function will pass statistical tests, but that doesn’t mean it’s good for cryptography.
Continue reading “33C3: How Can You Trust Your Random Numbers?” →

Autonomous Delivery: Your Impulse Buys Will Still Be Safe

January 16, 2017 by Dan Maloney 81 Comments

I heard a “Year in Review” program the other day on NPR with a BBC World Service panel discussion of what’s ahead for 2017. One prediction was that UAV delivery of packages would be commonplace this year, and as proof the commentator reported that Amazon had already had a successful test in the UK. But he expressed skepticism that it would ever be possible in the USA, where he said that “the first drone that goes over somebody’s property will be shot down and the goods will be taken.”

He seemed quite sincere about his comment, but we’ll give him the benefit of the doubt that he was only joking to make a point, not actually grotesquely ignorant about the limitations of firearms or being snarky about gun owners in the US. Either way, he brings up a good point: when autonomous parcel delivery is commonplace, who will make sure goods get to the intended recipient?

Continue reading “Autonomous Delivery: Your Impulse Buys Will Still Be Safe” →