There are a huge number of products available in the modern world that come with network connectivity now, when perhaps they might be better off with out it. Kitchen appliances like refrigerators are the classic example, but things like lightbulbs, toys, thermostats, and door locks can all be found with some sort of Internet connectivity. Perhaps for the worse, too, if the security of these devices isn’t taken seriously, as they can all be vectors for attacks. Even things like this Rigol oscilloscope and its companion web app can be targets.
The vulnerability for this oscilloscope starts with an analysis of the firmware, which includes the web control application. To prevent potentially bricking a real oscilloscope, this firmware was emulated using QEMU. The vulnerability exists in the part of the code which involves changing the password, where an attacker can bypass authentication by injecting commands into the password fields. In the end, the only thing that needs to be done to gain arbitrary code execution on the oscilloscope is to issue a
curl command directed at the oscilloscope.
In the end, [Maunel] suggests not connecting this oscilloscope to the Internet at all. He has informed the producer about it but as of this writing there has not been a resolution. It does, however, demonstrate the vulnerabilities that can be present in network-connected devices where the developers of the software haven’t gone to the lengths required to properly secure them for use with the modern Internet. Even things not connected to a traditional Internet connection can be targets for attacks.
With millions of phishing attempts happening daily, we’ve probably all had our fair share of coming across one. For the trained or naturally suspicious eye, it’s usually easy to spot them — maybe get a good chuckle out of the ridiculously bad ones along the way — and simply ignore them. Unfortunately, they wouldn’t exist if they weren’t successful enough in the big picture, so it might be a good idea to inform the targeted service about the attempt, in hopes they will notify users to act with caution. And then there’s [Christian Haschek], who decided to have some fun and trying to render the phished data useless by simply flooding it with garbage.
After his wife received a text message from “their bank”, [Christian] took a closer look at the URL it was pointing to, and found your typical copy of the real login form at a slightly misspelled address. As the usual goal is to steal the victim’s credentials, he simply wrote a shell script that sends random generated account numbers and PINs for all eternity via cURL, potentially lowering any value the attackers could get from their attempt.
As the form fields limit the input length of the account number and PIN, he eventually wondered if the server side will do the same, or whether it would crash if longer data is sent to it. Sadly, he’ll never know, because after he modified the script, the site itself returned a 404 and had disappeared.
In the quest against phishing attacks, this should count as a success, but as [Christian] seemed to enjoy himself, he yearned for more and decided to take a look at a similar attempt he saw mentioned earlier on Reddit. Despite targeting the same bank, the server-side implementation was more sophisticated, hinting at a different attack, and he definitely got his money worth this time — but we don’t want to give it all away here.
Rest assured, [Christian Haschek] continues the good fight, whether by annoying attackers as he did with ZIP-bombing random WordPress login attempts or battling child pornography with a Raspberry Pi cluster. Well, unless he’s busy hunting down an unidentified device hooked up in his own network.
(Banner image by Tumisu)
In it, the user is challenged in their knowledge of how to use the ubiquitous
curl in a variety of different ways. Perhaps this doesn’t sound terribly daunting, especially if your knowledge of curl is limited to knowing it is a command-line tool to fetch something from a web server. But curl has a staggering number of features. The man page is over 4500 lines in length. The software’s main site offers a (free) 250+ page guide on how to use curl and libcurl. Reflecting on this is exactly what led [Ben] to create his challenge.
It’s a wonderful piece of work, but things get really interesting once [Ben] starts talking about the infrastructure behind it all. At its core the game works by giving the user a problem and a virtual machine, and catching outgoing HTTP calls to see whether they look correct. If the outgoing HTTP call is the right solution for the problem, terminate the current VM and start up the next one with the next problem. He’s put a lot of work into getting suitable VMs up and running quickly, securely, and properly isolated. The code can be found on the project’s GitHub repository for those who want a closer look.
But that’s not all. [Ben] says that in the past he’s had a bad habit of presenting interactive features in his blog posts that can’t keep up with sudden demand. So to address that, the system auto-scales as needed with a small Linux cluster; small brick-sized PCs are started and shut down automatically to meet demand. Hey, the only thing cooler than a functioning cluster is a cluster doing an actual job, like this one that detects NSFW images.
[Ryan Flowers] writes in with a clever little hack that can allow you to hide data where nobody is going to go looking for it. By exploiting the fact that a web server will generally log all HTTP requests whether or not it’s valid, he shows how you can covertly send a message by asking the server for a carefully crafted fictitious URL.
We aren’t talking about requesting “yousuck.txt” from the server that hosts your least favorite website, either. As [Ryan] demonstrates, you can compress a text file, encode it with
uuencode, and then send it line by line to the destination server with
curl. He shows how the process, which he calls “CurlyTP” can be done manually on the command line, but it would be a simple matter of wrapping it up in a Bash script.
To get the message back, you just do the opposite. Use
grep to find the lines in the log file that contain the encoded data, and then put them through
uudecode to get the original text back. Finding the appropriate lines in the log file is made easier by prepending a prearranged keyword to the beginning of the URL requests. The keyword can be changed for each message to make things easier to keep track of.
If you’re still wondering why anyone would go through the trouble to do this, [Ryan] provides an excellent example: a covert “dead drop” where people could leave messages they’d rather not send through the usual channels. As long as the sender used a service to mask their true IP address, they could anonymously deliver messages onto the server without having to use any special software or protocol they might not have access to. Even the most restrictive firewalls and security measures aren’t likely to be scanning URLs for compressed text files.
We’ve seen web-based dead drops done with Python in the past, and even purpose built “PirateBoxes” that allow people to covertly exchange files, but we like how this method doesn’t require any special configuration on the server side. You should check your server logs, somebody might be trying to tell you something.
Although many people think of Linux-based operating systems as graphical, really that GUI is just another application running over the bare operating system. Power users, remote administrators, and people running underpowered computers like a Raspberry Pi have a tendency to do more with command line tools. [Igor] did a FOSDEM19 presentation you can see below about how he’s providing web-like services to the command line using web servers and curl as a client.
This is subtly different from just accessing an ordinary web server via curl. The output is meant for display in the terminal. Of course, you could also hit them with a web browser, if you wanted — at least, for some of them. [Igor’s] tools include a weather reporter, a QR code encoder, information and graphs for currency and cybercurrency rates, and an online help system for programmers.
Continue reading “Command Line Utilities… In The Cloud?”
[POTUSCamacho] listens to his @public_timeline rss feed. In part one of his project, he describes creating a bash script in which he uses cURL get his private feed, sed to clean it and eSpeak to output a WAV file. In parts two and three, he goes on to discuss how he created an audio stream (currently down, opens in a new window) of @public_timeline and how he plans on tweeting vocally.
BadPoetry WordPress 2.7 has just been released and features a complete interface overhaul. Hack a Day runs on WordPress MU hosted by WordPress.com, so we got this update last week. We run standard WordPress.org on all of our personal blogs though. We recommend it because it’s free, has a massive userbase, and if you host it yourself, you can do whatever you want with it.
To make the upgrade process as simple as possible (and for the sheer rush of ‘rm -rf’), we use a one line command.
$ curl http://wordpress.org/latest.zip -o "wp.zip" && unzip wp.zip && rm -rf ./wordpress/wp-content/ && cp -r ./wordpress/* ~/www/
curl downloads the latest version from wordpress. unzip unpacks all of the files into a directory called ‘wordpress’. rm -rf removes everything in the ‘wp-content’ directory. Otherwise, you will overwrite your images, themes, and plugins. cp -r copies everything to your http document root, overwriting the previous install.
Naturally, you should back up your current install and database beforehand. We tend to use the one-liner with reckless abandon. If you’re wondering about the terseness, it was designed to fit inside the 140 character limit of Twitter.
[Thanks, Chris Finke]