Category Archives: Security Research

the art of not thinking about elephants

Posted on by
Reply

We have been quite busy here at Security Art in the last few weeks (as the blog posting frequency suggests), but I figured I would provide a quick preview of some of the elements we have been working on in terms of risk management.

Now, I suppose you have read Yoram’s earlier post about risk informed decision making, so I won’t elaborate on this for too long, nevertheless, we are often posed with the question “so how does this apply to my organization”. this usually comes form someone who did spend a lot of time and resources on the technical aspects of their network security. The answer is usually “let’s take a look at how you do your business”, which is what we usually do anyways…

Having that in mind, we set off to investigate in a few recent engagements how would some of our clients actually fare against an informed and skilled attacker that has been commissioned to break into the organization. These engagements have been prompted by a few incidents in which the organization in questions was basically left in the dark as they were basing their forensics on the tools that commercial security vendors provided them with, and nothing much more than that (remember the ever expressive “generic” detection from your AV vendor… Ever wonder what it really means?).

With that in mind, and a network to steal data from as a target we accepted the challenge. The only caveat is that the network was disconnected. For real. No Internets…

But (and there’s always a “but”), there was a voice network that went out through PSTN to provide the office with telephony connectivity. Bingo. Ever seen a complete separation of the VOIP network and the internal network? yeah, neither have I. To make a long story short, we managed to get the data in the most old fashioned way possible… we beeped it away (actually transmitted over a VOIP connection using a custom written simulated trojan that encoded the data into audible voice signals and left them as a message on one of our voice mailboxes). Done deal. (and the PoC code can be found here if you’d like to play with some of the conecpts).

Bottom line – always remember that when you think of solutions, you should not be “blinded” by what’s available out there and the accompanying marketing materials. That’s basically the “pink elephant” that vendors tell you not to think about when pitching their solutions. You usually end up thinking about it (and buying the product thinking that you’ll never see that elephant again as you just bought the best “anti-elephant” solutions…).

Always challenge the way you think of networks and processes (we did have to get the code INTO the network somehow… but that’s for another post :-) ), and ALWAYS test your assumptions and protections. You’d be surprised how easy it mat be to out-compartmentalize you just because you were boxed in to take care of just a single aspect of the security 9and yes – that even applies to CIO’s, CISO’s, etc…).

Stuxnet Analysis Report

Posted on by
2

So, after quite some time of working behind the scenes, and making an effort to focus on essence rather than buzz, the CSFI have published their official report on Stuxnet.

I have had the opportunity to assist (just a bit… work has been taking its toll) in the report writing – mostly inCSFI Logo terms of countermeasures for a threat like this, and some basic analysis.

Feel free to download the report form here:CSFI_Stuxnet_Report_V1

As well as watch the demonstration video on the CSFI website: http://csfi.us/?page=stuxnet

Kudos to all the great contributions from the CSFI-CWD (Cyber Security Forum Initiative – Cyber Warfare Division)  fellows!

The Botnet Wars – industry Q&A

Posted on by
1

I was approached recently by Bart Parys from Panda security in order to participate in an industry expert Q&A about the botnet wars (apparently he did his homework as he got quite the lineup to participate in this, guessed he can count me as a close miss :-) …).

He managed to compile a great Q&A where you can read some of the views and opinions on the current state of business at the Botnet (including exploit kits and crimeware kits) marketplace.

The full article is available at: http://malwaredatabase.net/blog/index.php/2010/10/25/the-botnet-wars-a-qa/

Enjoy!

Learning from stux, and connecting more dots in infosec

Posted on by
5

So everyone has been fully focused on Stuxnet – trying to figure out (again) what 0-days were involved, how were networks crossed, which command-and-control channels are utilized and how the systems were compromised.

Great.

I’m really hoping that the technical analysis would help us get a better grip on what kind of risk a persistent and well-funded attacker poses to a target. Nevertheless, it’s almost as we have not really learned a lot from past events – and yes, I’m talking about connecting the dots again. This time not in the sense of linking between crime and nation-state, but more in the sense of understanding that the technological attacks are usually coupled with kinetic ones – especially when talking about the more advanced activities.

For starters – stuxnet could not have gotten to where it did without the “human factor”. Someone needed to carry the infected USB thumbdribve and stick it into some system that was in the separate network. Call it a hostile agent, call it a paid off internal agent, or a 3rd party provider that was recruited to provide slightly modified equipment. It had to be done.

Now that we established that the “matrix” could not have just jumped across networks, let’s see what else can we learn from such an incident. As in learn whether this could affect us, and how. Which brings me to the second point:

