Hacker News new | ask | show | jobs
by e12e 4195 days ago
> "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...]

2 comments

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.