Unexpected Betrayal From Your Right Hand Mouse

Some people really enjoy the kind of computer mouse that would not be entirely out of place in a F-16 cockpit. The kind of mouse that can launch a browser with the gentle shifting of one of its thirty-eight buttons ever so slightly to the left and open their garage door with a shifting to the right of that same button. However, can this power be used for evil, and not just frustrating guest users of their computer?

We’ve heard of the trusted peripheral being repurposed for nefarious uses before. Sometimes they’ve even been modified for more benign purposes. All of these have a common trend. The mouse itself must be physically modified to add the vulnerability or feature. However, the advanced mice with macro support can be used as is for a vulnerability.

The example in this case is a Logitech G-series gaming mouse. The mouse has the ability to store multiple personal settings in its memory. That way someone could take the mouse to multiple computers and still have all their settings available. [Stefan Keisse] discovered that the 100 command limit on the macros for each button are more than enough to get a full reverse shell on the target computer.

Considering how frustratingly easy it can be to accidentally press an auxiliary button on these mice, all an attacker would need to do is wait after delivering the sabotaged mouse. Video of the exploit after the break.

Continue reading “Unexpected Betrayal From Your Right Hand Mouse”

Microsoft Live Account Credentials Leaking From Windows 8 And Above

Discovered in 1997 by Aaron Spangler and never fixed, the WinNT/Win95 Automatic Authentication Vulnerability (IE Bug #4) is certainly an excellent vintage. In Windows 8 and 10, the same bug has now been found to potentially leak the user’s Microsoft Live account login and (hashed) password information, which is also used to access OneDrive, Outlook, Office, Mobile, Bing, Xbox Live, MSN and Skype (if used with a Microsoft account).

Continue reading “Microsoft Live Account Credentials Leaking From Windows 8 And Above”

Stegosploit: Owned by a JPG

We’re primarily hardware hackers, but every once in a while we see a software hack that really tickles our fancy. One such hack is Stegosploit, by [Saumil Shah]. Stegosploit isn’t really an exploit, so much as it’s a means of delivering exploits to browsers by hiding them in pictures. Why? Because nobody expects a picture to contain executable code.

stegosploit_diagram[Saumil] starts off by packing the real exploit code into an image. He demonstrates that you can do this directly, by encoding characters of the code in the color values of the pixels. But that would look strange, so instead the code is delivered steganographically by spreading the bits of the characters that represent the code among the least-significant bits in either a JPG or PNG image.

OK, so the exploit code is hidden in the picture. Reading it out is actually simple: the HTML canvas element has a built-in getImageData() method that reads the (numeric) value of a given pixel. A little bit of JavaScript later, and you’ve reconstructed your code from the image. This is sneaky because there’s exploit code that’s now runnable in your browser, but your anti-virus software won’t see it because it wasn’t ever written out — it was in the image and reconstructed on the fly by innocuous-looking “normal” JavaScript.

232115_1366x1792_scrotAnd here’s the coup de grâce. By packing HTML and JavaScript into the header data of the image file, you can end up with a valid image (JPG or PNG) file that will nonetheless be interpreted as HTML by a browser. The simplest way to do this is send your file myPic.JPG from the webserver with a Content-Type: text/html HTTP header. Even though it’s a totally valid image file, with an image file extension, a browser will treat it as HTML, render the page and run the script it finds within.

The end result of this is a single image that the browser thinks is HTML with JavaScript inside it, which displays the image in question and at the same time unpacks the exploit code that’s hidden in the shadows of the image and runs that as well. You’re owned by a single image file! And everything looks normal.

We like this because it combines two sweet tricks in one hack: steganography to deliver the exploit code, and “polyglot” files that can be read two ways, depending on which application is doing the reading. A quick tag-search of Hackaday will dig up a lot on steganography here, but polyglot files are a relatively new hack.

[Ange Ablertini] is the undisputed master of packing one file type inside another, so if you want to get into the nitty-gritty of [Ange]’s style of “polyglot” file types, watch his talk on “Funky File Formats” (YouTube). You’ll never look at a ZIP file the same again.

Sweet hack, right? Who says the hardware guys get to have all the fun?

Better TV Via Hacking

Smart TVs are just dumb TVs with a computer and a network connection, right? In a variation of rule 34, if it has a computer in it, someone will hack it. When [smarttvhacker] bought a Sony 48 inch smart TV, he noticed all the software licenses listed in the manual and realized that was a big leg up into hacking the TV.

We don’t have a comparable Sony model, but [smarttvhacker’s] post is a veritable travel log of his journey from TV viewer to TV ruler. By analyzing everything from network port scans to a dump of a firmware upgrade, he wound up being able to install a telnet server.

Continue reading “Better TV Via Hacking”

Exposing Private Facebook Photos with a Malicious App

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

Hacking Oklahoma State University’s Student ID Cards

[Sam] took an information security class at Oklahoma State University back in 2013. For his final project, he and a team of other students had to find a security vulnerability and then devise a theoretical plan to exploit it. [Sam’s] team decided to focus on the school’s ID cards. OSU’s ID cards are very similar to credit cards. They are the same size and shape, they have data encoded on a magnetic strip, and they have a 16 digit identification number. These cards were used for several different purposes. Examples include photo ID, physical access to some areas on campus, charges to an online account, and more.

[Sam] and his team analyzed over 100 different cards in order to get a good sample. They found that all cards started with same eight digits. This is similar to the issuer identification number found in the first six digits of a credit card number. Th analysis also showed that there were only three combinations used for the next two digits. Those were either 05, 06, or 11. With that in mind, the total possible number of combinations for card numbers was mathematically calculated to be three million.

OSU also had a URL printed on the back of each card. This website had a simple form with a single field. The user can enter in a 16 digit card number and the system would tell the user if that card was valid. The page would also tell you if the card holder was an employee, a student, or if there were any other special flags on the card. We’re not sure why every student would need access to this website, but the fact is that the URL was printed right on the back of the card. The website also had no limit to how many times a query could be made. The only hint that the university was aware of possible security implications was the disclaimer on the site. The disclaimer mentioned that usage of the tool was “logged and tracked”.

The next step was to purchase a magnetic card reader and writer. The team decoded all of the cards and analyzed the data. They found that each card held an expiration date, but the expiration date was identical for every single card.  The team used the reader/writer to copy the data from [Sam’s] card and modify the name. They then wrote the data back onto a new, blank magnetic card. This card had no printing or markings on it. [Sam] took the card and was able to use it to purchase items from a store on campus. He noticed that the register reached back to a server somewhere to verify his real name. It didn’t do any checks against the name written onto the magstripe. Even still, the cashier still accepted a card with no official markings.

The final step was to write a node.js script to scrape the number verification website. With just 15 lines of code, the script will run through all possible combinations of numbers in a random sequence and log the result. The website can handle between three and five requests per second, which means that brute forcing all possible combinations can be completed in roughly two days. These harvested numbers can then be written onto blank cards and potentially used to purchase goods on another student’s account.

[Sam’s] team offers several recommendations to improve the security of this system. One idea is to include a second form of authorization, such as a PIN. The PIN wouldn’t be stored on the card, and therefore can’t be copied in this manner. The primary recommendation was to take down the verification website. So far OSU has responded by taking the website offline, but no other changes have been made.

Hacking the Nike+ Fuelband

[Simone] was trying to reverse-engineer the Bluetooth protocol of his Nike+ Fuelband and made some surprising discoveries. [Simone] found that the authentication system of the Fuelband can be easily bypassed and discovered that some low-level functions (such as arbitrarily reading and writing to memory) are completely exposed to the end user or anyone else who hacks past the authentication process.

[Simone] started with the official Nike app for the Fuelband. He converted the APK to a JAR and then used JD-Gui to read the Java source code of the app. After reading through the source, he discovered that the authentication method was completely ineffective. The authenticator requires the connecting device to know both a pin code and a nonce, but in reality the authentication algorithm just checks for a hard-coded token of 0xff 0xff 0xff 0xff 0xff 0xff rendering the whole authentication process ineffective.

After he authenticated with the Fuelband, [Simone] started trying various commands to see what he could control over the Bluetooth interface. He discovered that he could send the device into bootloader mode, configure the RTC, and even read/write the first 65k of memory over the Bluetooth interface–not something you typically want to expose, especially with a broken authentication mechanism. If you want to try the exploit yourself, [Simone] wrote an Android app which he posted up on GitHub.