DNS-over-HTTPS Is The Wrong Partial Solution

Openness has been one of the defining characteristics of the Internet for as long as it has existed, with much of the traffic today still passed without any form of encryption. Most requests for HTML pages and associated content are in plain text, and the responses are returned in the same way, even though HTTPS has been around since 1994.

But sometimes there’s a need for security and/or privacy. While the encryption of internet traffic has become more widespread for online banking, shopping, the privacy-preserving aspect of many internet protocols hasn’t kept pace. In particular, when you look up a website’s IP address by hostname, the DNS request is almost always transmitted in plain text, allowing all the computers and ISPs along the way to determine what website you were browsing, even if you use HTTPS once the connection is made.

The idea of also encrypting DNS requests isn’t exactly new, with the first attempts starting in the early 2000s, in the form of DNSCrypt, DNS over TLS (DoT), and others. Mozilla, Google, and a few other large internet companies are pushing a new method to encrypt DNS requests: DNS over HTTPS (DoH).

DoH not only encrypts the DNS request, but it also serves it to a “normal” web server rather than a DNS server, making the DNS request traffic essentially indistinguishable from normal HTTPS. This is a double-edged sword. While it protects the DNS request itself, just as DNSCrypt or DoT do, it also makes it impossible for the folks in charge of security at large firms to monitor DNS spoofing and it moves the responsibility for a critical networking function from the operating system into an application. It also doesn’t do anything to hide the IP address of the website that you just looked up — you still go to visit it, after all.

And in comparison to DoT, DoH centralizes information about your browsing in a few companies: at the moment Cloudflare, who says they will throw your data away within 24 hours, and Google, who seems intent on retaining and monetizing every detail about everything you’ve ever thought about doing.

DNS and privacy are important topics, so we’re going to dig into the details here. Continue reading “DNS-over-HTTPS Is The Wrong Partial Solution”

This Week In Security: Is RSA Finally Broken? The Push For Cloud Accounts, Encrypted DNS, And More Mobile Mayhem

Ever wondered what “cyberwar” looks like? Apparently it’s a lot of guessing security questions and changing passwords. It’s an interesting read on its own, but there are some interesting clues if you read between the lines. A General in the know mentioned that Isis:

clicked on something or they did something that then allowed us to gain control and then start to move.

This sounds very similar to stories we’ve covered in the past, where 0-days are used to compromise groups or individuals. Perhaps the NSA supplied such an exploit, and it was sent in a phishing attack. Through various means, the U.S. team quietly compromised systems and collected credentials.

The article mentions something else interesting. Apparently the targets of this digital sting had also been compromising machines around the world, and using those machines to manage their efforts. The decision was made by the U.S. team to also compromise those machines, in order to lock out the Isis team. This might be the most controversial element of the story. Security researchers have wanted permission to do this for years. How should the third parties view these incursions?

The third element that I found particularly interesting was the phase 2 attack. Rather than outright delete, ban, and break Isis devices and accounts, the U.S. team installed persistent malware that emulated innocuous glitches. The internet connection is extremely laggy on certain days, certain websites simply don’t connect, and other problems. These are the sort of gremlins that networking pros spend all day trying to troubleshoot. The idea that it’s intentional gives me one more thing to worry about. Continue reading “This Week In Security: Is RSA Finally Broken? The Push For Cloud Accounts, Encrypted DNS, And More Mobile Mayhem”

Control Your Web Browser Like It’s 1969

Imagine for a moment that you’ve been tasked with developing a device for interfacing with a global network of interconnected devices. Would you purposely design a spring-loaded dial that can do nothing but switch a single set of contacts on and off from 1 to 10 times? What kind of crazy world would we have to live in where something like that was the pinnacle of technology?

Obviously, such a world once existed, and now that we’ve rolled the calendar ahead a half-century or so, both our networks and our interfaces have gotten more complex, if arguably better. But [Jan Derogee] thinks a step backward is on order, and so he built this rotary phone web browser. The idea is simple: pick up the handset and dial the IP address of the server you want to connect to. DNS? Bah, who needs it?

Of course there is the teensy issue that most websites can’t be directly accessed via IP address anymore, but fear not – [Jan] has an incredibly obfuscated solution to that. It relies on the fact that many numbers sound like common phrases when sounded out in Chinese, so there end up being a lot of websites that have number-based URLs. He provides an example using the number 517, which sounds a bit like “I want to eat,” to access the Chinese website of McDonald’s. How the number seven sounding like both “eat” and “wife” is resolved is left as an exercise to the reader.

And here we thought [Jan]’s rotary number pad was of questionable value. Still, we appreciate this build, and putting old phones back into service in any capacity is always appreciated.

Continue reading “Control Your Web Browser Like It’s 1969”

You Might Not Be Able To Read This

Early today, some party unleashed a massive DDoS attack against Dyn, a major DNS host. This led to a number of websites being completely inaccessible. DNS is the backbone of the Internet. It is the phone book that turns URLs into IP addresses. Without it, the Internet still works, but you won’t be able to find anything.

Over the past few months, security professionals have suggested — in as responsible terms as possible — that something big could happen. In early September [Bruce Schneier] wrote, Someone Is Learning How To Take Down The Internet. The implication of this very general warning is that someone — possibly a state actor, but don’t be too sure about that — was figuring out how to attack one of the core services of the web. The easiest way to effectively ‘turn off the Internet’ for everyone is a Distributed Denial of Service attack against root servers, DNS servers, or some other service that plays a key role in the web.

Dyn is responding well to the attack this morning, and the Internet is safe from attack for the time being. As for who is responsible for the attack, what the goal is, and if this will happen again, no one knows. An attack on this scale is most certainly someone with a very large pocketbook or a state actor (Russia, China, the US, UK, Germany, Israel, or the like) but that’s not a given. It’s also not given the DDoS attacks have stopped. You might not be able to read this, but if you can, it might be a good idea to find a shortwave radio.

