Simple and Effective Car Lock Jammer Detector

[Andrew Nohawk], has noticed a spike of car break-ins and thefts — even in broad daylight — in his native South Africa. The thieves have been using remote jammers. Commercial detectors are available but run into the hundreds of dollars. He decided to experiment with his own rig, whipping up a remote jamming ‘detector’ for less than the cost of a modest meal.

Operating on the principle that most remote locks work at 433MHz, [Nohawk] describes how criminals ‘jam’ the frequency by holding down the lock button on another device, hoping to distort or outright interrupt the car from receiving the signal to lock the doors. [Nohawk] picked up a cheap 433MHz receiver (bundled with a transceiver), tossed it on a breadboard with an LED connected to the data channel of the chip on a 5V circuit, and voila — whenever the chip detects activity on that frequency, the LED lights up. If you see sustained activity on the band, there’s a chance somebody nearby might be waiting for you to leave your vehicle unattended.

If you want to know more about how these jamming attacks work, check out [Samy Kamkar’s] talk from the Hackaday SuperConference.

Continue reading “Simple and Effective Car Lock Jammer Detector”

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.

ASLR^CACHE Attack Defeats Address Space Layout Randomization

Researchers from VUSec found a way to break ASLR via an MMU sidechannel attack that even works in JavaScript. Does this matter? Yes, it matters. A lot. The discovery of this security flaw along with the practical implementation is really important mainly because of two factors: what it means for ASLR to be broken and how the MMU sidechannel attack works inside the processor.

Address Space Layout Randomization or ASLR is an important defense mechanism that can mitigate known and, most importantly, unknown security flaws. ASLR makes it harder for a malicious program to compromise a system by, as the name implies, randomizing the process addresses when the main program is launched. This means that it is unlikely to reliably jump to a particular exploited function in memory or some piece of shellcode planted by an attacker.

Breaking ASLR is a huge step towards simplifying an exploit and making it more reliable. Being able to do it from within JavaScript means that an exploit using this technique can defeat web browser ASLR protection running JavaScript, the most common configuration for Internet users.

ASLR have been broken before in some particular scenarios but this new attack highlights a more profound problem. Since it exploits the way that the memory management unit (MMU) of modern processors uses the cache hierarchy of the processor in order to improve the performance of page table walks, this means that the flaw is in the hardware itself, not the software that is running. There are some steps that the software vendors can take to try to mitigate this issue but a full and proper fix will mean replacing or upgrading hardware itself.

In their paper, researchers reached a dramatic conclusion:

Continue reading “ASLR^CACHE Attack Defeats Address Space Layout Randomization”

Correct Horse Battery Staple: The Book

XKCD 936, the comic that introduced the phrase, ‘correct horse battery staple’ into both the lexicon and password dictionaries, is the best way to generate a password. Your passwords should be random phrases of random words, hopefully with a few random numbers or symbols sprinkled about. It’s the most entropy you can get that’s also easy to remember.

However, generating your own ‘correct horse’ password is generally a bad idea. Humans are terrible at coming up with random bits of information. Thankfully, the EFF has come up with a wordlist containing 7,776 random words (65, or five rolls of a six-sided die.) ready for the next time you reset a password.

[m145mcc] thought the EFF’s word list should be a book, so he made it a book. With the clever application of a laser printer, glue, thread, and some card stock, [m145mcc] has a handy password generator that fits in his pocket. All that’s needed to build a password is a single die, a pen, and some patience.

The EFF’s random passphrase list is based off [Arnold Reinhold]’s Diceware list from 1995, but has a few changes to make the list easier to use and more palatable for the audience they’re going for. Most significantly, vulgar words were removed from the Diceware list, as the netsec crowd doesn’t swear as a rule. Additionally, numbers were removed, along with rare and unusual words. The passwords generated by the EFF’s list are longer, but they are arguably more memorable.

Despite the idea of a random dice-based password list being around for two decades, there are few if any examples of this list in dead tree format. The idea of a bound version of this list is a great idea, and we’re glad [m145mcc] could bring it to the table.

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”

Motion Detecting Camera Recognizes Humans Using The Cloud

[Mark West] and his wife had a problem, they’d been getting unwanted guests in their garden. Mark’s solution was to come up with a motion activated security camera system that emails him when a human moves in the garden. That’s right, only a human. And to make things more interesting from a technical standpoint, he does much of the processing in the cloud. He sends the cloud a photo with something moving in it, and he’s sent an email only if it has a human in it.

Continue reading “Motion Detecting Camera Recognizes Humans Using The Cloud”