Epistemological Relativism

There is a rant over at Observations. In it the author rightly points out that user training is ineffective when you do not have a minimum set of security measures in place. For those not in the inner sanctum, we’re talking about information security. Basically, the rant is communicating that we have to pick and choose our battles. I’m totally on board here. In fact, I spoke about that here. The challenge is that everyone’s bare bones security measures are very different. In fact, over at Observations he practically throws in the kitchen sink! Don’t get me wrong, all of the measures are great, but integrating all systems into AD, starting a threat modeling effort and NAC are definitely not bare bones. Not even close. Now, I know this was a rant so I won’t be too critical here, but you can’t put everything in the bare bones category. It tends to lose meaning that way. Instead, after the author calms down, another attempt should be made to prioritize these efforts. Yes, you must prioritize. Especially in the security space where there is always work to be done, we have to select those efforts that will produce the greatest positive outcome. I know, great is vague and nebulous, but you know what I mean. Check out the laundry list, it is nice, a little idealistic, but nice nonetheless.

The taosecurity blog has an interesting post regarding application instrumentation. In it author Ricard Bejtlich argues that all applications should be able to defend themselves. This defense, according to Bejtlich, is defined as the ability to tell us “when they are abused, subverted, or breached”. Now I wouldn’t call this defense per se, but the I understand where he is coming from. Visibility into an application’s behavior or misbehavior is essential to properly respond to each situation. So, we’re all in agreement here, almost. Bejtlich writes:

I would like to see the next innovation be security application instrumentation, where you devise your application to report not only performance and fault logging, but also security and compliance logging. Ideally the application will be self-defending as well, perhaps offering less vulnerability exposure as attacks increase (being aware of DoS conditions of course).

While this is excellent, I think it fails to recognize one of the fundamental barriers to implementing such a system. The idea that an application has the ability to report information about security events, violations or what-have-you is great. The problem, however, is that because this functionality is found within the application’s runtime we may have some integrity issues. If that application is attacked and ultimately compromised the ability for that application to effectively communicate security event data with any sort of integrity is quite low. So low, in fact, that that function is useless. And this is exactly when we don’t want it to be.

This particular problem isn’t that new. The reference monitor, while not quite analogous, does provide some insightful parallels. In a nutshell, we cannot place the reference monitor-like functionality within the application’s runtime environment. If we do this, we seriously limit the effectiveness of its primary function. Now, the reference monitor concept isn’t a silver-bullet either, but the decoupling of that function from that of the application provides some compartmentalization and some level of non-bypassability (you can’t bypass the reference monitor by attack the application itself). Yes, you can attack the reference monitor and then attack the application, but you must do so in two discreet steps. This sounds strangely like an IDS doesn’t it?

So, I agree, we need the information, but is building it into every application the most effective way to do this? I don’t think it is.

While chatting with a friend yesterday about approaches to integrating security into a system or software development life cycle I mentioned something that bears repeating. There must be an overall strategy to a companies information security program. And strategy does not mean a list of projects to do for a given timeframe. Seriously though, I’ve seen a lot of companies approach the security game (yes, it is a game, didn’t you know?) with what I think is a reactive/product-based approach. I don’t really even think “approach” is the proper word here. Sure, there are some “no-brainer” products that most organizations need, but understanding what that need is and successfully implementing and managing these things are not at all the same. The product approach leads to great products that are poorly implemented, improperly managed and ultimately do not provide the value they are intended to deliver. This is because they can only deliver when surrounded by a coherent, realistic and repeatable process. But even this isn’t, in my opinion, the root cause. The root cause is the lack of an overall strategy, approach, plan or whatever you want to call it to the various facets of an information security program. Instead isolated islands of projects pop up without any sense of the big picture.

Now, back to my discussion. My advice was to loosely model the CMM. I say loosely because we only need the general concepts (with some modification) to steer us in the right direction. The CMM is focused on levels of maturity. As you progress upward in the CMM things become more defined, repeatable, measurable and optimal. First thing to do is to map out the various security products, processes, initiatives and what-not to the levels of the CMM. Of course I bastardized the CMM, because I made the point to say that things like security in the SDLC come after other more pressing issues get to level 2. It wouldn’t make sense to begin a full scale SDLC project when antivirus, patching and firewall management processes are not working at all. The ideas of the CMM is to allow you to take the various categories/tasks of information security and see where your gaps are and to plan more strategically to address them. The ad-hoc, on-demand approach can work, but you get stuck in that cycle.

