Some time ago, we had to coordinate with a security firm for a scan of our environments: infrastructure, servers, applications, services, accounts, physical access – the lot. The conversation went a bit like this:
Security: “Could you get us your root password so we can test your systems for vulnerabilities?”
Me: “No.”
Security: “We need it to check for specific kernel-level threats.”
Me: “No.”
Security: “We were told we’d have your complete cooperation.”
Me: “Yep.”
Security: “But you aren’t cooperating. Are you now saying you aren’t going to help us?”
Me: “I don’t think we’re all on the same page here.”
Security: “What do you mean?”
Me: “You’re the security consultant. You’re experts. The premise is that you’re testing our systems to identify actual threats. By all means, do so. But you’ll not be getting a leg up from us by giving you instant access to anything. Additionally, while management has asked that we provide full cooperation, it’s actually a violation of company policy to give anyone any passwords to any systems – even for actual security tests. Further, even if it weren’t a violation of company policy and general good administrative practice, there simply aren’t any root passwords to give you.”
Panic in the eyes of management and a smug look on the security consultant’s face when they think that no password means anyone can log in.
Me: “I know what you’re thinking – but we use operating systems that, by default, don’t have root passwords because root accounts are gaping security threats. We can’t give you a root password because nobody can log in to the root account. We actually require each person to have their own credentials and approppriate levels of access so we can manage and audit. Nobody can log in to root. Ever.”
Security: “But if you could just go ahead and enable the root account for us so we can scan these systems for vulnerabilities…”
Me: “Sorry, but no. What you’re saying is that you want us to violate company policy by divulging passwords that don’t exist and to create a security hole so you can tell us that our systems now have a security hole that wasn’t there until you insisted that we create it. And so you can test what it is that root can do on a system? It’s root – it can do anything it wants, which is precisely why we have it disabled. I’m not going to make things less secure so we can make them more secure.”
Fast forward a few months and see a security report from another agency testing another company and find that they remarked that the primary security threat consisted of easily obtaining the root passwords to key systems by simply making a few phone calls, asking around, then using some good, old-fashioned social engineering to trick people into divulging them.
So, can you have our root passwords for your company-sanctioned security test?
Outdoor installation by Aram Bartholl is a fire-powered wifi router which can make PDFs on survival available when heated:
The boulder from the region Neuenkirchen, Niedersachsen contains a
thermoelectric generator which converts heat directly into electricity.
Visitors are invited to make a fire next to the boulder to power up the
wifi router in the stone which then reveals a large collection of PDF
survival guides. The piratebox.cc
inspired router which is NOT connected to the Internet offers the users
to download the guides and upload any content they like to the stone
database. As long as the fire produces enough heat the router will stay
switched on. The title Keepalive refers to a technical network condition
where two network endpoints send each other ‘empty’ keepalive messages
to maintain the connection.
Think about it: if you aren’t smart enough to know how to build a fire, much less one that’s sufficient to power the thing, then you’re not going to get the survival docs.
Then again, I suspect that people who might have the skills to construct the fire are also not the kind who’d have much immediate need for such docs.
the rest of me 