Comparing Microsoft's Communication Methods

Today is Microsoft Patch Tuesday, which means if you so choose you can read posts by the Microsoft Security Response Center like February 2011 Security Bulletin Release. The advisory states "we have 12 bulletins addressing 22 vulnerabilities in Microsoft Windows, Office, Internet Explorer, and IIS (Internet Information Services). Three bulletins are rated Critical."

Microsoft communicates information about these vulnerabilities using two graphics.

The first is "Severity and Exploitability Index":



The second is "Bulletin Deployment Priority":



I'm not even going to start a discussion about why the first chart shows "risk" and then "impact" (isn't impact a component of risk?) I'm also not going to dwell about how the first column of the second chart has been "overloaded" to include only a small bit of information on the code affected, rather that prominently communicating that data in a column of its own.

Instead, I'd like to know who else finds this sort of red-yellow-blue presentation to be an assault on your senses? I mean, at the very least, isn't all the information from the top chart present in the bottom chart (despite more lovely coloring?)

In contrast to that communication method, I'd like to highlight content from a related Microsoft blog post titled Breaking up the Romance between Malware and Autorun. Why do I like this post? Check out this table:



Why do I like it?

• It shows 40 numbers. What you say? It only shows 36? I consider the NULL values to be valuable too because they demonstrate Microsoft wasn't tracking those malware families yet, or they didn't exist, etc.


• It identifies 10 malware families.


• It shows trends over time.


• The results are ranked by totals for 2H10.


• Nothing is colored RED to tell me THIS IS BAD.

I like to see content like that table because it treats the viewer like an adult who can at least read at the level of the sports pages in the newspaper, as the great Tufte says.

Tweet

Read More

Microsoft, Explain Threats to Microsoft

The Microsoft Malware Protection Center recently published their third Security Intelligence Report. The front page of the report says

An in-depth perspective on software vulnerabilities and exploits, malicious code threats, and potentially unwanted software, focusing on the first half of 2007

Inside it continues:

This report provides an in-depth perspective on software vulnerabilities (both in Microsoft software and third-party software), software exploits (for which there is a related MSRC bulletin), malicious software, and potentially unwanted software. The lists below summarize the key points from each section of the report...

The number of disclosures of new software vulnerabilities across the industry continues to be in the thousands...

Contrast that proper use of the word vulnerabilities in those excerpts with the incorrect use of the word threat in the quotes I noted in Someone Please Explain Threats to Microsoft:

As you go about filling in the threat model threat list, it’s important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team...

When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chose to ignore will remain in the document to provide guidance for the future.

In that excerpt, all uses of the word threat should be replaced with the word vulnerability, with possible exception of the term "threat modeling." In reality it should be "attack modeling," but in all other cases Microsoft is clearly talking about discovering holes/flaws/problems in their software, i.e., vulnerabilities.

So, it seems that the people who have the big security picture -- those who write the Microsoft Security Intelligence Reports -- know the difference between a threat and a vulnerability. The developers who focus on Microsoft's software -- those exercising the Microsoft Security Development Lifecycle -- are using "threat" when they should be saying "vulnerability."

It would be good for the SIR people to talk to the SDLC people. Without that coordination Microsoft's developers will continue to view the security problem incorrectly, and by extension, so will the customers who look to Microsoft for intellectual guidance.

On a related note, I was happy to see the latest SIR available as a .pdf.

Read More

Someone Please Explain Threats to Microsoft

It's 2007 and some people still do not know the difference between a threat and a vulnerability. I know these are just the sorts of posts that make me all sorts of new friends, but nothing I say will change their minds anyway. To wit, Threat Modeling Again, Threat Modeling Rules of Thumb:

As you go about filling in the threat model threat list, it’s important to consider the consequences of entering threats and mitigations. While it can be easy to find threats, it is important to realize that all threats have real-world consequences for the development team.

At the end of the day, this process is about ensuring that our customer’s machines aren’t compromised. When we’re deciding which threats need mitigation, we concentrate our efforts on those where the attacker can cause real damage.

When we’re threat modeling, we should ensure that we’ve identified as many of the potential threats as possible (even if you think they’re trivial). At a minimum, the threats we list that we chose to ignore will remain in the document to provide guidance for the future.

Replace every single instance of "threat" in that section with "vulnerability" and the wording will make sense.

Not using the term "threat" properly is a hallmark of Microsoft publications, as mentioned in Preview: The Security Development Lifecycle. I said this in my review of Writing Secure Code, 2nd Ed:

The major problem with WSC2E, often shared by Microsoft titles, is the misuse of terms like "threat" and "risk." Unfortunately, the implied meanings of these terms varies depending on Microsoft's context, which is evidence the authors are using the words improperly. It also makes it difficult for me to provide simple substitution rules. Sometimes Microsoft uses "threat" when they really mean "vulnerability." For example, p 94 says "I always assume that a threat will be taken advantage of." Attackers don't take advantage of threats; they ARE threats. Attackers take advantage of vulnerabilities.

Sometimes Microsoft uses terms properly, like the discussion of denial of service as an "attack" in ch 17. Unfortunately, Microsoft's mislabeled STRIDE model supposedly outlines "threats" like "Denial of service." Argh -- STRIDE is just an inverted CIA AAA model, where STRIDE elements are attacks, not "threats." Microsoft also sometimes says "threat" when they mean "risk." The two are not synonyms. Consider this from p 87: "the only viable software solution is to reduce the overall threat probability or risk to an acceptable level, and that is the ultimate goal of 'threat analysis.'" Here we see confusing threat and risk, and calling what is really risk analysis a "threat analysis." Finally, whenever you read "threat trees," think "attack trees" -- and remember Bruce Schneier worked hard on these but is apparently ignored by Microsoft.

