11–20 of 26 posts
But since Teensy is a different beast, maybe there could be some new neat things you could do with it.
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!
> "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 betwe…
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.
> "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 betwe…
> "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 betwe…
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 h…
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.
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 can't recall the URL and Google-fu is failing me right now, though.
Earlier quoted context omitted.
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!
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.
This exploit is mitigated by the fact that the keyboard/mouse normally only have user permission (not admin)
http://xkcd.com/1200/
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).