January 31, 2004

WSH: The demon of the dark

Recently Peter posted a good comment about how the Windows Script Host (WSH) is not actually riddled with vulnerabilities, even though its one of the FBI's Top 10 Windows Vulnerabilities.

He has a good point there. However, I do understand why its a nasty beast that is on the list. Combined with things like alternate data streams (ADS)... you can wreak HAVOK on a system that has scripting turned on (which it is by default on most Windows installations), and in many cases HIDE malicious code from even being detected.

If you are new to ADS, consider reading my previous post on The Dark Side of NTFS (Microsoft’s Scarlet Letter). The very fact that you can hide malicious code in a stream which most anti-virus and IDS/IPS tools will miss astounds me even to this day. Once more virogens figure this out... we will have a new attack vector to fight with.

Peter also brought up a great point though on how to stop scripts that are not signed. And that is to use Software Restriction Policies (SRP). One cavet is you must be running WSH 5.6 I believe, which means you will need to be running atleast Windows XP. (I may be wrong here). If you want to look at this method, consider reading this article on WSH on how to deal with this.

If you don't want to use SRP, there are some registry keys you can set. Under either HKLM or HKCU, take a look at the \Software\Microsoft\Windows Script Host key. Four values are relevant here: Enabled, TrustPolicy, UseWINSAFER, and IgnoreUserSettings. Here are their effects:

  • If Enabled is set to zero, then WSH will not run at all.
  • If TrustPolicy is set to zero, then all scripts will run. If it is set to one, then all signed, trusted scripts will run; unsigned scripts will prompt the user. If TrustPolicy is set to two, then only signed, trusted scripts will run and there will be no user prompt.
  • If UseWINSAFER is set, then there is first an attempt to use SRP if it is installed. If it is not, then this flag is ignored and the TrustPolicy flag is followed.
  • By default, both the HKLM and HKCU settings are checked and the user settings are followed rather than the machine settings. If you want the machine settings to be the default, set IgnoreUserSettings in the HKLM path to one.

It is sad that most of this is hidden away and unknown to most users. More sad that these "new features" are not turned off by default, reducing the attack surface of the platform. (Although as I have said before, Windows Server 2003 made a stronger effort in reducing the surface significantly) As Microsoft continues to work on this, hopefully the future will reduce the potential threats that can occur from such software, and move tools such as WSH off the FBI's top 10 list.

Thanks for pointing out SRP Peter.

Posted by SilverStr at 11:24 PM | Comments (4) | TrackBack

Using Threat Analysis to Design More Secure Systems

I am a big fan of threat modeling. Microsoft has released a great resource on doing threat analysis for more secure systems.

Check it out to see how to design and build more secure systems by evaluating threats and selecting technologies to counter those threats.

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

January 30, 2004

DHS Unveils National Cyber Alert System

The US's Department of Homeland Security unveiled the National Cyber Alert System, an operational system delivering to Americans timely and actionable information to better secure their computer systems. Called US-CERT, it provides coordinated national cyber security system for identifying, analyzing, and prioritizing emerging vulnerabilities and threats.

You can read more about it here.

Basically they have three distinct areas of operation:

  1. Cyber Security Tips
  2. Cyber Security Bulletins
  3. Cyber Security Alerts

I just wonder if Canadians will be allowed access, or get our own. Hey CSE, where is our equivalent??

Posted by SilverStr at 10:44 AM | TrackBack

Is finding security holes a good idea?

Eric Rescorla released a research paper this week looking at how effective bug reporting of security holes may be. His abstract goes a long way to explain his research:

A large amount of effort is expended every year on finding and patching security holes. The underlying rationale for this activity is that it increases welfare by decreasing the number of bugs available for discovery and exploitation by bad guys, thus reducing the total cost of intrusions. Given the amount of effort expended, we would expect to see noticeable results in terms of improved software quality. However, our investigation does not support a substantial quality improvement--the data does not allow us to exclude the possibility that the rate of bug finding in any given piece of software is constant over long periods of time. If there is little or no quality improvement, then we have no reason to believe that that the disclosure of bugs reduces the overall
cost of intrusions.
Interesting insight here.

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

January 29, 2004

NIST releases paper on Risk Management Guide for Information Technology Systems

NIST has released a DRAFT paper on risk management for IT Systems. Published as Special Publication 800-30 Rev A its shaping up to be a good reference.

Taken from the paper's introduction:

An effective risk management process is an important component of a successful IT security program. The principal goal of an organization’s risk management process should be to protect the organization and its ability to perform their mission, not just its IT assets. Therefore, the risk management process should not be treated primarily as a technical function carried out by the IT experts who operate and manage the IT system, but as an essential management function of the organization.

The paper goes on to show just how to achieve that.

Happy reading!

Posted by SilverStr at 02:23 PM | TrackBack

Free Security Posters

It seems Microsoft has released some free security posters as part of their "security education" program which you can download in PDF format. You can even order them online if you like.


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

Information Warfare

