D-kriptik Blog

I guess it is time to pick up with part 2 of this ramble, since some have asked. I may be playing with the concepts from the ramble, but I was actually planning on letting the ramble itself die without posting parts two and three.

-

I once shared an office with a great Windows developer for short duration a few years back. During this period, I had some free time, and I wanted to learn how buffer overflows worked from more than just a theoretical perspective. So, I started playing around with stack-based and then heap-based buffer overflows. I eventually managed (using other peoples’ shellcode) to exploit test code, then real world code (using already well-know bugs), and then I stopped. I stopped because I felt knowing the basics was enough for my purposes. The attacks were all essentially the same, regardless of the complications one had to go through to get their shellcode in well-layed-out memory and then executed. At least a couple of years before I did this, I was able to use stack-based buffer overflow exploits, although I only had a theoretical notion of why they worked.

Which is to make two points – 1. Technology is a tool, and 2. People don’t have to understand that tool in order to use it. (I guess a third point is that many exploit authors understand points one and two.) Let me harp on this a bit because, well, I say it all the time and love to say it. Technology is a means, not an end. When a technology stops being useful, when the burden of a technology outweighs its benefits as a tool, the technology will not be used. Technology for technology’s sake is just ridiculous. Which is where I think security technology, and the broader IT security arena, sometimes hit a wall. Then throw people into the mix, and the products (and processes) fail to even provide the protections intended. Perhaps the technology is so burdensome people find ways around it or just avoid it (e.g., DRM). Or perhaps it cannot be understood so they just ignore it (e.g., browser SSL warning dialogs).

Unfortunately, I have heard a few IT security people complain about people, but I think that completely misses the point. People make the world of people go around – security itself is about protecting people and their property. If your security mechanisms can’t work with actual people, then such mechanisms are often worthless by design.

Speaking of people, I sometimes hear talk about new attacks, which, when you look at the attacks, are really just the oldest of attacks, exploits of the people factor. Take phishing – this is a new variant of an old attack, as many a con has been based on just looking the part. This is where I think security people need to step back and just look at people. How do people think? How do they make decisions? Etc. And think about the old school based people attacks. How do they work? How might they work in this day and age? Etc. A little history may go a long way.

Anyway, lets involve those squishy targets, people. Technology too, perhaps, but people more so. Lets be a little classic, by ripping through some common scenarios security people throw out there.

For example, we have all thought about utilizing maintenance or cleaning staff as an attack point, as it is a common thought point in office security discussions. Think of shared office space – getting access to the phone closet is often just a mater of notifying the building management that you have someone coming from the telco that day. Or, how difficult do you think it would be to get the night cleaning staff to give you access to a particular office space? Looking the part, uh oh, it could be game over. (If nothing else, you could end up in the dumpster after the cleaning staff leaves.). Or just spoof being maintenance staff yourself.

Much simpler, gleaning sensitive information from someone you meet in a bar. Get them talking about that new project they are working on, or those lovely holes within the security at their company, or what have you. People love to talk. Throw in alcohol, and they may talk even more. (Now, just get good at picking out the truth from the bravado.) Using this approach, I sometimes wonder how hard password cracking would be. You can talk about job, family, kids, age, birthdays, background, maiden names, pets, crazy people that celebrate pet birthdays, etc. Build a relation, and gather lots of information that we openly discuss in social settings, some of which is used as secrets in other settings (remember my rant?). Perhaps then we can talk about online banking, or where we like to shop online. Perhaps we can talk about the nonsense security at work, such as me complaining about the ten passwords I have to remember at work. Oh, wait, lets talk about passwords and what I have seen, since you now know I work in computer security. I wonder if, say, I start bringing up weak passwords like a pets name, whether the person I am speaking to would reveal, through body language, at least, whether that was similar to their password. My guess, you could walk away with a good idea of some people’s passwords just through such a conversation.

And, how hard is it to get an image of someone’s ID badge? A cell phone camera in a bar might get enough detail at a close distance. You might even be able to swipe the magstripe. Even at a distance, quality cameras should be able to provide a clear enough image. From there, generating a reasonable reproduction should not be rocket science. How well are IDs checked at most organizations? I know many a shared office space that requires ID for admittance, but these IDs often receive a cursory glance by a rotating security staff.

Or go for laptops. Or hit people at hotels and conferences. I wonder how hard it would have been to steal a specific laptop at a conference like RSA. Better yet, steal it, rip its memory, and then return it. Maybe we could even just hook into the firewire port. Some blatant social engineers might be of use here – they appear to be quite effective.

Maybe you could just try walking into a large office looking like you belonged there. Will anyone notice? Could you provide a plausible reason for being there, if needed? Perhaps an outside consultant. Or, someone from IT checking up on suspicious behavior coming from a particular machine. Pop a few keyboard sniffers here, rip a few hard drives there. Not too shabby. (Here, beauty might be a drawback, as it is conspicuous. Then again, it might be an advantage, as it could reduce a security audit of that new face to little more than a friendly conversation.)

The attacks are endless, and we have all thought about many of them before. Nevertheless, I’d wager that they are still effective. And, that is what I am getting at.

It’s funny too. Extending our base programming, experience is what trains us to make the decision we most often make. When to cross the road, how best to put out a fire, what is causing that network issue, is that bug exploitable. Life moves too fast and is too complicated to create a list of options, research and rank them, and then choose the best. Instead, the best option just surfaces based on previous experience. For example, if we are used to strangers being in the office all the time, then we will probably tend to ignore strangers in the office from a security perspective. If someone is wearing a uniform, then they are most likely what that uniform implies (e.g., a security guard, maintenance staff).

So, I think about least privilege. I think about dividing privilege amongst many people, to make my attack against any one person quite difficult. But, I wonder how well this works. A distributed attack could leverage this separation. It reminds me of the classified world. Any piece of information by itself might be unclassified, but puts those pieces together and you suddenly have classified information. Use multiple targets, piece together information, and, well, there you go. From this perspective, it seems like distributed privilege may actually benefit an attacker. People are less likely to feel that their minimal access is worth anything, as other pieces of minimal access are necessary for privileged access. That flies out the window when we are actively targeting accumulation of all those pieces.

Ok, so we need logging. We need communications archived. We need actions recorded. We need logs/archives/records audited. Great, now we may know that something bad has happened. In fact, we may know exactly what that bad thing was. We may even be able to trace it back to someone, whether that someone is really the culprit or not. Those are important features. But, building a picture of what may have happened is quite different from stopping the attacks from happening in the first place. It helps the next time around, not this time. And, it only helps if we can build the right picture and learn the right things. And, you know, for all the logs/archives/records in the world, knowing that someone told me something they shouldn’t have in a bar in the LES is not likely to be traceable (to me, at least). Knowing who ripped information off that laptop, who planted that rogue wireless device, who copied your companies’ hard drives, is not necessarily going to be stored anywhere. Part of the point of using people is to find the ways to bypass security mechanisms, not fall for them.

The thing is, all our base programming and all our experience can be used against us. From the power of beauty to inaccurate perceptions of risk, it could be that security mechanisms fail to meet their objectives because, well, real people are involved. When security does not hit upon how real people act out there in the real world, it seems to miss a big chunk of risk.

This entry was posted on Wednesday, February 21st, 2007 at 11:33 pm and is filed under Security. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.