I’m not saying that processes, strategies and plans are the keys to a successful program. What I am saying is that these are usually conducive to creating discussions that address the appropriate problems, allowing people to stop and think about what they are or are not doing and, ultimately to develop some achievable and realistic goals. Many times, unfortunately, organizations are stuck in the producto-reactive cycle.

I just noticed (yes, I’m a bit slow) that about six months ago the OWASP project put up a page on risk rating. I’ve reviewed it and find it quiet usable for many organizations. Of course, it requires some customization, but it is much more applicable to corporate application environments that what is currently available.

In early 2006 while at my previous employer we spent many long hours attempting to create a somewhat more realistic approach to communicating risk. Many (read: most) of the methods available at the time were vendor-centric. They were not usable in corporate environments without a great deal of tweaking and by that time it didn’t look at all like the original method. The problem was that the metrics used by many of these methods artificially inflated the results. Everything turned out to be a high risk. Yes, some things were high risk, but not everything. The reality is that you have to have a sane risk rating system so that the truly high risks actually get fixed. If everything is high risk, then nothing is high risk and no real work will get done.

Anyways, we came up with something a bit similar to what OWASP has done. We took it a bit further and developed about nine, I think, characteristics of a vulnerability that could each receive a rating of 1, 2 or 3. We struggled with the subjectivity of Risk = Likelihood x Impact. To curb the subjectivity we had to identify what elements contributed to making a vulnerability more likely to be exploited. Before this method, it was simply an educated guess that produced a number usually between 1 and 10. While each of the characteristics are still determined by this educated guess, the collection of metrics provides a more balanced result. Breaking the vulnerability’s likelihood into discrete characteristics allows the guesser to treat the elements uniquely and realistically. During our QA sessions with the method we saw many high risk vulnerabilities move to medium risk. The simplistic, single number metric of the old method loads in too many assumptions to be useful.

During the development of our method we found that in a corporate environment there were enough differences between off-the-shelf applications and in-house applications that some of the characteristics did not make sense in both contexts. Having a sane risk rating process is nice too, because developers and architects can also play the game too. Since the characteristics are mostly intelligible it is easy to sit in a room with the project team and rate the identified vulnerabilities together. So, in short, if you don’t have the time like we were fortunate enough to have, use what the OWASP project has provide. If you do have time, trust me here, use the OWASP project’s work and build from there.

I tend to hear and attempt to preach about this principle when given the opportunity. The principle here is that testing does not guarantee or validate the security of a system. Testing provides some evidence that implementation bugs may not be present in a system. It is not certain. In fact, testing as I’ve sketched it out has scope that should further qualify my statement. You only have evidence of the absence or presence of bug that you are looking for. Many times a test is viewed as some sort of rubber stamp “secure” label. In reality though these testing efforts are, by definition, narrow and finite and don’t have the evidential ability to confer the label of “secure” on a system that has been tested.

The objective of a secure system is to prevent all unauthorized use of information, a negative kind of requirement. It is hard to prove that this negative requirement has been achieved, for one must demonstrate that every possible threat has been anticipated.

- Saltzer & Schroeder, The Protection of Information in Computer Systems (1974)

Being in the security industry we’re constantly confronted with the problem of protecting data in transit and data at rest. Of course, everyone has a different way of describing data traveling somewhere and data staying somewhere semi-permanently, but I digress. In any case, data at rest or data’s primary place of residence has been a nasty little problem these days. Many will tell you that it solves the worlds problems. It protects data from bad guys and from good guys we don’t trust (which is sort of an oxymoron isn’t it?). At least that is the perception. Various forms well-intentioned, but wholly uninformed pieces of legislation are attempting to mandate the implementation of encryption at rest. I hear of products for database encryption, filesystem encryption, whole-disk encryption and others.

Many people have fallen victim to the “Use encryption and your data will be protected” fallacy. The have made the mistake of equating the use of encryption with the mitigation of a broadly defined set risks or risks are not defined at all. Sure, it makes people sleep well at night, but only because they think their understanding of the situation is complete and correct. Unfortunately, this is not the case and the sleepful nights should be coming to a close.

