Hackaday Prize Entry: Minimalist HTTP

July 23, 2017 by Brian Benchoff 27 Comments

For his Hackaday Prize entry, [Yann] is building something that isn’t hardware, but it’s still fascinating. He’s come up with a minimalist HTTP compliant server written in C. It’s small, it’s portable, and in some cases, it will be a bunch better solution than throwing a full Linux stack into a single sensor.

This micro HTTP server has two core modules, each with a specific purpose. The file server does exactly what it says on the tin, but the HTTaP is a bit more interesting. HTTaP is a protocol first published in 2014 that is designed to be a simpler alternative to WebSockets.

[Yann] has been experimenting with HTTaP, and the benefits are obvious. You don’t need Apache to make use of it, HTTaP can work directly with an HTML/JavaScript page, and using only GET and POST messages, you can control hardware and logic circuits.

As this is a minimalist HTTP server, the security is dubious at best. That’s not the point, though. This is just a tool designed for use in a lab or controlled environments with an air gap. Safety, scheduling, encryption, and authentication are not part of HTTaP or this micro HTTP server.

Distributed, Open Source Chat With Vector And Matrix

July 3, 2016 by Eric Evenchick 44 Comments

When it comes to chat, you have many choices. Facebook Messenger, Google Talk, Whatsapp, Kik, and Slack are all viable options. However, all of these choices are proprietary, and require you to use servers that you can’t run yourself. They’re highly centralized, closed source tools.

In the open source world, IRC has been the go to solution for chat for many years, and for good reason. Anyone can run a server, there’s many clients, and it’s built on open standards. But IRC comes from a pre-mobile world, and relies on clients to maintain persistent connections to the server. It’s not the best experience on a phone.

Matrix.org and Vector.im aim to be a modern solution to chat. Matrix is a standard for passing messages around, and Vector is a chat solution built on top, with support for iOS, Android, and your browser.

What makes this solution different is the concept of Homeservers. A Homeserver manages messages for users, recording them when they are received and providing them to users when they connect. Homeservers also “federate” to communicate amongst each other. This means anyone can run a Homeserver and connect it to the greater network of Matrix, providing a distributed approach to building a chat network.

Under the hood, Matrix is just HTTP. You send messages into the network with POST requests, and receive new messages by polling with GET requests. This means no persistent connections are required, which is perfect for mobile and low power devices.

On the topic of devices, Matrix is designed for general purpose messaging, not just chat. It should be pretty simple to connect hardware up to Matrix, which would provide a simple way to get data in and out of connected devices. Since it’s all HTTP, a device based on the ESP8266 could hop into your chat room with relative ease.

Matrix and Vector are very much in beta, but are definitely usable and worth a try. To get started, you can create an account on Vector.im and start chatting. We’re awaiting some of the features in the works, including end-to-end encryption, and hope to see some future hacks talking to the Matrix infrastructure.

Alarm Notifies The Office When The Coffee Is Ready

July 24, 2015 by Rick Osgood 12 Comments

[Stian] thought it would be nice if his coworkers could be electronically notified when the latest batch of coffee is ready. He ended up building an inexpensive coffee alarm system to do exactly that. When the coffee is done, the brewer can press a giant button to notify the rest of the office that it’s time for a cuppa joe.

[Stian’s] first project requirement was to activate the system using a big physical button. He chose a button from Sparkfun, although he ended up modifying it to better suit his needs. The original button came with a single LED built-in. This wasn’t enough for [Stian], so he added two more LEDs. All three LEDs are driven by a ULN2003A NPN transistor array. Now he can flash them in sequence to make a simple animation.

This momentary push button supplies power to a ESP8266 microcontroller using a soft latch power switch. When the momentary switch is pressed, it supplies power to the latch. The latch then powers up the main circuit and continues supplying power even when the push button is released. The reason for this power trickery is to conserve power from the 18650 li-on battery.

The core functionality of the alarm uses a combination of physical hardware and two cloud-based services. The ESP8266 was chosen because it includes a built-in WiFi chip and it only costs five dollars. The microcontroller is configured to connect to the WiFi network with the push of a button. The device also monitors the giant alarm button.

When the button is pressed, it sends an HTTP request to a custom clojure app running on a cloud service called Heroku. The clojure app then stores brewing information in a database and sends a notification to the Slack cloud service. Slack is a sort of project management app that allows multiple users to work on projects and communicate easier over the internet. [Stian] has tapped into it in order to send the actual text notification to his coworkers to let them know that the coffee is ready. Be sure to watch the demo video below. Continue reading “Alarm Notifies The Office When The Coffee Is Ready” →

Race Conditions Exploit Granted Free Money On Web Services

April 29, 2015 by Rick Osgood 10 Comments

[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.

Exposing Private Facebook Photos With A Malicious App

March 20, 2015 by Rick Osgood 21 Comments

[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.

Stumbling Upon An Uber Vulnerability

February 27, 2015 by Rick Osgood 30 Comments

[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.

Data Logging Directly To Google Docs (Google Drive)

May 31, 2012 by Mike Szczys 15 Comments

[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)” →