Posts Tagged signature

The “X” Files


It’s been a little while since we last posted so I wanted to get a blog out there so everybody knows we’re still alive! We just finalized the XML schema for our soon to be released BlockWatch product so with all the XML tags, elements, attributes, and such running through my head I figured I’d blog about XML security. I’m sure the majority of penetration testers out there routinely test for the traditional web application vulnerabilities when looking at Web Services. The same old authentication/authorizations weaknesses, faulty encoding/reencoding/redecoding, session management issues, et al. are still all there and it’s not uncommon for a SOAP Web Service to hand off an attack string to some middleware app that forwards it on deep into the internal network for handling by the revered legacy mainframe. Some organizations process so much XML over HTTP that they place XML accelerator devices on their network perimeter. I have a feeling that this trend will increase the amount of private IP web servers that feel the effects of HTTP Request Smuggling.

Additionally, XML parsers that fetch external document references (e.g. remote URI’s embedded in tag attributes) open themselves up to client-side offensives from evil web servers. Crafted file attachments can come in the form of a SOAP DIME element or the traditional multipart HTTP POST file upload. With those things in consideration, Phillippe Lagadec’s ExeFilter talk from CanSecWest 2008 made some pretty good points on why verifying filename extensions and file header contents or magic numbers isn’t always good enough.

The new manifestations of these old problems should be cause for concern but I personally find the newer XML-specific bugs the most exciting. For example: XPath injection, infinitely nesting tags to cause resource exhaustion via a recursive-descent parser, XXE (XML eXternal Entity) attacks, etc.

A single file format for everything is supposed to make things more simple but the lion’s share of real-world implementations over-complicate the fleeting markup language tags to the point where they become a breeding ground for old school exploits and new attack techniques alike–we’re all familiar with the cliche regarding failure of a “system of systems” with too many moving parts. I’ll touch on some more advanced XML attacks later in the post, but first let’s take a step back and remember XML when it still had a fresh beginning.

Towards the end of the twentieth century, when I first started taking notice of all the hype surrounding XML (the eXtensible Markup Language) I held a fairly skeptic attitude towards it as I tend to do with many fledgling technologies/standards. Perhaps I’ve been over-analytical in that respect but look how long it’s taken IPv6 to amass even a minuscule amount of usage! Albeit, a formal data representation grammar certainly was needed in that “dot-bomb” era, a time when mash-up web applications were near impossible to maintain since consistently pattern matching off-site content demanded continuous tweaking of regular expressions, parsers, etc. The so-called browser war of Netscape Navigator vs. Internet Explorer couldn’t have helped things either. If that was a war, then we must be on the brink of browser Armagaeddon now that there’s Chromium, FireFox3, IE8 RTM, Safari4 Beta, Opera, Konqueror, Amaya, w3m, lynx, etc. The good news? We now have Safari for Win32. The bad news? Microsoft no longer supports IE for MacOS..bummer.

I think it’s fairly rational to forecast continued adoption of XML Encryption and WS-* standards for SOAP Web Services that handle business-to-business and other communications protocol vectors. If you’re bored of the same old Tomcat/Xerces, WebLogic/SAX, etc. deployments then prepare for applications written in newer API’s to arrive soon; namely Microsoft WCF and Oslo, the Windows Communication Foundation API and a modeling platform with design tools (respectively.) From the surface of .NET promotional hype it appears as if WCF and Oslo will be synthesized into a suitereminiscent of BizTalk Server’s visual process modeling approach. WCF has commissioned many Web Services standards including WS-Security but of course not all major software vendors are participating in the all of the standards. The crew in Redmond have committed to REST in WCF and it wouldn’t surprise me to see innovative XML communications techniques arising from the combination of Silverlight 3 and .NET RIA Services; for those of you who still don’t know, RIA is an acronym for Rich Internet Applications! Microsoft is leveraging the interoperability of this extensible markup language for the long-proprietary document formats of their Office product suite as part of their Open Specification Promise. Even the Microsoft Interactive Canvas, essentially a table that provides I/O through touch uses a form of XML (XAML) for markup.