Encryption at rest solves one problem. Physical compromise. Yes, it’s true and I know it is hard to believe. It does reasonably well if someone walks into your data center, home, office or what not and walks off with your computers. I must add, though, that this too only works if your data is not currently “decrypted for use”. If it is, you fall victim to the usual attacks. So, to clarify it solves the physical compromise problem as long as your data is actually encrypted at the time of attack. In all other cases encryption at rest is useless. It is useless against a successful attack against an application and associated components that process the information. It is useless against a successful compromise of a system hosting your information. It is absolutely useless against the administrator you’re not sure about. Here’s why..

The application attack is aimed at the unencrypted data stream and therefore not protected by encryption at rest. The application (I’m using the broad definition here) processes the “real” data at many points so it is a grave mistake to presume that encryption at rest protects data as it is being processed.

The system attack is aimed at gaining access (usually elevated). It is a small step on many systems to get privileges that enable you to retrieve keys, passphrases and other material that is required to decrypt the data at rest. Nevermind those pesky out-of-band crypto-machines. The unencrypted stream has to get there for it to work.

Administrator trust issues? Yeah, you have serious issues if you don’t trust these guys. Sorry to say this, but if you don’t trust your administrators you trust them implicitly. Game over. If you have elevated privileges on a system or software the game is over. See the system attack for a sampling. The best you can do here is detect, but even that is problematic in the administrator game. Since they are “god” on systems and software they can potentially control entry and exit points.

The list can certainly be expanded and elaborated. Even this sketch is a compelling case for why people who use encryption at rest are not solving the problems they think they are. They shouldn’t be sleeping well at night, because their data is no more protected than it was prior to shelling out hundreds of thousands of dollars on products and services.

Again, encryption at rest is useful for the physical threats. The usual threats are laptop thefts, tapes falling off of trucks, DVDs being thrown away, etc. Laptops, mobile media and even servers with data being shipped across the country are all cases where this solutions works well. Using it for anything else is big money sink that could have been used to enhance all of the other relevant controls that can support the protection of data at rest.

So, I’m writing this little proof-of-concept tool that uses various icmp types and codes to smuggle data out of networks. It is useful for networks that have a significant amount of filtering, but still manage to let out icmp. I know, it’s a stretch. If they’re blocking most traffic and doing it smartly with a white list (default deny) then this little tool won’t be very useful. That’s okay, it is only the first phase in my Han Solo’esque smuggling experiment. Besides it’s quite fun, in the painful sort of way.

Not wanting to allow just anyone to see my super-secret payloads riding on top of the innocuous icmp packets I decided to use some encryption. I made the decision that some sort of high-speed symmetric cipher would do the trick. But how do I handle the key exchange? Diffie-Hellman to the rescue! Wait a minute. Not so fast. Wanting to reinvent the wheel I starting writing my own bug-ridden implementation and suddenly realized I had stumbled upon a problem that people have been working on since the times of Euclid. Smart people. With Diffie-Hellman two parties have to agree on an prime number. We all remember what those are right? Public school education? Okay, a prime is a number that can only be divided by 1 and itself. Anyways, for my tool I have to randomly generate a number and then determine if it is prime in order to use it in the key exchange process. Sounds easy, but I run into all sorts of challenges when testing for primality. For example, you can run some tests that give you reasonable probability that your number is prime, but it is not certainty. Certainty is a much more lengthy process. Well, it is to my brain. So, instead of writing code I’ve found myself reading all sorts of documentation on primality testing and playing with python to see if I’m understanding everything. Anyways, it is times like this that I wish I would have paid more attention in math class.

I’ve been dabbling for a while now with scapy. A quick cursory examination and you can tell that this tool has a lot of flexibility and power. It takes a bit of time to learn the method of packet building and the arguments to the various methods. In one of my first experiments with the tool I thought I’d attempt to detect systems running the nifty, if not completely insecure, tool known as ICMP Shell. This tool gives you access to a remote shell and communication to and from this system is over ICMP. The default behavior is to send and receive ICMP echo-reply messages (icmp type 0) with the id set to 60165. Using the provided ish client all this is handled for you once you give it the IP address of the listening system. Since we aren’t using the client the first order of business is to craft a packet that looks similar to the one generated by the client.

Here’s a walkthrough of the packet construction. But, before I begin, I used the ‘pre’ tags and because of that the lines do not wrap properly. In fact, it looks quite bad.

Welcome to Scapy (1.0.4.24beta) >>> ip = IP(dst="172.20.62.0/24", len=59)

All I need for a valid IP packet is the destination IP address and, because I’m using padding, a correct total packet length. There may be a way to automate this but I haven’t figured it out yet. You may be wondering why I have not specified any other options and this is because scapy picks sane defaults. To see which defaults it has chosen for this packet use ls(ip).

>>> icmp = ICMP(type="echo-reply",id=60165)

It is the same story here as well. I only need to provide the appropriate icmp type/code and also, because ICMP shell is expecting it, an ICMP identifier.

>>> id = str('x69x64x0a')

>>> payload = str('x00' * 20) + str('x02') + str('x00' * 7) + id >>> padding=Padding(payload)

The ICMP shell client pads the ICMP message with some data and if I do not duplicate the appropriate positions of this data it will be rejected by the ICMP shell server. Using a bit of python to save typing I’ve created the necessary padding.

>>> packet=ip/icmp/padding

Since we’ve already created placeholders for the various parts we only need to glue them together to create a valid IP packet. Typing the name of the variable outputs the constructed object. Of course, we could have saved some typing and done something like this:

>>>packet=IP(dst="172.20.62.0/24", len=59)/ICMP(type="echo-reply", id=60165)/padding

And that would have done the same thing assuming we defined padding appropriately. After this we're ready to inject these packets on the wire. When we're ready we type:

>>>send(packet)

There are many other methods we can use to send packets, control timeout, retries and other behaviors. This particular method sends packets at layer three without keeping track of responses. We are, at first, going to use TCPdump to track our responses. Below is what a standard ICMP Shell negotiation looks like.