These sentiments reappeared in my review of Security Development Lifecycle: Microsoft continues its pattern of misusing terms like "threat" that started with "Threat Modeling" and WSC2E. SDL demonstrates some movement on the part of the book's authors towards more acceptable usage, however. Material previously discussed in a "Threat Modeling" chapter in WSC2E now appears in a chapter called "Risk Analysis" (ch 9) -- but within the chapter, the terms are mostly still corrupted. Many times Microsoft misuses the term risk too. For example, p 94 says "The Security Risk Assessment is used to determine the system's level of vulnerability to attack." If you're making that decision, it's a vulnerability assessment; when you incorporate threat and asset value calculations with vulnerabilities, that's true risk assessment.

The authors try to deflect what I expect was criticism of their term misuse in previous books. On p 102 they say "The meaning of the word threat is much debated. In this book, a threat is defined as an attacker's objective." The problem with this definition is that it exposes the problems with their terminology. The authors make me cringe when I read phrases like "threats to the system ranked by risk" (p 103) or "spoofing threats risk ranking." On p 104, they are really talking about vulnerabilities when they write "All threats are uncovered through the analysis process." The one time they do use threat properly, it shows their definition is nonsensical: "consider the insider-threat scenario -- should your product protect against attackers who work for your company?" If you recognize that a threat is a party with the capabilities and intentions to exploit a vulnerability in an asset, then Microsoft is describing insiders appropriately -- but not as "an attacker's objective."

Don't get me wrong -- there's a lot to like about SDL. I gave the book four stars, and I think it would be good to read it. I fear, though, that this is another book distributed to Microsoft developers and managers riddled with sometimes confusing or outright wrong ways to think about security. This produces lasting problems that degrade the community's ability to discuss and solve software security problems.

No one is going to take us seriously until we use the right terms. Argh.

Read More

Thoughts on Vista

To mark the launch of Microsoft Windows Vista, CSO Online asked me to write this article. The editor titled it "Security In Microsoft Vista? It Could Happen." I think I took a balanced approach. Let me know what you think. I was pleased to see my FreeBSD reference survived the editor's review!

Read More

Thoughts on Gates Security Memo

While reading Gary McGraw's great book Software Security, I had a chance to re-read the famous Bill Gates security memo of January 2002. I wasn't blogging back then, so I didn't record my reaction to it. Almost five years later, the following excerpt struck me:

[E]ven more important than any of these new capabilities is the fact that it is designed from the ground up to deliver Trustworthy Computing. What I mean by this is that customers will always be able to rely on these systems to be available and to secure their information. Trustworthy Computing is computing that is as available, reliable and secure as electricity, water services and telephony.

Today, in the developed world, we do not worry about electricity and water services being available. With telephony, we rely both on its availability and its security for conducting highly confidential business transactions without worrying that information about who we call or what we say will be compromised. Computing falls well short of this, ranging from the individual user who isn't willing to add a new application because it might destabilize their system, to a corporation that moves slowly to embrace e-business because today's platforms don't make the grade. (emphasis added)

Hold the phone (no pun intended). "[A]vailable, reliable and secure as electricity, water services and telephony"? You mean the solid electricity system that blacked out the northeast US in 2003? Or the two water pipes running into New York City that could be disrupted or poisoned? Or the telephone system owned by the Phone Masters in the late 1990s or spied upon by three letter agenices in this decade?

I propose that the main reason that electricity, water, and telephony are (wrongly) considered "secure" is the fewer number of threats facing them. Networked digital resources are exposed to far greater numbers of threats than analog resources like electrical power plants, water treatment facilities, and telephone closets. This is changing as all of these analog resources are being controlled by IP-enabled systems with global reachability.

This makes me wonder if digital security is being held to a higher, possibly impossible, standard. Is there any other system in the world that could be accessed by any threat, at any time? This is not a wise-guy question -- I'd appreciate your thoughts on this. What sorts of man-made systems are relentlessly under attack by intelligent adversaries? I'm adding intelligence here to remove comparisons to diseases, weather, earthquakes, and so on.

The first system that came to mind was the modern casino. People are always trying to cheat, so the threat level is high. A variety of financial systems come to mind, although I'm trying to avoid systems with close ties to digital functionality. Physical security probably has a few useful lessons.

What do you think?

Read More

Preview: The Security Development Lifecycle

Michael Howard and Steve Lipner were kind enough to send me a copy of their new book The Security Development Lifecycle. Michael's blog summarizes the book. I was surprised to see the book's CD includes a six-part security class video. That's a first for me, at least.

I'm also looking forward to another Microsoft security book called Hunting Security Bugs. Michael Howard has another security book through Osborne called Designing Security Software arriving in February. Good work Michael -- push that publication date far enough away for me to catch up on my other reading.

On a related note, does anyone recall learning about this?

I saw it at the Microsoft Security Development Center. Microsoft India hosted a Security Shootout last March. Varun Sharma won. It's interesting to see such a promotion, and I wonder if the US will host something similar.

In the future, I recommend changing the logo. Vulnerabilities in code are not "security threats" -- they are vulnerabilities. I think Microsoft is so hung with up their definition of threat modeling that they think problems in their code are threats, not vulnerabilities. (Cue comments that "vulnerabilities are threats," which I will promptly ignore.)

