cyberwart

Vendors fear disclosing vulnerability details. I’m not entirely sure why that is. I believe the general idea is that if they disclose too much information attackers will quickly develop an exploit. This chain of thought doesn’t make all too much sense. Some organizations claim they can produce an exploit in as little as 2 hours by patch diffing. Personally, I’m not sure how they do it in 2 hours (depending on how they measure). I think 1-2 days is certainly enough time to triage, reverse, target, and successfully DoS a vuln in an average complexity bundled series of updates on a MS Patch Tuesday. The exploit can then be developed somewhere between 5 minutes and 6 months after that. So by holding out on critical details the vendors are only gaining a day or two.

Not gaining much isn’t a problem unless they’re losing something, and I think they are. Foremost, by not disclosing vuln details we’re lowering the dialog. Rather than articulating a concise problem in software the discussion becomes about nebulous memory corruption  and an almost arbitrary severity rating. For security professionals, the discussion needs to be more than a Cliff Note summary. Until that happens software developers are going to continue to misundertand code defects and organizations will misinterpret risk.

Second, signature based IDS/IPS is crap. I don’t think it has to be crap but the basic process is flawed. Signature writers far too often use a particular exploit as a basis for their signature. Since the signature identifies a particular exploit, it doesn’t (in general) accurately identify variant exploits for the same vulnerability. Some heuristic systems strive to identify the truly generic exploit by things like NOP sleds, shellcode, or obscenely large data fields but they’re plagued by problems. In my opinion, if the discussion transitions from exploits to vulnerability signature based IDS will do much better. All exploits for the same bug have to share some level of similarity. That similarity is the thing that makes the exploit. If we look at a recent vulnerability (MS09-013) we see the Snort Rule:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:”WEB-CLIENT WinHTTP integer wrap buffer overflow attempt”; sid:15462; gid:3; rev:1; classtype:misc-attack; reference:cve,2009-0086; reference:url,www.microsoft.com/technet/security/bulletin/MS09-013.mspx; metadata: engine shared, soid 3|15462, service http, policy balanced-ips drop, policy security-ips drop;)

As you can see, the rule has little to do with the actual vulnerability — a hex encoded integer less than 0 in as the chunk size in an HTTP message. There are numerous possibily difficulties with detecting the actual vulnerability. At the very least, it requires a basic regular expression and at worst you’re moving toward deep packet inspection. To me though, it makes much more sense to start talking about the difficulties of properly detecting the vulnerability rather than doing complex log analysis in hopes of tieing poorly contructed rules into something useful.

While the IDS industry is writing the signatures I don’t think the problem currently rests with them. No single organization can be expected to reasonably maintain expertise around the entire security field. The IDS orgs are given poor vulnerability descriptions so they write poor signatures. Because we have poor signatures, one off exploits are missed or (more likely in the above case) the rule is so generic it’s disabled or ignored. This results in failed security monitoring and possibly successful attacks.

It’s not often that you find cool new things in highly technical computer security books. Usuaully they compile relevant information, tie it together, and make some marginal improvements. I’ve been working through the “Mac Hacker’s Handbook” and have been quite surprised with just how good it is. The authors are first rate so I’m not surprised that it’s good, but they demonstrate techniques to exploit a Mac that still work and real-world exploits that are just a few months old.

A year or so ago, I skipped Dowd’s talk on exploiting IE because IE itself wasn’t of particular interest to me. Not to linger on that too much, but at the time IE exploits were popping all the time. They used heap sprays and were 25-50% reliable in my experience… I was using phishing attacks that were 40+ percent reliable so it wasn’t my thing. I was more likely to get lucky with phishing and if I needed an exploit I could just wait until next week. What I missed was truly unfortunate as the talk walked through 10 years of exploiting the heap and went into working techniques (at the time). I’m not a Mac hacker yet, but clear working code presented in “The Mac Hacker’s Handbook” is useful for any security professional and should be a must read for exploits guys.

I hope to get a more complete review down the road, but I’m really digging through the book so I can speak more thoughtfully on the topic. Until then, I’d still recommend the purchase.

As to the title of this post, it appears generic heap overwrites are still workable on the mac.

Python’s ctypes is great for loading DLLs and other code into python. Recently I’ve been trying to use python to grab into the internals of an application rather than a library. This has presented a few hurdles. To get around it you can build the static libraries into a shared libraries by running:

gcc -shared *.o -o whatever.so

then you can load the whatever.so with the regular:
lib = ctypes.CDLL(“./whatever.so”)

Microsoft released their early press release for May’s Patch Tuesday. It’s available here: http://www.microsoft.com/technet/security/bulletin/ms09-may.mspx

The only item currently listed is the PowerPoint fix for the exploit that’s been around for over a month.

I’m trying to get into iPhone development and I’m also going though the Mac Hacker’s Handbook. If you start looking at Objective-C, the superset of C that Apple uses, you’ll notice the @ symbol. It warped my mind to see new symbols in C, but here’s some basic info:

The @ character isn’t used in C or C++ identifiers, so it’s used to introduce Objective-C language keywords in a way that won’t conflict with the other languages’ keywords. This enables the “Objective” part of the language to freely intermix with the C or C++ part.