$ sudo tcpdump -nexXs 1500 -i eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes 16:49:18.665206 00:11:25:47:72:b6 > 00:0b:cd:b8:7f:07, ethertype IPv4 (0x0800), length 73: 172.20.62.20 > 172.20.62.40: ICMP echo reply, id 60165, seq 0, length 39 0x0000: 4500 003b 0000 4000 4001 665d ac14 3e14 E..;..@.@.f]..>. 0x0010: ac14 3e28 0000 9f95 eb05 0000 0000 0000 ..>(............ 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0200 0000 0000 0000 6964 0a ........id. 16:49:18.669660 00:0b:cd:b8:7f:07 > 00:11:25:47:72:b6, ethertype IPv4 (0x0800), length 109: 172.20.62.40 > 172.20.62.20: ICMP echo reply, id 60165, seq 11264, length 75 0x0000: 4500 005f 0000 4000 4001 6639 ac14 3e28 E.._..@.@.f9..>( 0x0010: ac14 3e14 0000 32bd eb05 2c00 0000 0000 ..>...2...,..... 0x0020: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 0x0030: 0000 0000 0000 0000 7569 643d 3028 726f ........uid=0(ro 0x0040: 6f74 2920 6769 643d 3028 726f 6f74 2920 ot).gid=0(root). 0x0050: 6772 6f75 7073 3d30 2872 6f6f 7429 0a groups=0(root).

And here is what the scapy injected packed looks like.

16:50:35.649054 00:11:25:47:72:b6 > 00:0b:cd:b8:7f:07, ethertype IPv4 (0×0800), length 73: 172.20.62.20 > 172.20.62.40: ICMP echo reply, id 60165, seq 0, length 39
0×0000: 4500 003b 0001 0000 4001 a65c ac14 3e14 E..;….@….>.
0×0010: ac14 3e28 0000 14fa eb05 0000 0000 0000 ..>(…………
0×0020: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0×0030: 0200 0000 0000 0000 6964 0a ……..id.The result, again in TCPdump is

16:50:35.656251 00:0b:cd:b8:7f:07 > 00:11:25:47:72:b6, ethertype IPv4 (0×0800), length 109: 172.20.62.40 > 172.20.62.20: ICMP echo reply, id 60165, seq 11520, length 75
0×0000: 4500 005f 0000 4000 4001 6639 ac14 3e28 E.._..@.@.f9..>(
0×0010: ac14 3e14 0000 31bd eb05 2d00 0000 0000 ..>…1…-…..
0×0020: 0000 0000 0000 0000 0000 0000 0000 0000 …………….
0×0030: 0000 0000 0000 0000 7569 643d 3028 726f ……..uid=0(ro
0×0040: 6f74 2920 6769 643d 3028 726f 6f74 2920 ot).gid=0(root).
0×0050: 6772 6f75 7073 3d30 2872 6f6f 7429 0a groups=0(root).
Looks like we found a valid system that has ICMP Shell running on it. Hats off to scapy.

But, isn’t TCPdump a bit slow. Can’t we use scapy to filter through packets and show us only those that meet our criteria? Of course! Scapy has a sniff method that takes quite a few arguments. I have the minimum to get the job done.

>>> sniff(filter="icmp", prn=lambda x: x.sprintf("Found IShell: %IP.dst% > %IP.src% -- %Raw.load%"),lfilter=lambda x: str(x[Raw]).find("uid") != -1)

We want only icmp packets, we want to print some output and finally with the lfilter we’re telling the system to only deliver packets to the prn method that meet the criteria. In this case we’re looking for ‘uid’ in the payload of the ICMP packet. If uid is found we print out the source, destination and the payload for verification. I found out the long way the the lambda expressions only take simple statements. At first I tried to pack everything into the prn argument, but that failed miserably. Eventually I stumbled upon the lfilter and the realization of the statement requirement. Once you get past this I think it is smooth sailing.
There it is. Some basic features of scapy that, hopefully, demonstrate scapy’s flexibility and utility.

I took some time to download and install Microsoft’s latest application threat modeling tool. It is certainly a departure from the method documented in the Threat Modeling book. Not only that, the tool or the developers of the method manage to continue the confusion between threat, vulnerability and attack. They simply stop using the term vulnerability altogether. I may be picking nits here, but we need some consistency. That consistency can be had only if we agree on terms. How then can we have a meaningful conversation or, even better, how can we manage to use a tool that redefines terms without telling us. For example, the new tool quite nicely manages to automagically create “threats” based on our previously defined role, data, component and use cases. This really is quite nice. It forces the would-be modeler to really identify assets, actors and access controls within an application. But I digress. The “threat” you end up with seems to some sort of generic threat, but mysteriously you only have the ability to add attack countermeasures. But wait, where’s the attack? Sure we *could* say that the attack is the threat, but that is going a bit to the extreme isn’t it? I mean a threat is always an attack? I don’t think so, unless you say your building was attacked by a fire yesterday. So the confusion begins. Where is the vulnerability that realizes this threat? It seems to me that the guys were trying to hide|abstract|remove this ability. Correct me if I’m wrong (and I may be), but I thought the point of this threat modeling exercise was to use the identification of threats to detect and correct vulnerabilities that realize these threats. The tool goes a long way to make sure you understand what you’re doing in terms of understanding the application’s structure and function, but it leaves the analyst in a lurch when it comes time to use the identified threats as the source material for vulnerability analysis. I must say that their “attack” library is an excellent idea. Again though, they manage to confuse terms. They seemingly exchange attack for threat again. If we look deep enough into this library we finally see the term vulnerability pop up. Oddly enough, it actually *is* vulnerability information. What is odd is that some of the attacks appear to be threats, while others seems to be vulnerabilities. For example, the HTTP Replay Attack isn’t really an attack or a threat in my view. The threat in this case is that a user may attempt to spoof the identity of another user. The vulnerability is that the application, to use MS’s tool, utilizes “Ineffective or lacking verification of uniqueness of a request”. So where does the “HTTP Replay Attack” go? Well, I guess you can append it to the threat if you must, but why? The general threat and detailed vulnerability are the definition of a replay attack. Did I beat that enough? It is really not all bad because this “attack” library is quite nice. We happen to use something quite similar in my organization. We have a large list of well-known threats and when building our models we use these to define the high-level threats that are present. We customize the vulnerability information somewhat since it is application specific. Yes, I know, the vulnerability isn’t application specific in the strictest sense, but we like to put application specific information into our vulnerabilites so the readers know where to find them. Who knows, maybe the tools will grow on me, but with this sort of confusion I seriously doubt it.

Update: I read some of the other posts here. To be fair, it seems the tool’s focus has shifted somewhat. It no longer aims to be a purely security sme tool, but a developer, business and sme tool. With this in mind, I can understand why they’ve made some of the decisions with the tool. I still don’t entirely agree with some of the approach, but I guess the proof will be in the using.  In addition, it may be my “interesting” vantage point. From my view of the world, the devs won’t likely adopt a practice such as this for time time (especially since we’re not an MS dev shop). Because of this, we perform much of the discovery and threat identification. Take my views with a grain of salt.