I recently got a teensy 2.0 for rooting my chromecast, (which it does, roughly by appearing to chain 32 usb hubs, better description at https://fail0verflow.com/blog/2014/hubcap-chromecast-root-pt... )

They are nifty little dev boards, as you can pretend to be a variety of different devices, but the real benefit in my mind is the ease at which you can use the solder pads to build a device and connect it to usb. YOu can dump roms.

The teensy 3.0 is a 32 bit arm processor and has extra ram and flash memory, which is certainly an improvement over the 8 bit avr processor... that said the teensy 2.0 or 2.0++ might be better if you have arduino experience. Both are great boards to play around with, and I expect lots more exploits based around pretending to be various usb devices.

> "In OS X, if you attempt to adjust DNS servers via networksetup -setdnsservers, it asks for a password. (...) However, if you can go into the Network settings and manually click some buttons that the system prevents you from clicking with the keyboard, you can adjust settings without a password."

Interesting hack, somewhat relieved to see that a) it's for OS X, and b) it just leverages a poor design/trade-off between security and convenience on that platform.

I suppose this kind of stuff is a good reason to disable sudo-session caching (or whatever it's called) and demand an OTP for elevating privileges [on Linux].

Looks like windows supports OTP, but only with a dedicated server handling the authentication -- does anyone know if there's an easy way to demand OTP for UAC elevation to local admin on a stand-alone windows 8.1 workstation?

[edit: for Linux/freeBSD the libpam-oath package/toolkit can be used to enable TOTP (Time Based One-time Passwords) that are compatible with Google Authenticator -- there are a lot of tutorials on how to use it with openssh (and with the new ability to demand a set of authentication methods, how to demand eg: both ssh-key and a TOTP). With a little familiarity with pam, it's easy to set up for demanding OTP for sudo. AFAIK OS X also supports pam -- but if the gui allows the system to be backdoored, there's not much point...]

This exploit requires the currently logged in user to be a member of the 'Admin' or 'Administrators' on OSX or Windows respectively. Windows also employs an innovative "defense by frustration" strategy, where the control panel is wildly different in every damn version[1].

Still, you should be locking the screen if you leave your device unattended. The only things OTP guards against in a physical access scenario are hardware keyloggers and shoulder-surfing, neither of which were part of this attack.

[1] 😉 Just kidding, mostly.

> The only things OTP guards against in a physical access scenario are hardware keyloggers and shoulder-surfing, neither of which were part of this attack.

Well, yes. But in the case of bsd/Linux, if your user is in the sudo group/file -- requiring OTP on privilege escalation would help. While in many common configurations, when sudo is set to prompt for a password, it'll also cache that for a certain period.

If* you could make window UAC ask for an OTP (or password) rather than just accept a click on OK, it would also help in this scenario. Note that OTP for every UAC prompt would probably be quite annoying even in windows 8 -- but possibly more manageable than typing in a (secure) password.

Note that you can also force the admin password for any System Preferences GUI changes with a single click. I'm not sure whether the default for non-admin accounts is this, though.

For me under Mavericks, the Networks control panel always requires a click on the lock + then authentication to make DNS changes.

This isn't really a new concept, but previously I've seen this attack used from USB memory sticks which modified firmware. The idea being that you could use them as sort of dead drop and the target would still be able to see that it's fully functional storage device and it would still act like HID (e.g. keyboard) and execute the commands.

But since Teensy is a different beast, maybe there could be some new neat things you could do with it.

I have a Teensy firmware sitting around somewhere that immediately BSODs any Windows 7 machine. It's a good trick for nerd parties.

I'd be interested to see this, or a link to a guide someplace.

But how can you tell if you actually caused the BSOD? ;)

Stop hacking things Samy!

Can you actually move the mouse cursor pixel perfect using this? I would assume different mice, mouse acceleration and/or sensitivity settings would result in the mouse cursor being not over the button.

I remember reading about someone having built an USB business card with some low-cost ATTiny chip that opens Windows Paint and draws some picture there. The author had solved the problem of mouse acceleration by faking a graphics tablet with stylus instead of a mouse.

I can't recall the URL and Google-fu is failing me right now, though.

A bit off topic but how does one learn the skills that Samy repeatedly uses to build/hack things like this? Any guide you could recommend?

This exploit is mitigated by the fact that the keyboard/mouse normally only have user permission (not admin)

Hi totony, unfortunately with the way our systems are designed today, it's typically trivial to usurp admin later on when the user escalates privileges, even after the USB device has been removed. Examples such as injected LD_PRELOAD, adjusting PATH to MITMA sudo, etc.

In my example, we interestingly see how by default, OS X does not require additional permissions in this unique scenario. Crazy!

That's true, but this hack is a (clever) way to shortcut doing user commands (if you have access to the USB port and the logged user's unlocked screen, then it is conceivable that you should be able to do such a thing without such a tool).

The exploits that could lead to privilege escalation are a different matter (imo they should be fixed).

This hack is very relevent for personal computers, where the user account (in windows i.e.) is an admin and plugging in a USB device does not seem as dangerous as you demonstrated it is.

Is the screen resolution independent on the mouse x,y coordinates for the OK click? Looks like in the code you know how far from the top left corner the OK button is for that computer only.

Hi lukeholder, the screen resolution is "tied" to how quickly the mouse moves, so no matter which screen resolution you choose, the mouse will always move to the right location.

Ahah, that's quite true

But I was more thinking about corporate computer systems where such an exploit should only last one session (except for privilege escalation, as OP mentioned).

New so interesting.

bobevans783@gmail.com any news letters.

My hero!