Today is patch Tuesday for March 2010, and Microsoft has released two security bulletins for this round of updates, neither of which are deemed critical. The second bulletin addresses seven different vulnerabilities across various versions of Microsoft Office Excel.

ID: MS10-016
Title: Vulnerabilities in in Windows Movie Maker Could Allow Remote Code Execution
Microsoft Severity: Important

Summary: There is a buffer overflow in the Windows Movie Maker and MS Producer 2003 which can lead to code execution. Movie Maker 2.1 is included with Windows XP SP2 and SP3, and Movie Maker 6.0 is included with Vista. Movie Maker 2.6 is an optional download for Vista and Windows 7.

Praetorian’s Recommendation: This is deemed important instead of critical due to the user having to run content which exploits the vulnerability. A user would have to be tricked into opening a Movie Maker project file (mswmm) to be exploited. This can be updated in your next patch cycle, and is not considered urgent.

ID: MS10-017
Title: Vulnerability in Microsoft Office Excel Could Allow Remote Code Execution
Microsoft Severity: Important

Summary: This update addresses seven different vulnerabilities related to Microsoft Office Excel. Each vulnerability may affect one or more of the following versions: Office Excel 2003 SP3, Office Excel 2003 SP3, Office Excel 2007 SP1 and SP2, Office 2004 for Mac, Office 2008 for Mac, Open XML File Format Converter for Mac, Office Excel Viewer SP1 and SP2, Office Compatibility Pack for Word, Excel, and Powerpoint 2007 File Formats SP1 and SP2, and Office SharePoint Server 2007 SP1 and SP2.

Praetorian’s Recommendation: Although the same requirement exists as MS10-016 for users to open malicious files, Excel formats are more recognizable and phishing and social engineering techniques can be more successful with a known or common file format. This can be updated in your next patch cycle, but should warrant more attention than MS10-017.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• Press F1 for Help, pwned.
• February’s Patch Tuesday
• Using Group Policy to Disable JavaScript in Adobe PDF Files

• MS09-071 – Vulnerabilities in Internet Authentication Service Could Allow Remote Code Execution (974318)
• MS09-074 – Vulnerability in Microsoft Office Project Could Allow Remote Code Execution (967183)
• MS09-072 – Cumulative Security Update for Internet Explorer (976325)
• MS09-069 – Vulnerability in Local Security Authority Subsystem Service Could Allow Denial of Service (974392)
• MS09-070 – Vulnerabilities in Active Directory Federation Services Could Allow Remote Code Execution (971726)
• MS09-073 – Vulnerability in WordPad and Office Text Converters Could Allow Remote Code Execution (975539)

Severity Levels

Microsoft has a rating system for bulletins which includes: Critical, Important, Moderate, and Low. The severity levels I provide below are not directly from Microsoft. For example, MS will give an important rating when exploitation could result in compromise of availability, as in a denial of service. MS09-069 can result in a denial of service, however, the attacker must already be authenticated. For this reason I drop the severity to Low.

Bulletin Summaries

Bulletin: MS09-071
Recommended Action: Update Windows 2008 Server (32-bit and 64-bit) which have IAS configured to use PEAP with MS-CHAP v2 authentication.
My Severity Rating: Moderate, should patch the above mentioned software.

This update addresses two vulnerabilities in the Internet Authentication Service (IAS). One is an IAS memory corruption vulnerability and the second is an authentication bypass vulnerability in MS-CHAP authentication. Client operating systems contain the vulnerable code but the components are not used in a way to make them vulnerable.

Bulletin: MS09-074
Recommended Action: Update MS Project 2000 SR-1.
My Severity Rating: Important for Project Software

This update addresses a vulnerability in Microsoft Project which can cause remote code execution when a specially crafted Project file is opened.  Microsoft Project 2000 SR-1, Project 2002 SP1 and Project 2003 SP3 are affected.

Bulletin: MS09-074
Recommended Action: Update Internet Explorer
My Severity Rating Critical

This update addresses five difference vulnerabilities with at least one or more affected every version of Internet Explorer. Attackers can host malicious code which can lead remote code execution on vulnerable systems. Any issues that lead to remote execution in IE should be addressed immediately; even if you are confident about not browsing malicious sites, a known site, such as the Pentagon web site, could be used to automatically execute or redirect you to malicious code using cross-site scripting.

Bulletin: MS09-069
Recommended Action: Update Windows 2000, Windows XP and Windows 2003
My Severity Rating: Low

A vulnerability in LSASS can cause a denial of service. The attacker must be authenticated and communicating through IPSEC.

Bulletin: MS09-070
Recommended Action: Update Windows 2003 and Windows 2008 Servers
My Severity Rating: Low

This update addresses two vulnerabilities in Active Directory Federation Services, one which can be used to spoof an authenticated user and the second which can cause remote code execution. The spoofing requires access to a workstation and browser recently used by a targeted user and the remote code execution requires the attacker to have valid logon credentials to the vulnerable server.

Bulletin: MS09-069
Recommended Action: Update Windows XP SP3 and/or Office 2003 SP3
My Severity Rating: Moderate

A vulnerability in text converters in WordPad and Office can cause remote code execution. Malicious code can be hosted on a website to trigger an exploit, however, an attempt would cause a dialog box to appear prompting the user to open the file (unless the option to “Always ask before opening this type of file” has been unchecked).

Adobe

Adobe has mirrored the patch Tuesday schedule of releasing patches on the first Tuesday of the month. The severity ratings also follow the same definitions a s Microsoft’s.

Adobe has two advisories for this month:

Bulletin: APSA09-06
Recommended Action: Update Adobe Illustrator CS4 and earlier. (Avail Jan 8)
My Severity Rating: Low

A vulnerability in Illustrator CS4 and earlier could lead to remote code execution. The target is required to open a malicious eps file.

Bulletin: APSA09-17
Recommended Action: Update Adobe Flash Player and Adobe AIR
My Severity Rating: Low

Adobe states this is a critical update and it is scheduled for release today, but does not provide details of the update.

Updates

Adobe has released details on the Flash Player update. The update addresses six vulnerabilities, five which can lead to remote execution and one to information disclosure. The vulnerabilities were identified in Flash Player version 10.0.32.18 and earlier.

References

• Microsoft’s December Bulletins
• Adobe’s Security Advisories

Related Posts:

• Turning an ATM into a Slot Machine
• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.

In working with OSSEC agentless for some time now I have come across some limitations in the implementation that I felt needed to be addressed. As OSSEC agentless is designed to preform syscheck functions on remote hosts, more general features are hard (if not impossible) to write into a script.

Currently in OSSEC, agentless scripts are limited to the following commands:

Given the choices listed here more advanced agentless scripts are just not reasonably possible. I require the ability to pass more information to the OSSEC agentless process and have it raise alerts based on this information.

Solution patch OSSEC

So I starting digging into the OSSEC code. I am not a C coder, I don’t even play one on TV, but the OSSEC’s code is clear and has just enough comments to allow me to understand how things function. Once I saw where the communication happens between ossec-agentless and it’s subprocess I was quickly able to add a new OSSEC Agentless Command.

This simple command allow scripts to generate messages that will get processed by the standard OSSEC decoders and rules.

• Direct download of patch: agentless.patch.txt

Patching OSSEC

The patch I created works with the current code release of OSSEC. To apply the patch, first download OSSEC version 2.2 from the website. In the instructions below, I have changed to the tmp directory first as we will be removing the source files once we have finished the install.

obsd46# cd /tmp 
obsd46# ftp http://www.ossec.net/files/ossec-hids-2.2.tar.gz
Trying 75.126.165.213...
Requesting http://www.ossec.net/files/ossec-hids-2.2.tar.gz
100% |******************************************************************|   692 KB    00:03    
Successfully retrieved file.

Now expand the downloaded archive and change into the newly created directory ossec-hids-2.2.

obsd46# tar xfz ossec-hids-2.2.tar.gz                                                                                                                                                   
obsd46# cd ossec-hids-2.2       

This is where most of the work will happen, but first we need to download the patch.

obsd46# ftp http://praetorianprefect.com/wp-content/uploads/2009/11/agentless.patch.txt                             
Trying 75.101.150.229...
Requesting http://praetorianprefect.com/wp-content/uploads/2009/11/agentless.patch.txt
100% |******************************************************************| 10278       00:00    
Successfully retrieved file.

Now we just apply the patch. We will use the patch command do this, but using the argument -p1 to apply the patch cleanly to all sub-directories.

obsd46# patch -p1 < agentless.patch.txt  
Hmm... this looks like a unified diff to me...
The text leading up to this was:
 |-------------------------
 |diff -r 55072a52aaa4 -r 673c04be67e9 etc/decoder.xml
 |--- a/etc/decoder.xml  Wed Nov 04 20:51:36 2009 -0500
 |+++ b/etc/decoder.xml  Fri Nov 06 19:53:36 2009 +0000
 |-------------------------
Patching file etc/decoder.xml using Plan A...
Hunk #1 succeeded at 70.
Hunk #2 succeeded at 1498.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
 |-------------------------
 |diff -r 55072a52aaa4 -r 673c04be67e9 etc/rules/agentless_rules.xml
 |--- /dev/null  Thu Jan 01 00:00:00 1970 +0000
 |+++ b/etc/rules/agentless_rules.xml    Fri Nov 06 19:53:36 2009 +000 0
 |-------------------------
(Creating file etc/rules/agentless_rules.xml...)
Patching file etc/rules/agentless_rules.xml using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
 |-------------------------
 |diff -r 55072a52aaa4 -r 673c04be67e9 etc/rules/ossec_rules.xml
 |--- a/etc/rules/ossec_rules.xml        Wed Nov 04 20:51:36 2009 -0500
 |+++ b/etc/rules/ossec_rules.xml        Fri Nov 06 19:53:36 2009 +0000
 |-------------------------
Patching file etc/rules/ossec_rules.xml using Plan A...
Hunk #1 succeeded at 153.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
 |-------------------------
 |diff -r 55072a52aaa4 -r 673c04be67e9 etc/templates/config/rules.template
 |--- a/etc/templates/config/rules.template      Wed Nov 04 20:51:36 2009 -0500
 |+++ b/etc/templates/config/rules.template      Fri Nov 06 19:53:36 2009 +0000
 |-------------------------
Patching file etc/templates/config/rules.template using Plan A...
Hunk #1 succeeded at 44.
Hmm...  The next patch looks like a unified diff to me...
The text leading up to this was:
 |-------------------------
 |diff -r 55072a52aaa4 -r 673c04be67e9 src/agentlessd/scripts/nmap_policy
 |--- /dev/null  Thu Jan 01 00:00:00 1970 +0000
 |+++ b/src/agentlessd/scripts/nmap_policy       Fri Nov 06 19:53:36 2009 +0000
 |-------------------------
(Creating file src/agentlessd/scripts/nmap_policy...)
Patching file src/agentlessd/scripts/nmap_policy using Plan A...
Empty context always matches.
Hunk #1 succeeded at 1.
done 

Now we have a completed all the OSSEC 2.2 code patches for the expanded agentless features. At this point you will need to compile and install OSSEC. For full details the main OSSEC website covers this topic in more detail. A key thing to note here is that OSSEC has to be installed as a server or locally.

Please see my article on how to enable OSSEC agentless monitoring.

Making use of the new features

Now that we have a patched and installed version of OSSEC we can take advantage of the newly added features. Included with the patch is a new Agentless OSSEC script nmap_policy. This script is really not designed for production use, rather it’s geared to show how to use the new agentless features.

Let’s get into the details. Start by running the new script and looking at the output. I should note that this script uses python and needs at least version 2.5 in order to parse the xml output from nmap.

