Neohapsis Labs

Even if You Don’t Invent Your Own Crypto….It’s Still Hard

January 19, 2010

By: Patrick Toomey

So, yet another crypto related post. Often times crypto related attacks fall on deaf ears, as for most people crypto is like magic (include me in that group every now and again), and it becomes difficult for the average developer to differentiate the risks associated with the attacks circulated within the security community. There is a vast chasm between the crypto community and just about everyone else. The cryptographers will talk about differential cryptanalysis, meet in the middle attacks, perfect forward secrecy, etc, etc. Often, the cryptographers’ goals are different than your average developer. Cryptographers are trying to achieve perfection. For them, any flaw in a cryptographic protocol is something to be discussed, researched, and fixed. As is a famous saying in the crypto community, “Attacks only get better”. So, even the smallest flaw is worth their time and effort, as it may lead to a practical crack that will warrant more immediate attention.

Unlike cryptographers, for the vast majority of developers, the goal is “good enough” security. Often times the result is not good enough, but the goal is admirable, as it doesn’t make sense to over invest in security. As a result, there is a chasm between “good enough” for cryptographers and “good enough” for developers. In this chasm are the real world attacks that are too boring for your average cryptographer to discuss, yet too subtle as to be obvious to your average developer. Many of these attacks have nothing to do with the cryptography itself. Instead, many real world crypto attacks have more to do with how developers piece together proven crypto building blocks insecurely. It was on a recent assessment that I came upon the following story that perfectly illustrates how cryptography is difficult to get right, even when you think you have made an informed decision.

On a recent assessment a colleague of mine came across a typical SQL injection attack. In fact, it was just the kind of SQL injection you hope for as an attacker, as it returned data to the user in a nice tabular output format. After a bit of mucking around we managed to find where the system was storing credit card information for its users. A few minutes later we had output that looked like the following:

Base64 Credit Card Numbers

Hmmm, base64 encoded credit card numbers. I wonder what they look like when we base64 decode them. A simple base64 decode resulted in the following hex values:

Base64 Decoded Credit Card Numbers

If you start trying to translate the above hex values to their ASCII equivalent you will quickly find that the values do not represent plaintext ASCII credit card numbers. Our first guess was that they were likely encrypted. So, step two is trying to figure out how they were encrypted. We took a look at the base64 decoded values and observed a simple fact: the vast majority of them were either 15 or 16 bytes long. Well, a 16 byte long ciphertext could be any 128 bit symmetric algorithm in simple ECB mode. But, the 15 byte entries were evidence against that, as they would get padded out to 16 bytes due to the requirement that symmetric algorithms encrypt a full block (16 bytes in the case of AES). So, my first thought was the use of a stream cipher. In their most basic form, a stream cipher simply takes a secret value as input (the key), and begins to generate a pseudorandom output stream of bytes. Encryption simply involves XORing the stream of random bytes with your plaintext. Unlike a block cipher, there is no need to pad out your plaintext, as you only use as many pseudorandom bytes as is necessary to XOR with your plaintext. Decryption is also simple, as XORing is a trivially invertible operation. The user simply feeds the algorithm the same key, generates the same pseudorandom byte stream, and XORs that with the ciphertext.

To see why this works let’s take a look at how this works for a single plaintext/ciphertext. Let us say we wish to encrypt the credit card number “4012888888881881″. The ASCII values in hex result in a plaintext array of the following values:

Plaintext Credit Card Number ASCII in Hex

Also, let us assume that we are using a stream cipher with a strong key whose first 16 output bytes are:

Pseudorandom Byte Stream in Hex

When we XOR the plaintext with the pseudorandom stream we obtain the ciphertext.

Resulting Ciphertext

To decrypt we simply take the ciphertext and perform the same XOR operation. Let’s quickly take our ciphertext and see how we decrypt it.

Decrypted Ciphertext

When we XOR the ciphertext with the stream we obtain the plaintext we started with. Through the whole encryption/decryption process we have effectively XORed the plaintext with the stream twice. XORing anything with the same value twice is effectively a NOP on the original value. Pictorially:

Full Encryption Decryption Cycle

However, our examples so far have assumed knowledge of the pseudorandom stream. Without knowledge of the key it is difficult to reproduce the pseudorandom stream, and thus very difficult to perform the steps we just outlined to obtain the plaintext for a given ciphertext. Moreover, we don’t even know what algorithm is in use here. Did the developers use RC4? Did they try to make their own pseudorandom generator by repetitively hashing a secret key? We didn’t really know, but regardless of the algorithm, there is inherent risk with leveraging a stream cipher in its most basic form. If the stream cipher uses a shared key, the pseudorandom stream will be identical every time it is initialized. To test this conjecture we used several test user accounts to register several credit cards. Sure enough, identical credit card numbers resulted in identical ciphertext. So, what can we do with this? We have no idea what algorithm was used, and we have no idea of what the value of the secret key is. However, it turns out that we don’t need any of that information. To see why let’s first take a look at the hex of two encrypted credit cards we base64 decoded above.