Read More

Thoughts on Patching

As I continue through my list of security notes, I thought I would share a few ideas here. I recorded these while seeing Ron Gula discuss vulnerability management at RMISC.

Many people recommend automated patching, at least for desktops. In the enterprise, some people believe patches should be tested prior to rollout. This sounds like automated patching must be disabled. I'm wondering if anyoen has implemented delayed automated patching. In other words, automatic updates are enabled, but with a two or three day delay.

Those two or three days give the enterprise security group time to test the patch. If everything is ok, they let the automated patch proceed. If the patch breaks something critical, they instruct the desktops to not install the patch until further orders. I think this approach strikes a good balance since I would prefer to have automated patch installation be the default tactic, not manual installation.

Determining which systems are vulnerable results in imagining a continuum of assessment tactics.

• At the most unobtrusive level we have a "paper review" of an inventory of systems and their reported patch levels.


• Next comes passive assessment of traffic to and from clients and servers.


• Traditional vulnerability scanning, without logging in to the target, is the next least obtrusive way to assess hosts.


• Logging in to a host with credentials is another option.


• Installing an agent on the host is a medium-impact approach.


• Exploiting the host is the final way to definitively see if a host is vulnerable.

On a related note, Ron mentioned that the costs of demonstrating compliance far exceed those of maintaining compliance. This is sad. Ron also noted he believes auditors should work for the CFO and not the CIO. I agree.

Read More

Tom Gallagher Responds to Blog Post

Tom Gallagher, author of the forthcoming Hunting Security Bugs, sent the following in reply to my Microsoft Is Getting It post:

---

Hello Richard. Last weekend I read your blog about Microsoft BlueHat and our security books and thought you might be interested in some more information about these topics.

I joined the company almost 7 years ago. In that time, I've seen some major changes happen around how the company views security. As you are aware, the company didn't focus much on security back then. I was one of the few people at the company who did fulltime penetration testing. I worked on a small product team within Microsoft Office and was responsible for testing only it. Today things are very different. In Office's vision document for the release, the first tenet is about the importance of security. Unlike when I started, security is now the responsibility of everyone creating the software - not just the person writing the code, but also the people who design, test, and document it. Other products across the company do similar things. We're certainly not perfect, but are working harder and harder to get better.

As you noticed, we proactively try to learn about security issues from external researchers and bring them to Redmond to present to the product teams. The cool thing about this is it allows many people to get direct exposure to the information. For example, I can't justify sending everyone on my team to a security conference twice a year, but I can send them to BlueHat that often. We continue to send people to external conferences too. Since security is everyone's responsibility, people who don't work on security fulltime also attend BlueHat. It is unlikely that those people would attend external security conferences often.

I'm one of the authors of an upcoming MSPress title (Hunting Security Bugs). This book allows feature testers to understand how to find security bugs in their product. Writing Secure Code is for developers to understand how to create secure software; the testing book teaches testers how to ensure that carefully probing for vulnerabilities. Both books cover a wide variety of topics. And of course testers aren't limited to the people who work on the team creating the software.

---

If you have any questions for Tom, please post them here.

Read More

Microsoft is Getting It

I learned through Slashdot that Microsoft held its third Blue Hat Security Briefings. They also have a Blue Hat Blog. Reading this article, and considering that this is the third Blue Hat, it sounds to me like Microsoft is taking security seriously. It's been over over four years since Bill Gates issued his famous security memo. What's happened since then?


With Blue Hat, Microsoft is listening to the top public security researchers who are breaking Windows. Halvar Flake at Black Hat Federal 2006 says it is getting tougher to find vulnerabilities in Windows. I reported that a talk I saw on Vista at RSA 2006 impressed me. The company is incorporating good security practices like least privilege and privilege separation, already found in Unix OS' and tools. Microsoft is publishing books like Writing Secure Code, 2nd Ed, Hunting Security Bugs, and The Security Development Lifecycle. The company has a group which has the power to stop shipment of software due to security concerns, and it has exercised that power already.

All of these factors are going to make a difference when Vista is released. I plan to buy a new laptop running Vista (and dual-booting FreeBSD) when the new OS is available. I am optimistic, but we'll have to see what sorts of security advisories Microsoft releases once Vista ships.

I believe that threats are going to shift their attention to the infrastructure surrounding Microsoft. We've already seen that with attacks on applications. The next target will be network infrastructure, especially so-called embedded devices and appliances. These products suffer the sorts of vulnerabilities seen in Microsoft products of the past. I saw Barnaby Jack's latest presentation and his compromise of an embedded consumer grade router scared the heck out of me.

Stay tuned.

Read More

Microsoft Says Wait One More Week

I just received notice of the updated Microsoft Security Advisory on the WMF fiasco. It states:

Microsoft has completed development of the security update for the vulnerability. The security update is now being localized and tested to ensure quality and application compatibility. Microsoft’s goal is to release the update on Tuesday, January 10, 2006, as part of its monthly release of security bulletins. This release is predicated on successful completion of quality testing...

What’s Microsoft’s response to the availability of third party patches for the WMF vulnerability?

Microsoft recommends that customers download and deploy the security update for the WMF vulnerability that we are targeting for release on January 10, 2006.

As a general rule, it is a best practice to utilize security updates for software vulnerabilities from the original vendor of the software. With Microsoft software, Microsoft carefully reviews and tests security updates to ensure that they are of high quality and have been evaluated thoroughly for application compatibility. In addition, Microsoft’s security updates are offered in 23 languages for all affected versions of the software simultaneously.