Thus with very few exceptions, any time you see @ in some Objective-C code, you’re looking at Objective-C constructs rather than C or C++ constructs.

The major exceptions are id, Class, nil, and Nil, which are generally treated as language keywords even though they may also have a typedef or #define behind them. For example, the compiler actually does treat id specially in terms of the pointer type conversion rules it applies to declarations, as well as to the decision of whether to generate GC write barriers.

Other exceptions are in, out, inout, oneway, byref, and bycopy; these are used as storage class annotations on method parameter and return types to make Distributed Objects more efficient. (They become part of the method signature available from the runtime, which DO can look at to determine how to best serialize a transaction.) There are also the attributes within @property declarations, copy, retain, assign, readonly, readwrite, nonatomic, getter, and setter; those are only valid within the attribute section of a @property declaration.

from: http://stackoverflow.com/questions/25749/what-does-the-symbol-represent-in-objective-c

Also you should note that the dash ‘-’ character indicates a class method.

From the BBC:

the US Air Force’s chief information officer Lt Gen William Shelton, said the US relies heavily on industry efforts to respond to cyber threats which, he says, “does not keep pace with the threat”

I find that statement very odd. I haven’t seen the document sited but in my experience the government itself lags behind defense contractors who lag behind the commercial industry. Therefore, I’m unsure of the practical solution for the government to keep pace. Thoughts?

NOTE: the “lag” operator above is a generalization. The government has some of the most technical people, as do defense contractors, and industry has some duds. My generalization is only based on personal experience and more relates to government process and efficiency negatively impacting the overall technical culture.

Everyone in the DC area is going Cloud crazy. The government and industry believes they can throw whatever problem they have into the cloud and everything will be better. Fortunately, the security folks mentioned that throwing all your data and code into an unknown whole and hoping for the best might not be the best idea. So of course, the next wave of security guys came in and are “securing the cloud”.

You can’t secure the cloud.

Why not? Because the reason everyone loves “cloud computing” is that it’s a nebulous concept that claims it will solve all problems. Therefore, it has undefined functional requirements and use cases. You can’t build real security into something that doesn’t have a definite form. As it is, every party involved in building cloud systems blames the other guy.

The security engineers yell at the developers saying “of course you can’t secure a system if you don’t write secure code”.

The developers respond “why would I secure user interfaces to my application when I accept and trust the user”. This sounds a little crazy but realistically if you’re running Word you don’t sandbox it from Powerpoint. Having written high throughput code I’ve seen a single if statement have large performance impacts. So writing your code to trust nothing will severely diminish performance and increase development time.

To emphasize the security risks, Immunity (in a very private release and very public video demo) released their Cloudburst exploit to pop out from a guest to the host. This exploits represents huge risks to many organizations that use VMware extensively. In many cases VMware is the host, guest, network, firewall, switch, and change management system all in one so an exploit that traverses from an untrusted guest to management networks and/or restricted assets is huge.

I like scientific computing, parallel processing, and virtualization. So the components that make up cloud computing are great. But realistic solutions aren’t ubiquitous. If organizations want to secure cloud systems, they need to restrict cloud environments to security groups and functional requiments. Trusted scientific processes aren’t meant to run next to malware. Likewise, disk bound processes aren’t generally well suited to the same environments as cpu bound processes. As with everything else in the world, cloud computing needs a realistic engineering solution.

As an analogy, the military doesn’t secure a mountain pass from artilary the same way it secures a city block from insurgents. Similarly, a Hadoop cloud for internal use by a search engine has entirely different security objectives of a public cloud meant to run web services. The hadoop cluster requires mainly perimeter security, code review, and sanity checks, the latter requires a complicated infrastructure to ensure your clients aren’t stealing data, running a bot, or performing other nefarious actions.

Wrapping this up, you can’t secure the generic cloud. You can of course secure particular cloud implementations given that functional requirements and use cases are enumerated and feasible. The root problem may be that the technologies have yet to adequately mature. Therefore the term cloud has different meanings to different individuals. What is likely and necessary to occur is that the cloud computing industry will increase specialization so that one can build security recommendations for classes of cloud systems. Specialization will likely cut into projected profit margins in the short term. But as industries turn to cloud implementations they’re going to require better security around their data — which represents real dollars to most organizations, and will require real security.

My typing skills leave much to be desired. I remeber the first time I made a typo in domain name and it didn’t give me a “Address Not Found”. Instead, I was forwarded to what appeared to be a Yahoo portal. I wasn’t pleased when I discovered this. I felt that it was wrong for my ISP to break protocol and send me to advertisements. Additionally, security experts like Dan Kaminsky and others have rightfully sounded the alarm. Real world attacks have taken place, and I’m still uneasy with the technology. So what’s with the title of this post?

Botnets are now using dynamic domain generation schemes. Researchers can sometimes register a few domains to gain control of parts of a botnet. But researchers and AV can’t register all the possibilities. Typosquatting technologies such as Paxfire could be leveraged to get between the victims and the C&C. Such a tool could enable PC owners to be notified of an infection and give statistical information on the size and location of the botnet. Other fun could of course be had but before broatching hijacking and/or DPI I’ll see how this is received. Worst case, ISPs could resell an opt-in service for a small fee (or even free) to maintain a list of all botnet domains and protect their users.