4 ms·

Oh damn, I am dying to know how they did it. They talked about gawker having outdated kernels. I can understand a compromised staff password, a sql injection, s

by vinhboy 16y ago

Oh damn, I am dying to know how they did it. They talked about gawker having outdated kernels. I can understand a compromised staff password, a sql injection, some other weak link in the chain. But a kernel exploit would be crazy. For complete security we have to worry about our kernels too??

saurik 16y ago
Typically, daemons installed on servers are all running as isolated user accounts. So, if you find a bug in someone's database server, or website, or e-mail daemon, or whatever, most often you only get access to that one user account, which requires you to hope that there is some path from where you are to where you want to be (maybe the password to the database can be gotten from the website) However, if there is also a local user-to-root exploit available (which is what 99% of kernel exploits are about), then having the ability to execute code as any user now gives you complete access to the entire box: the user security model is totally worthless if you have a kernel sufficiently flawed that it cannot enforce it.
trotsky 16y ago
Nine times out of ten with a targeted compromise like this the trail will lead back to a successful spear phishing campaign. Blanket the staff with a malicious pdf, an exclusive first look at a new popular executable, or an older browser exploit. Once you've compromised a client machine (essentially inevitable as long as you have a few dozen or more staff), use that to discover CMS/FTP/SSH credentials, or impersonate the user to request new ones. Once you have a user login on the server, as noted the old kernel reference was undoubtedly connected to a privilege escalation. Directly exploiting remote flaws in an OS on a major website is usually going to be pretty hard - they focus security efforts there and if there were any existing flaws they'd likely already have been compromised by them (and since fixed it)

by vinhboy 16y ago

saurik 16y ago

Typically, daemons installed on servers are all running as isolated user accounts. So, if you find a bug in someone's database server, or website, or e-mail daemon, or whatever, most often you only get access to that one user account, which requires you to hope that there is some path from where you are to where you want to be (maybe the password to the database can be gotten from the website) However, if there is also a local user-to-root exploit available (which is what 99% of kernel exploits are about), then having the ability to execute code as any user now gives you complete access to the entire box: the user security model is totally worthless if you have a kernel sufficiently flawed that it cannot enforce it.

trotsky 16y ago

Nine times out of ten with a targeted compromise like this the trail will lead back to a successful spear phishing campaign. Blanket the staff with a malicious pdf, an exclusive first look at a new popular executable, or an older browser exploit. Once you've compromised a client machine (essentially inevitable as long as you have a few dozen or more staff), use that to discover CMS/FTP/SSH credentials, or impersonate the user to request new ones. Once you have a user login on the server, as noted the old kernel reference was undoubtedly connected to a privilege escalation. Directly exploiting remote flaws in an OS on a major website is usually going to be pretty hard - they focus security efforts there and if there were any existing flaws they'd likely already have been compromised by them (and since fixed it)