Microsoft cannot provide similar assurance for independent third party security updates.

In other words, get 0wn3d, stay 0wn3d.

I'm going to keep my eye on the Kaspersky Lab Analyst Diary for news on any other WMF worms.

Read More

Windows Via Real Thin Clients

Real thin clients, like the Sun Ray 170, don't run operating systems like Windows or Linux. I like the Sun Ray, since its Sun Ray Server Software runs on either Solaris or Red Hat Enterprise Linux. That's fine for users who want to access applications on Solaris or Linux. What about those who need Windows? I can think of four options:

1. Run a Windows VM inside the free VMware Player on the Red Hat Enterprise Linux user's desktop.


2. Run VMware Workstation on each user's desktop.


3. Run VMware GSX Server on the Red Hat Enterprise Linux server running Sun Ray Server Software, and let users connect to the Windows VMs using the VMware Virtual Machine Console


4. Run VMware ESX Server on a separate platform, and let users connect to the Microsoft VMs using the Remote Console

Is anyone trying this already?

Update: I noticed a similar issue appeared in the VMTN Blog.

Read More

Thoughts on Recent Microsoft Common Criteria News

Through Slashdot I hunted down this story about certain Microsoft products being awarded Common Criteria (CC) Evaluation Assurance Level (EAL) 4 Augmented with ALC_FLR.3 certification. They include:

• Microsoft Windows Server™ 2003, Standard Edition (32-bit version) with Service Pack 1


• Microsoft Windows Server 2003, Enterprise Edition (32-bit and 64-bit versions) with Service Pack 1


• Microsoft Windows Server 2003, Datacenter Edition (32-bit and 64-bit versions) with Service Pack 1


• Microsoft Windows Server 2003 Certificate Server, Certificate Issuing and Management Components (CIMC) (Security Level 3 Protection Profile, Version 1.0)


• Microsoft Windows XP Professional with Service Pack 2


• Microsoft Windows XP Embedded with Service Pack 2

Achieving this certification is important to Microsoft, because of certain laws:

"[E]ffective 1 July 2002... departments and agencies within the Executive Branch shall acquire, for use on national security systems, only those COTS products or cryptographic modules that have been validated with the International Common Criteria for Information Technology Security Evaluation, the National Information Assurance Partnership (NIAP) Common Criteria Evaluation and Validation Scheme (CCEVS), or by the National Institute of Standards and Technology (NIST) Federal Information Processing Standards (FIPS) Cryptographic Module Validation Program."

It is important to remember that "EALs refer to the level of confidence in the conclusions of the evaluation, and not to the level of secrity the product provides. In other words, you can have more confidence that a EAL4 product performs as advertised than an EAL2 product... But an EAL4 product will not necessarily provide more security."

What really matters is the Protection Profile used to evaluate the products. I read that "[t]he Microsoft products were evaluated against the Controlled Access Protection Profile," (CAPP) which is available here (.pdf). Here are a few choice excerpts from the CAPP. Where you see "TOE", think "Microsoft system".

• The system does not have to defend itself against physical attacks: "The processing resources of the TOE will be located within controlled access facilities which will prevent unauthorized physical access."


• Sorry, I had to highlight this statement: "There will be one or more competent individuals assigned to manage the TOE and the security of the information it contains."


• The following implies that the evaluated system should not be a publicly accessible server: "Any other systems with which the TOE communicates are assumed to be under the same management control and operate under the same security policy constraints. CAPP-conformant TOEs are applicable to networked or distributed environments only if the entire network operates under the same constraints and resides within a single management domain."

If you continue reading the document, you'll find a great deal of requirements for keeping audit records, authorizing users, vendor-provided documentation, and so forth. This is probably not what people first imagine when they think of "secure" products.

Keep these assumptions in mind when you consider the importance of Microsoft products achieving EAL-4 certification.

Update: You can download the Windows XP / Server 2003 Common Criteria Evaluation Technical Report in .zip format.

Read More

Windows Remote Administration Options

This morning I worked with several remote administration tools on my Windows Server 2003 system. First I enabled the native Remote Desktop (aka Terminal Services) capability via My Computer -> Properties -> Remote

At this point I am only letting administrator connect remotely. Since administrator can connect remotely by default once the service is activated, I didn't need to make any other changes. Once Remote Desktop is listening, it will appear active on port 3389 TCP.

To access the Windows server remotely from Unix using the RDP protocol, I use Rdesktop. It's available in the FreeBSD ports tree as net/rdesktop. I like the option to change screen geometry, e.g., 'rdesktop -g 80% 192.168.2.2'.

To access the RDP server from my Windows 2000 laptop, I installed the MSRDPCLI.EXE package.

Next I tried RealVNC. This program has client and server components. I installed the entire package on the Windows server. Setup is fairly simple, and the server should be configured to accept clients that enter a pre-defined password. RealVNC starts two listening services. One can access a Web page with a Java-enabled VNC service on port 5800 TCP. The default native VNC server listens on port 5900 TCP.

To access the Windows server remotely from Unix using the VNC protocol, I use vncviewer, packaged with RealVNC. It's available in the FreeBSD ports tree as net/vnc. To send ctrl-alt-delete through VNC, I like to hit the F8 key to bring up a VNC menu, through which I select "Send ctrl-alt-del".

