[Nathan] is a mobile application developer. He was recently debugging one of his new applications when he stumbled into an interesting security vulnerability while running a program called Charles. Charles is a web proxy that allows you to monitor and analyze the web traffic between your computer and the Internet. The program essentially acts as a man in the middle, allowing you to view all of the request and response data and usually giving you the ability to manipulate it.
While debugging his app, [Nathan] realized he was going to need a ride soon. After opening up the Uber app, he it occurred to him that he was still inspecting this traffic. He decided to poke around and see if he could find anything interesting. Communication from the Uber app to the Uber data center is done via HTTPS. This means that it’s encrypted to protect your information. However, if you are trying to inspect your own traffic you can use Charles to sign your own SSL certificate and decrypt all the information. That’s exactly what [Nathan] did. He doesn’t mention it in his blog post, but we have to wonder if the Uber app warned him of the invalid SSL certificate. If not, this could pose a privacy issue for other users if someone were to perform a man in the middle attack on an unsuspecting victim.
[Nathan] poked around the various requests until he saw something intriguing. There was one repeated request that is used by Uber to “receive and communicate rider location, driver availability, application configurations settings and more”. He noticed that within this request, there is a variable called “isAdmin” and it was set to false. [Nathan] used Charles to intercept this request and change the value to true. He wasn’t sure that it would do anything, but sure enough this unlocked some new features normally only accessible to Uber employees. We’re not exactly sure what these features are good for, but obviously they aren’t meant to be used by just anybody.
[Emanuele] is using Google Docs to log his temperature sensor data automatically (translated). We can see a few benefits gained by using this system. One is that you don’t have to visit the site of the logging hardware to harvest the data, another is that Google will automatically graph the data for you. Of course this means you need some way to connect your logger to the Internet, but we’ve seen buckets of different techniques for doing so. In this case, [Emanuele] is using PIC hardware that has a NIC on the board. But the technique could be used from a computer just as easily as from a microcontroller.
The meat and potatoes of the hack is sniffing out the HTTP header and syntax for writing to cells on a Google Docs (soon to be Google Drive) spreadsheet. After making a new spreadsheet and copying the URL and key from the address bar, he loads up the page using a header-viewer web service. With all the pertinent info in hand he crafts about a dozen lines of code to assemble the HTTP packet, and rolls the timestamp and temperature reading into it dynamically. See the system in action after the break.
Continue reading “Data logging directly to Google Docs (Google Drive)”
[Alex] sent in a neat Ikea DIODER build that controls strings of RGB LEDs with HTTP requests.
We’ve seen Ikea DIODERs controlled wirelessly and over USB, but using the Internet with a DIODER is new to us. For his build, [Alex] used a Nanode, a small Arduino-like board that has built-in web connectivity.
The hardware portion of the build is very simple. A MOSFET controls each LED strip on the DIODER. The stock controller of the DIODER was ditched, meaning [Alex] needed to figure out how to convert an RGB color space to a Hue, Saturation, and Lightness color space “for super-classy fading.” Once that was figured out, [Alex] implemented a 1D Perlin noise function to blend between two colors.
Finally, the great EtherCard library was used to turn HTTP requests into dancing LEDs. [Alex] is thinking about building a JQuery webpage so he won’t have to muck around with entering commands like 192.168.1.25/hsl?i=0&h=135&s=90&l=50 into a browser. Without a nice web interface, it’s not as futuristic as [Alex] would like, but it’s still cool to us.
There are Kinect hacks out there for robot vision, 3D scanners, and even pseudo-LIDAR setups. Until now, one limiting factor to these builds is the requirement for a full-blown computer on the device to deal with the depth maps and do all the necessary processing and computation. This doesn’t seem like much of a problem since [wizgrav] published Intrael, an HTTP interface for the Kinect.
[Eleftherios] caught up to [wizgrav] at his local hackerspace where he did a short tutorial on Intrael. [wizgrav]’s project provides each frame from the Kinect over HTTP wrapped up in JSON arrays. Everything a Kinect outputs aside from sound is now easily available over the Internet.
The project is meant to put computer vision outside the realm of desktops and robotic laptops and into the web. [wizgrav] has a few ideas on what his project can be used for, such as smart security cameras and all kinds of interactive surfaces.
After the break, check out the Intrael primer [wizgrav] demonstrated (it’s Greek to us, but there are subtitles), and a few demos of what Intrael ‘sees.’
Continue reading “Web-enabled Kinect”
[RSnake] has developed a denial of service technique that can take down servers more effectively. Traditionally, performing a denial of service attack entailed sending thousands of requests to a server, these requests needlessly tie up resources until the server fails. This repetitive attack requires the requests to happen in quick succession, and is usually a distributed effort. However, [RSnake]’s new technique has a client open several HTTP sessions and keeps them open for as long as possible. Most servers are configured to handle only a set number of connections; the infinite sessions prevent legitimate requests from being handled, shutting down the site. This vulnerability is present on webservers that use threading, such as Apache.
A positive side effect of the hack is that the server does not crash, only the HTTP server is affected. His example perl implementation, slowloris, is able to take down an average website using only one computer. Once the attack stops, the website will come back online immediately.
Update: Reader [Motoma] sent in a python implementation of slowloris called pyloris
Last week at Black Hat DC, [Moxie Marlinspike] presented a novel way to hijack SSL. You can read about it in this Forbes article, but we highly recommend you watch the video. sslstrip can rewrite all https links as http, but it goes far beyond that. Using unicode characters that look similar to / and ? it can construct URLs with a valid certificate and then redirect the user to the original site after stealing their credentials. The attack can be very difficult for even above average users to notice. This attack requires access to the client’s network, but [Moxie] successfully ran it on a Tor exit node.
If you are an Atmel fan, you may enjoy this webserver built around the ATmega88. Since it has full TCP and HTTP support, communication can be done using a standard web browser on any system. We also noticed that the code uses AVR Libc and the processor can be replaced with an ATmega168, both used on the Arduino platform. Honestly, we think the most interesting part about this project is the firmware. The author has assumed that the webserver will only be sending one packet per request and the code is optimized for this setup. This leaves around 50% of the memory for the web application.