[Josip] has been playing around with race conditions on web interfaces lately, finding vulnerabilities on both Facebook and Digital Ocean. A race condition can occur when a piece of software processes multiple threads using a shared resource.
For example, [Josip] discovered that he was able to manipulate page reviews using just a single Facebook account. Normally, a user is permitted to leave just one review for any given Facebook page. This prevents a single user from being able to skew the page’s overall ranking by making a bunch of positive or negative reviews. The trick to manipulating the system was to intercept the HTTP request that submitted the page review. The request was then replayed over and over in a very short amount of time.
Facebook’s servers ended up processing some of these requests simultaneously, essentially unaware that multiple requests had come in so close together. The result was that multiple reviews were submitted, artificially changing the pages overall ranking even though only one review actually showed up on the page for this user. The user can then delete their single review, and repeat this cycle over and over. It took Facebook approximately two months to fix this vulnerability, but in the end it was fixed and [Josip] received a nice bounty.
The Digital Ocean hack was essentially the exact same process. This time instead of hacking page reviews, [Josip] went after some free money. He found that he was able to submit the same promotional code multiple times, resulting in a hefty discount at checkout time. Digital Ocean wasted no time fixing this bug, repairing it within just ten days of the disclosure.
[Laxman] is back again with another hack related to Facebook photos. This hack revolves around the Facebook mobile application’s “sync photos” function. This feature automatically uploads every photo taken on your mobile device to your Facebook account. These photos are automatically marked as private so that only the user can see them. The user would have to manually update the privacy settings on each photo later in order to make them available to friends or the public.
[Laxman] wanted to put these privacy restrictions to the test, so he started poking around the Facebook mobile application. He found that the Facebook app would make an HTTP GET request to a specific URL in order to retrieve the synced photos. This request was performed using a top-level access token. The Facebook server checked this token before sending down the private images. It sounds secure, but [Laxman] found a fatal flaw.
The Facebook server only checked the owner of the token. It did not bother to check which Facebook application was making the request. As long as the app had the “user_photos” permission, it was able to pull down the private photos. This permission is required by many applications as it allows the apps to access the user’s public photos. This vulnerability could have allowed an attacker access to the victim’s private photos by building a malicious application and then tricking victims into installing the app.
At least, that could have been the case if Facebook wasn’t so good about fixing their vulnerabilities. [Laxman] disclosed his finding to Facebook. They had patched the vulnerability less than an hour after acknowledging the disclosure. They also found this vulnerability severe enough to warrant a $10,000 bounty payout to [Laxman]. This is in addition to the $12,500 [Laxman] received last month for a different Facebook photo-related vulnerability.
[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