First Encrypted Credit Card

The above shows the 16 ciphertext bytes for one of the credit card numbers in the database.

Second Encrypted Credit Card

The above shows the 16 ciphertext bytes for a second credit card number in the database.

Let’s assume that the ciphertext from the first encrypted credit card was ours, where we know the plaintext ASCII hex values for the card.

Plaintext Bytes for the First Credit Card

Let’s also assume that the second credit card represents a credit card of unknown origin (i.e. all we can observe is the ciphertext. We have no ideas what the digits of the card are). Similarly, without knowledge of the key, we have no idea how to generate the pseudorandom byte stream used to encrypt the cards. But, what happens if we simply XOR these two ciphertexts together.

XOR of the Two Encrypted Credit Cards

Well, that doesn’t really look like it got us anywhere, as we still don’t have anything that looks like an ASCII credit card number. However, let’s take a look at what actually happened when we did the above operation. We are confident that both credit card numbers were encrypted with the same pseudorandom byte stream (remember that encryption of the same credit card under different users resulted in the same ciphertext). Furthermore, we know that the first credit card number is “4012888888881881″, as that is our own credit card number. The key insight is that we have effectively XORed four different byte sequences together. We have XORed the plaintext bytes of our credit card, the plaintext bytes of an unknown credit card, and the same pseudorandom sequence twice.

Encrypted Credit Card XOR Expanded

In the above picture the unknown plaintext credit card number is represented with a series of “YY”s. Similarly, the unknown pseudorandom stream is represented with a series of “XX”s. However, despite the fact that we don’t know the value of the pseudorandom stream, we do know they are the same. As a result, whenever you XOR anything with the same value twice you effectively create a NOP. So, the above three XOR operations can be simplified to the following:

Simplified XOR of Encrypted Credit Cards

So, what we actually did by XORing the two ciphertexts is create a new value that is the XOR of the two plaintexts. Wow, that is kind of cool. We just got rid of the pseudorandom byte stream that is supposed to provide all the security without ever knowing the key. But, what do we do now? We still don’t have plaintext credit card numbers yet. Ah, but we do! You can think of what we now have as the unknown credit card number encrypted with our known credit card number as the pseudorandom stream. In other words, we can simply XOR our result with our known credit card value again and we will obtain the resulting plaintext for the unknown credit card number.

Decrypted Credit Card

One you translate the resulting hex into the equivalent ASCII string you obtain “5362016689976147″, a valid MasterCard number (obviously we have used test credit card numbers throughout this blog entry). We can simply apply the above steps to recover the full unencrypted credit card numbers for the entire database. We have effectively used our own encrypted credit card number as a key to decrypt all of the other unknown credit cards in the database. This is a pretty impressive feat for not knowing the algorithm and/or the secret key used to encrypt all of the credit card information.

As it turns out, we eventually received source code for the functionality under investigation and discovered that the developers were using RC4. RC4 has had its fair share of issues, and is generally not a recommended algorithm, but none of what we just discussed had to do with any weakness with RC4. The above attack would have worked on any stream cipher used in the same way. So, as is typical, the attack had more to do with how cryptography is used than the cryptographic algorithm itself. We can’t say it enough….crypto is hard. It just is. There are just too many things that developers need to get right for crypto to be done correctly. Algorithm selection, IVs, padding, modes of encryption, secret key generation, key expiration, key revocation…the list goes on and on. We in the security community have been pounding the “don’t invent your own cryptography” mantra for a long time. However, that has lead to a swarm of developers simply leveraging proven cryptography insecurely. So, we need to take this one step further. On average, it is best for developers to defer to proven solutions that abstract the notion of cryptography even further. For example, GPG, Keyczar, et al have abstractions that simply let you encrypt/decrypt/sign/verify things based off of a secret that you provide. They handle proper padding, encryption mode selection, integrity protection, etc. That is not to say that there aren’t use cases for needing to delve into the weeds sometimes, but for the average use case a trusted library is your friend.

6 Comments | Information Security | Tagged: Cryptography, Encryption, RC4, Stream Cipher | Permalink
Posted by Patrick Toomey

Virtualization: When and where?

November 17, 2009

We often field questions from our clients regarding the risks associated with hypervisor / virtualization technology. Ultimately the technology is still software, and still faces many of the same challenges any commercial software package faces, but there are definitely some areas worth noting.