obsd45# (cd /var/ossec && ./agentless -b 21,23,80 -n 172.17.20.20/32 )
INFO: Starting
INFO: running `nmap -p 21,23,80 -oX - 172.17.20.0/24` command
INFO: completed `nmap -p 21,23,80 -oX - 172.17.20.0/24` command
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)
LOG:alert=11 Policy violation port 23 (telnet) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.19 (00:18:8B:1E:27:A5 Dell)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.20 (00:0C:29:84:72:11 VMware)
LOG:alert=11 Policy violation port 21 (ftp) is open on host 172.17.20.20 (00:0C:29:84:72:11 VMware)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.21 (00:0C:29:8D:39:E4 VMware)
LOG:alert=11 Policy violation port 21 (ftp) is open on host 172.17.20.21 (00:0C:29:8D:39:E4 VMware)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.31 (00:0C:29:29:CF:35 VMware)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.32 (00:0C:29:58:5F:C1 VMware)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.57 (00:1E:0B:9D:C0:03 Hewlett Packard)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.91 (00:14:38:D8:01:DD Hewlett Packard)
LOG:alert=11 Policy violation port 21 (ftp) is open on host 172.17.20.134 (00:1E:C2:03:2D:E8 Apple)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.202 (00:19:B9:24:7E:F2 Dell)
LOG:alert=11 Policy violation port 80 (http) is open on host 172.17.20.203 (00:19:B9:24:7E:F2 Dell)
INFO: Ending

So what this script does is run nmap and looks for ports that are open and not allowed per an internal policy. In this example I checked for http, telnet, and ftp, but the selection of ports is configurable with the -b/--badport arguments. The second argument -n/--network is used to specify which IP addresses to scan. The format of this option is very liberal, in fact any valid nmap network specification will work.

Just as I specified above any string following the LOG: OSSEC agentless command will be pushed to the ossec-analysisd process for decoding and rules filtering.

As part of the patch I have also included an updated decode.xml and a new agentless_rules.xml to begin the first level of processing of output from the scripts. Using ossec-logtest we can see this in action, but due to how ossec-agentlessd processes the messages we need to slightly modify the output for it to work with ossec-logtest.

obsd46# (cd /var/ossec && ./bin/ossec-logtest )                                                                                                                                                            
2009/11/06 20:48:28 ossec-testrule: INFO: Started (pid: 9789).
ossec-testrule: Type one log per line.

Agentless: Log:alert=11 Policy violation port 80 (http) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)


**Phase 1: Completed pre-decoding.
       full event: 'Agentless: Log:alert=11 Policy violation port 80 (http) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)'
       hostname: 'a'
       program_name: '(null)'
       log: 'Agentless: Log:alert=11 Policy violation port 80 (http) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)'

**Phase 2: Completed decoding.
       decoder: 'agentless'
       id: '11'
       extra_data: 'Policy violation port 80 (http) is open on host 172.17.20.1 (00:0E:83:A9:E6:80 Cisco Systems)'

**Phase 3: Completed filtering (rules).
       Rule id: '10011'
       Level: '11'
       Description: 'Agentless.'
**Alert to be generated.

You can see from the output that a level 11 alert would be generated for the line we just tested with ossec-logtest. In the case of the full output of the nmap_policy script it has 13 LOG: lines returned and would have generated 13 alerts. Needless to say this is a lot of alerts, so it’s up to you to tune and configure this correctly for your environment.

In our lab here at Praetorian we don’t ever want to see the telnet port open. So lets make this script live, but only checking for telnet. I am going to once again make use of ossec-hids-tools to add the new agentless monitoring. As is always the case a restart of OSSEC will be needed.

obsd46# ossec-config --section agentless --add --host jrossi@172.17.20.0 --type nmap_policy 
--frequency 86400 --state periodic --argv "-p 23 -n 172.17.20.0/24"
obsd46# (cd /var/ossec && ./bin/ossec-control restart )

While adding this new agentless script I had to specify a --host argument. This is required for OSSEC agentless as the host field is NOT optional. In the case of the script nmap_policy it will have no effect, but this needs to be taken into account when writing your own scripts as the first argument passed will always be what you specified as the host.

Related Posts:

• March’s Patch Tuesday
• The “Aurora” IE Exploit Used Against Google in Action
• Scareware Purveyors, Spammers, and Crooks Take Advantage of Haiti Earthquake
• Baidu.com the Latest Victim of Iranian CyberArmy
• JUNOS (Juniper) Flaw Exposes Core Routers to Kernel Crash

Table of Contents

• Agentless Scripts

  • Periodic diff Specification
  • Periodic Specification
• Agentless Script: ssh_integrity_check_linux

• Our own Agentless Script: ssh_dmz_linux

  • Finding all setuid and setgid files
  • Finding all authentication and applications specific files
  • Merging finds
  • Creating ssh_dmz_linux
  • Testing

Agentless Scripts

All scripts that work with OSSEC agentless security monitoring use stdout for communication and reporting to the OSSEC server. This makes writing scripts for OSSEC simple as you do not need to do anything more then print or echo to stdout. The format of the output does need to meet the OSSEC specification, but that is a very simple thing to do.

Before we move to the specification details I need to explain that OSSEC agentless runs to different types of scripts. Namely the following:

Periodic diff Specification

The output for periodic_diff is very simple, any and all output after the agentless command “STORE: now” and before the next OSSEC Command will be stored and compared for differences. This type of script is mostly used for hardware devices such as Cisco IOS, Juniper JunOS, and other products.

Scripts that use the periodic_diff make use of the following commands:

Here is an example of a periodic_diff script that comes with OSSEC. (Please note with all agentless scripts you must be in the root of the OSSEC install for them to function correctly.)

obsd46#( cd /var/ossec && ./agentless/ssh_pixconfig_diff cisco@172.17.0.1 'show hardware' )
spawn ssh -c des cisco@172.17.0.1
No valid ciphers for protocol version 2 given, using defaults.
Password: 

a.zfw.tss>INFO: Starting.
enable
Password: 
a.zfw.tss#ok on enable pass

STORE: now
no pager
             ^
% Invalid input detected at '^' marker.

a.zfw.tss#term len 0
a.zfw.tss#terminal pager 0
                     ^
% Invalid input detected at '^' marker.

a.zfw.tss#show version | grep -v Configuration last| up
                         ^
% Invalid input detected at '^' marker.

a.zfw.tss#show running-config
Building configuration...


Current configuration : 14631 bytes
!
version 12.4

[................SNIP CONFIG.................]

a.zfw.tss#show hardware
Cisco IOS Software, 3800 Software (C3845-ADVENTERPRISEK9-M), Version 12.4(24)T1, RELEASE SOFTWARE (fc3)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2009 by Cisco Systems, Inc.
Compiled Fri 19-Jun-09 19:21 by prod_rel_team

ROM: System Bootstrap, Version 12.3(11r)T2, RELEASE SOFTWARE (fc1)

a.zfw.tss uptime is 1 week, 5 days, 7 hours, 29 minutes
System returned to ROM by reload at 13:34:26 UTC Thu Oct 22 2009
System image file is "flash:c3845-adventerprisek9-mz.124-24.T1.bin"


This product contains cryptographic features and is subject to United
States and local country laws governing import, export, transfer and
use. Delivery of Cisco cryptographic products does not imply
third-party authority to import, export, distribute or use encryption.
Importers, exporters, distributors and users are responsible for
compliance with U.S. and local country laws. By using this product you
agree to comply with applicable laws and regulations. If you are unable
to comply with U.S. and local laws, return this product immediately.

A summary of U.S. laws governing Cisco cryptographic products may be found at:

http://www.cisco.com/wwl/export/crypto/tool/stqrg.html

If you require further assistance please contact us by sending email to
export@cisco.com.

Cisco 3845 (revision 1.0) with 1007615K/40960K bytes of memory.
Processor board ID FTX1043A2CR
2 Gigabit Ethernet interfaces
1 ATM interface
1 Virtual Private Network (VPN) Module
4 CEM T1/E1 ports
DRAM configuration is 64 bits wide with parity enabled.
479K bytes of NVRAM.
492015K bytes of USB Flash usbflash0 (Read/Write)
62720K bytes of ATA System CompactFlash (Read/Write)

Configuration register is 0x2102


a.zfw.tss#exit
Connection to 172.17.0.1 closed by remote host.
Connection to 172.17.0.1 closed.

INFO: Finished.

In this example above the script would store the contents between “STORE: now” and “INFO: Finished.“. If this is the first time that OSSEC agentless has run this command no alerts would be generated and the contents would have been saved for later comparisons. If OSSEC agentless has a stored copy from a previous execution it will compare the files and if there are any differences it will generate an alert.

Periodic Specification

The periodic specification has more options and gives more control to the script writer on what actions OSSEC will take. Once again stdout is used for communication so script writing is easy.

Example of real FWD: command.

FWD: 19419:600:0:0:fb30de5b02029950ae05885a3d407c8c:017cd6118cdc166ee8eba8af1b7fdad6763203d3 ./.bash_history

The Fields break down in to the following

Using this format OSSEC can store the information about a file and then in the future run compare that they are the same. If for some reason they are not the same an alert will be generated. Here is an example of a password change on a linux system:

OSSEC HIDS Notification.
2009 Sep 21 15:19:00

Received From: (ssh_integrity_check_linux) root@172.17.20.20->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/etc/shadow'
Old md5sum was: '0d92e12c92f3edcf9d8876ea57c5f677'
New md5sum is : '2bd51b61dea17c5682fb2c0cf4f92c63'
Old sha1sum was: '2270c03a920ef8dd50e11cefdef046a8660f7a29'
New sha1sum is : 'd9518ea9022b10d07f81925c6d7f2abb4364b548'

--END OF NOTIFICATION

Agentless Script: ssh_integrity_check_linux

Now that we have an understanding of how agentless scripts communicate with the parent OSSEC preocess, let’s move on to a working example. The OSSEC supplied script ssh_integrity_check_linux is a great place to start, so lets open it up and see what is going on.

obsd46# cat /var/ossec/agentless/ssh_integrity_check_linux
 #!/usr/bin/env expect

 # @(#) $Id: ssh_integrity_check_linux,v 1.11 2009/06/24 17:06:21 dcid Exp $
 # Agentless monitoring
 #
 # Copyright (C) 2009 Trend Micro Inc.
 # All rights reserved.
 #
 # This program is a free software; you can redistribute it
 # and/or modify it under the terms of the GNU General Public
 # License (version 3) as published by the FSF - Free Software
 # Foundation.


 # Main script.
source "agentless/main.exp"


 # SSHing to the box and passing the directories to check.
if [catch {
    spawn ssh $hostname
} loc_error] {
    send_user "ERROR: Opening connection: $loc_error.\n"
    exit 1;
}


source $sshsrc
source $susrc

set timeout 600
send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do tail \$i >/dev/null 2>&1 && 
md5=`md5sum \$i | cut -d \" \" -f 1` && sha1=`sha1sum \$i | cut -d \" \" -f
 1` && echo FWD: `stat --printf \"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
send "exit\r"

expect {
    timeout {
        send_user "ERROR: Timeout while running commands on host: $hostname .\n"
        exit 1;
    }
    eof {
        send_user "\nINFO: Finished.\n"
        exit 0;
    }
}

exit 0;

The comments in the script hints to what is going on, but everything up to and including set timeout 600 is related to setting up the expect functions and code for handling the ssh subprocess and connecting to the remote host. I am not going to spend any time with this section, I am just going to make use of it.

The meat of what is getting processed on the remote end all happens in two lines.

send "echo \"INFO: Starting.\"; for i in `find $args 2>/dev/null`;do tail \$i >/dev/null 2>&1 && 
md5=`md5sum \$i | cut -d \" \" -f 1` && sha1=`sha1sum \$i | cut -d \" \" -f
 1` && echo FWD: `stat --printf \"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
send "exit\r"

Let’s break this down to see what is happening.

The send command pushes the following string to the ssh subprocess which gets run on the remote end of the connection. Before the script is sent to the remote host expect internally processes the string. This includes searching for variables and removing any control characters.

The control characters are first taken into account, and in the case of our example all escaped special characters are processed. \", \r, and \$ would be replaced with ", “carriage return“, and & respectively. The reason the escape characters are needed so that they will not interfere with expects own string processing and control. We will need to handle control characters in this way when we begin writing our own script.

While special characters were being handled by expect it also looked for variables to replace, in this case it will find $args and replace it with what ever arguments were passed to the script by the OSSEC agentless process. If we specified the following in /var/ossec/etc/ossec.conf the $args variable would be replaced with “/bin /etc /sbin“.

  <agentless>
    <type>ssh_integrity_check_linux</type>
    <frequency>3600</frequency>
    <host>root@172.17.20.20</host>
    <state>periodic</state>
    <arguments>/bin /etc /sbin</arguments>
  </agentless>

Back to the commands that get run. Once expect has completed replacement we are left with this command.

echo "INFO: Starting."; for i in `find /bin /etc /sbin 2>/dev/null`;do tail $i >/dev/null 2>&1 && 
md5=`md5sum $i | cut -d " " -f 1` && sha1=`sha1sum $i | cut -d " " -f
 1` && echo FWD: `stat --printf "%s:%a:%u:%g" $i`:$md5:$sha1 $i; done; exit
exit

This script then goes and uses the Unix find command to locate all files in the specified path (from the arguments passed) and generates an OSSEC FWD: command for each one and prints it to stdout. Making use of the commands stat, md5sum, and sha1sum to generate the data needed. Here is an example of the output checking.

spawn ssh root@172.17.20.20
Last login: Wed Nov  4 11:32:51 2009 from 172.17.20.131^M
[linux26 ~]# 
INFO: Started.
echo "INFO: Starting."; for i in `find {/bin /etc /sbin} 2>/dev/null`;do tail $i >/dev/null 2>&1 && 
md5=`md5sum $i | cut -d " " -f 1` && sha1=`sh a1sum $i | cut -d " " -f
 1` && echo FWD: `stat --printf "%s:%a:%u:%g" $i`:$md5:$sha1 $i; done; exit
INFO: Starting.
FWD: 833:644:0:0:4148adea745af5121963f6b731b60013:60877a6f6981b16c0d53d32bcd3f07d41cfb5bd4 /etc/modprobe.d/
glib2.sh
[...........SNIP............]
FWD: 1696:644:0:0:c2bd306b205ad9e81fb02ce6b225d384:5244d65815cb228a4fac7bc4c1c7774508fb7505 /etc/nsswitch.conf
FWD: 85179:644:0:0:8db574225cd1068b47e77ceccd96f8ff:b5ef6183b35ee9d1b66ed2cefe98003c5bd99192 /etc/sensors.conf
FWD: 49:644:0:0:52c3df2f1edf30ca3db82174be3a68d2:1934648f2429b70b1f729d343a6956fb0ea73136 /etc/php.d/imap.ini
FWD: 873:644:0:0:04559d1fe27ecd079b69df8b319f937e:e5cab1bf1f9e4bc4386309f4e00a9b7be3e543a2 /etc/php.d/memcache.ini
FWD: 59:644:0:0:94636ba6c4bac9d8d49d9de1a513ae0c:41d5164a2c6e332e40edf55c59a2d0df8a260964 /etc/php.d/pdo_mysql.ini
FWD: 49:644:0:0:917dbbafbfaaa20f660063d627123dae:0e829d4ffc69f58dc258510b4b8452412e31ccc5 /etc/php.d/json.ini
FWD: 0:644:0:0:d41d8cd98f00b204e9800998ecf8427e:da39a3ee5e6b4b0d3255bfef95601890afd80709 /etc/wvdial.conf
logout
Connection to 172.17.20.20 closed.

INFO: Finished.

Our own Agentless Script: ssh_dmz_linux

Using the built in OSSEC agentless scripts are great, but sometimes we need more focused scanning and checking. So let’s modify the ssh_integrity_check_linux for our environment.

The goals for this new script will be to watch for changes to files based on the following criteria:

• All setuid and setgid files
• All files related to authentication (including .htaccess and ssh files)
• All application specific files (apache, ssh)

Finding all setuid and setgid files

Let’s first start by identifying a method to locate all files with their setuid or setgid bits enabled. To do this we will ssh to the host 172.17.20.20 and use find to locate the files.

obsd46# sudo -u ossec ssh root@172.17.20.20
[linux26 ~]# find / -type f \( -perm -4000 -o -perm -2000 \) 
/sbin/umount.nfs
/sbin/netreport
/sbin/unix_chkpwd
/sbin/mount.nfs
/sbin/pam_timestamp_check
/sbin/mount.nfs4
/sbin/umount.nfs4
/bin/ping6
/bin/su
/bin/umount
/bin/ping
/bin/mount
/lib/dbus-1/dbus-daemon-launch-helper
/usr/libexec/openssh/ssh-keysign
/usr/libexec/utempter/utempter
/usr/sbin/usernetctl
/usr/sbin/postqueue
/usr/sbin/userhelper
/usr/sbin/userisdnctl
/usr/sbin/postdrop
/usr/sbin/suexec
/usr/bin/chsh
/usr/bin/chfn
/usr/bin/sudo
/usr/bin/locate
/usr/bin/wall
/usr/bin/sudoedit
/usr/bin/gpasswd
/usr/bin/lockfile
/usr/bin/newgrp
/usr/bin/write
/usr/bin/screen
/usr/bin/passwd
/usr/bin/chage
/usr/bin/sperl5.8.8
/usr/bin/crontab
/usr/bin/ssh-agent

Finding all files related to authentication and applications specific files

Finding all files with setuid and setgid was simple, but finding all files related to authentication is more invloved. This of course will vary from system to system, but this should be good starting point.

obsd46# sudo -u ossec ssh root@172.17.20.20
[linux26 ~]# find / \( -name ".ssh" -o -name "ssh" -o -name "sshd" -o -name "httpd" -o -name ".htaccess" 
-o -name "pam.d" \) -exec find {} \;
/var/www/html/admin/modules/framework/var/www/html/admin/modules/.htaccess
/etc/httpd
/etc/httpd/conf
/etc/httpd/conf.d
/etc/httpd/conf.d/php.conf
/etc/httpd/conf.d/proxy_ajp.conf
/etc/httpd/conf.d/README
/etc/httpd/conf.d/ssl.conf
/etc/httpd/conf.d/welcome.conf
/etc/httpd/conf/httpd.conf
/etc/httpd/conf/magic
/etc/httpd/logs
/etc/httpd/modules
/etc/httpd/run
/etc/logrotate.d/httpd
/etc/pam.d
/etc/pam.d/authconfig
[...................SNIP PAM Files.....................]
/etc/pam.d/system-config-network-cmd
/etc/pam.d/vsftpd
/etc/rc.d/init.d/httpd
/etc/rc.d/init.d/sshd
/etc/ssh
/etc/ssh/ssh_config
/etc/ssh/sshd_config
/etc/ssh/ssh_host_dsa_key
/etc/ssh/ssh_host_dsa_key.pub
/etc/ssh/ssh_host_key
/etc/ssh/ssh_host_key.pub
/etc/ssh/ssh_host_rsa_key
/etc/ssh/ssh_host_rsa_key.pub
/etc/sysconfig/httpd
/root/.ssh
/root/.ssh/authorized_keys
/usr/bin/ssh
/usr/lib/httpd
/usr/lib/httpd/modules
/usr/lib/httpd/modules/libphp5.so
[...................SNIP Apache modules................]

/usr/lib/httpd/modules/mod_vhost_alias.so
/usr/sbin/httpd
/usr/sbin/sshd
/usr/src/tbm-pbxconfig-5.5.1/amp_conf/htdocs/admin/modules/framework/htdocs/admin/modules/.htaccess
/usr/src/tbm-pbxconfig-5.5.1/amp_conf/htdocs/admin/modules/.htaccess
/var/empty/sshd
/var/empty/sshd/etc
/var/empty/sshd/etc/localtime
/var/www/html/admin/modules/framework/var/www/html/admin/modules/.htaccess
/var/www/html/admin/modules/.htaccess

Merging finds

Now we have two basic find methods that identify the files we want to monitor for changes, but our finds were a little greedy so we should create a way to strip out unwanted files from the list. As this is a unix system egrep is the king for finding or removing items from a list. To simplify things we can use egrep with the -v command line argument which tells egrep NOT to print any matching items.

Just to make sure that we do not end up double processing files we can make use of the sort command with -u argument to remove any duplicates.

Here is how we would put together both finds, egrep, and sort to locate and filter what is needed.

(find / -type f \( -perm -4000 -o -perm -2000 \) && \find / \( -name ".ssh" -o -name "ssh" -o -name "sshd" 
-o -name "httpd" -o -name ".htaccess" -o -name "pam.d" \) -exec find {} \; ) 2>/dev/null | egrep 
-v "known_hosts|moduli|var\/log|var\/lock" | sort -u

The above command we have found all files and paths that we would like to monitor, but this still needs to be integrated into a script on the OSSEC server.

Creating ssh_dmz_linux

We don’t want to make changes to ssh_integrity_check_linux directly so we will need to make a copy.

obsd46# (cd /var/ossec/agentless && cp ssh_integrity_check_linux ssh_dmz_linux)

Integrating our new command line into the script we must pay close attention to special characters that expect will process. Due to this we will need to escape all / and " by proceeding them with \. Once we are done escaping we just insert our new line in place of find $args 2>/dev/null in our new file.

Here is what the completed script will look like.

obsd56# cat /var/ossec/agentless/ssh_dmz_linux
 #!/usr/bin/env expect

 # @(#) $Id: ssh_integrity_check_linux,v 1.11 2009/06/24 17:06:21 dcid Exp $
 # Agentless monitoring
 #
 # Copyright (C) 2009 Trend Micro Inc.
 # All rights reserved.
 # 
 # This program is a free software; you can redistribute it
 # and/or modify it under the terms of the GNU General Public
 # License (version 3) as published by the FSF - Free Software
 # Foundation.


 # Main script.
source "agentless/main.exp"


 # SSHing to the box and passing the directories to check.
if [catch {
    spawn ssh $hostname
} loc_error] {
    send_user "ERROR: Opening connection: $loc_error.\n"
    exit 1;
}


source $sshsrc
source $susrc

set timeout 600
send "echo \"INFO: Starting.\"; for i in `(find / \\( -name \".ssh\" -o -name \"ssh\" -o -name \"sshd\" 
-o -name \"httpd\" -o -name \".htaccess\" -o -name \"pam.d\" \\) -exec find {} \\; && find / -type f 
\\( -perm -4000 -o -perm -2000 \\); ) 2>/dev/null | egrep -v \"known_hosts|moduli|var\\/log|var\\/lock\" | sort -u`;
do tail \$i >/dev/null 2>&1 && md5=`md5sum \$i | cut -d \" \" -f 1` && sha1=`sha1sum \$i | cut -d \" \" 
-f 1` && echo FWD: `stat --printf \"%s:%a:%u:%g\" \$i`:\$md5:\$sha1 \$i; done; exit\r"
send "exit\r"

expect {
    timeout {
        send_user "ERROR: Timeout while running commands on host: $hostname .\n"
        exit 1;
    }
    eof {
        send_user "\nINFO: Finished.\n"
        exit 0;
    }
}

exit 0;

Testing

Before we add this new script to OSSEC configuration we need to test it.

obsd46# (cd /var/ossec && sudo -u ossec ./agentless/ssh_dmz_linux root@172.17.20.20 )