Blogosphereans, Security Twits, and other Netizens alike seem to take this Really Simple Syndication thing for granted. Over the past several years or so there’s been a trend of malicious payloads piggybacking on banner ads. Since RSS and Atom are capable of syndicating images as well, I’d like to see a case study detailing the impact of a shellcode-toting image referenced from within an XML-based syndication format. Obvious client-side effects that occur when the end user’s browser renders the image are to be expected (gdiplus.dll, anyone?) What else could be done? Web 2.0 search engines with blog and image search features often pre-process those images into a thumbnail as a part of the indexing process. A little recon might discover the use of libMagick by one and libgd by another. Targeting one specific spiderbot over another could be done by testing the netmask of the source IP address making the TCP connection to the web server or probably even as simple as inspecting the User Agent field in the HTTP request header. Crafting a payload that functions both before and after image resizing or other additional processing (ex. EXIF meta-data removal) would be quite an admirable feat. Notwithstanding, I was quite surprised how much Referer traffic our blog got from after Shane included a picture of the great Charlie Brown in his “Good Grief!” post…but I digress.

Several years ago when I was still living in New York, I became fascinated with the subtle intricacies of XML-DSig while studying some WS-Security literature. XML Signature Validation in particular had attracted my attention in earnest. In addition to the characteristics of traditional digital signatures, XML Signatures exhibit additional idiosyncrasies that require a bit of pragmatism in order to be implemented properly and therefore also to be verified properly as well (ex. by a network security analyst.) This is mainly because of the Transform and Reference elements nested within the Signature elements–References and Transforms govern the data to be provided as input to the DigestMethod which produces the cryptic DigestValue string. A Reference element contains a URI attribute which represents the location of the data to be signed. Depending on the type of Transform element, data first dereferenced from the Reference URI is then transformed (i.e. via an XPath query) prior to signature calculation. That’s essentially how it works. Something that may seem awkward is that the XML being signed can remain exactly the same while the digital signature (e.g. the DigestValue element value) has changed. I’ve decided to leave some strange conditions that often come about as an exercise for the reader:

What happens to an XML Digital Signature if … ?

  • No resource exists at the location referenced by the Reference element’s URI attribute value.
  • A circular reference is formed because a URI attribute value points to another Reference element whose URI attribute value is identical to the first.
  • The URI identifies the Signature element itself.
  • A resource exists at the URI, but it’s empty.
  • The Reference element has a URI attribute value which is an empty string, <Reference URI=””>

Leave a Comment

The Philosophical Future of Digital Immunization

digital-trojan-horse-viriiUsually it’s difficult for me to make a correlation between the two primary subjects that I studied in college–computer science and philosophy. The first few things that pop into mind when attempting to relate the two are typically artificial intelligence and ethics. Lately, intuition has caused me to ponder over a direct link between modern philosophy and effective digital security.

More precisely, I’ve been applying the Hegelian dialectic to the contemporary signature-based approach to anti-virus while pontificating with my peers on immediate results; the extended repercussions of this application are even more fascinating. Some of my thoughts on this subject were inspired by assertions of Andrew Jacquith and Dr. Daniel Geer at the Source Boston 2008 security conference. Mr. Geer painted a beautiful analogy between the direction of digital security systems and the natural evolution of biological autoimmune systems during his keynote speech. Mr. Jacquith stated the current functional downfalls of major anti-virus offerings. These two notions became the catalysts for the theoretical reasoning and practical applications I’m about to describe.

Hegel’s dialectic is an explicit formulation of a pattern that tends to occur in progressive ideas. Now bear with me here–In essence, it states that for a given action, an inverse reaction will occur and subsequently the favorable traits of both the action and reaction will be combined; then the process starts over. A shorter way to put it is: thesis, antithesis, synthesis. Note that an antithesis can follow a synthesis and this is what creates the loop. This dialectic is a logical characterization of why great artists are eventually considered revolutionary despite  initial ridicule for rebelling against the norm. When this dialectic is applied to anti-virus, we have: blacklist, whitelist, hybrid mixed-mode. Anti-virus signature databases are a form of blacklisting. Projects such as AFOSI md5deep, NIST NSRL,  and Security Objectives Pass The Hash are all whitelisting technologies.