The following thoughts are by no means a comprehensive overview of all issues, but they should provide the reader with a general foundation for thinking about virtualization-specific risks.

Generally speaking, virtual environments are not that different than physical environments. They require much of the same care and feeding, but that’s the rub; most companies don’t do a good job of managing their physical environments, either. Virtualization can simply make existing issues worse.

For example, if an organization doesn’t have a vulnerability management program that is effective at activities like asset identification, timely patching, maintaining the installed security technologies, change control, and system hardening, than the adoption of virtualization technology usually compounds the problem via increased “server sprawl.” Systems become even easier to deploy which leads to more systems not being properly managed.

We often see these challenges creep up in a few scenarios:

Testing environments – Teams can get the system up and running very quickly using existing hardware. Easy and fast…but also dirty. They often don’t take the time to harden the system or bring it up to current patch levels or install required security software.

Even in the scenarios where templates are used, with major OS vendors like Microsoft and RedHat coming out with security fixes on a monthly basis a template even 2 months old is out of date.

Rapid deployment of “utility” servers – Systems that run back-office services like mail servers, print servers, file servers, DNS servers, etc. Often times nobody really does much custom work on them and because they can no longer be physically seen or “tripped over” in the data center they sometimes fly under the radar.

Development environments – We often see virtualization technology making inroads into companies with developers that need to spin-up and spin-down environments quickly to save time and money. The same challenges apply; if the systems aren’t maintained (and they often aren’t – developers aren’t usually known for their attention to system administration tasks) they present great targets for the would-be attacker. Even worse if the developers use sensitive data for testing purposes. If properly isolated, there is less risk from what we’ve described above but that isolation has to be pretty well enforced and monitoring to really mitigate these risks.

There are also risks associated with vulnerabilities in the technology itself. The often feared “guest break out” scenario where a virtual machine or “guest” is able to “break out” of it’s jail and take over the host (and therefore, access data in any of the other guests) is a common one, although we haven’t heard of any real-world exploitations of these defects…yet. (Although the vulnerabilities are starting to become better understood)

There are also concerns about the hopping between security “zones” when it comes to compliance or data segregation requirement. For example, typically a physical environment has a firewall and other security controls between a webserver and a database server. In a virtual environment, if they are sharing the same host hardware, you typically can not put a firewall or intrusion detection device or data leakage control between them. This could violate control mandates found in standards such as PCI in a credit card environment.

Even assuming there are no vulnerabilities in the hypervisor technology that allow for evil network games between hosts, when you house two virtual machines/guests on the same hypervisor/host you often lose the visibility of the network traffic between them. So if your security relies on restricting or monitoring at the network level, you no longer have that ability. Some vendors are working on solutions to resolve intra-host communication security but it’s not mature by any means.

Finally, the “many eggs in one basket” concern is still a factor; when you have 10, 20, 40 or more guest machines on a single piece of hardware that’s a lot of potential systems going down should there be a problem. While the virtualization software vendors will certainly offer high availability scenarios with technology such as VMware’s “VMotion”, redundant hardware, the use of SANs, etc., the cost and complexity adds up fairly fast. (And as we have seen from some rather nasty SAN failures the past two months, SANs aren’t always as failsafe as we have been lead to believe. You still have backups right?)

While in some situations the benefits of virtualization technology far outweigh the risks, there are certainly situations where existing non-virtualized architectures are better. The trick is finding that line in the midst of the hell mell towards virtualization.

–Tyler

1 Comment | Compliance, Information Security, PCI, Risk Management, Security Industry, Security Tools | Permalink
Posted by tylerallison

Hacker Halted 2009

October 21, 2009

As many of you know, Greg Ose and I recently spoke at Hacker Halted 2009 in Miami. We discussed a distributed password cracker that we designed and implemented that utilizes redirected browsers to build a swarm of worker nodes. The method which we demonstrated can be implemented using large numbers of otherwise useless stored cross-site scripting vulnerabilities. The client-side worker was implemented as a Java applet in an injected iframe.

Greg and I also showed several methods which can be used on different platforms to trick the Java virtual machine into continuing execution after a client has closed the page where it is embedded. This can be used to maintain large numbers of workers even when the vulnerable sites are not visited for long periods of time.

The following video shows the administrative interface to DistCrypt where we can add and manage password hashes.

You can view the high quality version here.

You can also view the slides from our presentation on the Hacker Halted website here.

3 Comments | Information Security, Neohapsis, Security Tools | Tagged: conference, distributed computing, hacker halted | Permalink
Posted by Cris Neckar

What do Rootkits and Xerxes have in common?

August 25, 2009

By: Cris Neckar and Greg Ose

Just think of your kernel as Greece…

