Better Linux Through Coloring

March 7, 2017 by Al Williams 6 Comments

Cyber security is on everyone’s minds these days. Embedded devices like cameras have been used by bad guys to launch attacks on the Internet. People worry about data leaking from voice command devices or home automation systems. And this goes for the roll-your-own systems we build and deploy.

Many network-aware systems use Linux somewhere — one big example is pretty much every Raspberry Pi based project. How much do you think about security when you deploy a Pi? There is a superior security system available for Linux (including most versions you’d use on the Pi) called SELinux. The added letters on the front are for “Security-Enhanced” and this project was originally started by the NSA and RedHat. RedHat actually has — no kidding — a coloring book that helps explain some of the basic concepts.

We aren’t so sure the coloring book format is really the right approach here, but it is a light and informative read (we didn’t stay in the lines very well, though). Our one complaint is that it doesn’t really show you anything in practice, it just explains the ideas behind the different kind of protections available in SELinux. If you want to actually set it up on Pi, there’s a page on the Pi site that will help. If you have an hour, you can get a good overview of using SELinux in the video below.

Continue reading “Better Linux Through Coloring” →

Friday Hack Chat: Raspberry Pi Principal Hardware Engineer Roger Thornton

March 1, 2017 by Mike Szczys 4 Comments

Have 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:

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

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

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.

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?