Back in 1994 a new book came out called "Information Warfare: Chaos on the Electronic Superhighway." In its first edition, the US Government thought there was too much classified information in it and the Brits wanted to ban it. At the time, the ideas of an "electronic perl harbour" sewn into the book rattled many an infosec professional's cage (well, there were very few infosec pros that didn't work for some sort of government agenciy back then ;-) )

Some say the actual term "information warfare" became a part of regular infosec vocabulary with the release of this book. Its content is now old, and to most of us common knowledge, but its good to reflect on our mindsets of the past, to understand where we go in the future.

If you are interested in the book, the publishers have released the complete first edition for free download in pdf format.

Happy reading!

Posted by SilverStr at 10:49 AM | Comments (1) | TrackBack

Hacking IE Security Zones

I am not one to promote IE since I am a real FireBird fan, but if you MUST run IE, and want to lock it down even further, consider reading Peter's entry on Hacking IE Security Zones.

With just a few registry tweaks you can create one or more "Partially Trusted Zone(s)", ratchet down the My Computer Zone and change the defaults and minimum levels for all the zones.

Fun stuff. YMMV.

Oh, and remember, if you wanna muck with your registry... do so at your own risk! (Export the working config first!)

Posted by SilverStr at 10:38 AM | Comments (1) | TrackBack

FBI's Top 10 Online Security Threats for Windows

The FBI has worked with the SANS Institute to develop a list of the 10 most exploited Windows threats. You can read more about it here.

The gist of it? There are 10 component on the Windows platform that are prone to new vulnerabilities, and are regularly used as the source of an attack vector. They are:

  1. Internet Information Services (IIS)
  2. Microsoft SQL Server (MSSQL)
  3. Windows authentication
  4. Internet Explorer (IE)
  5. Windows remote access services
  6. Microsoft Data Access Components (MDAC)
  7. Windows Scripting Host (WSH)
  8. Microsoft Outlook and Outlook Express
  9. Windows peer-to-peer file sharing (P2P)
  10. Simple Network Management Protocol (SNMP)

I am not sure I would have put IE so far down the list, but theoretical and practical attacks organize it differently. SQL injection/misuse attacks ARE more common that IE URL attacks.

Posted by SilverStr at 10:29 AM | Comments (2) | TrackBack

Integer overflow in the new[] operator

Raymond wrote an excellent entry on how to integer overflow the new[] operator. I liked how he broke down the C++ code into assembly to hit the point home. He even provides a wrapper function to do the allocation check for you to use.


Posted by SilverStr at 09:29 AM | TrackBack

January 28, 2004

Integer Handling with the C++ SafeInt Class

Ken pointed out on the SC-L mailing list that David LeBlanc published a paper on Integer Handling with the C++ SafeInt Class. David LeBlanc introduces a C++ template class that helps reduce the chances of incurring integer arithmetic errors in your code. The code is fast, flexible, and easy to use.

I have always liked David's writing (he wrote Writing Secure Code with Michael), and this is no exception.


Posted by SilverStr at 01:56 PM | TrackBack

XP Security Guide

Following the success of some of their other recent security guides, Microsost has released a new XP Security Guide. This guide includes settings for Windows XP clients deployed in a Microsoft Windows 2000 or Windows Server 2003 Active Directory domain. The document also includes guidance for an environment requiring an extremely high level of security in which application compatibility or usability may be constrained. Finally, this guide discusses procedures for implementing Windows XP security settings in stand-alone clients.

Happy reading!

Posted by SilverStr at 12:10 PM | Comments (1) | TrackBack

Identity Based Encryption

I was reading an interesting article on identy based encryption this morning when I stumbled across a good paper on "certificateless" public key encryption. John Callas, CTO over at PGP has shared his thoughts on IBE as a response in an article he published in PGP's CTO Corner.

Not sure what to make of IBE. Mathematically it sounds quite interesting, but since I am a computer security software architect, and not a cryptographer, I really don't have the expertise to poke holes in it.

Anyways, interesting research. Happy reading!

Posted by SilverStr at 08:37 AM | TrackBack

January 27, 2004

Public ISA 'Stingray' Beta Available

If you recall back in December I pointed out that Microsoft was betaing its latest version of Internet Security and Acceleration Server.

Well here is some good news. Microsoft has announced that it is making broad availability of Internet Security and Acceleration Server 2004 Beta 2 ('Stingray' Beta 2) to the public.

So if you have ever wanted to try the application layer firewall, VPN and Web caching features of ISA, now is your chance. You can register and download it here.

Posted by SilverStr at 10:47 AM | TrackBack

Virus, Vandals and Thieves: An Open letter to the Virii Author(s) of 'MyDoom'

To whom it may concern,

Congratulations on your new found fame. CERT has recently published a new Incident Note about your W32/Novarg.A Virus (aka 'MyDoom') and I could only assume you must be proud. After all, writing such malevolent code with the intent of causing a distributed Denial of Service (DDoS) to SCO is not only creative, but to some enthusiasts downright brilliant. And to boot, you show how user complacency perpetuates the problems on vulnerable Windows machines. This must satisfy you.

I can only imagine how you must feel right now. You have struck a blow to the Internet in a way that many cannot comprehend. You have now clogged up the arteries that make up the Internet’s email backbone. According to InfoWorld, you have even caused significant performance slowdowns to the top 40 US business Web sites, impacting on their ability to do business.

On February 1st and 12th, when the actual DoS payload is executed, be proud in knowing that you have required administrators at SCO’s ISP to respond by making infrastructure changes to try to mitigate the attack. Be content in knowing that your keylogger will have recorded enough passwords and other vital (and private) information that you can keep your script-kiddie ways going for another year. Hey, maybe you can use that credit card information to buy a backbone… or at least a date. (Oops... did I say that out loud?)

But most of all, I would like to congratulate you on now becoming more annoying and cowardous than SCO itself. Striking such an anonymous blow puts another notch in your virogen ways… and has increased your profile in the underground. Of course, what you haven’t thought about is the fact that there is no honour amongst thieves, and authorities are now looking for you. There are real costs associated with the damage you have caused, and those costs are growing as IT professionals confine, eradicate and clean up your mess. Hey, maybe with any luck SCO will turn a suit on you. Or perhaps Mr. Gates will put a bounty on your head. We can only hope.

In closing, thank you for showing the world yet again why information security is important. And showing why the 8 Rules of Information Security are vital.

Now go away. Your 15 minutes of fame are up.

- Dana M. Epp

Posted by SilverStr at 10:08 AM | Comments (8) | TrackBack

January 26, 2004

How to Advertise on Google

Recently I have been absorbed in learning how to fully take advantage of marketing, especially in emarketing on the Net. One of the areas which I have been trying to understand is click through advertising, especially how it relates to things like google ads.

Well, I found an AWESOME resource over at startupskills.com which I thought I should share, since I know a number of the people who read here are also building software startup companies. Take the time and invest it in reading these great articles on Advertising on Google:

I would also suggest that if you are going to spend money on advertising on google, that you learn how to run an advertising campaign:

And to end this all off, I have learned about this for some time by subscribing to Richard's RSS feed.

Thanks for a great resource Richard!

Posted by SilverStr at 07:50 PM | Comments (1) | TrackBack

January 25, 2004

Windows Security Model: What Every Driver Writer Needs to Know

I am not sure if I pointed this out before, but if you are writing kernelmode drivers on the Windows platform, you should be taking extra care to ensure you are applying the Windows Security Model to all of your code.

Microsoft has a great document on this which addresses driver security responsibility, and provides in depth descriptions on doing the right thing, from creating secure comms to setting up security in your inf. I found myself reading it again this morning, and thought I would blog the link in case I haven't before.


Posted by SilverStr at 08:57 AM | TrackBack

NIST releases new Computer Security Incident Handling Guide

Computer security incident response has become an important component for the informaiton security professional, and the departments he or she runs. Security-related threats have become not only more numerous and diverse but also more damaging and disruptive. NIST has released a new paper published as Special Publication 800-61 which addresses computer security incident handling.

At over 148 pages its not a light read, but it is well worth it. Here is a quick glimpse as to what it covers:

  1. Organizing a Computer Security Incident Response Capability
  2. Handling an Incident
  3. Handling Denial of Service Incidents
  4. Handling Malicious Code Incidents
  5. Handling Unauthorized Access Incidents
  6. Handling Inappropriate Usage Incidents
  7. Handling Multiple Component Incidents

The paper breaks the way to deal with incidents into distinct compoents:
  • Preparation
  • Detection and Analysis
  • Containment, Eradication and Recovery
  • Post-Incident Activity

I really enjoyed how the authors positions each action, and the practical expectations they describe in the document. This is a great find, and something you should take a look at when you have a chance, especially to measure up against your own Incident Response plan. You do have a plan don't you? Remember, it was one of the things you were to have as part of the Rule of Immediate and Proper Response.

Happy reading!

Posted by SilverStr at 02:34 AM | TrackBack

Secure Server Policies and Procedures for Novell NetWare Compliance

Found an interesting paper in the SANS Reading Room on creating/maintaining secure server policies and procedures for Novell NetWare compliance.

I am not much of Novell guy anymore, but it seems quite detailed and focused on a lot of the latest stuff they have out there. If you are a Novell administrator, you might appreciate the paper.

Happy reading!

Posted by SilverStr at 02:10 AM | TrackBack

An Introduction To SQL Injection Attacks For Oracle Developers

Ken mentioned that Stephen Kost has published a paper called "An Introduction to SQL Injection Attacks For Oracle Developers".

Its a good read, even if it is focused on Oracle developers and aimed to be more Oracle specific. If you are doing any sort of mult-tier SQL database software design and programming, you might find this paper useful.

Happy reading!

Posted by SilverStr at 02:00 AM | Comments (2) | TrackBack

January 24, 2004

Server back up.. kinda

Alan had some difficulties with the rebuilt server, so we are limping along with some hardware from Neil until he rebuilds it. You can read more about the ordeal here.

Thanks for all the hard work Alan... and thanks for the loan of hardware Neil!

THe new system should hopefully go in over the next week or two, and everything will be back to normal. Thanks for the patience!

Posted by SilverStr at 11:55 AM | TrackBack

January 21, 2004

Cyberguard releases firewall on a PCI card

You ever have an idea, you know its right, but it just doesn't work out the way you like?

Well, for those who know me know I invented the Firecard (now called GGBlade) over 5 years ago. It was the first completely embedded security device on a PCI card, and was heading to be a network card replacement, designed to be a security deployment platform of different technologies to help the infosec field. (With the ultimate goal to become an integrated chip to be placed on any network endpoint, including cellphones and PDA.) Even before the "bladeserver" idea was coming to market... I was designing a kewl foundation for "security blades".

To this day I have cards running firewalls, IPSec VPN tunnels, vulnerability scanners and even an few IDS sensors. (Although none of them are running the outdated version of Gateway Guardian that hasn't been updated/patched since I left. I now use a more customized version until the current dev team at NetMaster releases some updates to all the vulnerable packages... which I hear is supposed to be RSN.)

One of the things I was designing before I left was the ability to dynamically reprogram cards in the network to do different tasks. Imagine... scheduled reprogramming to dynamically shift FireCards to act as vulnerability scanners, completing their scanning/testing tasks and then becoming IDS sensors. All automatically. Before an attack, to reprogram itself to rescan hosts... finding vulnerability and resetting its IDS configuration to continue to watch for those attacks, all while updating the main firewall to prevent the attack from occuring. Ya I was designing kewl stuff. And one of my goals was to basically make these cards act like security endpoint clusters, working together in a meshed network to provide a more integrated and intelligent secure defensive posture. (I always wanted to beowulf cluster these things. I always gave Alan crap when he wanted to make a SETI package for FireCard... all the while secretly wanting to make a cluster of these to do similar things *lol*. Guess the professional side of me won over :) )

Anyways, it seems Cyberguard has announced that they now have a network card doing just that. Its not using the dynamic reprogramming I was designing.. but it is a full fledged network card with complete security functionality. We have seen firewalls on a card come out since we launched FireCard at Comdex years ago... but this is one I actually think might work. And since its running Linux... it wouldn't be too hard to port some of my old ideas and research to it.

Course.. I left this field of research for a reason... and have no interest in doing this myself. But if you are curious into hacking similar functionality into these cards, it wouldn't be too hard.

Have fun.

Posted by SilverStr at 09:36 AM | Comments (6) | TrackBack

January 20, 2004

Server downtime this Thursday

Just to inform the masses, the main Ufies server (where Alan graciously lets me host my blog) will be down for most of the day on Thursday, January 22, 2004.

With any luck, it should be a painless process, and will increase the performance of the system as it gets cleaned up. Hopefully all will be back to normal by Friday.

Thanks to Alan for admining a great server, and I wish him a clean and painless rebuild. (Especially with all his bad hardware karma as of late)

Posted by SilverStr at 05:01 PM | Comments (3) | TrackBack

January 19, 2004

Group Policy Settings Reference for WS2K3/XPSP2

Have you ever wanted to get a detailed breakdown of the Group Policy settings of the Administrative Template (.adm)? If so, you are gonna love this.

Today Microsoft released an excel spreadsheet with the complete breakdown for you! It even includes full registry hive information and a short description which you can easily search if you want to really take advantage of it.

This is a great find. Happy reading.

Posted by SilverStr at 07:56 PM | TrackBack

Microsoft Baseline Security Analyzer v1.2

As part of Microsoft's Strategic Technology Protection Program, and in response to direct customer need for a streamlined method of identifying common security misconfigurations, Microsoft has release a new version of the Microsoft Baseline Security Analyzer (MBSA).

Microsoft released a new version today. And I'm impressed with the changes.

They added better support for checking realtime security updates instead of using a local catalog, and it now properly tests for Office security updates and macros as well, just to name a few things that its doing better.

You can download it for free, and you should give it a try if you haven't yet.

Good job Microsoft.

Posted by SilverStr at 07:44 PM | TrackBack

January 14, 2004

Tomorrow is Personal Firewall Day

If you remember back in November I discussed the idea floating around about having a Personal Firewall Day.

Well, tomorrow is that day. Please visit the official site and show your support!

Posted by SilverStr at 09:10 PM | TrackBack

Security Blog Presentation

Since most of you read my blog via RSS, using RSS feeds is probably not new to you. However today I had the distinct pleasure of presenting the powers of RSS and weblogging as it relates to information gathering techniques for the infosec professional to my peers at the CIPS Security SIG.

It was nice to see a majority of the people there open to the opportunities of RSS, and the very fact that most have stated that they are going to try it out over the next few months was a rewarding result.

I promised I would put my powerpoint presentation online so they can get some info on some good feeds to start with, as well as a few links to starter aggregators. Here is that presentation. Many thanks to Robert Scoble for providing the RSS vs HTML thread as a basis to help describe the productivity gains of RSS.

And thanks to the CIPS Security SIG for inviting me to present. I hope you enjoy the new world you have been exposed to!

P.S. If anyone has a server running moveable type that they are willing to let others host on for free, please let me know. The CIPS Security SIG is considering putting a low traffic blog up, but does not have the resources to do so. Please let me know if you can help us out.

Posted by SilverStr at 09:01 PM | TrackBack

January 12, 2004

New Comment Spam Defence

This morning I found myself checking my SpamAssassin logs, and finding that I was just hit with another round of comment spam... 97 entries in less than 10 minutes... all of which were from the ip

I get about 4 or 5 daily, and I just manually delete them, but 97 entries were too much for me... I needed a better solution. While talking to Alan he suggested I check out MT-Blacklist.


In less than 5 minutes I had this MoveableType plug installed, and 53 seconds later it removed every comment spam from the IP, and set up a new defensive perimeter around my comments.

Thanks to Alan for pointing it out. And thanks to Jay Allen for an AWESOME plugin to battle the beasts of the net!

Posted by SilverStr at 10:32 AM | TrackBack

January 11, 2004

Information Security Stillness: Tuning for Tranquility

Think for a second about your digital defences. When you are probed, do you know? When you are attacked, are you aware? Do you even care?

Over the last five years there has been a paradigm shift. Where in the past it was quite easy to review and audit logs for attacks, it is becoming much more difficult as of late. Why is this? Well, it is something I call the "noise poise". Far to many security tools report any activity that they see, without understanding the context that they are in. The result? Far too much noise overwhelms the information security professional, making it more difficult to really see what is going on. Intrusion detection sensors are the worst for this, because they trigger so many false positives that when a true attack occurs, many people miss it.

This can be fixed. What we have to do is tune our tools for silence, eliminating the regular false positives and putting ourselves in a state of tranquility, or stillness. This way we can truly listen, knowing that any noise made should be investigated further.

What do I mean? Consider network probing. Do you really care if some script kiddie runs nmap against your firewall? Probably not. Especially if your firewall is configured properly. How about the IIS related traversal attacks against your Apache server? (Snort reports I currently get hit with over 100 IIS attacks a day on my personal Apache server) Doubtful. Useless noise. The idea is to tune any security checkpoint you have to give you a sense of stillness. This may take time. A good way to do this is to go through a series of steps to get to that state of tranquility:

  1. Understand what it is that your security tool can log, and what it can’t. By first understanding its capabilities, you can then learn how to better utilize it.
  2. Understand what the security tool does in the context of your layered defensive posture. You will probably have internal firewalls protecting critical resources tuned more sensitively than you perimeter firewall against certain kinds of probes. Know your enemy to know thyself.
  3. Once you understand the landscape the tool is defending against, set it to its most sensitive setting, generating a plethora of logs so you can really see what it can trigger. Remember, many of the alerts will be false positives, and that is ok at this stage.
  4. Apply filters and adjust the logging settings to remove acceptable events. If possible, have these events stored in secondary event logs, allows for correlation later if needed. This is where the power of tools like Perl can really come in handy. It can help to filter commonly accepted events and sift through the noise for you. How did I know I get 100 IIS attacks a day on my Apache server? Because I have a Perl script that goes through my Snort reports and sifts out this information for me, giving me a single line telling me of the attack instead of having 100 separate event entries. I could just as easily not look for this sort of attack (being that I refuse to run IIS)... but I have my reasons for wanting to know when this sort of attack occurs.
  5. At this stage, the waters begin to calm. Events that are triggered now can be more scrutinized. Some events may not be malicious, but they may not fit in with your information security policies. Misconfigured networked devices may throw events, or unapproved software may attempt to do tasks that are unknown to the administrator. This is the time where you can fix your defences. You shouldn’t be trying to filter these events with your security tools, but rather fix the actual problem at the source. Either fix or remove the offending soft/hardware, or modify the security policy. Never just accept the activity as normal. False positives should be stomped out where possible.
  6. Stand in stillness. Listen for the enemy. Trust in your alarms, and verify the events.

There is a fine balance when doing this. If you don’t filter, you will be overwhelmed with logging events, and the attack will probably get through along with a plethora of extraneous logs and false alarms. Filter too much, and the attack will slip through undetected. Only you can decide how to set a balance between the two. When doing so though, consider this:
  • Remember the Rule of Immediate and Proper Response. You should be prepared to respond to anything. When someone yells "The sky is falling" (and they always do) you have to be able to quickly filter out the nutjobs from the sincere. You can only do this if you are working in stillness, looking for where the ripples are in you defences. When done right, you can respond with "I already know".
  • Know your Five W's. Ensure your filters take into account who is accessing what resource from where, why, and when. Consider what is considered normal activity during office hours, and when it is not. Should someone be accessing the corporate financial data at 2 in the morning? Should VPN access be allowed after hours? Your policy will dictate what is acceptable, and it will also allow you to tune the sensitivity of your filters accordingly. Where possible… use security tools that are intelligent enough to apply time of day conditional sensors and filters.
  • Respect the Rule of Change Management when modifying your logging facilities. No single person should be allowed to adjust, or more importantly turn off, security event logging without management understanding WHY. Intentionally ignoring security alerts is a bad idea. And leaving such critical data to a single person may breach the Rule of Trust.

Let me explain WHY ignoring security alerts is a bad idea. It all comes down to the human condition. The weakest link is the human factor… and there is a major reason for this. Too many false positives in any environment will eventually be ignored. Perhaps you heard of such a fable when you were a child. If you recall, a boy “cried wolf” one to many times, and was gobbled up. The same is true in the security world. There are stories about how in World War II, the French resistance would purposely trigger security defences three or four times in a night to annoy the Germans into turning off their safeguards, or giving up on checking the alarms all together because they were tired of false alarms. Then they would sneak by undetected. Or the hacker that would continiously trigger the IDS sensor...causing the admin to turn it off because it continiously paged him all night every night for a week. (Coincidentally... this specific example occured in a few well published attacks)

Don’t ever relax your security in this manner. When you least expect it… expect it.

Be vigilant. Be safe. And be still.

Posted by SilverStr at 04:21 PM | Comments (4) | TrackBack

Secure Code vs. Quality Code

On the Secure Coding mailing list we have been discussing the issues that surround secure coding practices. To be honest its been getting tiresome as we seem to all be in agreement that education is key (something I have been saying for years) and that current certification processes (Orange book, S/COMP, GEMSOS, PSOS etc) are not widely applied as economic factors seem to stiffle the use of these standards to build secure systems.

One of the messages that really hit home for me was from from Gene Spafford. He really drove it home when he stated that "When the code is incorrect, you can't really talk about security. When the code is faulty, it cannot be safe."

Anyways, I thought it might be good if you read his message in its entirety.

Spaf's Message

I have noted several of the comments on this list from people about the need for standards for security, either for certification or for development.

Historically, attempts at setting such standards have had limited success. The Orange Book (and the "Rainbow Series" in general) presented some very good guidelines for a particular kind of environment (mainframe, limited networking, cleared personnel). However, it turned out that the community didn't have development methods that were fast enough and cheap enough to compete with the consumer market, so those standards were eventually abandoned. Some extremely secure systems have been developed using those standards -- S/COMP, GEMSOS, PSOS and even Multics, to name a few. That they are not widely used now is a result of economic factors more than anything else. Some standards are still in use in the same environments (e.g., the DITSCAP, see <http://iase.disa.mil/ditscap/>), which is a good thing considering the sensitivity of those environments.