It’s probably not the first thing you expected to hear me say but bear with me. The arms race between rootkit development and detection has been raging for years, and although there have been great advancements in detection, rootkit developers have always had the upper hand. You simply cannot defend against what you cannot predict. Recently the battle has become increasingly heated as rootkit developers dig deeper and deeper. One only need look at the Blackhat Briefings for the past few years to see the trend.

Increasingly subversive and complex rootkits threaten to over-run our kernels and turn our business critical systems into slaves. So what are we to do? Should we simply throw up our hands and resolve ourselves to a life of bondage?

To answer this question lets approach the problem from a different angle. It has become clear that we cannot simply monitor everything a rootkit developer might change. There are just too many function pointers, operating modes, and devices to allow us to watch them all. However, one commonality does exist in all kernel mode rootkits. In some way they must all be inserted into the kernel.

There are a number of ways to introduce new code into a running kernel but not nearly so many as there are places to hide once inside. I propose that, instead of building a blacklist and peeking under all the rocks where they have hidden in the past, we instead monitor the entry point. Leonidas used a similar approach when Xerxes threatened Greece, instead of fighting on even ground the Spartans guarded the narrow door through which the Persians must travel to enter Greece.

So, you say, it’s a great theory, but how do we implement it? Assuming an attacker has compromised a system’s most privileged usermode context, for instance a process running as root, code can be introduced into the running kernel in a number of ways. The most obvious of these is to install a module or driver and be done with it. Aside from that, an attacker would need to patch kernel memory directly, this is not trivial but is still a common method of rootkit insertion. Aside from these options, the attacker would be forced to edit the kernel binary, or an existing module on disk and either cause or wait for a reboot (There is one additional threat which we will save for later). The interesting thing about all of these potential insertion points is that they are events which would almost never occur in a production server (If they do occur an administrator will certainly be aware of the reason). By monitoring these few events we would be notified of the insertion of any existing kernel mode rootkit that I am aware of, as well as any that could be written in the future (barring a further vulnerability.. more on this later).

To implement this on Linux is actually fairly trivial. To monitor for code inserted into the kernel while running we can use the tricks of rootkit developers ourselves. Namely we can hook sys_init_module (for module insertions), and the write() handlers within the kmem and mem file operations structures (for writes to /dev/(k)mem where these are still possible).

The next step is to defend against changes made to kernel components on disk. For the kernel image itself, on a system which is rarely rebooted such as a production server, it is possible to accomplish this by booting a known good kernel. For example a kernel could be booted from media which is only physically attached to the system when the kernel is initially loaded into memory. A similar approach could be used with required kernel modules, or if preferable, they could be compared on load to known good check sums.

Now that we have covered the entry points we can focus on what to do once one of these events occurs. We do not actually need to prevent the insertion as, in some cases, these events may legitimately occur (once a root compromise has occurred a re-image of the system is generally the best approach anyway). Instead we simply need to securely log the event to a location which is not controlled by the intruder. Obviously we can not log locally. Additionally we cannot log with mechanisms which are already under the attackers control (anything accessible from user mode is out). One relatively trivial solution is to simply create a syslog packet and drop it on the network stack when one of our traps triggers. This will provide us with a remote log on a system which (hopefully) has not been compromised. When implementing this you would of course want to be careful to temporarily disable any netfilter hooks (think iptables) as these could allow the intruder to block our logging packet from usermode.

Like Sparta’s defense at Thermopolae, this method also has its mountain path. I mentioned earlier that there was an additional method for introducing code into a running kernel. This would involve the existence of a vulnerability within the kernel or a loaded module which allows arbitrary memory to be written. An attacker could create an exploit which uses such a vulnerability to introduce a rootkit into the kernel. We cannot possibly predict where an exploit will occur (if we could, vulnerability research would be a lot easier ) making it impossible (so far ) to guard against this threat using this method. Fortunately a rootkit which used this installation method would be obsolete the moment it was first detected. This means that this type of rootkit could never reach widespread usage and would most likely be used only in a very targeted attack.

Leave a Comment » | Information Security, Security Tools | Tagged: detection, rootkits | Permalink
Posted by Cris Neckar

Michael Rasmussen Blogs on the topic of GRC

August 11, 2009

Gregg LaRoche, VP Product Management, Neohapsis

I recently spotted an interesting posting on Mr. Rasmussen’s Blog – GRC Pundit entitled “The Forrester GRC ‘Ripple’ (OOOPS . . . I Mean, ‘Wave’)”. In addition to some very candid observations regarding industry analysts’ well-known graphical reports, Neohapsis is mentioned as one of the significant GRC vendors ‘missed’ in this year’s GRC Wave report. As you may know, the Wave criterion includes product deployment metrics to ensure new or Beta products are omitted. Certus GRC is in Beta stage and as such was not eligible for inclusion in the report. Why is Neohapsis’ Certus GRC offering significant although not included? Certus GRC is a ground breaking product that I have no doubt the analyst community will find compelling and will challenge many prior perceptions they have held about the GRC technology space and how Certus GRC can be used to manage highly complex, interrelated GRC relationships in ways that make sense for business stakeholders and employees.

I was particularly interested in Mr. Rasmussen’s perspective on the dangers of relying on the major analyst firms’ industry graphic to make critical technology selection decisions. Enterprise technology decisions are important not only in terms of investment and return, but also can dictate employee and partner experiences and limitations for years to come. Graphical summaries are useful to compare and contrast the largest, most established products at a high level. They can tell us who within that group is investing in technology over time and can also gauge some interesting peer enterprise viewpoints. But what does that tell your enterprise about the performance of that investment, the overall fit, or the user experience for your unique environment and set of business challenges? Rasmussen makes the astute observation that in this particular case, the report has focused on the IT buyer and has missed the essential business buyer. GRC is a discipline and a solution set that spans the enterprise when fully realized, and requires cross functional cooperation and C-level visibility to be truly successful.

I happen to agree with Mr. Rasmussen’s well-informed pros and cons on this topic and also respect and find good value in the analyst firms I work with, including the highly regarded author of the Wave report and others. But like most good things, analyst opinions do need to be measured in the fullness of our own judgment, unique experiences, and those of our customers and stakeholders.

Check out Michael Rasmussen’s post at http://corp-integrity.blogspot.com/2009/07/forrester-grc-ripple-ooops-i-mean-wave.html

Leave a Comment » | GRC | Permalink
Posted by glaroche

ViewStateViewer: A GUI Tool for deserializing/reserializing ViewState

August 3, 2009

By: Patrick Toomey

Background

So, I was reading the usual blogs and came across a post by Mike Tracy from Matasano (Matasano has been having some technical difficulties…this link should work once they have recovered). In the blog post Mike talks about the development of a ViewState serializer/deserializer for his WWMD web application security assessment console (please see Mike’s original post for more details). Mike noted that the tools for viewing/manipulating ViewState from an application testing perspective are pretty weak, and I can’t agree more. There are a number of ViewState tools floating around that do a tolerable job of taking in a Base64 encoded ViewState string and presenting the user with a static view of the deserialized object. However, no tools up until this point, save for Mike’s new implementation, have allowed a user to change the values within the deserialized object and then reserialize them into a new Base64 string. Mike’s tool does exactly this, and is immensely useful for web application testing. The only downside to Mike’s tools is that it is built for his workflow and not mine (how can I fault the man for that). So, I decided to build an equivalent that works well for me (and hopefully for you as well).

I tend to have a web proxy of some sort running on my machine throughout the day. There are tons of them out there and everyone seems to have their personal favorite. There is Paros, WebScarab, BurpSuite, and I am sure many others. In the last few months I have been using a newer entrant into the category, Fiddler. Fiddler is a great web proxy whose only big drawback is that it is Windows only. However, at least for me, the upsides to Fiddler tend to outweigh the negatives. Fiddler has a fairly refined workflow (don’t get me started on WebScarab), is stable (don’t get me started on Paros), and is pretty extensible. There are a number of ways to extend Fiddler, most trivially using their own FiddlerScript hooks. In addition, there is a public API for extending the application using .NET. Fiddler has a number of interfaces that can be extended to allow for inspecting and manipulating requests or responses. Please see the Fiddler site for more details on extending Fiddler using either FiddlerScript or .NET. In particular, take a look at the development section to get a better feel for the facilities provided by Fiddler for extending the application.

Anyway, I had been thinking about writing a ViewState serializer/deserializer for Fiddler for the past month or two when I saw Mike’s blog post. I decided that it was about time to set aside a little time and write some code. I was lucky that Fiddler uses .NET, as I was able to leverage all of the system assemblies that Mike had to decompile in Reflector. After a bit of coding I ended up with my ViewStateViewer Fiddler inspector. Let’s take a quick tour…

ViewStateViewer seamlessly integrates into the Fiddler workflow, allowing a user to manipulate ViewState just as they would any other variable in a HTTP request. An extremely common scenario for testing involves submitting a request in the browser, trapping the request in a proxy, changing a variable’s value, and forwarding the request on to the server. ViewStateViewer tries to integrate into this workflow as seamlessly as possible. Upon trapping a request that contains ViewState, ViewStateViewer extract the Base64 encoded ViewState, Base64 decodes it, deserializes the ViewState, and allows a user to manipulate the ViewState as they would any other variable sent to the server. Let’s take a look at some screenshots to get a better idea of how this works.

ViewStateViewer Tour

Serialized ViewState

By Default, Fiddler lets a user trap requests and view/edit a POST body before submitting the request to the server. In this case, the POST body contains serialized ViewState that we would like to work with. Without ViewStateViewer this is non-trivial, as Fiddler only shows us the Base64 encoded serialization.

Deserialized ViewState

ViewStateViewer adds a new “ViewState” tab within Fiddler that dynamically identifies and deserializes ViewState on the fly. The top half of the inspector shows the original Base64 serialized ViewState string. The bottom half of the inspector shows an XML representation of the deserialized ViewState. In between these two views the user can see if the ViewState is MAC protected and the version of the ViewState being deserialized. In this case we can see that this is .NET 2.X ViewState and that MAC protection is not enabled.

Reserialized ViewState

Once the ViewState is deserialized we can manipulate the ViewState by changing the values in the XML representation. In this example we changed one of the string values to “foobar”, as can be seen in the figure above. Once we change the value we can reserialize the ViewState using the “encode” button. The reserialized Base64 encoded ViewState string can be seen in the top half of the ViewStateViewer window. Once we have “encoded” the ViewState with our modifications, ViewStateViewer automatically updates the POST body with the new serialized ViewState string. This request can now be “Run to Completion”, which lets Fiddler submit the updated request to the server.

Limitations

It should be noted that if the original ViewState had used MAC protection ViewStateViewer would not be able to reserialize the manipulated ViewState with a valid MAC. While ViewStateViewer will not prevent you from deserializing, manipulating, and reserializing MAC protected ViewState, it will not be able to append a valid MAC to modified ViewState. ViewStateViewer will warn us that “Modified ViewState does not contain a valid MAC”. Modified requests made using reserialized MAC protected ViewState will ultimately fail, as we don’t know the machine key used to produce a valid MAC. Regardless, sometimes simply being able to view what is being stored in MAC protected ViewState can be useful during an application assessment.

In addition to MAC protection, ViewState can be optionally protected using encryption. Encryption will prevent any attempt by ViewStateViewer to deserialize the ViewState. If encryption is detected ViewStateViewer will simply show the user the original Base64 ViewState string. However, as any application security consultant can attest, there are many applications that do not encrypt or MAC protect their ViewState. ViewStateViewer is aimed squarely at these use cases.

Finally, ViewStateViewer was written entirely with deserializing/serializing ViewState 2.X in mind. While ViewState 1.X is supported, the support at this time is limited, though completely functional. ViewState 1.X, unlike ViewState 2.X, Base64 decodes into a completely human readable ASCII based serialization format (think JSON). As such, ViewStateViewer simply Base64 decodes ViewState 1.X and displays the result to the user. The user is then free to make any changes they wish to the decoded ViewState. This works exactly the same as the example shown above, except that the decoded ViewState object will not be a nicely formatted XML document. I might get around to adding true ViewState 1.X support, but the benefits would be purely cosmetic, as the current implementation has no functional limitations.

Wrap Up

ViewState is one of those areas that tends to be under-tested during application assessments, as there have been no good tools for efficiently evaluating the effects of modifying ViewState. Hopefully the release of ViewStateViewer will make evaluation of ViewState a more common practice. If you want to give ViewStateViewer a try you can download the Fiddler plugin(with source) here. Simply copy ViewStateViewer.dll into your “Inspectors” folder within your Fiddler install directory. It should be noted that this inspector is for Fiddler2, so please update your copy of Fiddler if you are out of date. Finally, this is very much a work in progress. As I found out during development, there is ton of ViewState out there that is either non-trivial to deserialize/reserialize or is impossible to deserialize/reserialize (non-standard objects being serialized for example). Maybe I’ll do another blog post detailing some of these difficult/impossible to handle edge cases in a subsequent post. So, while I have done some limited testing, I am sure there are some bugs that will crop up. If you happen to find one please don’t hesitate to contact me.

1 Comment | Information Security, Security Tools | Tagged: application security, Encryption, ViewState, web application security | Permalink
Posted by Patrick Toomey

Security Fitness in Lean Times – The Webinar

July 20, 2009

We are hosting a webinar inspired by Nat Puffer’s recent blog post. He and Erik Bataller, senior consultants at Neohapsis, will present Security Fitness in Lean Times on Tuesday, July 28th at 12:00 p.m. They will discuss what IT security teams can do today to manage risk and improve security despite budget challenges, including how to assess current capabilities, find key areas for improvement, develop appropriate plans and expectations, stay on target, and ensure essential testing and maintenance.

If you are interested but can’t make that time, go ahead and register anyway; we will send you a link to the archived version so you can view it at your convenience.

Webinar details:
Title: Security Fitness in Lean Times
Date: Tuesday, July 28, 2009
Time: 12:00 p.m. EDT
Duration: 60 minutes
Speakers: Nat Puffer and Erik Bataller, senior consultants at Neohapsis
Register

Leave a Comment » | Neohapsis | Permalink
Posted by Erik Bataller

Enterprise, or Opportunity Risk Management?

July 2, 2009

The Enterprise Risk Management (ERM) market seems to have been driven by the Finance & Banking (F&B) sector’s interpretation of what ERM means. They have taken their traditional risk methodology in the areas of Credit, Market and Operational risk management and extended that out to other areas of their businesses and called that ERM. But, for true ERM, the F&B institution’s methodology for managing risk is applying too much emphasis on backward-looking analysis of loss, as opposed to a more forward-looking speculation about potential loss (or risk) in future. Historical analysis of actual loss is of course a significant indicator of further loss in future, but only where defined losses are to be expected, such as in the areas of insurance or the provision of credit, or speculation into markets etc.

However, such a methodology doesn’t provide a sound analytical basis for those less frequent and possibly more drastic events, or those events where historical loss data doesn’t exist, which applies to the general operations of most businesses today.

So, in F&B, risk management has become very much a science, but for areas of risk outside the realms of credit, market and banking operations, and without the benefit of hindsight and a loss history, it is very much an art today.

Perhaps analyzing some of the more accepted definitions of risk will help us to figure out where and how we should be focusing our risk assessment efforts, acronyms aside:

Wikipedia by its very nature takes a broad view, not specifically in the context of business, and states simply that “risk is a concept that denoted the precise probability of specific eventualities”. Interestingly Wikipedia’s definition of risk continues by stating that risk can be defined as “the threat or probability that an action or event, will adversely or beneficially affect an organization’s ability to achieve its objectives” Hmmm, so immediately Wikipedia is recognizing that we have to tie our speculation of loss to our desire to achieve stated objectives; in other words, realizing our opportunities.

Corporate Integrity, a leading Global advisory on Governance, Risk and Compliance succinctly defines Risk as “the effect of uncertainty on business objectives”. Again, focusing on what a company is endeavouring to achieve through the realization of its opportunities.

So, how about substituting the word ENTERPRISE and replace it with OPPORTUNITY? After all, businesses are in business to profit from opportunities, and given that the above definitions of risk relate its management to the achievement of those objectives, it would seem that this has to be the basis of risk analysis.

However, this would provide us with ORM instead of ERM as an acronym for the management of risks in our business, but unfortunately, ORM is already generally accepted as meaning Operational Risk Management, which is a term well understood and accepted in the F&B world because it is a component part of the Basel II Capital Accord. This might explain the route cause of the problem!

F&B understands Operational Risk Management in Basel II terms and by extending that across the enterprise they assume it to be Enterprise Risk Management, but, as stated previously the methodology used is driven by the analysis of losses, not the analysis of risks to the achievement of objectives, goals or opportunities.

It is correct that loss analysis is an excellent way of predicting likely loss in future, but as noted earlier only if an extensive loss history exists. This is the key point. In most businesses the loss history does not exist or is very limited, and even in the F&B industry it is limited to the scope of Basel II, which does not cover business risks such as supply-chain, internal operations such as HR or reputational risks and many other risk areas.

So, whilst extensive loss history can help us to add some science to the art of risk management across the enterprise, the fact is that an extensive history of losses does not exist for most businesses, so the only viable methodology is to start with understanding a businesses strategy, its objectives, its opportunities, and trying to quantify what will prevent the company achieving those. i.e. what are the risks to the realization of opportunities.

Opportunity Risk Management (ORM).

3 Comments | Information Security, Risk Management | Tagged: Enterprise Risk management, ERM, Operational Risk Management, Opportunity risk | Permalink
Posted by Lindsay John Cox

Security Fitness in Lean Times

June 18, 2009

I recently had the opportunity to spend a little downtime with a colleague who does a lot of writing and thinking about security. As we talked about what crashing economies, tightening budgets, and 2009 in general might mean to IT security, he made an interesting statement,”There is no such thing as a security diet pill.”

We’d seen so many security programs fail, not because of a lack of resources, but because of a lack of discipline or understanding. They had been operating like someone who is furiously trying to get in shape purchasing fitness products and diet books in bulk. The results were exactly what you’d expect, some initiatives worked great for a short while. However, in time, most became exercises in installing the newest exciting product or were abandoned all together due to the pace of business. Technology was courted as a series of solutions instead of what it is, a tool for getting the most out of the work you put in.

So here we are with the same goal we’ve had for a while. The budgets are shrinking and the problem isn’t. Time to put our feet up on the dusty weight bench, have a cheeseburger, and resign ourselves to the way things are, right?

Or maybe we can look at this as an opportunity. Perhaps this is a good time to take stock.

Measuring initiatives by the budgets they carry or the technology they purchased isn’t going to resonate with upper management the way it once might have. Fiscal tightness will start to require security fitness. We know the tools are laying around, we bought them all. Now may be a good time to make sure we’re using them the best we can. Now is a good time to make sure we’re putting in the work.

See your Doctor Before Starting any Program

What are your true security strengths? What are your weaknesses? What are you trying to protect? Are all your assets of equal value? The answers to these questions should be your guide going forward. This is also the point where you need to ensure you’re taking an honest look at the situation. With the resources you’ve already amassed, what is your capability? Politics has no place here.

Set Realistic Goals

If you don’t even have an IDS in place, don’t create a mandate that every packet in the network will be tracked by next quarter. Understand the limitations imposed by your business, your current capability, and your culture. Realize that changes, especially ones involving adding restrictions or controls, take time to adopt. The bright side is that you’re first goal is to use the technology and systems you’ve already paid for more efficiently. Install the IDS. Update it. Tune it. Integrate the data with your vulnerability scanner to create a more accurate risk profile.

Maintain a Healthy Diet

Fear, Uncertainty, and Doubt are the hallmarks of an unhealthy security diet. News channels propagate this. Conferences do their share. Industry trade magazines don’t help. The net result is security programs that think they are being reactive to cutting edge threats, but are never truly increasing their over all security. Gartner declares IDS is dead; IPS is the new future. You mean IDS with blocking? So everyone upgrades and tears out the infrastructure. Attention isn’t paid to the original problem. Nobody ever upgrades the signatures. Nobody ever looks at the alerts. Before you spend resources looking into Vishing attacks, ask yourself if you have any assets exposed by attacks on an automated call system? Is that exposure more critical than the current initiatives?

There’s no Substitute for Exercise

I haven’t seen anyone talking about security as a continuous process lately. I’ve heard about programs, initiatives, even sprints. At its core though, security is something that should be part of the organization and the culture. Evaluation and improvement of the system should be done through continuous movement. Small steps with a commonly understood purpose. The guidance of Security Offices should become integrated into the business operations of the organization. Monitoring the effectiveness and providing honest, actionable feedback should become routine. Eventually, testing of the system will become a non-event. It’ll already be in shape.

1 Comment | Information Security | Permalink
Posted by Nathaniel Puffer

COSO II Event Identification will be a significant challenge for companies

June 2, 2009

COSO’s improvement to COSO II, sometimes referred to as COSO ERM, added requirements for objective setting, risk identification, management & reporting, as well as risk treatment and event identification. These would be regarded as the basic elements of a good ERM (Enterprise Risk Management) program, and tying these into COSO integrates the already established control framework around those ERM practices.

Sounds good! It is good, or at least a good starting point, I believe. A far more granular assessment to derive a risk level is needed if this is to become truly scientific, but that’s for another blog topic!

The issue now is that whilst most companies will probably be able to implement just about all the elements of COSO II, there is one that I believe will be a significant challenge, the ‘Event Identification’ element.

Under COSO II, Event Identification encompasses incidents (internal or external) that can have a negative (or positive – so perhaps opportunities?) effect. Much like under Basel II Operational Risk analysis, the benefit of hindsight determines or assists the prediction of future risk. So, effectively, to adhere to COSO II a company must identify and quantify incidents within the ERM framework, such that predictions of risk can be assisted by knowledge of actual loss in the past.

This is a whole new set of business processes and responsibilities that certain individuals must accept as part of their regular employment descriptions. But it is more complicated than that, because internal systems and processes will need to be developed to help those individuals to obtain the correct data to support event identification.

Take a simple example in IT. Let’s assume we are a pharmaceutical company, and a system falls victim to a security breach. On that system is 20 years of clinical trial information for a product and we know that an outside organization has potentially accessed that IP. Who’s responsibility is it to recognize that the incident has occurred? Who decides what the cost to the organization is? Who’s responsibility is it to capture that information? Who’s responsibility is it to identify the business and technical risks associated with the incident? Who’s responsibility is it to decide what actions should be taken as a result of the incident to prevent it happening again?

Even for this fairly tangible event, there are a whole set of new processes, policies, documentation and responsibilities that need to be in place to properly implement Event Identification.

So much so, that I contend most companies should not declare COSO II compliance, just yet.

Leave a Comment » | COSO, Compliance, Risk Management | Tagged: Compliance, COSO, Risk Management | Permalink
Posted by Lindsay John Cox