A successful hybrid application of these remains to be seen since the antithesis (whitelisting) is still a relatively new security technology that isn’t utilized as often as it should be. A black/white-list combo that utilizes chunking for both is the next logical step for future security software. When I say hybrid mixed-mode, I don’t mean running a whitelisting anti-malware tool and traditional anti-virus in tandem although that is an attractive option. A true synthesis would involve an entirely new solution that inherited the best of each parent approach, similar to a mule’s strength and size. The drawbacks of blacklists and whitelists are insecurity and inconvenience, respectively. These and other disadvantages are destined for mitigation with a hybridizing synthesis.

The real problem with mainstream anti-virus software is that it’s not stopping all of the structural variations in malware. PC’s continue to contract virii even when they’re loaded with all the latest anti-virus signatures. This is analogous to a biological virus that becomes resistant to a vaccine through mutation. Signature-based matching was effective for many years but now the total set of malicious code far outweighs legitimate code. To compensate, contemporary anti-virus has been going against Ockham’s Razor by becoming too complex and compounding the problem as a result. It’s time for the security industry to make a long overdue about-face. Keep in mind that I’m not suggesting that there be a defection of current anti-virus software. It does serve a purpose and will become part of the synthesization I show above.

The fundamental change in motivation for digital offensive maneuvers from hobbyist to monetary and geopolitical warrants a paradigm shift in defensive countermeasure implementation. For what it’s worth, I am convinced that the aforementioned technique of whitelisting chunked hashes will be an invaluable force for securing the cloud. It will allow tailored information, metrics and visualizations to be targeted towards various domain-specific applications and veriticals. For example: finance, energy, government, or law enforcement, as well as the associated software inventory and asset management tasks of each. Our Clone Wars presentation featuring Pass The Hash (PTH) at Source Boston and CanSecWest will elaborate on our past few blog posts and much more.. See you there!

Leave a Comment

Good grief!

Charlie Brown Good GriefHaving just caught up on some of the conference “Source Boston”, I can’t help but call out some of the musings of Andrew Jaquith. Something of a more technical abstract can be read at the code project’s article by Jeffrey Walton (pay special attention to Robin Hood and Friar Tuck). If anybody doubt’s the current trend of sophistication in malware, I’m sure it is somebody who is currently penetrated. I’ve had the opportunity to devote specific analysis on occasion over the years to MAL code and its impact on the enterprise. I know FOR SURE the level of sophistication is on the rise. One thing I had to deal with recently, the extent of capability afforded by most desktop OS’s being so advanced, the majority of functionality desired by MAL code is pre-deployed. Unfortunately paving the way for configuration viruses and their ability to remain undetected in that all they are is an elaborate set of configuration settings. You can imagine, a configuration virus has the entire ability of your OS at its disposal, any VPN/IPSEC, self-(UN) healing, remote administration, etc… The issue is then, how do you determine if that configuration is of MAL intent, it’s surely there for a reason and valid in many deployments. The harm is only when connected to a larger entity/botnet that harm begins to affect a host. Some random points to add hard learned through experience;

  • Use a native execution environment
    • VMWare, prevents the load or typical operation of many MAL code variants
      • I guess VM vendors have a big win here for a while, until the majority of targets are VM hosts.
  • Have an easily duplicated disk strategy
    • MAC systems are great for forensics, target disk mode and ubiquitous fire-wire allows for live memory dumps and ease of off-line disk analysis (without a drive carrier).
    • I’m planning a hash-tree based system to provision arbitrarily sized block checksums of clean/good files, useful of diff’ing out the noise for arbitrary medium (memory, disk, flash).
  • Install a Chinese translator locally
    • As you browse Chinese hack sites, (I think all Russian site’s are so quiet these days due to the fact that they are financially driven, while Chinese are currently motivated by nationalistic motivators), you need to translate locally. Using a .com translation service is detected and false content is rendered, translate locally to avoid that problem.
      • Also, keep notes on lingo.. there are no translation-hack dictionaries yet. (I guess code pigeon is referring to a homing pigeon, naturally horse/wood code is a Trojan).

Unfortunately part of the attacker advantage is the relatively un-coordinated fashion defenders operate, not being able to trust or vet your allies to compare notes can be a real pain. One interesting aspect of a MAL system recently analyzed was the fact that that it had no persistent signature. It’s net force mobility so complete, that the totality of its functionality could shift boot-to-boot, so long as it compromised a boot-up driver it would rise again. The exalted C. Brown put it best, “Good grief!”

Comments (10)

%d bloggers like this: