August 30, 2004

(In)securities of SSL

Today Mark Wagner asked me how secure SSL is, in the face of a MSDN presenter who said that SSL was only secure when sent from client to the server. Since I didn’t attend this session and hearing this 3rd hand, I can’t really comment to the extent of the presenter’s view, as I have no context to base his assumptions on.

However, as a security professional let me give you my take on the (in)securities of SSL.

SSL is one of those tools that give people a false sense of security. Touted as the end-all/be-all for eCommerce security, it has been shamelessly plugged as the best solution for secure transactions. The reality is that it is far from it.

SSL doesn’t provide the right protection mechanisms that you think it does, and actually does nothing to protect you when you expect it to. It really is nothing more than a secure communication channel with weak endpoints. It uses public key encryption and provides data encryption, server authentication, message integrity, and in some cases, even client authentication. These are all good things. And you rarely hear about attacks against the communication channel itself.

However, you are only as strong as your weakest link. In this case one aspect is the end points. Although you have data integrity across the SSL channel, once it hits the server or client it is decrypted and at the mercy of the machine. The attack path won’t be against the communications pipe, but rather the unencrypted data on the endpoint. Further to this, the weakest link is the human factor when it comes to security. It is common for administrators of these endpoints to misconfigure the SSL endpoint or use lax security policies for protecting this configuration, putting the tunnel at risk. I have seen a few cases in the past where people have used Linux boxes with OpenSSL and then have copies of their cert lying around (and worse yet world readable access to the private cert), which makes the tunnel moot; once an adversary has the private cert he can simply use it to decrypt the session midstream at any time. Actually, some application level firewalls use this to their advantage to allow them to “covertly” monitor SSL streams entering the network by decrypting the stream, reviewing the content, and then deciding whether or not to actually forward it to the real host you intended it to.

If history is an indication, attackers couldn’t care less about the stream. Most information disclosure incidents which relate to theft of data are actually done by breaching the host, and just taking it. Why? Because it is easier to use a weaker attack vector such as vulnerable software on the host than to try to breach an encrypted stream. It’s like spending $15,000 for a solid core oak door at the front of your house, and then leaving the $100 back door unlocked. Your effective level of security is really $100… not $15,000. (Some infosec pros would say the effective level of security is actually $0, the back door was open anyways… but that’s not the point)

Does this mean we shouldn’t use SSL? Far from it. Using SSL to secure communications is a good thingTM (sorry Martha… sue me from jail). But to really be effective solid security policies need to augment this by ensuring strong data protection of the data as it enters the host. Levels of data integrity and assurance need to be maintained by ensuring that as the data enters the system it continues to be protected. Further to this, remember that for secure communications SSL cannot be used to create a trust relationship between the client and the server. It can really only give you a CERTAIN level of assurance that you are connecting to the right server. An implicit trust level must occur in the stream for the exchange of data.

So Mark, SSL itself can be made secure in either direction. But that’s a moot point. Neither the client nor the server can be trusted past that without other methods of authentication and authorization to be in place for access to data.

Hope that answers your question.

Posted by SilverStr at 09:12 AM | Comments (3) | TrackBack

Getting SBS to work standalone in a DMZ with a single NIC

So earlier this evening I came across an interesting little "issue" with Small Business Server 2003. The wizards that work to configure the firewall and other major security settings fails to work correctly if you have a single nic card. Further to this, if you are not careful you bind both the internal AND external to the outside world. (Thank god this sucker is in a DMZ with some heavy iron on the outside to prevent the script kiddies from playing while I work this out)

Realizing it needs two ethernet cards to "do its things", I came up with the idea of using a virtual network adapter, similar to how VMWare works. After searching google for some time... I was hit with a tonne of bricks when I thought to myself ... "why not just fake it with a loopback device".

So I did.

Well, I tried anyways. Although I could add the loopback device in, I just couldn't seem to change the binding order, which was preventing me from setting the loopback device as the INTERNAL nic, and the real nic as the EXTERNAL one.

Solution?

Remove the real network device. Add the loopback device, and give it a private class C address (192.168.*). Add the real nic back. Configure it as per info from ISP. Walla. Small Business Server and ISA are none the wiser, and you can now use the direct broadband wizards correctly! Just finished tweaking the firewall and doing a vulnerability scan, nmap scan and pentest. It's locked down tight.

Next step when I have some spare time... to configure ISA to force authentication before access to any URL (including OWA) via HTTPS in a browser. I'll keep you posted on how I figure out how to make that work.

Posted by SilverStr at 02:29 AM | Comments (4) | TrackBack

SBS Rant

OK, I want to rant. Feel free to ignore me.

Would someone be so kind as to tell me WHY all SBS wizards require that I have two ethernet cards in my box to denote private and public addressing to do all the normal security features? What if I want to simply put a box on the Internet, but still use the frigging ISA configuration, WITHOUT having a network behind it????

You know. Like a server on the Internet in a DMZ. What's sad is that the Internet Connection wizard even tells you that you need a separate firewall if you work in "router mode with a local IP". Why can't ISA be that firewall.. OUT OF THE BOX!!!!

*sigh*

The sad thing is a simple fix would be to throw a nic card in there and simply not use it... and call it the internal IP network. Unfortunately I don't have the room on the board to do so.

Time to dig through google and see if I can fake this out with a virtual adapter somehow.

Posted by SilverStr at 12:05 AM | Comments (8) | TrackBack

August 27, 2004

Locking down OWA with ISA 2000

Sorry that I have been so quiet lately. Been emmersed in so much work it isn't funny. Top that off, I took some time this week to work on some personal development and do a leadership and skills training workshop which has had me swamped.

In the little free time I do find I have been spending some time getting to understand the relationship with ISA and SBS, and came across a REALLY good set of articles showing how to configure ISA to pre-authenticate connections BEFORE even getting to try any type of interaction with the IIS web server, and OWA. In other words, you can filter out a lot of anonymous attacks by authenticating users before they can actually send tainted data towards OWA. A really good strategy.

The articles are based on having a dedicated ISA server on a stand alone box in front of the Exchange server, but of course my limitation of having everything on one box for SBS makes that kinda of difficult. None-the-less, it was still a very insightful set of articles. Well worth reviewing if you are new to this sort of stuff.

The articles are broken down into five distinct components:

  1. Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 Part 1
  2. Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 Part 2: Understanding SSL Bridging and Installing an Enterprise CA
  3. Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 - Part 3: SSL Bridging Drill Down and Requesting a Web Site Certificate
  4. Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 - Part 4: Importing the OWA Web Site Certificate, Binding the Certificate to the Web Listener and Creating the Destination Set
  5. Publishing Exchange 2003 Outlook Web Access (OWA) with ISA Server 2000 - Part 5: Creating the OWA Web Publishing Rule, Configuring DNS and Installing URLScan 2.5 for ISA Server Firewalls
I would be interested to see if ISA 2004 is any better for this sort of thing. For now I think I better stick with ISA 2000 since it comes with SBS2003.

Anyways, enjoy if you haven't seen these articles yet. Happy Reading!

Posted by SilverStr at 12:55 AM | Comments (3) | TrackBack

August 19, 2004

Dana using SBS2003? No I am NOT nuts

Ok, so I never expected this. A little itty bitty blog entry that would cause such a stir that I received over 25 private emails from people.... ranging for honest to goodness help and suggestions to quasi-death threats for being so stupid. Why don't you guys ever comment on my blog???

Rather than respond to each email individually, I thought I would just break down and explain my thought process on why I am considering SBS2003.

As a computer security professional who LOVES Unix environments... you would think I would stay away from ever having a Microsoft product on an Internet facing server. You wouldn't be far off from that assumption, as Microsoft's history in this manner hasn't been the greatest. Quite frankly I refuse to look at any version of Microsoft's operating system older than Windows Server 2003. However, I think that only the fool hearted would back themselves into a corner and take a stance of an OS zealot. We saw this years ago when "Team OS/2" was preaching that you need to be "Warped". Not a pretty sight. Then we saw it with Linux. Hey... I got sucked into that one.... as I truly believe in many of the benefits of the operating system. I was one of the original geeks at LinuxWorld, preaching the powers of Linux before it was kewl to do so.

Yet for me, over the years I have come to realize it is all about selecting the right tool for the right job. Absolute security is a myth. What needs to be done is to find the right tools with the right safeguards to help defend against the digital divide. In other words, its about putting enough security in to defend against the risks exposed to us out there. Not ALL the security in the world. "Just enough security" to do the job. Am I going to prevent covert black bag ops issued by foreign governments from circumventing my safeguards? Probably not... the ISP that hosts my servers will typically fold like a cheap suit under pressure. But by understanding the threats to which I am exposed to while ensuring I have control over the assets I wish to protect, coupled with smart decisions on how to mitigate these threats in a practical manner, I can gain the assurance that I need in using a Windows platform of today.

You see, any operating system can be made safe. It is just that practically every commercial operating system shipped today isn't done so in its initial state. And I include many Linux environments in there as well... not just Windows. Just as an OS can be made safe... it is just as easy to make it susceptible to attack.

Past these views, the decision is then weighed against fiscal responsibility. After all, I am an owner of a really small ISV where cash is king... and spending thousands upon thousands of dollars for licensing doesn't make a whole lot of sense when you don't need to. And that is the point of view I would like to use as I talk about my decision to look at Small Business Server 2003. It might make sense if I give some background information to help you see how I came to my decision.

The Growth of a Small ISV


In the past two years I have been building a small ISV that is focused on building host-based intrusion prevention software for the Microsoft Windows platform. Focused towards the small to medium business target demographic who use Microsoft Windows servers, I found myself being emmersed in the platform. For good, bad or indifferent I have come to realize that Windows Server 2003 isn't all that bad. It has a ways to go yet... but the kernel itself is getting pretty good.

Self funding the company, the last thing I wanted to do was to shell out tens of thousands of dollars for all the licenses I would need to run a Microsoft shop. Being a fan of Linux with years of experience under my belt, it took me less than an hour to get a Debian server up and running with SSH, email, secure web, database and all the fixings. An hour after that, I had the firewall in place, a good IDS net and remote logging and monitoring facilities that would rival an ISP NOC. It cost me little more than my time for a couple of hours, the cost for the hardware and the cost to put it at the ISP. When measuring direct TCO for this solution, its a joke to try to measure it against Windows Server. Microsoft's offerings fall flat on their face. They simply CANNOT measure up to a Linux server focused on offering a simple hardened web server with email and database access (Personally I am a PostgreSQL fan). Now before you freak out and try to pull out all the Microsoft marketing hype on TCO... give it up. Read the whole article before your criticize.

You see, if you have the experience and have normal "Internet services" access needs a Linux server is a great choice. You know what you are getting. Very little EXTRA is exposed... and you don't have to fear the unknown. You know what you are running, and you know what to secure against. But what if you have more needs? What if you have to grow the business communications? What if you need it to scale to support more business services. Well, then options for Linux start to thin out.

Let me explain where I am going in the next two years so that point can make sense. I am growing the business and expect to be hiring at a minimum 25 new people. Most of these people will work in a virtual environment, working in the field or from home most of the time. Telephony is managed by using VoIP services through an Internet PBX offered through a company called Packet8 which gives me excellent PSTN access while ensuring clean PBX bridging functionality across the Internet.

Email, shared calendaring, contacts and files will be managed through Outlook Web Access (OWA). Lets be honest, very few offerings in Linux support such good group collaberation and communications as Exchange. Although commerical competitors such as GroupWise and Lotus Notes are nice, the complete integration that Microsoft has done in the browser with OWA 2003 is just amazing. Have you seen this thing? Not only is it pretty... but its extremely functional... and works just like the Outlook client. And lets not go into the open source group collaberation servers, or webmail clients like SquirrrelMail. They are just not ready for real collabertive business interaction and use.

Why not use the Outlook client then over HTTPS? (Yes you can do this if you didn't know) Well, you will be able to. But only on machines I can trust; machines the company has actual authority over and can manage. In many situations though, that won't be available. OWA (and OMA for those of us lucky enough to have an MPx200) will be the only solution for them.

To strengthen the authentication process and create a strong audit policy for these remote users to Active Directory I am going to roll out two factor authentication with one time passwords (OTP). I was originally looking at using RSA SecurID keyfobs and the USB 6100 USB key smartcard, but the costs are quite prohibitive for a small company such as mine. You have to buy at a MINIMUM 25 licenses TO START, and there are ongoing licensing costs and upgrades to tokens needed after a period of time. I found another company offering similar technology, but at a fraction of the cost. Authenex offers an OTP token called A-Key which ALSO supports USB key storage for PKI. The interesting thing is that the OTP is shown ON the USB key, where as RSA uses a smartcard approach and requires a USB driver be installed to work. RSA's approach won't work when at a location where USB access is prohibited, or not desireable. Which is why I am looking at Authenex.

A note to the security vendors out there. Small businesses are not second class citizens! We have security needs just like the big boys. Why is it so hard to believe a small business of 5 or 10 people wouldn't want to implement strong security solutions? Think about that next time you do market research. You are missing a HUGE target demographic and I bet if you looked... you have some easy wins that could increase you sales pipeline.

So anyways, I have been taking a bit of a tangent explaining what is going to happen and give you a background on some of my needs. Now let me explain why I blogged about looking for a SBS MVP. Quite frankly I think Microsoft is doing a big diservice to its customers in not talking about SBS, and I wanted to poke around to see who was in the field. For small companies like my own, Microsoft has a very compelling offering which actually DOES show a sane TCO argument. It's in an unknown product solution called Small Business Server 2003, more commonly known as SBS2003 (or sometimes just SBS).

SBS2003 is an an inexpensive server solution which is really just Windows Server 2003 installed with Exchange 2003, SharePoint, ISA 2000 and SQL Server. It is slightly more restricted than Windows Server 2003 in that all the components must be loaded on a single domain controller. Although you can have secondary file and print servers... everything else must reside on a single box. From a security perspective this isn't really desirable (See my post on the 8 Rules of Information Security to understand why; the Rule of Seperation is really important here.), as you really should separate services, but its a reasonable limitation for most small businesses. After all, most small businesses don't have a plethora of server hardware to support seperation anyways.

Another limitation includes the fact you can only have one domain. The domain is based on Active Directory, but it cannot form trust relationships, which kinda sucks for more complex deployments. Again, not a serious limitation for most small businesses. The final limitation that I know of is that there is a client limit. You can only buy 75 CALs (Client Access Licenses) for the server. At this point, you will probably be moving to a larger server anyways, so again... this isn't a real big limitation for most small businesses.

Depending where you get it, this entire bundled solution costs about 1/5th the cost of a similar deployment done by putting pieces together of various Microsoft technologies due to its tight integration with all the components. The cost savings are enormous, and match in many respects to the same costs of a Red Hat Advanced Server offering similar services. But that tight integration is also its weakness (in my opinion), which is why I was calling out to SBS experts.

I have real concern with not knowing how everything is interacting on this box. If you recall, earlier in this post I explained how that was a strong point in Linux. I don't have that same confidence in SBS. As I am not an expert in Sharepoint or IIS configuration, I get chills when reading documentation about how you can surf to shared resources in this manner with a browser. I begin to fret when I see administrative tools accessable via little known URLs (which attackers know)... especially when I thought I turned them off. This is where experience comes into play, which is why I am seeking out a local expert in the lower mainland of BC.

All I want to do is expose two ports.... SMTP (port 25) and HTTPS (port 443) to the world. The first for mail coming in and going out and the second for OWA access. I don't want ANYONE to be able to go to ANY URL without first authenticating to Active Directory... and quite frankly... I don't know how to configure that. And thats why I am seeking out the expertise.

I had some interesting and helpful feedback from Susan Bradley who introduced me to a few MVPs and gave me some recommendations. It looks like I might not need an MVP after all, but just a really qualified MCSE or something. Of course, with the ratio of idiots to experts in the MCSE field, its really hard to determine which camp they lie in. I guess some further research may assist me in making that determination.

So there you have it. I don't have really complex needs... but they are not exactly normal either. I am confident that SBS can be locked down... just as I am confident that I can find default Linux installs that are not. No operating system is a panacea, but I do believe Microsoft's SBS offering makes sense, is cost effective and is quite manageable. I know I am just being paranoid, but I would rather be that than be 0wned. So thanks to those who have sent me feedback and hooked me up with others. And thanks to those who have criticized me and challenged me to explain myself. Writing this has made me realize I am maturing in my understanding and management of risk, and breaking the shackles of ignorance as it comes to operating system zealousy. (Ask around... I used to be pretty bad).

Posted by SilverStr at 02:50 PM | Comments (12) | TrackBack

Small Business Server 2003 MVP out there?

Is there a SBS 2003 MVP out there that reads my blog?

I am looking for a security-conscious individal who may have some time to do some thoughtful reflection with me on the intricities of putting a SBS2003 server on the Net with OWA and OMA. This individual should live in the lower mainland of British Columbia, closer to the Abbotsford/Chilliwack/Hope area.

Experience in setting up Active Directory with two factor authentication (RSA SecurID or Authenex A-Key) and the usage of ISA 2000/2004 is recommended, but not essential.

If you fit the description, drop me a line. I might have some work for you.

Posted by SilverStr at 07:28 AM | Comments (2) | TrackBack

August 17, 2004

Microsoft Baseline Security Analyzer V1.2.1 Released

A new version of MBSA was released yesterday to allow users on XPSP2 to take advantage of the tool.

In case you didn't know, MBSA is the free, best practices vulnerability assessment tool for the Microsoft platform. It is a tool designed for the IT Professional that helps with the assessment phase of an overall security management strategy. MBSA Version 1.2.1 includes a graphical and command line interface that can perform local or remote scans of Windows systems.

You can go grab it here. More information can be found here.

Posted by SilverStr at 01:14 PM | Comments (2) | TrackBack

Recommendations for an Obfuscator?

Can anyone out there in C# land give me some recommendations for a good Obfuscator for standalone C# apps under the following parameters?

  • Must be able to be launched in an automated build environment (through nant)
  • Should do String and Resource encryption/hiding
  • Should just work. No weird complex profiling needed for apps
  • Must defeat all known decompilers
  • Must fit the pocket book of a small ISV

The short list I have compiled so far include:


Anyone have any real experience with any of these? I am currently using DotFuscator Community Edition which comes with Visual Studio .NET, and it blows as it needs Visual Studio to be open and running for it to work, which means it won't work in my automated build environment. I need something, but not sure what to turn to without having to either mortgage my house or live with half my stuff not being obfuscated.

Advice and feedback welcomed!

Posted by SilverStr at 08:42 AM | Comments (1) | TrackBack

SHA-0 Broken, MD5 Rumored Broken

"Anyone who creates his or her own cryptographic primitive is either a genius or a fool. Given the genius/fool ratio for our species, the odds aren't very good."

- Bruce Schneier
So the Internet is a buzz with rumors of SHA0, SHA1 and MD5 being broken.

There is an email that started this, reporting that a collision was found in SHA0. Further to this, a paper was published yesterday showing collisions in MD4, MD5, HAVAL-128 and RIPEMD. This paper couldn't be verified originally, but this morning I found a post where a cryptographer was able to successfully reproduce the collision results on MD5. You can even download the source and verify it yourself if you are so inclined.

So what does this mean about the cryptography field? Nobody really knows. Is it still safe to buy your antique collection of Smurf memorabilia online? Absolutely. For now.

Theory and practice are two different things. Simply finding a collision doesn't make a cryptographic hash function (CHF) worthless. I think Edwin said it best when he says that the finding of a single collision in SHA-1 would not, by itself, cause much trouble, since one arbitrary collision won't do an attacker much good in practice. But history tells us that such discoveries are usually followed by a series of bigger discoveries that widen the breach, to the point that the broken primitive becomes unusable.

To be cryptographically sound, a CHF should have two main properties:

  1. Given a digest from a source, it must be essentially impossible to figure out what data generated that digest.
  2. It must be essentially impossible to find two different data values that have the same digest, which is commonly called a "collision".
A break in the SHA-1 primitive (which is one of the most used CHF, and is recommended by NIST) may lead for the need to refactor code using it, including applications that use technology like digital signatures. (Which could be ugly for the eCommerce world)

Of course right now this is just rumor, and hasn't been verified. Will be interesting to see what is published from the CRYPTO conference this week.

Posted by SilverStr at 08:16 AM | Comments (1) | TrackBack

August 13, 2004

Arp cache issue with NMAP

Was talking with Fyodor yesterday and he brought to my attention the fact that in SP2, Microsoft also added some new anti-arp-spoofing code which, on top of the raw sockets, prevents nmap from working correctly.

This means that unless your target is in your arp cache, nmap will not find the host.

Well, that is, until I added arp support into the patch.

You can read more about it from Fyodor in the post he made today over on nmap-dev.

If you want to grab the new patch (yes thats 3 revisions in less that 24 hours), you can grab it here. If you don't want to build it yourself, Fyodor has merged my changes into nmap and you can download it here.

Posted by SilverStr at 12:02 AM | Comments (6) | TrackBack

August 12, 2004

Updated nmap patch for XP SP2

Thanks to everyone for the kind words about the patch. I have received tonnes of mail today, and I appreciate the thanks. However, I am just a small cog here and the real thanks should be going to Fyodor for making such a kick-ass tool in the first place.

One criticism I have gotten in a bunch of the emails was to so aggressively STOP raw socket support. You are right, this patch stops raw socket on all Windows systems. I wanted to get a quick fix out, and wasn't expecting people to put it into their main master sources for nmap.

Alas, not one to leave loose ends, I have updated the patch to do a version check against XP and which service pack it is. Quite simple really:

--- winip.c 2004-08-12 10:18:46.000000000 -0700
+++ winip.c 2004-08-12 16:04:56.000000000 -0700
@@ -379,6 +379,13 @@
rawsock_avail = 0;
}

+ // Disable rawsock support if its XP SP2
+ if( ver.dwMajorVersion >= 5 && ver.dwMinorVersion == 1 && ver.wServicePackMajor == 2 )
+ {
+ winbug = 1;
+ rawsock_avail = 0;
+ }
+
if(pcap_avail)
{
if(wo.trace) printf("***WinIP*** reading winpcap interface list\n");

You can download the updated patch here.

Posted by SilverStr at 04:15 PM | Comments (3) | TrackBack

nmap patch for XPSP2

For those people who need nmap working on XP SP2, I have written a quick patch that will remove raw socket support from nmap and let nmap work again, failing over to standard mode as it is in previous versions of Windows.


--- winip.c 2004-08-12 10:18:46.000000000 -0700
+++ winip.c 2004-08-12 10:19:08.000000000 -0700
@@ -379,6 +379,9 @@
rawsock_avail = 0;
}

+ winbug = 1;
+ rawsock_avail = 0;
+
if(pcap_avail)
{
if(wo.trace) printf("***WinIP*** reading winpcap interface list\n");

You can also download the patch here.

Posted by SilverStr at 10:28 AM | Comments (3) | TrackBack

XPSP2 rips out raw sockets

Ok, now this just sucks.

One of the 'security additions' added to XP SP2 is the fact that raw sockets are no longer available. Result? Tools like nmap no longer work in their current form.

The reason from Microsoft. 'Only attack tools seem to use raw sockets'.

ARG!!!!!!!!!!!

So be forewarned. If you upgrade to SP2, you will lose access to nmap. Now I got a valid reason for keeping my other Linux box around ;-)

My next buy was going to be a TabletPC. Wonder if I pray hard enough if Steve Jobs can 'Newton-afy" a Powerbook and give my OSX on a powerbook supporting tablet functionality. Then I could have raw sockets, OSX and a tablet all rolled up in one. *sigh*

Posted by SilverStr at 08:31 AM | Comments (12) | TrackBack

August 11, 2004

Top Security Papers for New Security Software Engineers

Recently on the SC-L mailing list a discussion on some of the topic good security papers has insued. As you know, on the right side of my blog I have some of my personal favorites. Those are papers that at the time of reading, actually "changed" my thinking in some way. What it doesn't truly reflect is what are GOOD papers for OTHER security software engineers.

To rectify that, let me give you a list (in no particular order) of my favorite "security papers" that have interesting components. Please note this is FAR from an exhaustive list, but merely papers that I read that I enjoyed at the time.

Funny thing is, most of these are over 20 years old! What does that say for our industry, when many of the issues in infosec have foundations we could have learned from so many years ago?

Anyways, if you have the time, consider reading some (or all) of these papers. Good stuff.

Posted by SilverStr at 11:07 AM | TrackBack

August 06, 2004

Understanding Tangible ROI Through Secure Software Engineering

Sadly in this day and age, most application security is bolted on after a product is launched. It is weird but generally accepted software engineering principles hold that software flaws are less expensive to fix earlier in the application development process, but the same thinking isn't applied for application security. People don't understand how a properly documented threat model can really expose an application through its threat profile and find more critical vulnerabilities before a product launches, which has a similar cost/benefit as the ROI for finding normal software flaws. (In my opinion even more savings due to reputation and credibility loss, customer risk etc that are more exposed when not done)

There is a short paper on the subject that examines if cost savings justify an early investment in secure software engineering. Entitled Tangible ROI Through Secure Software Engineering it examines return on security investment by looking at security defect remediation costs and cost multipliers to the entire process.

The paper itself was published back in 2001, but the content still applies today. If you have any interest in understanding if there is a tangible ROI in secure software programming, consider reading this paper.

Posted by SilverStr at 11:29 AM | TrackBack

August 04, 2004

Web Based MSN Messenger

Kudos to Microsoft. I just stumbled across a beta of their new Web Based MSN Messenger.

It even works great through FireFox. I use Windows Messenger exclusively now (Windows Messenger is MSN Messenger without any ads :) ), surrendering my Jabber, Yahoo and ICQ accounts. If I find myself offsite and don't want to use my MPx200, I now have a new way to stay in contact. Works great.

Good job Microsoft!

Posted by SilverStr at 11:19 PM | Comments (7) | TrackBack

Upgrade your Putty Clients IMMEDIATELY!

To all the Windows users using Putty for SSH, please upgrade your putty clients IMMEDIATELY.


PuTTY 0.55, released today, fixes a serious security hole which may allow a server to execute code of its choice on a PuTTY client connecting to it. In SSH2, the attack can be performed before host key verification, meaning that even if you trust the server you think you are connecting to, a different machine could be impersonating it and could launch the attack before you could tell the difference.

You can grab the latest version of putty here.

Of course, if you use cygwin and use OpenSSH... you're fine. :)

UPDATE: A reader of the blog pointed out that I am blindly pointing to the executable, which for the paranoid could be a bad thing without explaining what is going on.

You can go to the putty main page to read the news and get the above statement in detail.

Posted by SilverStr at 11:25 AM | Comments (7) | TrackBack

August 03, 2004

Book Review - Threat Modeling

I finished reading Threat Modeling last week but just haven't had time to blog a review about it until now.

I first learned of Frank Swiderski when he worked at @stake, meeting him in passing at a convention. When I heard he was working for Microsoft as an application security specialist I wasn't to sure what was going on.

Then he released a pretty good threat modeling tool (check out his Channel9 interview on the subject) and I started to put it together.

Out of no where, announcements of his new book on threat modeling were abound. I dug deep trying to find it, only to learn it wasn't actually released. I waved my money at Amazon, but they just wouldn't take it until the pre-order.

Long story short, I finally got it. And it was well worth the wait.

If I could sum up the book in a single sentence it would be something like, "Frank took the ball from Michael in Writing Secure Code (WSC) and ran with it to the goal line." This book picks up where Michael left off, and completes the picture of threat modeling in greater depth. But you would have to expect that. The threat modeling process is evolving at Microsoft and the snap shot we see in this book is knowledge improved upon since the release of WSC. Actually, you will notice a big difference between v1 and v2 of WSC, and this step was logical in the new book.

With that said, an abridged table of contents can show how this was broken down:

  1. Introduction to Application Security
  2. Why Threat Modeling
  3. How an Adversary Sees an Application
  4. Constraining and Modeling the Application
  5. The Threat Profile
  6. Choosing What to Model
  7. Testing Based on a Threat Model
  8. Making Threat Modeling Work
  9. Sample Threat Models

Now that I read that TOC, it doesn't do the book justice. Let me see if I can provide some highlights of the book.