DNS Tunneling: Getting The Data Out Over Other Peoples’ WiFi

[KC Budd] wanted to make a car-tracking GPS unit, and he wanted it to be able to phone home. Adding in a GSM phone with a data plan would be too easy (and more expensive), so he opted for the hacker’s way: tunneling the data over DNS queries every time the device found an open WiFi hotspot. The result is a device that sends very little data, and sends it sporadically, but gets the messages out.

This system isn’t going to be reliable — you’re at the mercy of the open WiFi spots that are in the area. This certainly falls into an ethical grey zone, but there’s very little harm done. He’s sending a 16-byte payload, plus the DNS call overhead. It’s not like he’s downloading animated GIFs of cats playing keyboards or something. We’d be stoked to provide this service to even hundreds of devices per hour, for instance.

If you’re new here, the idea of tunneling data over DNS requests is as old as the hills, or older, and we’ve even covered this hack before in different clothes. But what [KC] adds to the mix is a one-stop code shop on his GitHub and a GPS application.

Why don’t we see this being applied more in your projects? Or are you all tunneling data over DNS and just won’t admit it in public? You can post anonymously in the comments!

Remotely Controlling Automobiles Via Insecure Dongles

Automobiles are getting smarter and smarter. Nowadays many vehicles run on a mostly drive-by-wire system, meaning that a majority of the controls are electronically controlled. We’re not just talking about the window or seat adjustment controls, but also the instrument cluster, steering, brakes, and accelerator. These systems can make the driving experience better, but they also introduce an interesting avenue of attack. If the entire car is controlled by a computer, then what if an attacker were to gain control of that computer? You may think that’s nothing to worry about, because an attacker would have no way to remotely access your vehicle’s computer system. It turns out this isn’t so hard after all. Two recent research projects have shown that some ODBII dongles are very susceptible to attack.

The first was an attack on a device called Zubie. Zubie is a dongle that you can purchase to plug into your vehicle’s ODBII diagnostic port. The device can monitor sensor data from your vehicle and them perform logging and reporting back to your smart phone. It also includes a built-in GPRS modem to connect back to the Zubie cloud. One of the first things the Argus Security research team noticed when dissecting the Zubie was that it included what appeared to be a diagnostic port inside the ODBII connector.

Online documentation showed the researchers that this was a +2.8V UART serial port. They were able to communicate over this port with a computer with minimal effort. Once connected, they were presented with an AT command interface with no authentication. Next, the team decompiled all of the Python pyo files to get the original scripts. After reading through these, they were able to reverse engineer the communication protocols used for communication between the Zubie and the cloud. One particularly interesting finding was that the device was open for firmware updates every time it checked in with the cloud.

The team then setup a rogue cellular tower to perform a man in the middle attack against the Zubie. This allowed them to control the DNS address associated with the Zubie cloud. The Zubie then connected to the team’s own server and downloaded a fake update crafted by the research team. This acted as a trojan horse, which allowed the team to control various aspects of the vehicle remotely via the cellular connection. Functions included tracking the vehicle’s location, unlocking hte doors, and manipulating the instrument cluster. All of this can be done from anywhere in the world as long as the vehicle has a cellular signal.

A separate but similar project was also recently discussed by [Corey Thuen] at the S4x15 security conference. He didn’t attack the Zubie, but it was a similar device. If you are a Progressive insurance customer, you may know that the company offers a device that monitors your driving habits via the ODBII port called SnapShot. In exchange for you providing this data, the company may offer you lower rates. This device also has a cellular modem to upload data back to Progressive.

After some research, [Thuen] found that there were multiple security flaws in Progressive’s tracker. For one, the firmware is neither signed nor validated. On top of that, the system does not authenticate to the cellular network, or even encrypt its Internet traffic. This leaves the system wide open for a man in the middle attack. In fact, [Thuen] mentions that the system can be hacked by using a rogue cellular radio tower, just like the researchers did with the Zubie. [Thuen] didn’t take his research this far, but he likely doesn’t have too in order to prove his point.

The first research team provided their findings to Zubie who have supposedly fixed some of the issues. Progressive has made a statement that they hadn’t heard anything from [Thuen], but they would be happy to listen to his findings. There are far more devices on the market that perform these same functions. These are just two examples that have very similar security flaws. With that in mind, it’s very likely that others have similar issues as well. Hopefully with findings like this made public, these companies will start to take security more seriously before it turns into a big problem.

[Thanks Ellery]

Siri Proxy Adds Tons Of Functionality, Doesn’t Require A Jailbreak

siri-proxy

[Pete] has an iPhone 4s and loves Siri, but he wishes she had some more baked-in capabilities. While the application is technically still in beta and will likely be updated in the near future, [Pete] wanted more functionality now.

Since Apple isn’t known for their open architecture, he had to get creative. Knowing how Siri’s commands are relayed to Apple thanks to the folks at Applidium, he put together a proxy server that allows him to intercept and work with the data.

The hack is pretty slick, and doesn’t even require a jailbreak. A bit of DNS and SSL trickery is used to direct Siri’s WiFi traffic through his server, which then relays the commands to Apple’s servers for processing. On the return trip, his server interprets the data, looking for custom commands he has defined.

In the video below, he gives a brief overview of the system, then spends some time showing how he can use Siri to control his WiFi enabled thermostat. While the process only works while Siri is connected to his home network via WiFi, it’s still pretty awesome.

Continue reading “Siri Proxy Adds Tons Of Functionality, Doesn’t Require A Jailbreak”