ERROR: ssh_integrity_check <hostname> <arguments>

Due to not making use of the of the $arg variable in the way that ssh_integrity_check_linux wants use too, this caused this the problem above. Solving this problem would require making changes to files that will effect other built in scripts. So a quick solution is to just pass anything as an argument to the script. This will have no effect on our script as we do not make use of the $arg variable.

obsd46# (cd /var/ossec && sudo -u ossec ./agentless/ssh_dmz_linux root@172.17.20.20 NOTUSED)
spawn ssh root@172.17.20.20
Last login: Wed Nov  4 13:46:32 2009 from 172.17.20.131^M
[linux26 ~]#  
INFO: Started.
echo "INFO: Starting."; for i in `(find / \( -name ".ssh" -o -name "ssh" -o -name "sshd" -o -name "httpd" 
-o -name ".htaccess" -o -name "pam.d" \)  -exec find {} \; && find / -type f \( -perm -4000 -o -perm -2000 
\); ) 2>/dev/null | egrep -v "known_hosts|moduli|var\/log|var\/lock"`;do tail $i >/dev/null 2>&1 &&
 md5=`md5s ^Mum $i | cut -d " " -f 1` && sha1=`sha1sum $i | cut -d " " -f 1` && echo FWD: `stat --printf 
"%s:%a:%u:%g" $i`:$md5:$sha1 $i; done; exit
INFO: Starting.
FWD: 14:775:100:101:3bc0a3e92f8170084dd102eda9a474b1:25a1783a3c6bdd9745ec245ec1bfa0414ee05d23 /var/www/html/admin/modules/.htaccessmodules/.htaccess
FWD: 3519:644:0:0:e4ca381035a34b7a852184cc0dd89baa:6e43d0b5a46ed5ba78da5c7e9dcf319b27d769e7 /var/empty/sshd/etc/localtime
FWD: 560:644:0:0:58370830ecfa056421ad21aff9c18905:d115bb5aeefaab97c53fbbd5df84ebcb9170d796 /etc/httpd/conf.d/php.conf
[...................SNIP.............................]
FWD: 392:644:0:0:e92bea7e9d70a9ecdc61edd7c0a2f59a:d77b61dac010c60589b4d8a2039e3b8a5bed18b2 /etc/httpd/conf.d/README
FWD: 70888:4711:0:0:9046bd13339e7ef22266067b633e601a:3fc41029ddb14fe4ed613f479fa9e89c944f04dd /usr/bin/sperl5.8.8
FWD: 315416:6755:0:0:4c63a9709fb7f0f97c30aa29d204859c:c379efa658de72866b8f6de5767906ff78d127b0 /usr/bin/crontab
FWD: 88964:2755:0:99:baf3ebef6377d6ef42858776c33621b0:62394bf57d18c3fd49adeb39a1da61661cabc3c8 /usr/bin/ssh-agent
logout
Connection to 172.17.20.20 closed.

INFO: Finished.

Going live

We have created a new OSSEC agentless script and I am going to enable this script using the ossec-hids-tools that I introduced in my last post about ossec (OSSEC: Agentless to save the day). Also a restart of OSSEC will also be needed for the changes to take effect.

obsd46# ossec-config --section agentless --add --host root@172.17.20.20 --type ssh_dmz_linux 
--state periodic --argv "NOTUSED"
obsd46# /var/ossec/bin/ossec-control restart                                                                                                        (root@jcli-1:/var/ossec)
Killing ossec-monitord .. 
Killing ossec-logcollector .. 
Killing ossec-remoted .. 
Killing ossec-syscheckd .. 
Killing ossec-analysisd .. 
Killing ossec-maild .. 
ossec-execd not running ..
Killing ossec-agentlessd .. 
OSSEC HIDS v2.2 Stopped
Starting OSSEC HIDS v2.2 (by Trend Micro Inc.)...
Started ossec-agentlessd...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010

Lois, Clark Kent may seem like just a mild-mannered reporter, but listen, not only does he know how to treat his editor-in-chief with the proper respect, not only does he have a snappy, punchy prose style, but he is, in my forty years in this business, the fastest typist I’ve ever seen.

Perry White

Michael Starks from Immutable Security published the “Week of OSSEC” all last week (find their links at the end of article), and it was a great setup of posts.

With all the hard work done by Michael in his “Week of OSSEC”, I figured I should follow up with a few posts of my own about this great tool. I am NOT going to do a week of posts, but will try to get as much information out as I can.

OSSEC

OSSEC is a Host Intrusion Detection System (HIDS) in name, but in reality it is far more. It’s able to look for rootkits, monitor logs (LIDS), and even actively respond to defined events. While all these features are great, the unsung hero is agentless monitoring.

Agentless security monitoring is really a great feature that does not get explored often enough, so I am going to show how to get it up and running and then get it monitoring remote hosts.

Installing OSSEC

This is going to be one of the fastest OSSEC install instructions on the internet. For full details the main OSSEC website which covers this topic with more detail. Key things to note here is that I have installed it as a server. I could have installed OSSEC locally and we would have still been able to do whatever was needed.

My install log for OSSEC 2.2 is here.

Enabling agentless

To make use of agentless security monitoring, it first needs to be enabled. Full details also on the OSSEC webpage.

Agentless Requirements

For most of the built-in agentless monitoring scripts, expect is needed to function. In this example on OpenBSD 4.5, adding the expect package is simple with pkg_add.

obsd46# pkg_add http://openbsd.mirror.frontiernet.net/pub/OpenBSD/4.5/packages/i386/expect-5.43.0p0-no_tk.tgz
tcl-8.4.19: complete
expect-5.43.0p0-no_tk: complete
--- tcl-8.4.19 -------------------
You may wish to add /usr/local/lib/tcl8.4/man to /etc/man.conf

Turning on Agentless

Now we need to enable agentless by running the following command:

obsd46# /var/ossec/bin/ossec-control enable agentless

Adding a host.

We need to add a host to agentlessly monitor. If we were to authenticate using a password for host 172.17.20.20 we would use the following:

obsd46# /var/ossec/agentless/register_host.sh add agentless@172.17.20.20

While using a password does work, the preferred method would be to use SSH keys to provide the access level needed. To setup that method of access, you first need to create ssh keys for the user ossec which is the account the agentless scripts runs as.

obsd46# sudo -u ossec ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/var/ossec/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /var/ossec/.ssh/id_rsa.
Your public key has been saved in /var/ossec/.ssh/id_rsa.pub.
The key fingerprint is:
b8:c3:47:9a:33:09:5c:eb:54:a0:82:39:a6:06:63:08 ossec@obsd45.ptnsecurity.com
The key's randomart image is:
+--[ RSA 2048]----+
|E     .          |
|oo   . .         |
|Bo. . . .        |
|=o o . +         |
|..  o + S        |
|.    = *         |
|      @ .        |
|       =         |
|                 |
+-----------------+

Now that the SSH keys are present, we can add the host without a password. The special command line argument used with register_host.sh is NOPASS in all capitals, which will tell OSSEC supplied scripts to make use of SSH keys.

obsd46# /var/ossec/agentless/register_host.sh add root@172.17.20.20 NOPASS

Enabling SSH key on the host to be monitored.

You will now need to securely get the contents of /var/ossec/.ssh/id_rsa.pub to 172.17.20.20.

Using SSH and the password for a single time will make this simple. This will create the /root/.ssh if it is not already created, but might throw an error as it does if the directory is already present. This is not a problem and can be ignored.