The NRC "Computers at Risk" study (still a valid and comprehensive look at some of our problems) articulated the need for security training and standards. The GASSP came out of that, and represent a useful set of standards to support security. (See <http://web.mit.edu/security/www/gassp1.html>.) Unfortunately, those were not widely articulated, particularly in educational programs. The fact that so much discussion has gone on in this list without someone even mentioning them indicates how so many people mistakenly equate the problem of code quality with security. That is largely caused by the "noise" right now, I suspect. Too many reports about buffer overflows leads the average person to believe that is the biggest (or only) security threat. Comparing flaws in IIS to Apache leads one to believe that Microsoft is at fault for most security problems. Repeat something often enough without applying the scientific method and it must be true, right? A lead ball must drop faster than a wooden ball because it is heavier, and breaking a mirror brings bad luck, and vitamin C prevents colds, and open source is more secure than proprietary code. Anecdotal experience does not prove general truths -- but it does lead to superstition. And a lack of knowledge of the field (e.g., DITSCAP, GASSP, PSOS, CMM) reinforces shallow opinions.

A software system cannot be evaluated for security if it is faulty -- it automatically fails. Arguments about issues of buffer overflow, argument validation, and bad pointer arithmetic are arguments over quality of implementation. Those things will cause software to fail under circumstances that are not related to security policy -- they aren't security-specific, they are issues of quality. That doesn't make them unimportant, but it does distract people from thinking about the big picture of security.

Suppose that you had your software written in a fully type-safe language by expert programmers. There are no buffer overflows. There are no pointers. All error conditions are caught and handled. Is it secure? Well, that question is silly to ask, because security is an absolute across all contexts and uses. In the strictest sense, no system can ever be truly secure.

We CAN ask "Is it trustworthy to use in context A against security policy B?" Then we need to evaluate it against a set of questions: The lack of coding errors does not give us an automatic answer. We might need to ask about auditing, about proper authentication, about media residue handling, about distribution pathways, about the connectivity to removable media and networks, about data provenance, and about dozens of other properties that determine whether the software upholds policy B in context A. Safe coding does not equal security or trustworthiness. People who REALLY understand information security understand this basic maxim.

The topic of this list, "secure coding" is, in a sense, a misnomer. "Safe coding" or "Quality coding" would be a better term. Security is a property supported by design, operation, and monitoring....of correct code. When the code is incorrect, you can't really talk about security. When the code is faulty, it cannot be safe. Of course, that harkens back to my earlier posts about requirements and specifications. You can't really tell if the code is faulty if you aren't precisely sure of what it is supposed to do.....

At the recent CRA Grand Challenges conference on security (<http://www.cra.org/Activities/grand.challenges/security/home.html>), several of us were bemoaning the fact that we have a generation who think that the ability to download tools to exploit buffer overflows makes them "security experts." If nothing else, could I request that the participants in this list keep from perpetuating that canard?


Posted by SilverStr at 02:59 PM | Comments (1) | TrackBack

January 07, 2004

Looking for SCM feedback

To all the programmers out there,

I was wondering if anyone that reads my blog has suggestions for source control management tools that they use with their team on a regular basis. Right now we use CVS here, with WinCVS being our front end.

Trying to get developers "into" SCM isn't easy... and using CVS in Windows is not the most eligent way of doing things. Nor is it easy for those new to using SCM. So I started hunting down other options.

I have checked out TortoiseCVS, which is basically CVS integrated within Window's Explorer ... but I don't think it really is a great leap in simplifying the SCM process.

I was seriously considering SourceGear's Vault, but to be honest I am quite disappointed at how unresponsive Eric Sink has been in the past to emails I have sent. I have always respected his outlook as an ISV, as depicted in many great articles on his weblog. Yet to this day he has never once responded to any communication I have sent. If this is how he handles himself, I really don't want to dispense any more energy chasing him down if I need to communicate as a potential customer. Which is really to bad, as Vault looked interesting, especially with its integration with FogBugz.

Microsoft's Visual Source Safe is right out. When Microsoft isn't willing to eat its own dogfood, you have to wonder why. I have heard horror stories of master source trees getting corrupted, and the fact VSS does not scale at all. With no positive experiences, war stories or case studies around... I'd rather not waste my time, even if it is free and part of my MSDN Universal subscription.

I found out that Microsoft uses a customized version of a product called Perforce for its own source code, and that is what I am leaning towards right now. It's quite nice as it has a server that runs on Unix and Linux machines as well as Windows... which means I should be able to use the current CVS server hardware (running Debian) and run both systems concurrently... atleast for testing. Perforce seems to be quite easy to use from what I have seen, and the rave reviews from Windows developers abound has me taking a more serious look at this. The Windows client looks pretty nice.

If I had to pick a set of features I want, this is what I am looking for:

  • Something braindead easy with a point and click UI that can be used externally (good for kernelmode code using the DDK... stuff that isn't done in Visual Studio)
  • It should integrate directly into Visual Studio 2003 for such projects (ie: C# stand-alone apps)
  • It must support the ability to branch and merge back changes, as well as tag versions to allow me to run different versions concurrently, while easily being able to fix bugs in the main tree.
  • It must be able to run over a secure channel, allowing for remote users to check in/out code after being authenticated. (Even just supporting connections over SSH like CVS does would suffice) It also must have well documented ports, as I will not pierce my firewalls with tonnes of different ports to support it.
  • It must be small ISV friendly on the pocket book. I have spent so much money on Windows developer tools it isn't funny. I can't really afford to be blowing thousands of dollars more on a solution that might not work for us. Besides the standard ROI calc, I would like to KNOW I am getting the most bang for the buck.

So, what are your thoughts? Anyone know if Perforce fits this bill... or of other SCM tools that will? Chime up here... or send me an email to dana@vulscan.com.

Posted by SilverStr at 08:07 PM | Comments (15) | TrackBack

Defeating the BOFH: Compromising A Windows System

Tonight I found myself in the situation where one of my clients has had an administrator go rogue on them, leaving the company and refusing to give them vital information like access to their administrator passwords without first being 'compensated'. This is the EXACT risk I was talking about when I was discussing last month the Rule of Trust, one of the 8 Rules of Information Security. And the sad thing is, this isn't the first company I have seen that has had this issue. So in a 'generic' sort of way, I thought I would blog about how I compromised Windows XP to gain access to the administrator's primary machine, in an effort to recover information that was needed without giving into the blackmail.

First off, I must admit I am a little hesitant to discuss how I accomplished this breach. It is not because this is some sort of black art and I don’t wish to give up trade secrets; I just don’t like being responsible for educating “script-kiddies”. But after much deliberation, I realized that the basis of this technique is NOT new… and most attackers can already piece together this attack vector. Moreover, since most readers of my blog are in or want to be in the information security field anyways, I would rather show you how to COUNTER this attack by explaining how it works... and what could have been done to prevent it.

Anyways, onto the compromise. In this particular case, I needed to get access to the system for a few different reasons as part of a stage of evidence gathering, which I cannot discuss here out of respect for client confidentiality. However, I can say that if I could get onto the system, 90% of the battle would immediately be won. Knowing this… and with written permission from my client to breach the system, I went to work.

In the old Win9x days gaining access was quite trivial. Lets ignore the fact you could basically hit ‘escape’ and bypass the system for a moment and look at what their major security was. It was a screen saver password. I used to love this as I would watch the local computer store salespeople laugh as kids would try to breach their complex screen saver passwords in an effort to check out the latest store offerings. One day I just had to say something and explain how they should realize it’s quite trivial to breach their screen passwords. They wouldn’t accept my explanation until I came in one day, handed them a CD and told them that if they put it into the CD tray, they would never again have to enter in the screensaver password. Less than 30 seconds later, they were staring at the Windows 9x desktop. Why? Well almost every Windows 9x machine has autorun turned on. (I have yet to come across a machine that has it turned off in a production environment that I have had to access) This code execution path means that if you put a CD that has an autorun.inf file into the cdrom drive, it will spin up and execute. In my case, I wrote a small exe in C that would kill the process running the screensaver. The result? Put the CD in, Windows would see the autorun and executes my code that would then search for the appropriate process and kill Windows only defence between you and the desktop.

With the introduction of newer versions of Windows, Microsoft made strides to make this sort of attack vector harder. You can no longer just hit ‘escape’ to get into the system, and process separation makes it difficult (but not impossible) to kill off a screensaver. Yet the way systems like XP work gave me an idea about how the screensaver works during logon.

In Windows XP (well all recent Microsoft OSs actually) on boot up you are presented with a logon screen. After a default timeout (approximately 10 to 15 minutes) if there is no interaction with the mouse or keyboard the kernel executes the logon screensaver. Knowing this… it is possible to use this code execution path to gain elevated privileges if we can trick Windows into executing our code.

The way I did this is actually quite trivial. In my case, I simply booted into an environment that would let me access the filesystem directly (For this I use a slightly modified version of Knoppix-STD with NTFS write support) and simply tamper with the logon screensaver. In Windows XP, this file is located at %SYSTEMROOT%\System32\logon.scr. I replaced it with a copy of cmd.exe, and then synced the disk and unmounted it.

Once my “Trojan” was in place, I ejected my boot CD and rebooted the machine, and waited. XP booted up to its logon screen, waiting for me to enter my credentials. But I didn’t. I just sat there, enjoying a Tim Horton’s Café Mocha, documenting my procedures to this point. About 15 minutes later, with my indulgence in coffee satisfied and documentation completed, Windows XP launched my version of the logon screen saver, giving me a command prompt. But not just ANY command prompt. A command prompt with SYSTEM privileges. For those of you that do not know… consider SYSTEM the $DEITY of the machine… with higher privileges than even the Administrator. I’m in. Now, simply type “explorer” and watch the system come up. The result? See for yourself:

If you cannot make out the image (sorry, I should have gotten a better screen scrape) you will note that the USER is System (not a normal thing) and the background has a command shell... but look at the titlebar. Its actually logon.scr!

Ok, so now you know how to breach Microsoft's latest flavours of operating systems. What could have been done to stop me? There were plenty of failures that happened here, some that could have easily been fixed, and others that could not. Here is a brief rundown:

  1. System should have had a BIOS password: Although it is possible to bypass the BIOS, its makes it considerably harder. Why would I want access to the BIOS? Simple. To set the boot order of devices.
  2. Do NOT allow bootup from secondary/removable media: I should NEVER have been able to boot from CD. A combination of a strong BIOS password and only allowing a boot from harddisk would have prevented that.
  3. Consider using a Syskey bootup password: This is a bit tricky, and not ideal for everyone, but can provide you with an extra level of protection. A system would simply NOT boot until a bootup password was provided. For Linux people, this is like password protecting LILO. NOTE: NOT a good idea for headless servers :)
  4. Prevent physical access to the machine: This is kind of moot in my case, since I had permission from the company. But it still fits. The first three laws of Immutable Security, are basically that if an attacker can get you to run a program, alter your OS or get access to your computer… it’s not your computer anymore. I broke all three laws to breach the system.

Well there you have it. At this point you now know how to breach the system, and techniques you can use to counter the attack. I have purposely left out what I did once on the machine, as I will leave that exercise up to the user… and quite frankly am not interesting in teaching kiddies how to actually use this attack vector to change administrative passwords or create secret accounts for themselves.


Posted by SilverStr at 12:37 AM | Comments (16) | TrackBack

January 05, 2004

New local privilege escalation vulnerability in Linux kernel

Well, if you haven't heard yet, you might want to grab the latest kernel. There is a new critical security vulnerability in most of the kernels which, due to a bound check failure, allows a local user to gain root privileges.

More information can be found at: http://isec.pl/vulnerabilities/isec-0013-mremap.txt

Time to compile and reboot.

Posted by SilverStr at 10:49 AM | TrackBack

Security related chats and web casts for January 2004

Jerry points out that Microsoft has a bunch of security related webcasts going on this month. There are just so many of them that I will let you check out his site to get the low down on the agenda for the month.

If you have the time, it is well worth the effort to try to hook up with a few of these tracks.

Posted by SilverStr at 09:29 AM | TrackBack

January 01, 2004

Happy New Year!

Happy New Year everyone. Just got home from a nice night on the town, and I do hope you had a joyous and safe holiday season. (**Psst*** ITS OVER NOW!)

I wish you all the best in 2004. May it be filled with laughter, a few joyous tears and be full of prosperity.


Posted by SilverStr at 02:14 AM | TrackBack