We got nothing. Nothing in the sense of actual protection. And no, your claims that “our production control and monitoring network is physically disconnected from other networks” does not hold water anymore. It didn’t before either, but now it’s easier to point out how wrong you were.
Not only we got nothing, we keep listening to vendors that are too cheap/lazy to implement proper controls (from proper secure development, to taking into account that security measures would need to live on the systems), and completely lose focus when something proprietary comes along the way. When we should have been kicking vendors in the round ones and making sure that we make ourselves experts in the “proprietary” protocols thrown at us. Time to taste a bit of what we’ve been cooking.

Because stuxnet is not going to be hitting us soon. It’s going to be something much more appropriate for our culture and more targeted towards our soft spots. If delaying a nuclear development plan was on the top of the objective list when the operation that included stuxnet was planned, the counter-plans we would have to defend from would be different.
Think more in the lines of altering the way we perceive reality. Seriously. What if someone would be able to change what the newspapers printed tomorrow morning? What if they could change/affect what we see on TV? And no, this is not science fiction (check out what happened during Cast Led where Israel hacked the palestinian TV station, and how a retaliation effort was mounted and almost succeeded).
Such actions can be pulled out more easily than you’d think. The fact the everyone is focused on the pure technical aspects of defense left us pretty much open on any front that combined both human/social, physical and technical efforts.
Thinks furthermore on how the economy would hurt if the stock exchanges would be provided with false information (remember what happened when computers were involved in making decisions back in May 2010?).

And there’s more. Out travel, insurance and a lot of our financial systems are running on technology that was created back in the time when “strong authentication” means that you had to guess a really cryptic username. That’s right – not even a password is needed. And we are running billions of dollars on these things. They are protected of course – by separation. But network separation is not enough as we have just seen.

So back to connecting the dots. Remember my last rant? (you better!) – that’s exactly where the dots connect. Think critically of the business as a whole. Not in a system by system, or network by network scheme, but in the “how does this business work” scheme. How does the paper get printed at the end of the day? It may be easier to hack into the printing press facility control system than to the editor’s or the publisher’s network. Same goes for financial institutions, hospitals, airports, manufacturers, etc… Identify the weak spots in your industry, not in your office or your network.
And don’t blame me from giving the bad people ideas. They should be considered at least as smart as all of us are (smarter than me for sure :-) ). The anger that you are feeling right now reading this, is coming from the pain of sticking your neck out of the sand your head was buried in, and the uncomfortable feeling of getting a grip on reality…
Thanks for taking the red pill, and welcome to the matrix.

Now go and change things.

Pentesters and businessman are doing it wrong

Posted on by
6

Following my last post on the realistic cost of a pen-test (which as I mentioned was derived from long conversations on the topic with a couple of friends from the industry), I’d like to review one of the best presentations I have seen lately – Chris Nickerson’s Brucon talk.

I’ve had the opportunity to see this talk shape up to be what it ended up like in the week or so that we have been hanging out together. And let me tell you – it was one hell of a week. There were some reactions to the talk (no wonder – Chris was on stage) and I’d like to put things in perspective (at least mine, if you want more go talk to Chris…).

The first point which is directly derived from the talk is that we, as an industry, have been doing the wrong thing for a long time. Pentesting has become a glorified minion work, and we just kept it behind for such a long time. What the talk tries to say is open your mind, and DO YOUR HOMEWORK. Chris calls it “do work”, but I’m saying that before we do work we need to do homework. Learn. Inspect. Absorb. See beyond the technical aspects of a pentest. Understand what is the environment in which the business operates, who are the key players, partners and customers. How does the business make money? What would hurt the business the most? Only then, we can approach the pentest with a clear goal in mind (and no – it’s not getting root/shell on a box).

The second point that I’d like this talk to provoke is that we are not the only ones at fault. It’s also the customers (yeah – I said that the customer is wrong. Sue me). They have been trained to ask for technicalities. Be it a pentest, a product or even a service. Most of the times they can’t really explain the methodology behind what they are asking for and the business relevance of it. Instead of asking for a pentest for a new web application, they should be asking for a security assessment of what makes their business “tick” which may be related to the web application. Small difference in wording, HUGE difference in scope and ROI from such an engagement. And yes, this all comes back to us as we have been offering “off the shelf” pentests that have no actual relevance to the business side, and have “technofied” our services and products to fit checkboxes of some obscure regulatory compliance. We need to retrain our customers (i.e. the industry) and get ourselves trained on the business aspects as well.

This topic is just one of many more that were conceived during the security-on-steroids-week which was Source Barcelona and Brucon. I’d rather post these side-effect ideas that were generated from discussions around the talks than the actual talk contents (you should be able to download these anyway in the near future from the conference websites anyway).