There is an importance difference between using RDP and VNC on Windows Server 2003. RDP is a Terminal Services application, which allows multiple users to remotely interact with the server. VNC takes control of the physical desktop. For example, I was able to run one RDP instance and then use VNC to connect to the server. Neither session was interrupted by the other. Also, RDP seems to be more efficient and responsive, although I have not sought to tweak VNC.

Note that (thanks to comments from Blog readers), I found Rdesktop allows one to "attach to console" if passed the -0 command, like this:

rdesktop -0 192.168.2.2

This eliminates the need to use VNC, in my opinion.

I noticed that I could not get VMWare to start a guest OS when I was logged in to the Windows Server 2003 box using RDP (not attached to the console). I could start a guest when logged in using VNC. I typically set a screen geometry because VNC doesn't appear to have a menu option for it, e.g. 'vncviewer geometry="1024X768"'.

With rdesktop -O, I can attach to the console and hence start VMs properly over RDP.

inally I installed OpenSSH. I considered installing the SSH for Windows package, which is a stripped-down Cygwin version. Since that program had not been updated in over a year (i.e., 3.8.1), I decided to use the complete Cygwin version. Nicholas Fong's guide was extremely helpful.

I followed all of his instructions. Remember to add a new environment variable where 'variable name' is CYGWIN and 'variable value' is ntsec tty. Also add ';c:\cygwin\bin' to the PATH.

I noticed a different set of prompts when I ran 'ssh-host-config', so here is how I proceeded.

$ ssh-host-config
Generating /etc/ssh_host_key
Generating /etc/ssh_host_rsa_key
Generating /etc/ssh_host_dsa_key
Generating /etc/ssh_config file
Privilege separation is set to yes by default since OpenSSH 3.3.
However, this requires a non-privileged account called 'sshd'.
For more info on privilege separation read /usr/share/doc/openssh/README.privsep.

Should privilege separation be used? (yes/no) yes
Warning: The following function requires administrator privileges!
Should this script create a local user 'sshd' on this machine? (yes/no) yes
Generating /etc/sshd_config file

Warning: The following functions require administrator privileges!