First off, one thing I really liked was the fact that almost HALF the book is dedicated to actual sample threat models, showing practical applications approached differently. Throughout the book three examples were used:

  1. Fabrikam Phone 1.0 - A phone system
  2. Humongous Insurance Price Quote Website - A simpe web application
  3. A. Datum Corporation Access Control API - A software library
These three examples were interesting as it showed different approaches to threat modeling, in three different areas. These examples really hit home for me, and brought concepts together quite nicely.

An area which I enjoyed was looking at how an advesary would approach the system. Now, this isn't like how Gary did it in Exploiting Software: How to Break Code. In a simplistic overview, Frank presents it like:

An advesary's view is based on entry points of the system, which when entered get you access to assets, based on what trust level you appear to have. An application can not be attacked unless an adversary has a way to interact with it, and an asset of interest must exist for that to occur. In other words, a threat cannot exist unless there is an asset that interests the advesary.
You can explore how this comes about by properly modeling the system with the use of data flow diagrams (DFD). I really enjoyed this part, as I never properly understood how to graphically depict this. With this new knowledge I will make better use of the visio component in the threat modeling tool Frank released.

Quite frankly I found a lot of things approached different in the book. In my office our use of threat modeling has been to create a Threat Profile by classifying threats against STRIDE effects for each part of the system, and then map attack trees on how to exploit that. When complete we would then use the standard infosec risk formula of...

risk = Probability(chance) * Damage Potential (damage)
... to prioritize the risks and they reduce it with mitigation techniques.

This book showed me a lot of new ways to approach threat modeling. We were only doing a fraction of what really COULD be done in threat moding. From data flow diagrams to DREAD analysis, the book shows how to properly do an end to end threat model.

Would I recommend this book? Absolutely. Do I have any complaints? Only that I now want to go back and redo our threat models in greater depth. I have to make time for this... crucial time I don't really have. Of course, the book even covers that off, and helps to show how in a time crunch, how to prioritize things to get the most in the least amount of time.

I arrogantly believed I knew everything there was "needed to be known" about threat modeling to use it in a real world environment. I was wrong. This book has exposed me to a greater depth modeling process which should be a requirement in any development environment. Get this book. Period.

Posted by SilverStr at 08:40 AM | Comments (4) | TrackBack

Mozilla Security Bug Bounty Program

Now here is something interesting.

Mozilla is offering $500 USD and a free t-shirt to anyone who reports critical security bugs. They are calling this their Mozilla Security Bug Bounty Program. With some donations from Linspire and Mark Shuttleworth, Mozilla is offering this program for any of the STABLE release end-user software (ie: FireFox, ThunderBird, Mozilla)

It is an interesting idea. And it puts their money where their mouth is. I wasn't to sure about the program when I first heard about it, but after taking a glace at the Security Bug Bounty Program FAQ I am convinced it could work.

Only question is, I am curious how they deal with conflict resolution. What if two people report the same bug, but with different test cases? What if the bug exposed two different threats? I'm glad I am not on the committee that has to decide that.

Wonder if other software companies would ever do this. Hmmm.... hey Bill I know what you can do with those Billions!!!!

Posted by SilverStr at 07:40 AM | TrackBack

August 02, 2004

FirstOnScene, the 10-second Forensic Data Gathering Tool

bmonday announced that he has released a script called FirstOnScene which basically will take a working forensic snapshot of a Windows system within 10 seconds.

Basically he has written a visual basic script wrapper of some of the more common tools from guys like SysInternals and Foundstone. I haven't actually tried it yet, but will definitely follow his progress and see where this tool ends up. It sounds quite interesting.

I have something similar that I use, but is based on a bootable live CD. Why a separate bootable CD you ask? Because Windows has a major inherit problem from a forensic analysis point of view. By simply running some of the standard auditing tools you trample on critical evidence as it relates to cache, swap and data access. (This is an issue with the OS, not the tools) Timelines get tainted in an unfortunate way if you do to much on a Windows system for to long after you enter the system. Normally, unless I HAVE to get a map of volitile memory, I just pull the plug, mirror the drive and work on the data on an isolated forensic machine.

But thats just me.

Anyways, looks like bmonday has been busy. If you got the time, check of FirstOnScene and see if it meets your needs.

Posted by SilverStr at 12:34 AM | TrackBack