obsd46# cat /var/ossec/.ssh/id_rsa.pub | ssh root@172.17.20.20 "( mkdir /root/.ssh/;  cat - >> /root/.ssh/authorized_keys )"
root@172.17.20.20's password:
mkdir: cannot create directory `/root/.ssh/': File exists
obsd46# ssh root@172.17.20.20 "cat  /root/.ssh/authorized_keys "
root@172.17.20.20's password:
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAzyTBo7CqkI0TISR9S+KPS/gYY60nkD7Qe8wTTXrAEFvPNFJ
NJJpVVKsij6zw86lvTZ6hx9ib1M+MXvt+70uF/z1hYwnYrczR2TR03Z5nwOUA9OK61nBWXVwCi9GsQs6Oeo
mY9vkBDoKzB52+TKKSk9ZoC+HYPiT5SaiHZvMOV7kWuwF67lnYwlG5FdkRdOiXp7DcRjje4/Hixg7RLLl7o
dEXpIakzGfalt3yQDmwvSUZhyg3OuoKimTeNiKU/jlHlmEPuDZpiQe6QhFH38EeEIZTdHsYITodl8sY+n9I
eNMalGIHPs+bph+qcK+6cOb1RGaeGqJBFjaqPUyismz0bw== ossec@obsd45.ptnsecurity.com

We can also verify that it worked with the following command.

obsd46# sudo -u ossec ssh root@172.17.20.20
The authenticity of host '172.17.20.20 (172.17.20.20)' can't be established.
RSA key fingerprint is 14:cd:f2:e9:c3:5b:07:28:68:75:a7:b5:88:c2:6b:77.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '172.17.20.20' (RSA) to the list of known hosts.
Last login: Tue Oct  6 12:40:05 2009 from 172.17.20.154
[linux26.ptnsecurity.com ~]# exit

Add the agentless host to ossec.conf

While we have setup and prepared everything to allow agentless security monitoring of 172.17.20.20 we have not told ossec to make use of it. To simplify adding agentless to the config, we are going to make use of the python library and tools I created ossec-hids-tools.

First, let’s check to see what agentless hosts have been configured, and just like a good unix program, it should not output anything if nothing happens.

obsd46# ossec-config --section agentless --show

Next, add our host to the configuration. I am using the OSSEC supplied script ssh_integrity_check_linux. This script will login to the remote host and send back to the OSSEC server via stdout an MD5 and SHA1 hash of every single file inside the paths specified in the arguments. To demonstrate the output from the server, let’s test the script and review said output.

All testing of agentless scripts must be run from the directory /var/ossec/ unless you compiled a different install location.

obsd46# cd /var/ossec
obsd46# sudo -u ossec ./agentless/ssh_integrity_check_linux root@172.17.20.20 /etc
spawn ssh root@172.17.20.20
Last login: Mon Nov  2 17:53:23 2009 from 172.17.20.131
[tss-uvc-01v.ptn.local ~]#
INFO: Started.
t -d " " -f 1` && echo FWD: `stat --printf "%s:%a:%u:%g" $i`:$md5:$sha1 $i; done; exit md5=`md5sum $i | cut -d " " -f 1` && sha1=`sha1sum $i | cu
INFO: Starting.
FWD: 14612:644:0:0:509377d820692110c7a6cc83ef2c2da8:bf610c1fa14d84d8b3b44ec80b81788457f77420 /etc/sound/events/gtk-events-2.soundlist
FWD: 22291:644:0:0:d6139aa9554d4997ea25ec2d56095f51:26b9ae7784943eecaeb2dcd4b2ae3a32371d61c8 /etc/sound/events/gnome-2.soundlist
FWD: 83:644:0:0:9f87609f65b51761657c7d67881ae582:de82c03c535e9deb16aed94153883280891da2d7 /etc/modprobe.d/blacklist-firewire
^C^C#

I only let the script run for a few seconds to see the output, but the key things to notice are the lines beginning with “INFO” or “FWD”.

Anything that starts with “INFO” is logged to the /var/ossec/logs/ossec.log file for debugging and troubleshooting, we will make use of this later on in this blog. The “FWD” tag at the beginning of the line lets the OSSEC server store the HASH information. Where this becomes useful is when a file’s contents change, the HASH will in turn change and OSSEC is able to notify you when this happens.

Now let’s complete adding our host to the OSSEC configuration.

obsd46# ossec-config --section agentless --add --host root@172.17.20.20 --type ssh_integrity_check_linux \
--state periodic --argv "/bin /etc /sbin"

Let’s verify it’s what we expect.

obsd46# ossec-config --section agentless --show

type: ssh_integrity_check_linux
frequency: 3600
host: root@172.17.20.20
state: periodic
arguments: /bin /etc /sbin

Time to restart the deamons for the changes to take effect.

obsd46# /var/ossec/bin/ossec-control stop
Killing ossec-monitord ..
Killing ossec-logcollector ..
ossec-remoted not running ..
Killing ossec-syscheckd ..
Killing ossec-analysisd ..
Killing ossec-maild ..
ossec-execd not running ..
ossec-agentlessd not running ..
OSSEC HIDS v2.2 Stopped
obsd46# /var/ossec/bin/ossec-control start
Starting OSSEC HIDS v2.2 (by Trend Micro Inc.)...
Started ossec-agentlessd...
Started ossec-maild...
Started ossec-execd...
Started ossec-analysisd...
Started ossec-logcollector...
Started ossec-remoted...
Started ossec-syscheckd...
Started ossec-monitord...
Completed.

Testing agentless

Checking the log files, we can see what the agentless security monitor has done so far.

obsd46# grep agentless logs/ossec.log
2009/09/21 14:59:49 ossec-agentlessd: INFO: Started (pid: 15320).
2009/09/21 14:59:51 ossec-agentlessd: INFO: Test passed for 'ssh_integrity_check_linux'.
2009/09/21 15:00:53 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Started.
2009/09/21 15:00:53 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Starting.
2009/09/21 15:01:34 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Finished.

Now we have one last thing to do to see that it’s working as expected, make a change to the file system on 172.17.20.20 that the ossec will notice on the next run. I am going to change the root password for now.

obsd46# ssh -i /var/ossec/.ssh/id_rsa root@172.17.20.20
Last login: Tue Oct  6 14:38:48 2009 from 172.17.20.154
[linux26.ptnsecurity.com ~]# passwd
Changing password for user root.
New UNIX password:
Retype new UNIX password:
passwd: all authentication tokens updated successfully.
[linux26.ptnsecurity.com ~]# exit

Take a look at the logs for ossec-agentlessd to check the host. Again, we see that it completed another scan.

obsd46# grep agentless logs/ossec.log
2009/09/21 15:18:27 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Started.
2009/09/21 15:18:27 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Starting.
2009/09/21 15:18:46 ossec-syscheckd: INFO: Finished creating syscheck database (pre-scan completed).
2009/09/21 15:19:06 ossec-agentlessd: INFO: ssh_integrity_check_linux: root@172.17.20.20: Finished.

Note that we also received the following email notifying that the password has changed, a message that is very useful to report.

OSSEC HIDS Notification.
2009 Sep 21 15:19:00

Received From: (ssh_integrity_check_linux) root@172.17.20.20->syscheck
Rule: 550 fired (level 7) -> "Integrity checksum changed."
Portion of the log(s):

Integrity checksum changed for: '/etc/shadow'
Old md5sum was: '0d92e12c92f3edcf9d8876ea57c5f677'
New md5sum is : '2bd51b61dea17c5682fb2c0cf4f92c63'
Old sha1sum was: '2270c03a920ef8dd50e11cefdef046a8660f7a29'
New sha1sum is : 'd9518ea9022b10d07f81925c6d7f2abb4364b548'

--END OF NOTIFICATION

Week of OSSEC Links:

• Day 1: Detecting World-Writable Files
• Day 2: Detecting New Files
• Day 3: Using Variables
• Day 4: Using Groups
• Day 5: Reusing Rule IDs
• Day 6: Developing a Tuning Strategy
• Day 7: Developing a Workflow

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010

About one month ago, a problem in the Blackberry browser left devices open to attack due to a certificate notification flaw. An advisory from Research in Motion details how a malicious user could spoof a “trusted” website then use a phishing technique to send users to that site using SMS or email.

A malformed SMS message causing a memory corruption error could be used to cause a denial of service or execution of arbitrary code on Apple’s iPhone (CVE-2009-2204). Although not related to Blackberry, I wanted to get the point across that mobile devices are beginning to see their fair share of vulnerabilities which could lead to malicious activity.

Turning our focus back to the Blackberry, a director for Hermis Consulting in Jakarta, Indonesia recently wrote an application for the Blackberry which can turn the handheld into a remote bugging device.
The software is called PhoneSnoop and was written to demonstrate how an “attacker can activate the microphone of a Blackberry handheld and listen to sounds near or around it.” There are currently no stealth or spyware aspects of the software, but it shows how the capabilities of a Blackberry could be used for malicious purposes.

These issues remind me of my previous position, managing a global infrastructure team for a financial company.  Exchange and Blackberry services were under our umbrella of responsibilities.  When I first arrived many years ago, as with most companies that are victims of rapid growth, IT policies were non-existent.  Though unpopular with the users, I had to have a BES policy implemented, and one that took quite a bit of control from the user. From password policies to WiFi disabling, where is your BES policy?

Note: A BES (Blackberry Enterprise Software) is middleware software which connects to your enterprise messaging solution (such as Microsoft Exchange or IBM Lotus Domino) and redirects email and PIM information to and from Blackberry mobile devices.

Note: A BES IT Policy is configured from the BES and are assigned to the Blackberry devices over the air.  Policies can be assigned to users and user groups. The default installation does not enforce policies which should definitely be enabled and are best practices on any platform or device. See the bottom of this post for the KB with instructions on how to create and apply policies.

At the bare minimum, you should have these basic policies set:

• Password Required Rule – True
• User Can Change Time – False
• User Can Disable Password – False
• Password Pattern Checks – Require at least 1 alpha and 1 numeric
• Minimum Password Length – 7 characters
• Maximum Password Age – 30 or 60 days
• Set Password Timeout – 10 minutes
• Set Maximum Password Attempts – 10
• Maximum Password History – 6
• Set Owner Info – Customize
• Set Owner Name – Customize
• Lock Owner Info – Customize
• Remote Wipe Reset to Factory Defaults – True

Control Upgrades:

• Allow Non Enterprise Upgrade – False
• Disallow Device User Requested Upgrade – True

Camera Options:

• Disable Photo Camera – True 
• Disable Video Camera – True

Application Control:

• Disable Application Center – True
• Allow Application Down Services – False
• Disallow Third Party Application Downloads – True

Other Policies I Like:

• Disable USB Mass Storage – True
• Disable Blackberry Messenger – True
• Disable Bluetooth – True
• Allow Application Download Services – False
• Allow Hotspot Browser – False
• Allow IBS Browser – False

Too Much?

Now, these policies are starting to sound too strict at a glance; but, the purpose of the device is for users to have access to their email, contacts and calendars anywhere and to have a mobile phone they can be reached at any time.  Cameras, Hotspots and transferring photos and music using USB mass storage are features that are not necessary. If you have legitimate business needs for these features, than you can enable them for certain user groups using a policy.

The policies mentioned are a very small fraction of what is available. I’d like to hear which policies you find useful in your environment, or which you find to be more harm than good.

For a complete list of policies, please see the Policy Reference Guide.

Howto

Create, Assign, View, and Send IT policies
Doc ID : KB02022
Last Modified : 2007-02-01
Document Type : How To
Environment
This article applies to BlackBerry® Enterprise Server software versions 3.6, 4.0, and 4.1 for Microsoft® Exchange.
Procedure
The BlackBerry Enterprise Server uses an IT policy to control the behavior of the BlackBerry devices assigned to it. IT policies cover a wide range of BlackBerry device functions (for example, passwords, attachment viewing, and available browsers). Administrators can create custom IT policies in addition to the IT policies already present on the BlackBerry Enterprise Server.
Creating IT Policies
To create an IT policy, complete these steps:
BlackBerry Enterprise Server software versions 3.6 and 4.0

1. Depending on your version, open the BlackBerry Enterprise Server Management console or BlackBerry Manager.
2. Right-click the BlackBerry Enterprise Server name, then click IT Policy.
3. Click New, then create a name for the IT policy.
4. Select the check box beside each IT policy rules item you would like to assign. A description of the IT policy will appear.
5. To enable the selected IT policy, in the description window, click TRUE.
6. Click Apply, then click OK.

BlackBerry Enterprise Server software version 4.1

1. In BlackBerry Manager, select Servers, then click the Global tab.
2. From the Tasks menu, click Edit Properties.
3. Select IT Policy, then double-click IT Policies.
4. Click New, then create a name for the IT policy.
5. Select an IT policy group to view the associated IT policy rules.
6. Select the appropriate IT policy rules.
7. Click Apply, then click OK.

Assigning IT Policies
To assign an IT policy to a BlackBerry device user, complete the following steps:
BlackBerry Enterprise Server software versions 3.6 and 4.0

1. Depending on your version, open the BlackBerry Enterprise Server Management console or BlackBerry Manager.
2. Right-click the BlackBerry Enterprise Server name, then click IT Policy.
3. Select an IT policy, then click Edit User List.
4. Click Add Users to This Policy.
5. Select a BlackBerry device user, then click Add.
6. Click Close, then click OK to close the Edit IT Policy Userlist window.
7. Click OK again.

BlackBerry Enterprise Server software version 4.1

1. In BlackBerry Manager, select Servers, then click the Global tab.
2. From the Tasks menu, select Edit Properties.
3. Select IT Policy, then double click IT Policy to User Mapping.
4. Select a BlackBerry device user, then click the button next to the appropriate IT policy.
5. Click OK to close the IT policy to User Mapping window.
6. Click Apply, then click OK.

Viewing IT Policies
To view IT policies on the BlackBerry Enterprise Server, complete these steps:
BlackBerry Enterprise Server software versions 3.6 and 4.0

1. Depending on your version, open the BlackBerry Enterprise Server Management console or BlackBerry Manager
2. Right-click the BlackBerry Enterprise Server name, then click IT Policy.
3. Select an IT policy, then click View to see the BlackBerry device and Desktop Policy Settings that have been applied.
4. Click OK to close the View Policy window.
5. Click OK again.

BlackBerry Enterprise Server software version 4.1

1. In BlackBerry Manager, click Servers, then click the Global tab.
2. From the Tasks menu, select Edit Properties.
3. Select IT Policy, then double-click IT Policies.
4. To view the IT policy rules, click Properties.
5. Click OK.

To view an IT policy on a BlackBerry device, complete these steps:

1. From the Home screen, select Options.
2. Select Security Options > General Settings.
3. The IT policy Name, Last Updated, and Time Stamp fields will be listed.

Note: Depending on the BlackBerry device and BlackBerry Device Software version, the instructions for viewing the IT policy on the BlackBerry device may vary. For example, on the BlackBerry 7100 series, the BlackBerry device user must select Settings or Tools, then select Security.

Sending IT Policies
To send an IT policy to a BlackBerry device user, complete the following steps:
Note: By default, when you assign an IT policy to a BlackBerry device user, the IT policy is automatically sent to the BlackBerry device user.
Note: When a change is made to an existing IT policy, it is automatically resent to all BlackBerry device users assigned to that IT policy.
BlackBerry Enterprise Server software versions 3.6 and 4.0

1. Depending on your version, open the BlackBerry Enterprise Server Management console or BlackBerry Manager
2. Select the BlackBerry Enterprise Server name, then right-click a BlackBerry device user name.
3. Click Properties.
4. On the IT Admin tab, click Resend policy.
5. Click Apply, then click OK.

BlackBerry Enterprise Server software version 4.1

1. In BlackBerry Manager, select the BlackBerry Enterprise Server name.
2. Select a BlackBerry device user, then click the question mark ( ? ) symbol beside IT Admin.
3. From the menu that appears, you can resend the IT policy or assign an IT policy to a BlackBerry device user.
4. Click OK.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010

Little Bit of History

I am going to quickly cover some of the history of the Internet and how it grew borders, but please skip to the highlight of the article if you are familiar with this already: Borderless Networks, What?

ARPANET (‘69-’91)

In the beginning, there was ARPANET which was the pioneer in packet switching networks and gave providers the choice of which method and hardware for communication it would use. However, the base protocol used for devices to communicate in ARPANET was NCP. The NCP protocol could best be described as a network device driver and less as a network transport stack. It did not have any method for end-to-end error handling which was seen as a problem, but nothing was done about this until 1983.

In 1983, TCP/IP replaced NCP as the protocol for transport and ARPANET became a part of what was to become the Internet. TCP/IP was a huge improvement over NCP in that it accounted for problems on the network and allowed the network not to come to a grinding halt when packets were lost. It also achieved the concept of end-to-end connectivity between each host. This meant that as long as two hosts were on the Internet they could reach each other by utilizing standard TCP/IP. This standard framework also lead to the growth of many different applications as there was no longer any need to make changes to the network to add new applications/protocols.

First Borders (‘91-’94)

All the building blocks were in place and what formed was a large group of interconnected networks to share and exchange data. Then the first virus and worm hit in 1983 and 1988 respectively. The morris worm gained a fair amount of media attention and in fact prompted the establishment of CERT. Even in this embryonic stage the vitality of the information being shared caused many researchers to begin placing limitations on the end-to-end connectivity of their hosts. Thus began the ‘Us’ and ‘Them’ status of the Internet.

‘Us’ and ‘Them’ started out simple with a move to keep networks segregated-or put another way, adding a border between the networks. At first, the borders were nothing more than routers that limited the effects from network A from spilling over into network B. They were effective, but in 1991 DEC released the first modern Firewall: SEAL. This marked the first real security border on the Internet, where all packets were inspected and compared to a set of policy rules before being passed on. These first security borders were instrumental in providing the trust and assurance in the network that companies and researchers required, speeding the growth of the Internet. While intrusion was still possible, the bar of entry was raised beyond causal attacks and probes.

Figure 1: Us vs. Them

In 1992, the dominant addressing of hosts was IPv4, where each host is a assigned a 32-bit address. This assignment limited the total number of addressable hosts to 4,294,967,296, but, due to reservations and subnetting, this could never be fully utilized. At this time, it was recognized that IPv4 limitations would be become a problem in the future, beginning the process of creating a new IP protocol with a much higher number of addressable hosts. IPv6 was born in 1994, based on a 128-bit address for each host. This would effectively allow every man, woman, and child on Earth to be assigned an address many times over. As a part of the formation of IPv6, security between networks was also taken into account and IPSec was created as a requirement of the IPv6 protocol.

IPv6’s creation gave the Internet a secure method of communications between networks via IPSEC and nearly unlimited address space, but IPv6 did not get off the ground quickly. This was mostly due to the fact that all devices and operating systems would need to be upgraded to handle the new protocol, and there was little to no pressure from the market to push things forward. IPSec on the other hand did take off, as it quickly became the standard method for interconnecting trusted networks over an untrusted medium (such as the Internet).

At the same time that IPv6 and IPSec were being developed, another group of people began working on an alternate method for dealing with the lack of addressable space in IPv4. Network Address Translation (NAT) was published in RFC1631 in 1994 as a short term solution, while the larger problems were being addressed. NAT became very successful quickly as it allows a very large number of hosts to access the larger Internet while using very few publicly addressable IP addresses. As with most things, NAT came with some trade-offs. One of the big ones was that hosts no longer had complete end-to-end connectivity. Thus, another border on the network was created; in practice firewalls became the dominate NAT devices. Nonetheless, the NAT border would create problems for applications developers for years to come.

Present (‘09)

In 2009, the way Internet runs is really not very different from 1994; IPv6 is just now getting underway, NAT is used everywhere, and IPSEC still secures networks over an untrusted medium. What has changed in a big way is the applications and uses of the Internet. Telephone calls commonly use the Internet for transport, on demand video is a huge source of traffic, social media networks garner huge numbers of users, online shopping is an important revenue stream for companies, and most recently more and more services are being hosted elastically on demand via the Internet.

Borderless Networks. What?

Now let’s get back to Borderless Networks…

Cisco envisions a global network where you can go any place and access any data you could need at anytime. John Chambers detailed the approach on a video at Cisco.com:

Cisco also has a Virtual event on Oct 20th for Borderless Networks, and have been encouraging people to register via twitter and emails for the last two weeks.

I first learned of the Borderless Networks push during the SC World Congress. I was there to get a preview of Borderless Networks as presented by Joel McFarland. The session description sounded interesting and as it was a keynote there was nothing else to pull on my time.

Two co-workers and I attended the session, but being a little late we had to make our way to the very front of the room to find seats. Up front we were able to hear and see everything in great detail, but in hindsight this might have not been the best place for us. There was no way Joel could have missed the looks of skepticism on all three of our faces.

Joel pushed the Cisco idea of Borderless Networks in many different ways, but pointed to the iPhone as the game changer, the beginning of things to come. Then iPhone and salesforce.com became his prime example of how the mobile sales team are almost completely disconnected from the enterprise network. They access leads, manage contacts, input orders, and exchange notes and information all without even logging into the corporate network. At this point, I looked to my co-workers with a questioning expression and whispered the rhetorical question “No corporate login?“.

The example Joel used is common for a sales workforce, and is actively encouraged in many environments, but this was just something that I have always felt was wrong. In many companies, sales leads are valuable information and something that competitors and even other sales people would actively try to gain access to. When all access to this information is controlled by an external party you are no longer able to apply your own controls. In fact, you are beholden to the policies and procedures of the provider. Joel was one step ahead of me on this. He pointed out the problems that were playing through my head and countered that salesforce.com can be made to use a corporation’s internal authentication methods (Active Directory, RSA Token, etc.). As such, your internal policies for access and removal of access are once again in your control. I conceded. Joel is correct that salesforce.com can be brought into line with one’s internal security policy, but he does not address the issue of the remote device-the iPhone itself.

Borderless

Let me come back to the iPhone in a bit, I want to point out another slide that came up during this iPhone praise. In Figure 2 I have created a combined version of the two slides Joel was showing to demonstrate the future of networking (I have recreated them from memory, but its close enough for this post).

Figure 2: Before & After

In Figure 2, we have the before and after sections. According to Joel, currently the before example is a good summary of how most enterprises networks allow access into and between their networks. This Joel and I agree on.

As seen in the before section, you have a defined entry point into the network from outside, where all external resources gain access. This is your border between “us” and “them“. In the examples, both the remote home desktop and iPhone access the network and are allowed across past the border only if proper authentication and authorization have take place. Once completed, the remote device is granted access to the resources that are allowed for it to function as an effective job tool: access to to internet via internal proxy, access of files in the London office, or logging into the salesforce.com website. The key thing is that all access flows through this single point of entry.

By restricting access for remote devices to a single point, we are able to overcome some technical shortcomings and greatly reduce the vectors of attack for the network. NAT is required due to the limited number of publicly addressable addresses. Thus end-to-end connectivity is not an option for the remote devices. The use of IPSec for transport and assigning a RFC1918 address to the remote device end of the IPSec tunnel allows one to overcome the NAT limitations. This gives you remote device end-to-end connectivity within the enterprise network. By using this method the network administrators are able to capture and monitor at a single point all access into and out of the network. NAC, IPS/IDS, and other methods of monitoring are commonly deployed here.

With the after diagram of Figure 2, we see the future as Cisco/Joel see it. This is where all resources are able to access all other resources; also known as complete end-to-end connectivity. Joel did not say how this was to be achieved, but given the network diagram it’s not hard to surmise that Cisco is planning a big push for IPv6. IPv6 will allow for this type of network, and will bring down the NAT boundary. With it the technical limitation of too few addresses for end-to-end connectivity on the Internet is eliminated and things can get a lot more complex as we see in the after section of the diagram.

On the after diagram you see end-to-end connectivity to each resource both inside the network and outside. We have an iPhone going directly to salesforce.com, directly accessing a file in the London office, and able to access all the data that it could ever need. What about limiting access to resources? How do you make sure that a remote home desktop does not start copying all of the data from the London office, NYC office, and salesforce.com to a remote site? What if the desktop is infected with malware? How do you log the activity of the remote device access? All the questions become much harder when you have completed end-to-end connectivity, and historically we have learned it becomes an even larger problem when there are remote devices involved.

All the questions I have asked about the security of the after sections can be answered with products already on the market and in fact are recommended for use in both networks. The problem becomes the scale that is needed to protect and defend a network that has complete end-to-end connectivity. Once again, going back to the after diagram, only taking into account remote device access, the number of policies that needs to be maintained, protected, and monitored goes from 1 to 4. Now a growth of 400% is big, but almost manageable. If you start to think about a small enterprise with 20 offices, 2 datacenters, and 200 remote users, the problem of scale is instantly untenable.

IPv6 will solve a lot of problems for networks as the need for NAT will go away and devices will be able to directly address each other across networks and boundaries, but as with just about everything there are side effects. Keeping control of access into and out your network is the first line of defense and with IPv6 this becomes a policy and enforcement issue even if it is no longer a technical requirement.

The iPhone, Key to the Borderless Network

Joel said he likes his iPhone and from the huge number of videos from Cisco featuring an iPhone it’s safe to assume Cisco does too. During the keynote Joel pointed out the iPhone a few times in a number examples and in general with heavy praise. Joel and I agree the iPhone is an amazing device, an important step forward in mobile computing. After this Joel and I begin to disagree, namely around one key point: “The iPhone is a game changer.” I think that statement needs to add “for the consumer market“.

Figure 3: The iPhone

iPhones are enabling users to use the Internet from almost anyplace; it’s one of the most popular cameras on flickr, has a huge list of applications, and, for some people, a complete replacement for the traditional computer. While its strong points work well in the consumer market, in the enterprise markets it’s a very different beast. In fact the strongest points for the iPhone in the consumer market are security concerns for the enterprise. Application controls are limited, centralized control is even more limited, and encryption of the data residing on the devices is a problem on the most fully featured phone to date.

Devices like the iPhone should be thought of less as a phone and more as a laptop. With that comes all the same protections and controls that we use to mitigate risk on an enterprise laptop. Here is a quick list of what I expect from a laptop and by extension from an iPhone for it to become a viable remote access device in the enterprise environment:

• Virus and Malware software with centralized reporting
• Secure communications for the device; both internal resources and the ability to define policies
• Strong Data Encryption on the device
• Ability to do remote kill of device
• Application installation and run controls
• Web Filter/Proxy controls
• Access controls, password complexity settings and password failure data destruction

Some of the areas listed are available on the iPhone, but none of them are near complete and ready for everyday use in an enterprise. Research In Motion (RIM) dominates the enterprise market for the reasons I have listed here. RIM via the BlackBerry Enterprise Server (BES) gives the enterprise complete control of every device that connects via a centralized management station. BES also does network traffic correctly in that all devices came back to the BES at a single point of entry into the enterprise. This allows an enterprise to place additional control directly attached to the BES and not with multiple devices all over the network. RIM’s BES product represents the minimum level of security that should be expected for remote access of phone like devices. I would go so far as to say it should be the starting standard for how remote access devices should behave.

The iPhone might be the start of things to come, but in no way is it even close to ready for the enterprise market.

Why?

Cisco’s push with Borderless Networks is either something that they haven’t completely vetted from a security perspective or the security strategy isn’t completely explained in the marketing. The huge increase in the number of points needing protection, the corresponding increase in the policy and management, and management data flow and access controls are areas that need addressing. These are problems we still having troubles controlling with our current network deployments. Unless Cisco has a magic bullet coming out of their research and development departments, I don’t see how this move to Borderless Networks is even possible.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action

Functional levels were first introduced when Active Directory made its appearance in Windows 2000 Server. They allowed you to run different versions of domain controllers in your environment, and when all the domain controllers were brought up to a certain version of Windows, you could raise the functional levels to gain the added features of that operating system version. Now that Windows 2008 R2 is released, it is unlikely that you will mass deploy this new operating system to your entire forest or domain. Instead, you’ll deploy a single domain controller and kick the tires, so to speak. The time will eventually come when you’ve upgraded every domain controller to R2, and at that point you can raise the functional level to 2008 R2 to take advantage of the new features.

Functional levels can be raised in domains or, as of Windows 2003 Server, in the forest, providing different features in each. They are differentiated by labeling them Domain Functional Level and Forest Functional Level.

What’s new in 2008 R2

Domain Functional Level

There are two features added when raising the domain functional level to 2008 R2. They are Authentication Mechanism Assurance and Automatic SPN Management.

Authentication mechanism assurance is meant for domains that utilize federation services (ADFS) or certificate-based authentication methods, such as smart card or token-based authentication. This mechanism adds information to the user’s kerberos token on the type of authentication used. This allows administrators to modify group membership based on how the user authenticates. For example, a user can have access to different resources if they log in with a certificate versus when they log in with just their username and password.

Automatic SPN management provides a method for managing service accounts for applications such as Exchange, SQL and IIS. In the past, regular domain accounts were used for these purposes, adding management headaches in terms of password management and service principle names (SPNs). This new feature provides the following benefits:

• A class of domain accounts can be used to manage and maintain services on local computers.
• Passwords for these accounts will be reset automatically.
• Do not have to complete complex SPN management tasks to use managed service accounts.
• Administrative tasks for managed service accounts can be delegated to non-administrators.

Forest Functional Level

There is one new feature in raising the forest functional level to Server 2008 R2, and it is long overdue. It is the Active Directory recycle bin. In the days of old, when an IT administrator or help desk operator accidentally deleted an OU filled with user or computer objects (this has happened more times than you would think), there would be a scramble to perform a restore. The delete replicates to all domain controllers, so an authoritative restore in Active Directory restore mode from a good backup using NTDSutil would be in order. With 2008 R2 forest functional level, a powershell cmd-let will undo this instantly.

Note that this feature is not enabled automatically when raising forest functional level. Additionally, you must run the following command in the Active Directory Module for Powershell.

Enable-ADOptionalFeature –Identity ‘CN=Recycle Bin Feature,CN=Optional Features,CN=Directory
Service,CN=Windows NT,CN=Services,CN=Configuration, DC=mydomain,DC=com’
–Scope ForestOrConfigurationSet –Target ‘mydomain.com’

Functional levels of previous version

The following are the previous functional levels and what features they added, as documented in Technet.

Domain Functional Levels:

Windows 2000 Native:

• Universal groups are enabled for both distribution groups and security groups.
• Group nesting.
• Group conversion is enabled, which makes conversion between security groups and distribution groups possible.
• Security identifier (SID) history.

Windows Server 2003

• The availability of the domain management tool, Netdom.exe, to prepare for domain controller rename.
• Update of the logon time stamp. The lastLogonTimestamp attribute will be updated with the last logon time of the user or computer. This attribute is replicated within the domain.
• The ability to set the userPassword attribute as the effective password on inetOrgPerson and user objects.
• The ability to redirect Users and Computers containers. By default, two well-known containers are provided for housing computer and user/group accounts: namely, cn=Computers, and cn=Users,. This feature makes possible the definition of a new well-known location for these accounts.
• Makes it possible for Authorization Manager to store its authorization policies in Active Directory Domain Services (AD DS).
• Includes constrained delegation so that applications can take advantage of the secure delegation of user credentials by means of the Kerberos authentication protocol. Delegation can be configured to be allowed only to specific destination services.
• Supports selective authentication, through which it is possible to specify the users and groups from a trusted forest who are allowed to authenticate to resource servers in a trusting forest.

Windows Server 2008

• Distributed File System (DFS) Replication support for SYSVOL, which provides more robust and detailed replication of SYSVOL contents.
• Advanced Encryption Services (AES 128 and 256) support for the Kerberos authentication protocol.
• Last Interactive Logon Information, which displays the time of the last successful interactive logon for a user, from what workstation, and the number of failed logon attempts since the last logon.
• Fine-grained password policies (FGPP), which make it possible for password and account lockout policies to be specified for users and global security groups in a domain.

Forest Functional Levels:

Windows 2000:

There were no forest functional levels, just domain.

Windows Server 2003:

• Forest trust.
• Domain rename.
• Linked-value replication (changes in group membership store and replicate values for individual members instead of replicating the entire membership as a single unit). This change results in lower network bandwidth and processor usage during replication and eliminates the possibility of lost updates when different members are added or removed concurrently at different domain controllers.
• The ability to deploy a read-only domain controller (RODC) that runs Windows Server 2008.
• Improved Knowledge Consistency Checker (KCC) algorithms and scalability. The Intersite Topology Generator (ISTG) uses improved algorithms that scale to support forests with a greater number of sites than can be supported at the Windows 2000 forest functional level. The improved ISTG election algorithm is a less intrusive mechanism for choosing the ISTG at the Windows 2000 forest functional level.
• An improved ISTG algorithm (better scaling of the algorithm that the ISTG uses to connect all sites in the forest).
• The ability to create instances of the dynamic auxiliary class called dynamicObject in a domain directory partition.
• The ability to convert an inetOrgPerson object instance into a User object instance, and the reverse.
• The ability to create instances of the new group types, called application basic groups and Lightweight Directory Access Protocol (LDAP) query groups, to support role-based authorization.
• Deactivation and redefinition of attributes and classes in the schema.

Windows Server 2008:

No forest functional level changes occurred from Windows 2003 to Windows 2008.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• Using Group Policy to Disable JavaScript in Adobe PDF Files

This article is not just for the CLI fans like me, who snicker when forced to grab at the mouse for tasks they much prefer taking on in that wonderful black box with the blinking cursor; but for anyone who will deploy a core installation of Windows. This is not an anti-GUI rant, but a look into the CLI, and one that is much needed after Microsoft released Windows 2008 Server Core Edition.

Microsoft started to return CLI tools back to administrators in Windows 2000 when they released netsh.exe. More and more CLI options surfaced with releases of Support Tools, Resource Kits, and the popular PS suite from SysInternals (now Microsoft). The most recent evidence of the resurgence of the CLI is Windows 2008 Server Core Edition. This version is entirely driven with the command line interface.

The following roles are supported in a core installation:

• Active Directory Certificate Services
• Active Directory Domain Services
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services (including File Server Resource Manager)
• Hyper-V
• Print and Document Services
• Web Server (including a subset of ASP.NET)

Why choose core over a standard installation? A core setup will only install the binaries needed by the server roles. Microsoft claims that if Windows 2000 Server had a core edition, it would have had a 60% reduction in patches (40% in Windows 2003). This is a considerable amount of patches for critical servers such as domain controllers.

So let’s get started with some administration tasks in Windows 2008 Server Core Edition: getting things up and running, configuring roles, promoting to a domain controller, and essentially running a version of Microsoft’s OS that does not include explorer.exe. (What? No Desktop?)

The following commands were executed on an installation of Microsoft Windows 2008 Server Core Standard R2. For those who don’t have the time to muck with the CLI, R2 has included a new VBScript (sconfig.vbs) which provides a menu driven server configuration tool to quickly get through these steps. However, I recommend doing it the long way at least once to understand what’s happening in case you run into issues in the future. The install is straightforward, so details not needed. Most important is the option of which version of the OS to install, which I selected Windows 2008 R2 Standard (Server Core Installation). After a dialog to set the administrator password, I’m left with a DOS prompt.

GETTING STARTED

First things first, IP connectivity. I’ll be using 192.168.1.0/24 for the network:

Note: netsh.exe allows you to add all the options/parameters in one line, or you can run netsh.exe and go into each configuration category, (ie. interface), then eventually when deep enough into the options, execute the command, (ie. set). To keep it simple, I’ll write out the commands in single lines, but definitely run netsh.exe with no options and look into the many configuration areas available.

Let’s list available network interfaces to see which one we need to configure:

netsh interface ipv4 show interfaces

Result:

  Idx     Met        MTU           State                Name
  –--  ----------  ----------  ------------  ---------------------------
    3           5        1500  connected     Local Area Connection
    1          50  4294967295  connected     Loopback Pseudo-Interface 1

netsh int ipv4 set address name=3 source=static address=192.168.1.25 mask=255.255.255.0 gateway=192.168.1.1

Note the name=3 parameter; 3 was the IDX number retrieved in the previous step. You will not get a resulting output, but you can double check your settings by running ipconfig /all.

Next step is to add DNS servers for name resolution. If this will be the first Domain Controller in the Forest and will run DNS, you can skip this, otherwise, add your DNS servers now (the example assumes DNS servers 192.168.1.20 and 192.168.1.21):

netsh interface ipv4 add dnsserver name=3 address=192.168.1.20 index=1

add a secondary dns server:

netsh interface ipv4 add dnsserver name=3 address=192.168.1.21 index=2

Note that we used the name=3 parameter again to add these DNS entries to the network interface we are interested in. Once again, you can double check your settings with ipconfig /all.

Now we have connectivity. Let’s rename the computer and join a domain. Windows had assigned a random computer name, you can see what it is by typing hostname. Mine happened to be WIN-EPNB8G5FAUI. Let’s rename this to CORE-DEV:

netdom renamecomputer %COMPUTERNAME% /NewName:CORE:DEV

You will be warned about the potential hazards of renaming the computer, not our concern since this is a brand new installation. Proceed, and you will have the following results:

The computer needs to be restarted in order to complete the operation.

The command completed successfully.

Restart the computer by typing: shutdown /r /t 001

After restarting, log back in, and let’s join a domain. Our test domain is called testdom.local. We will use an account called admin to join the domain:

netdom join CORE-DEV /domain:testdom.local /userd:testdom\admin /passwordd:*

The * for the password option will prompt you for the password. A reboot is again required.

Now you can log in with a domain account by choosing other user, then typing domain\user for the user.

ACTIVATION

Now, let’s activate Windows. In R2, you enter the license key with slmgr.vbs (prior to R2, the installation setup prompted for the license key).

slmgr.vbs –ipk ABCDE-FGHIJ-KLMNO-PQRST-UVWXY

Next, activate:

slmgr.vbs -ato

If successful, you will not receive any messages back.

CONFIGURING AUTOMATIC UPDATES

I recommend controlling the behavior of automatic updates with Group Policy, but if you need to toggle the settings, here are the commands:

To verify the current setting:

cscript scregedit.wsf /AU /v

To enable automatic updates:

cscript scregedit.wsf /AU 4

To disable automatic updates:

cscript scregedit.wsf /AU 1

To check for updates:

wuauclt /detectnow

FIREWALL

Let’s take a look at the firewall now, since we will want to open up some rules to perform remote administrations tasks, such as using Remote Desktop or MMC tools to manage the server.

We can take a look at the firewall profiles by typing:

netsh advfirewall show allprofiles

If you have a domain profile applied via GPO, then those will apply. You can also look at all the rules by typing:

netsh advfirewall firewall show rule name=all

That command will display quite a bit of information. I like to output it to a text file and view it with notepad.

Now, let’s make some changes to allow remote connections to the server. Here, I don’t exactly follow the steps documented in Technet or most web sources since the commands documented will open up the ports and allow any source address. Here, we open Remote Desktop (TCP-3389) only to our subnet.

netsh advfirewall firewall set rule name="Remote Desktop (TCP-In)" new remoteip=192.168.1.0/24

This changes the firewall RDP rule to allow our subnet only. The default rule is Any. Now, let’s go ahead and enable this rule:

netsh advfirewall firewall set rule name="Remote Desktop (TCP-In)" new enable=yes

The firewall is now open for RDP connections from our internal subnet, but we still have to enable Remote Desktop:

cscript %windir%\system32\SCRegEdit.wsf /ar 0

Now you could Remote Desktop to the server. Of course you will only get a command prompt when you do.

Next, we’ll open up some rules to allow remote management using the MMC. This will allow using Computer Management, Shared Folders, Event Viewer, and other important snap-ins to manage your server. The process is the same as it was opening the Remote Desktop rule, but the rule names are different:

netsh advfirewall firewall set rule name="Remote Administration (NP-In)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (NP-In)" new enable=yes
netsh advfirewall firewall set rule name="Remote Administration (RPC)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (RPC)" new enable=yes
netsh advfirewall firewall set rule name="Remote Administration (RPC-EPMAP)" new remoteip=192.168.1.0/24
netsh advfirewall firewall set rule name="Remote Administration (RPC-EPMAP)" new enable=yes

These three rules are in a group called “Remote Administration” and if you are not concerned about modifying the rules so that only the specific subnet is allowed, you can modify enable the group as-is which will allow connections from any IP:

netsh advfirewall firewall set rule group="Remote Administration" new enable=yes

CONFIGURING ROLES

There are two commands to use when dealing with server roles: oclist and ocsetup. Later, we will look at the new dism.exe If you type oclist, you will get a list of all the roles and their optional components. The list is pretty lengthy, so I like to use the find command to narrow my results. For example, if we wanted to add the DHCP server role, I would check for the precise name of the role by typing:

oclist | find /i "dhcp"

Results:

Not Installed: DHCPServerCore

Now I know the role name is specifically DHCPServerCore and that it is in fact not installed. So, we install the role by typing:

ocsetup DHCPServerCore

Note that the above server role IS case sensitive. If I use oclist again to check for DHCP, I now see the following:

oclist | find /i "dhcp"

Results:

Installed: DHCPServerCore

If I wanted to remove the role, I’d use the uninstall switch with ocsetup:

ocsetup DHCPServerCore /uninstall

Pretty straight forward. Now, with R2, there is a new CLI tool called dism.exe. This tool can also configure server roles, but it does much more. For now, we will use it to configure roles like we did with ocsetup/oclist.

To get a list of roles (called features in dism):

dism /online /get-features

Let’s add that DHCPServerCore feature using dism:

dism /online /enable-feature /featurename:DHCPServerCore

And then to remove it:

dism /online /disable-feature /featurename:DHCPServerCore

So, what is the big deal? Same results as ocsetup, but, dism will replace it because it goes further than just toggling features. It will service WIM and VHD image files, allowing add/remove of drivers and features, especially useful if your server has the role of deploying images or runs Hyper-V.

PROMOTING TO A DC

dcpromo is still the way to handle promoting and demoting domain controllers, but in a Server Core installation, there is no GUI wizard that comes along with it. Instead, you use an answer file with the command to instruct how to promote your DC. The syntax to this is:

dcpromo /unattend:c:\temp\answerfile.ini

I like to use ini for my answer file extension, but that’s a personal preference. Here are two examples of answer files to us with dcpromo:

To create the very first DC in a Forest:

[DCInstall]
ReplicaOrNewDomain=Domain
Installdns=Yes
confirmgc=yes
domainlevel=4
domainnetbiosname=TESTDOM
forestlevel=4
newdomain=forest
newdomaindnsname=testdom.local
safemodeadminpassword=password123

To add a replica domain controller in an existing domain:

[DCInstall]
ReplicaOrNewDomain=Replica
ReplicaDomainDNSName=testdom.int
Installdns=Yes
confirmgc=yes
safemodeadminpassword=password123

MORE IN THE CLI

Now you have a fully functioning server, are able to manage it with your MMC, and can connect via Remote Desktop. Although there are hundreds of commands you can use in the CLI, one that can do an enormous amount of tasks is wmic.exe. WMIC is a tool with hundreds of options for WMI. You can do just about anything here. A few examples:

wmic useraccount list
wmic process list
wmic share list

The above examples are all very simple queries for information. You can also use wmic to add and modify (ie. not just list shares, but create or change them). To see a full list of options: wmic /?

POWERSHELL

Powershell is now included with R2 and you can enable it just like any other feature. Powershell provides a shell and scripting language which will open up a world of options for administrating your Windows environment. What gives this shell its power is that it accepts and returns .NET objects. Instead of getting stdout, you can get an object and then perform actions with that object or get its properties. With a couple of lines of script code, you can pull all users from an OU and set their description field, or check when the passwords were last set. That is just one simple example working with objects using the DirectoryServices interface, and there are many others.

CONCLUSION

It is nice to see that the command line has made a return in the Windows world. If you’re unlike me, who typically has five or six command prompts open during a regular day, don’t be intimidated by it. Server Core can be a lean, secure, and well-managed option in your environment. It may take a little time getting used to not reaching for the mouse and clicking on the start button, but at the end of the day you will have that extra bit of satisfaction knowing exactly what occurred without a GUI keeping the details behind the scenes.

References:

• Real Men Don’t Click–The Project: http://isg.ee.ethz.ch/tools/realmen/
• Server Core Installation: http://technet.microsoft.com/en-us/library/cc753802(WS.10).aspx
• Using DISM: http://www.windowsnetworking.com/articles_tutorials/Deploying-Windows-7-Part2.html
• DISM Command Line Options: http://technet.microsoft.com/en-us/library/dd772580(WS.10).aspx
• WMIC: http://technet.microsoft.com/en-us/library/bb742610.aspx
• Powershell: http://www.microsoft.com/windowsserver2003/technologies/management/powershell/default.mspx
• Windows 2008 Command Line List (A-Z): http://technet.microsoft.com/en-us/library/cc772390(WS.10).aspx

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• The “Aurora” IE Exploit Used Against Google in Action

This information can be handy for several reasons:

• An interface running in promiscuous mode may be due to the user running network sniffer such as Wireshark.
• An interface running in promiscuous mode may be due to the user running virtualization software, such as Virtual PC.
• An interface running in promiscuous mode may be due to malicious code.

I definitely want to know if users are running network sniffers, or virtualization software (likely the guests are not licensed or managed causing rogue workstations in the environment). Of course any potential activity that may be caused by malware or malicious code is a concern as well.

You could very easily download promqry and run a for loop against your machines. I wanted to use WMI for this task instead and rather than a text file, use the directoryservices object to query my AD for computers.

I couldn’t find any property in Win32_NetworkAdapterConfiguration to check for this, but I found this post on promqry which tracked down the WMI classes it uses. That led me in the right direction. The other key to this is what MSNdis_CurrentPacketFilter returns. Microsoft documents this here and we are checking if the NDIS_PACKET_TYPE_PROMISCUOUS bit is enabled.

Below is a quick Powershell script which will grab computer objects from AD, then use WMI and the MSNdis_CurrentPacketFilter class to check for promiscuous mode. You can incorporate this WMI query with Win32_NetworkAdapterConfiguration and get a better picture of the interface network settings:

$ErrorActionPreference = "SilentlyContinue"


$PingTest = New-Object System.Net.NetworkInformation.Ping
$Filter = "(&(ObjectCategory=computer))"
$Searcher = New-Object System.DirectoryServices.DirectorySearcher($Filter)
ForEach ($comp in $Searcher.Findall()) {
    $strComputer = $comp.properties.item("Name")
    write-host "Checking: $strComputer"
    if ($PingTest.Send($strComputer).Status -eq "Success") {
        $colComputer = get-wmiObject -class "MSNdis_CurrentPacketFilter" -namespace "root\WMI" -comp $strComputer
        if ($colComputer -eq $null) {
            write-host "Couldn't connect to WMI" }
        else {
            foreach ($comp in $colcomputer) {
                $val = $comp.NdisCurrentPacketFilter
                if ($val -band 0x00000020) {
                    $inst = $comp.InstanceName
                    write-host "Interface: $inst"
                    write-host "The NDIS_PACKET_TYPE_PROMISCUOUS value is set" -foregroundcolor red -backgroundcolor yellow
                }
            }
        }
    }
    else { write-host "Could not ping, machine not queried." }
}

The following screenshot shows the results. I don’t like waiting for RPC to time out when the machine is off or not reachable, so a quick ping check before querying WMI speeds things up. Also, when an interface has the bit set, the output is highlighted with red text and a yellow foreground. You could wrap an email function and schedule this so that you are alerted when it comes up.

You will need proper access to the workstations to query root\WMI so when you run this in a domain, your account should have local administrator privileges to the computers it will query. If it doesn’t, the command will return “Couldn’t connect to WMI”.

Finally, if you haven’t looked at the MSNdis class yet, I suggest taking a look, especially at MSNdis_80211 which will query various wireless information that may be of interest. There isn’t a whole lot of documentation on it, so I’ll work on getting some details together and maybe draft a Powershell script to find wireless adapters and networks they are connected to or available networks close enough to connect to. Until then, enjoy finding those promiscuous mode adapters in your domain.

Related Posts:

• iPhone 4 Ordering and Session Switching
• May’s Patch Tuesday
• March’s Patch Tuesday
• Press F1 for Help, pwned.
• First Patch Tuesday of 2010

Unless you have invested in an enterprise solution for tasks, you are using Windows Task Scheduler and have the tools included with the Windows OS to do the trick. This article is to point out two major snafus you may come across when attempting to manage scheduled tasks across your environment:

1. Using WMI class versus the task scheduler API and what effects it has.

2. New versions in Vista / Windows 7 / Windows 2008 that do not work with XP / 2003.

The first item is more for those who attempt scripting and programming to manage the tasks across machines in the environment. WMI has a class called Win32_Scheduledjob which does quite a bit for managing tasks. However, any tasks created with or modified by the task scheduler API  (such as through the task scheduler GUI or schtasks.exe) will cause the tasks to no longer be managed by WMI. For example, if you create a task using schtasks.exe, this tasks will not be returned in a WMI query; or, if you create a task using WMI, but then modify it with the task scheduler GUI, it will also no longer turn up in WMI. 

So, Win32_Schedulejob is not a great option and we go about our business using the GUI and schdtasks.exe. We move on to our second issue, which is the backwards incompatibility for those using Vista, Windows 7 or Windows 2008. For example, from my Windows 7 workstation, if I use schtasks.exe or the Task Schedule MMC snap-in, I can query, manipulate, create tasks on Vista, Windows 7 or Windows 2008. When I attempt to reach a Windows XP or Windows 2003 machine, I get Access Denied. Running the older XP version of schtasks.exe did not return errors when run against any version OS. This is painful. The solution is to run the management commands from an XP or 2003 machine, or to copy the schtasks.exe and schedsvc.dll files from those version into a directory on your Vista / Win7 machine and run it from there. See this screenshot using both versions of the tool from my  Windows 7 workstation, querying a Windows XP machine. I printed the file version each time to show the newer copy fails with Access is Denied.

  You may very well have proper access, but this Access Denied means you have a newer version of the tool.

This Technet article explains what is new in Task Scheduler 2.0 (Vista and above) compared to 1.0. There are many new features, but I would have liked to have a schtasks.exe and a MMC snap-in that was backwards compatible to manage older versions.

One last note is that .job files from XP/2003 are not compatible with the newer Task Scheduler 2.0 (xml format). I’ve seen that folks used the older schtasks.exe to dump the task information in table format, than use Excel to properly edit it to the valid xml format.

Related Posts:

• March’s Patch Tuesday
• Regular or Decaf? Tool launched to combat COFEE
• Six Bulletins in Last Patch Tuesday of 2009
• OSSEC: Agentless…It’s good, but not good enough
• OSSEC: Agentless scripts