You use 0days for serious tests to see how a mature organization's security holds and teams react in a real situation. When you get to that level, simulated breaks down so many ways, you're basically doing a tabletop, which does not give you an accurate picture.

· · tweetoot · 1 · 0 · 0

@sj I don't know how people actually do these simulations, but having a payload that would be on a time delay and a cover story of why an admin had to SSH into that machine/device seems like it would help this situation.

@adam In these cases of network device 0days, you also have the issue of not having any supported method of running a payload, so you first need an 0day to break out of the management interface, or you have to coordinate some kind of outage, disassemble the device, pull out the drive, figure out how to decrypt if necessary, reverse how it runs stuff, drop something on the hard drive, test it,... and at that point you have almost done the work to find the 0day in the first place.

@adam honestly this hysteria about 0days is exhausting. People act like they're weapons grade uranium, but they're more like water. Maybe they never saw any, but if you're in the business you know you can spend a little time digging anywhere and probably half the time hit something. I'm sure the world would like to know all your watering holes. No, you have no obligation to tell them.

@sj Yeah, simulating 0-days on locked down devices is extra tough, be the routers or kiosks or what have you.

I find it interesting that one of the big concerns with security testing in general, but especially with exploiting production systems, is the potential downtime. If that's the case, then we've already uncovered what is probably a critical DoS vulnerable: that one server/device/software package can take down everything. If downtime is critical, be more resilient.

Sign in to participate in the conversation
Scriptjunkie Social

scriptjunkie's server