Friday Hack Chat: Raspberry Pi Principal Hardware Engineer Roger Thornton

rpichat1-01Have you heard about the new Raspberry Pi Zero W which now includes WiFi and Bluetooth? Of course you have. Want to know what went into the addition to the popular design? Now’s the time to ask when this week’s Hack Chat is led by Roger Thornton, chief hardware engineer for Raspberry Pi.

Raspberry Pi was born on February 29th, 2012 and has seen a remarkable number of hardware flavors and revisions. Throughout, the hardware has been both dependable and affordable — not an easy thing to accomplish. Roger will discuss the process his team uses to go from concept, all the way through to the hands of the user. It’s an excellent chance to ask any questions you have from soup to nuts.

The Hack Chat is scheduled for Friday, March 3rd at noon PST (20:00 GMT).

Here’s How To Take Part:

join-hack-chatOur 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

Mark your calendar for Friday March 10th when Hack Chat features mechanical manufacturing with members from the Fictiv team.

Cloudbleed — Your Credentials Cached in Search Engines

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.”

sexAccording 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

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

securityforiot-01Over 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:

join-hack-chatOur 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

[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

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?

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.

mpv-shot0012-zoomCryptographically 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?”