Security researchers have found a way to remotely execute code on a fax machine by sending a specially crafted document to it. So… who cares about fax? Well apparently a lot of persons are still using it in many institutions, governments and industries, including the healthcare industry, legal, banking and commercial. Bureaucracy and old procedures tend to die hard.
This is one of those exploits that deserve proper attention, for many reasons. It is well documented and is a great piece of proper old school hacking and reverse engineering. [Eyal Itkin], [Yannay Livneh] and [Yaniv Balmas] show us their process in a nicely done article that you can read here. If you are into security hacks, it’s really worth reading and also worth watching the DEFCON video. They focused their attention in a all-in-one printer/scanner/fax and the results were as good as it gets.
Our research set out to ask what would happen if an attacker, with merely a phone line at his disposal and equipped with nothing more than his target`s fax number, was able to attack an all-in-one printer by sending a malicious fax to it.
In fact, we found several critical vulnerabilities in all-in-one printers which allowed us to ‘faxploit’ the all-in-one printer and take complete control over it by sending a maliciously crafted fax.
As the researchers note, once an all-in-one printer has been compromised, it could be used to a wide array of malicious activity, from infiltrating the internal network, to stealing printed documents even to mining Bitcoin. In theory they could even produce a fax worm, replicating via the phone line.
The attack summary video is bellow, demonstrating an exploit that allows an attacker to pivot into an internal network and taking over a Windows machine using Eternal Blue NSA exploit.
Oh, the hijinks that the early days of the PC revolution allowed. Back in the days when a 20MB hard drive was a big deal and MS-DOS 3.1 ruled over every plain beige PC-clone cobbled together by enthusiasts like myself, it was great fun to “set up” someone else’s machine to do something unexpected. This generally amounted to finding an unattended PC — the rooms of the residence hall where I lived in my undergrad days were a target-rich environment in this regard — and throwing something annoying in the AUTOEXEC.BAT file. Hilarity ensued when the mark next booted the machine and was greeted with something like an inverted display or a faked hard drive formatting. Control-G was good to me too.
So it was with a sense of great nostalgia that I watched [Ben Cartwright-Cox]’s recent 35C3 talk on the anatomy and physiology of viruses from the DOS days. Fair warning to the seasoned reader that a sense of temporal distortion is inevitable while watching someone who was born almost a decade after the last meaningful release of MS-DOS discuss its inner workings with such ease. After a great overview of the DOS API elements that were key to getting anything done back then, malware or regular programs alike, he dives into his efforts to mine an archive of old DOS viruses, the payloads of most of which were harmless pranks. He built some tools to find viruses that triggered based on the system date, and used an x86 emulator he designed to test every day between 1980 and 2005. He found about 10,000 malware samples and explored their payloads, everything from well-wishes for the New Year to a bizarre foreshadowing of the Navy Seal Copypasta meme.
We found [Ben]’s talk a real treat, and it’s good to see someone from the current generation take such a deep dive into the ways many of us cut our teeth in the computing world.
Here’s a puzzler for you: If you’re phreaking something that’s not exactly a phone, are you still a phreak?
That question probably never crossed the minds of New Yorkers who were acoustically assaulted on the normally peaceful sidewalks of Manhattan over the summer by creepy sounds emanating from streetside WiFi kiosks. The auditory attacks caused quite a stir locally, leading to wild theories that Russian hackers were behind it all. Luckily, the mystery has been solved, and it turns out to have been part prank, part protest, and part performance art piece.
To understand the exploit, realize that New York City has removed thousands of traditional pay phones from city sidewalks recently and replaced them with LinkNYC kiosks, which are basically WiFi hotspots with giant HDTV displays built into them. For the price of being blitzed with advertisements while strolling by, anyone can make a free phone call using the built-in VOIP app. That was the key that allowed [Mark Thomas], an old-school phreak and die-hard fan of the pay telephones that these platforms supplanted, to launch his attack. It’s not exactly rocket surgery; [Mark] dials one of the dozens of conference call numbers he has set up with pre-recorded audio snippets. A one-minute delay lets him crank the speakerphone volume up to 11 and abscond. The recordings vary, but everyone seemed most creeped out by the familiar jingle of the [Mr. Softee] ice cream truck franchise, slowed down and distorted to make it sound like something from a fever dream.
Yes, it’s a minimal hack, and normally we don’t condone the misuse of public facilities, even ones as obnoxious as LinkNYC appears to be. But it does make a statement about the commercialization of the public square, and honestly, we’re glad to see something that at least approaches phreaking again. It’s a little less childish than blasting porn audio from a Target PA system, and far less dangerous than activating a public safety siren remotely.
[Anjul Patney] and [Qi Sun] demonstrated a fascinating new technique at NVIDIA’s GPU Technology Conference (GTC) for tricking a human into thinking a VR space is larger than it actually is. The way it works is this: when a person walks around in VR, they invariably make turns. During these turns, it’s possible to fool the person into thinking they have pivoted more or less than they have actually physically turned. With a way to manipulate perception of turns comes a way for software to gently manipulate a person’s perception of how large a virtual space is. Unlike other methods that rely on visual distortions, this method is undetectable by the viewer.
The software essentially exploits a quirk of how our eyes work. When a human’s eyes move around to look at different things, the eyeballs don’t physically glide smoothly from point to point. The eyes make frequent but unpredictable darting movements called saccades. There are a number of deeply interesting things about saccades, but the important one here is the fact that our eyes essentially go offline during saccadic movement. Our vision is perceived as a smooth and unbroken stream, but that’s a result of the brain stitching visual information into a cohesive whole, and filling in blanks without us being aware of it.
Part one of [Anjul] and [Qi]’s method is to manipulate perception of a virtual area relative to actual physical area by making a person’s pivots not a 1:1 match. In VR, it may appear one has turned more or less than one has in the real world, and in this way the software can guide the physical motion while making it appear in VR as though nothing is amiss. But by itself, this isn’t enough. To make the mismatches imperceptible, the system watches the eye for saccades and times its adjustments to occur only while they are underway. The brain ignores what happens during saccadic movement, stitches together the rest, and there you have it: a method to gently steer a human being in a way that a virtual space is larger than the physical area available.
Embedded below is a video demonstration and overview, which mentions other methods of manipulating perception of space in VR and how it avoids the pitfalls of other methods.
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.
Show of hands: how many of you have parked your car in the driveway, walked up to your house, and pressed your car’s key fob button thinking it would open the front door? We’ve probably all done it and felt a little dopey as a result, but when you think about it, it would be tremendously convenient, especially with grocery bags dangling off each arm and the mail clenched between your teeth. After all, we’re living in the future — shouldn’t your house be smart enough to know when you’re home?
Reverse engineer par excellence Samy Kamkar might think so, but given his recent experiences with cars smart enough to know when you’re standing outside them, he’d probably have some reservations. Samy dropped by the 2017 Hackaday Superconference in November to discuss the finer points of exploiting security flaws in passive car entry systems, and also sat down with our own Elliot Williams after his talk for a one-on-one interview. Samy has some interesting insights on vehicle cybersecurity, but the practical knowledge he’s gained while exploring the limits of these systems teach some powerful lessons about being a real-world reverse engineer.
There’s a natural order to the world of game console hacking: every time a manufacturer releases a new game console they work in security measures that prevent the end user from running anything but commercially released games, and in turn every hacker worth his or her salt tries to break through. The end goal, despite what the manufacturers may have you believe, is not to run “bootleg” games, but rather to enable what is colloquially referred to as “homebrew”. That is to say, enabling the novel concept of actually running software of your choice on the hardware you paid for.
At 34C3, noted console hackers [Plutoo], [Derrek], and [Naehrwert] have demonstrated unsigned code running on Nintendo’s latest and greatest and while they are keeping the actual exploit to themselves for now, they’ve promised that a platform for launching homebrew is coming shortly for those who are on firmware version 3.0.0. From the sound of it, after 9 months on the market, Switch owners will finally have complete access to the hardware they purchased.
The key to running the team’s own code was through a WebKit exploit that was already months old by the time the Switch was released. Loading up an arbitrary webpage was the tricky part, as the Switch generally uses its web browser for accessing official sources (like the online game store). But hidden away in the help menus of Tetris, the developers helpfully put a link to their website which the Switch will dutifully open if you select it. From there it’s just a matter of network redirection to get the Switch loading a webpage from your computer rather than the Internet.
But as the more security-minded of our readers may have guessed already, that just gets you into the browser’s sandbox. The team now had to figure out a way to break out and get full control of the hardware. Through a series of clever hacks the team was able to learn more about the Switch’s internal layout and operating system, slowly working their way up the ladder.
A particularly interesting hack was used to get around a part of the Switch’s OS that is designed to check which services code is allowed to access. It turns out that if code doesn’t provide this function with its own process ID (PID), the system defaults to PID 0 because the variable is not initialized. In other words, if you don’t ask the operating system which functions you have access to, you will get access to them all. This is a classic programming mistake, and a developer at Nintendo HQ is likely getting a very stern talking to right about now.
But not everything was so easy. When trying to get access to the boot loader, the team sniffed the eMMC bus and timed the commands to determine when it was checking the encryption keys. They were then able to assemble a “glitcher” which fiddled with the CPU’s power using FPGA controlled MOFSETs during this critical time in an attempt to confuse the system.
The rabbit hole is pretty deep on this one, so we’d recommend you set aside an hour to watch the entire presentation to see the long road it took to go from a browser bug to running their first complete demo. It’s as much a testament to the skill of [Plutoo], [Derrek], and [Naehrwert] as it is the lengths at which Nintendo went to keep people out.