Do you want to install sshd as service?
(Say "no" if it's already installed as service) (yes/no) yes

You appear to be running Windows 2003 Server or later.  On 2003 and
later systems, it's not possible to use the LocalSystem account
if sshd should allow passwordless logon (e. g. public key authentication).
If you want to enable that functionality, it's required to create a new
account 'sshd_server' with special privileges, which is then used to run
the sshd service under.

Should this script create a new local account 'sshd_server' which has
the required privileges? (yes/no) yes

Please enter a password for new user 'sshd_server'.  Please be sure that
this password matches the password rules given on your system.
Entering no password will exit the configuration.  PASSWORD=obscured

User 'sshd_server' has been created with password 'obscured'.
If you change the password, please keep in mind to change the password
for the sshd service, too.

Also keep in mind that the user sshd_server needs read permissions on all
users' .ssh/authorized_keys file to allow public key authentication for
these users!.  (Re-)running ssh-user-config for each user will set the
required permissions correctly.

Which value should the environment variable CYGWIN have when
sshd starts? It's recommended to set at least "ntsec" to be
able to change user context without password.
Default is "ntsec".  CYGWIN=

The service has been installed under sshd_server account.
To start the service, call `net start sshd' or `cygrunsrv -S sshd'.

Host configuration finished. Have fun!

Administrator@moog ~
$ net start sshd
The CYGWIN sshd service is starting.
The CYGWIN sshd service was started successfully.

Using SSH to access Windows is the most bandwidth-efficient remote access system possible.

ssh administrator@192.168.2.2
administrator@192.168.2.2's password: 
Last login: Mon Aug 22 06:20:58 2005 from 192.168.2.5

Administrator@moog ~
$ df -h
Filesystem            Size  Used Avail Use% Mounted on
C:\cygwin\bin         9.8G  5.1G  4.7G  53% /usr/bin
C:\cygwin\lib         9.8G  5.1G  4.7G  53% /usr/lib
C:\cygwin             9.8G  5.1G  4.7G  53% /
c:                    9.8G  5.1G  4.7G  53% /cygdrive/c
g:                     60G   53G  7.3G  88% /cygdrive/g
h:                     70G   50G   20G  73% /cygdrive/h

Administrator@moog ~
$ who
sshd_server tty0         Aug 22 06:20 (MOOG)
Administrator tty1         Aug 22 06:56 (192.168.2.5)

It appears the 'who' command is not aware of an existing RDP session.

I was hoping I would find an easy way to configure Windows through a serial port. Unfortunately, Windows is not Unix. The closest approximation I found was Emergency Management Services (EMS), which requires motherboard support. EMS is definitely not as simple as modifying /etc/ttys.

I'm concerned with remote administration because this Windows server is in my lab. Also, I am trying to imagine the best way to change the system's IP address remotely, or at least in a headless situation. For example: I bring my Shuttle Windows server to class. The box has no monitor. I decide I need to change the system's IP address to use DHCP in a classroom setting, or to set a new static IP address. Using my laptop, I connect to the server (using on of these methods) and change the IP.

I plan to use one or more of these netsh commands. I can run these as a batch file or through the scheduler.

netsh interface ip show config

netsh interface ip set address name="Local Area Connection" static 192.168.0.100
 255.255.255.0 192.168.0.1 1

netsh -c interface dump > c:\location1.txt 

netsh -f c:\location1.txt 

netsh interface ip set address "Local Area Connection" dhcp

netsh interface ip set dns "Local Area Connection" static 192.168.0.200

netsh interface ip set dns "Local Area Connection" dhcp

These are not the actual commands I would run, only examples of what is possible.

From a Windows system, one other option exists: PsExec. For example:

C:\Program Files\pstools>psexec \\192.168.2.2 -u administrator -p "password"
 cmd.exe /c cmd.exe

PsExec v1.58 - Execute processes remotely
Copyright (C) 2001-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

Microsoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

C:\WINDOWS\system32>cd 
C:\>ipconfig

Windows IP Configuration

Ethernet adapter Local Area Connection:

   Connection-specific DNS Suffix  . :
   IP Address. . . . . . . . . . . . : 192.168.2.2
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.2.1

Does anyone have any suggestions?

Read More

Windows Server 2003 x64 Enterprise Edition

I managed to install Windows Server 2003, Enterprise x64 Edition (64-bit) trial on my Shuttle SB81P. The only component that wasn't recognized natively was the BCM5751
NetXtreme Gigabit Ethernet Controller for Desktops. I used the Windows Server 2003 (AMD x86-64) driver to get the NIC working. I'm lucky my FreeBSD dmesg output recognized this NIC accurately:

bge0:  mem 0xd0000000-0xd000ffff irq 16 at device 0.0 on pci1
miibus0:  on bge0
brgphy0:  on miibus0
brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto
bge0: Ethernet address: 00:30:1b:b6:96:75

The first time I booted Windows, I saw this message:



This was an interesting take on the idea of host-centric security. Microsoft could have started with no listening services, and let an administrator decide what to enable. Instead, Microsoft starts services by default, but blocks remote access to them until they are patched. This is a step in the right direction, but I am not happy with the underlying security model.

I decided to apply patches, after which I got this report:



This reminded me of the sign that said "Abandon all hope, ye who enter." At least that message should have had a red X or similar!

I installed IIS and then a 15-day trial version of VMWare GSX Server 3.2. I managed to install a FreeBSD 5.4 guest OS using 4 GB of HDD and 64 MB of RAM. I plan to push this box to see how many concurrent guests it can accommodate.

Read More

Plug and Play Worm in Wild

The SANS ISC is reporting that a worm which exploits the Plug and Play (PnP) vulnerability described by MS05-039 is in the wild. The F-Secure Blog reports the worm is called Zotob. The Microsoft bulletin lists three mitigating factors:

• On Windows XP Service Pack 2 and Windows Server 2003 an attacker must have valid logon credentials and be able to log on locally to exploit this vulnerability. The vulnerability could not be exploited remotely by anonymous users or by users who have standard user accounts. However, the affected component is available remotely to users who have administrative permissions.


• On Windows XP Service Pack 1 an attacker must have valid logon credentials to try to exploit this vulnerability. The vulnerability could not be exploited remotely by anonymous users. However, the affected component is available remotely to users who have standard user accounts.


• Firewall best practices [e.g., blocking SMB ports] and standard default firewall configurations can help protect networks from attacks that originate outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed.

Frank Knobbe is writing rules for the worm, which can be found by watching changes to the Bleeding Snort CVS interface for the all.rules file. Search for MS05-039 or 2002185, the rule SID.

His latest rule as of posting this story is

# Created 2005/08/14 by Frank Knobbe in response to first information posted on ISC
alert tcp any any -> any 1024:65535 (msg:"BLEEDING-EDGE Possible MS05-039 PnP worm infection";
flow:established,to_server; content:"get winpnp.exe"; depth:200; nocase; 
reference:url,isc.sans.org/diary.php?date=2005-08-14; classtype:trojan-activity; 
sid:2002185; rev:2;)

That rule watches for the compromised victim to retrieve a copy of itself using FTP from the infecting machine. Who says intrusion detection or full content monitoring is dead in an "age of encryption?" Remember the phases of compromise:

1. Reconnaissance


2. Exploitation


3. Escalation


4. Consolidation


5. Pillage

During steps 3 and 4, the victim can't expect the tools he needs to already be on the victim (like an encrypted transport tool such as scp). Hence the intruder uses FTP, TFTP, etc. These are good reasons to remove such client programs from production servers if possible. Escalation is the process of moving from user privileges to root privileges, if the exploitation phase doesn't yield root immediately. Consolidation is the process of installing back doors, retrieving tools, or other actions to establish control of the victim. In the case of a worm, consolidation is the means whereby the worm replicates itself.

SANS ISC is also releasing rules that appear to concentrate on the initial exploitation, not the propagation of the worm via FTP.

You can test the vulnerability of your systems via controlled exploitation using this Metasploit module. The worm may be based on this exploit by houseofdabus.

Incidentally, while writing this post, I came across the new OpenRCE.org (Open Reverse Code Engineering) site. I also found that the Security Forest Exploit Tree CVS Interface is up, and that site has started a blog.

Read More

Trying Microsoft Update and MBSA 2.0

Today while updating my Windows 2000 laptop I had the opportunity to try two new Microsoft programs. The first is the new Microsoft Update, more of a one-stop-shop for Windows patches. The second is version 2.0 of Microsoft Baseline Security Analyzer. Computerworld has some coverage, but here was my experience.

When I started Windows Update, I saw the following screen.



I decided to follow the "Upgrade" recommendation. After running Microsoft Update, I got these results.



You can see that Microsoft Office updates and updates for other Microsoft programs are available. I think the new interface works well.

Once I downloaded and installed all of the updates, I turned to the new MBSA 2.0. It doesn't look that much different, so the improvements are under the hood.



I got my results following the scan of the single laptop.



I don't necessarily agree with the "severe risk" assessment. I think MBSA complained because it found a FAT partition I use to share data between Windows 2000 and FreeBSD on the same laptop. MBSA prefers using NTFS.

In any case, MBSA did not report any security vulnerabilities. It was good to apparently see Microsoft Update retrieving the right updates and MBSA confirming it.

Read More

Virtual Desktops on Windows

I've been working in Windows more than usual recently as I push to complete my next book Extrusion Detection. I realized I really missed having multiple virtual desktops, like I do using Fluxbox or generally any UNIX windowing environment.

Enter Virtual Dimension. This is an open source virtual desktop system for Windows. It works flawlessly on my Windows 2000 Professional laptop. At the right you can see the small desktop that appears when you click on a tray icon. I like being able to see small icons representing the applications active on each desktop. For example, desktop 0 is running Firefox, 1 has Adobe Reader, 2 has Putty and Wish (for Sguil), and 3 has Windows Media Player. I don't know how I coped with a single Windows desktop before using this program.

Read More

Microsoft Windows Server 2003 Trial Downloads

I'm not one to ignore free software from Microsoft, even if it's only in trial format. I saw that a beta of Windows Server 2003 R2 is available for download. You must install it on the trial version of Windows Server 2003 with Service Pack 1 (SP1); normal Windows Server 2003 SP1 will apparently not work. I registered to download R2 beta and also Windows Server 2003 SP1. You can get them on CD as well, but that takes 4-6 weeks. I might try converting server to workstation using the provided link.

Read More

Microsoft Security Bulletins Obscure Details

Today is "patch Tuesday" at Microsoft. Let's consider how easy or difficult it is to get real details on the new vulnerabilities. First we visit www.microsoft.com/security and see "Current security updates:"

Get information on the latest software security updates.

- Exchange Security Update
- Windows Security Updates
- MSN Messenger Update
- Office Security Update

This is nice. Where do I start? I click on the link Windows Security Updates and end up at a page titled "Windows Security Updates Summary for April 2005." This page lists five security bulletins, Security Bulletin MS05-016 through MS05-20. I can't really tell a whole lot looking at the information on this page, although the "Technical bulletin" item for each yields clues.

The first security bulletin, MS05-016 says Vulnerability in Windows Shell That Could Allow Remote Code Execution (893086). Remote code execution is always bad. Does this mean an attacker can exploit a listening Windows service? I can't tell. I do click on the technical bulletin link to learn more.

Now I'm on a Microsoft TechNet page. It says the "Impact of Vulnerability" is "Remote Code Execution." I still don't see anything which clues me in to how this vulnerability can be exploited. I decide to click on the link "Vulnerability Details." Under the title "Windows Shell Vulnerability - CAN-2005-0063:" we read the following:

"A remote code execution vulnerability exists in the Windows Shell because of the way that it handles application association. If a user is logged on with administrative privileges, an attacker who successfully exploited this vulnerability could take complete control of the affected system. However, user interaction is required to exploit this vulnerability."

Ok, I still don't know if this vulnerability affects a listening service. Under "Vulnerability details" there's also a "FAQ for Windows Shell Vulnerability - CAN-2005-0063:", which I click.

Finally I read the answer to my question:

"How could an attacker exploit the vulnerability?

An anonymous attacker could try to exploit the vulnerability by convincing a user to open a specially crafted file. Opening this file could then cause the affected system to run code. The vulnerability would generally be exploited through unregistered file name extension types."

At least I learn that this "Remote Code Execution" vulnerability involves an administrator opening a malicious file.

Does this process seem ridiculous to you too? Now I have to perform the same process for the other vulnerabilities. How long is that going to take?

I suggest Microsoft publish a single page with a table showing the salient details of each new vulnerability. Those of us with network security responsibilities would probably like to see a table column with the title "Involves listening service vulnerable to attack" or similar. That way, we could quickly narrow our focus to the services which will likely become the targets for the next worm, script kiddie, or worse.

Read More

Security Insights from Microsoft Security Architect

Last night I attended the northern Virginia ISSA monthly meeting. The guest speaker was Dean Iacovelli, Security Systems Architect for the Microsoft Mid-Atlantic district. His overall theme was "beyond patching." Dean supports over 200 enterprise customers, for which he serves as "security pinata." Several ISSA members took him to task for Microsoft's security failings, but I thought Dean was diplomatic and handled their mildly aggressive questions well.

Dean said that the patching approach to security is becoming a "second or third line defense, like backups. You patch regularly but hope you don't need them." As evidence he cited the decreasing window of time between announcement of a vulnerability and release of an exploit. Patches are still the best way to fix a vulnerability in broken software, so Microsoft has been pursing multiple initiatives to improve their patches.

First, Microsoft is migrating from multiple update sites (e.g., Office Update, Windows Update, and Microsoft Update Center) to a single future "Microsoft Update" site in late 2005.

Second, Microsoft realized their seven profit and loss centers support eight different software installation methods. This year they will move all software installation to two methods. Operating systems will use update.exe and applications will use MSI 3.0. This will make using Microsoft Baseline Security Analyzer, Microsoft Systems Management Server, and Microsoft Software Update Services (migrating to Windows Update Services) more predictable and effective.

Third, Microsoft has worked to make their patches better. They have a standardized naming convention to ease management. They use binary diffs to reduce patch size. They are also "actually inspecting system configuration" (as opposed to pretending to do so?) to determine what patches are really needed.

Dean next discussed Security Configuration Wizard. This seemed like a fairly impressive way to lock down systems. It automatically detects and configures Microsoft services and their options, Microsoft client applications and their options, third-party applications, IPSec policies, registry settings, audit features, and IIS. Essentially you can apply all of Microsoft's recommended configuration options via an automated tool. I was disappointed to see Dean's demo fail, but I see the promise of the technology.

Dean mentioned a related tool called Microsoft Application Compatibility Analyzer. The idea behind this program is to run it for a week or so on a host to determine what applications users employ. This helps administrators learn if XPSP2 will break any of the user's applications. I hope to see more of this sort of tool for future Windows upgrades.

Speaking of XPSP2, Dean gave a behind-the-scenes look at the reasons for its development. Apparently the Blaster worm had a huge effect on Microsoft. They "took almost all developers off Longhorn for a year to work on XPSP2." The theme of XPSP2 was applying good default configurations. For example, XPSP2 enables the Microsoft firewall by default. It denies inbound connections to help prevent intrusions. XPSP2 also denies null sessions by default. Dean said XPSP2 has been downloaded 150 million times.

One of the ISSA attendees complained that XPSP2 features were not available for Windows 2000. In fact, Dean said Internet Explorer 7.0 will only be available for XPSP2 (at least at present). The ISSA attendee said it was too expensive for customers to upgrade to XP. I wanted to say that the best update to Windows 2000 is Windows XP, but I kept quiet. Dean replied to the other ISSA attendee that most big Microsoft customers with Windows 2000 installations "already own Windows XP" by virtue of their Microsoft Enterprise Agreement. He said getting these customers to upgrade to Windows XP is one of Microsoft's biggest problems.

Dean pitched four efforts Microsoft sees as being "beyond patching." Since he spent so much time on the earlier issues, Dean had to briefly describe each. The four efforts are:

1. Isolation and resiliency
2. Network segmentation
3. Rights Management Services
4. Smart cards for remote access

I found his network segmentation discussion interesting. Microsoft is pushing for an all-IPSec internal network. All Active Directory-managed hosts would speak IPSec, and anything that doesn't is considered untrusted. I believe Dean said this is how Microsoft operates its internal network.

Regarding Microsoft's internal practices, Dean encouraged listeners to visit the IT Showcase site. There Microsoft publishers papers on how it secures its own network. He said that Microsoft operates the largest wireless 802.1x deployment in the world. They have also run Network Access Protection for two years for VPN clients.

I found Dean's short description of Rights Management Services to be intriguing. It will use eXtensible rights Markup Language and AES 128 encryption to protect individual documents. Only those operating rights management-enabled programs should be able to read RM-protected documents. I welcome the idea of a data-centric approach to security, but I am sure someone will figure out how to break this system.

Beyond the four efforts already in production, Dean pointed to three future area for Microsoft:

1. Network quarantine
2. Vulnerability assessment
3. Active protection

First, Microsoft Network Access Protection will work with Cisco Network Admission Control. Initially they did not want to cooperate, but their alliance was a result of customer pressure. Network Magazine profiled the two technologies recently. At first glance I prefer Cisco's 802.1x switch port-centric approach, rather than Microsoft's DHCP-centric method. Who cares if I don't get a DHCP server to provide an IP, when I can steal what I need from another host?

Dean's quarantine slide said NAP is "not designed to protect against malicious users." Somehow I think the Microsoft marketing drones will end up twisting NAP to be useful against malicious users. Again referring to Blaster, Dean said 70% of his customer's compromises were caused by VPN users, and 30% by "walk-ins." Microsoft believes that if NAP can quarantine these sorts of users, then it will help contain future Blaster-like problems.

The second step, vulnerability assessment, is code named the "Geneva feature set." Microsoft seems to want to offer continuous internal vulnerability assessment services. These will make further inroads to the security space, given Microsoft's Malicious Software Removal Tool, Microsoft AntiSpyware, and SpyNet. I didn't really hear much about the third step, code-named Mako.

All of these are slated for Longhorn, due some time in 2007. He said a beta should be available by Q4 2005. However, Microsoft now says "it's ready when it's ready." Customers will need to do a lot of testing for these features, especially network quarantine. Dean recommended the following processes need to be considered: rollout and change process control planning; success matrices and measures; exemption analysis; host health modeling; health policy zones; secure network infrastructure analysis; RADIUS implementation; and zone enforcement selection. What does all of this mean? Figuring it out is probably the first step!

One of my responses to this was to consider the complexity of all of the steps Microsoft is taking to implement security for hosts running Windows. With complexity comes opportunity for misconfiguration, plus vulnerabilities introduced by new code and processes. Microsoft might say their new systems will prevent rogue insiders or malicious outsiders from attacking Microsoft services. It seems to me that the opportunity to attack the authentication and encryption services still exists. Why bother to fool, bribe, or otherwise subvert a guard if you can silently kill him?

I had a similar thought with respect to the IPSec-everywhere approach. This will help preserve confidentiality and integrity within the enterprise. However, most internal intruders are probably rogue insiders. They will already have the authorization needed to access internal documents. Independent network-based systems trying to audit internal activity will be blind to IPSec-encrypted traffic. Is this trade-off worth it? I'm not sure.

As an aside, Dean mentioned a Windows feature of which I was unaware: Server Message Block signing. I plan to look more closely at this.

I find these ISSA meetings very useful and I plan to join my local chapter.

Read More