Tech Swamp – Ramblings about Information Security, DNS and IT in general

January 5, 2012

Say buh bye to SSL/TLS certs with internal server names

Have you read the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates, v.1.0” document adopted in November 0f 2011 and published in December of 2011?

It’s actually a very good read, short, simple and not overly technical for the sake of being overly technical (assuming that you’re familiar with the content before hand). It’s also overdue and might take a few critical steps towards restoring some faith in the broken CA system we have today (mostly due to shoddy security and operations with certain CAs).

But, truth be told, what really got attention was this little nugget buried in Section 9.2.1, on Page 9, quoted here in its entirety:

As of the Effective Date of these Requirements, prior to the issuance of a Certificate with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name, the CA SHALL notify the Applicant that the use of such Certificates has been deprecated by the CA / Browser Forum and that the practice will be eliminated by October 2016. Also as of the Effective Date, the CA SHALL NOT issue a certificate with an Expiry Date later than 1 November 2015 with a subjectAlternativeName extension or Subject commonName field containing a Reserved IP Address or Internal Server Name. Effective 1 October 2016, CAs SHALL revoke all unexpired Certificates whose subjectAlternativeName extension or Subject commonName field contains a Reserved IP Address or Internal Server Name.

The effective date of the requirement is July 1, 2012. So, in other words, starting July 1, 2012 you can expect be notified by your chosen CA if you try to purchase a certificate for an internal (not resolvable using publicly available DNS records) host. Interesting. When you do purchase your certificate on or after July 1, 2012, it will be limited in its lifetime to an expiry date of no later than November 1, 2015. That makes sense. The last sentence is the kicker though: if, for some reason, you should actually still have an active certificate with an internal name (or IP address), then it will be automatically revoked on October 1, 2016.

Just for reference, the internal name spaces (as defined by RFC 2606) include the following:

.test
.example
.invalid
.localhost

And, of course, everyone knows their RFC 1918 private IP ranges:

10.0.0.0 – 10.255.255.255
172.16.0.0 – 172.31.255.255
192.168.0.0 – 192.168.255.255

However, I found this additional listing of internal name spaces in Comodo KB article 1295:

.local
.lan
.priv
.localdomain

So, this is where things start to get really interesting. What percentage, world wide, of networks based on Microsoft Active Directory do you think are NOT using .local as their name space root? I’d venture it’s less than 10%. Of course, that’s also ironic now given the fact that Apple has completely gone off the reservation and makes using Mac’s in a .local name space all but impossible (but I digress, that’s an entirely separate issue all together).

So, if you like to purchase and use commercial CA certificates inside your network for some reason, say perhaps for LDAPS support on your Domain Controllers…well, you’re about out of luck unless you have or can stand up an internal (ADCS perhaps) PKI infrastructure.

August 10, 2011

Export a CSV file of active certificates from your ADCS PKI

A few weeks ago I was asked to create a process to export a listing of the active certificates that had been issued to users from our ADCS Subordinate Issuing CA. I saw, as explained on the powershell.no blog, that could use the certutil.exe command included in Windows Server 2008 R2 to get a CSV export of certificates. From there, some PowerShell and you’re in business.

The CA I was working with was not yet Server 2008 R2, still being just Server 2008, so a copy of the certutil.exe file was needed. You can get it from any Server 2008 R2 installation, but for it to work right your CA will need to be the 64-bit version of Server 2008 if you’re going that route. I renamed the R2 version R2certutil.exe and dropped in the same location directory on the CA as the PowerShell script would run from. The script shown here is a cleaned up and simplified version of what the final product ended up being. You can certainly configure more items to be excluded from the list of what is written the final file, etc. As well, this was a quick and dirty script so it could use some proper cleaning up using Switch with cases instead of the If / ElseIf / Else statements.

A few notes:

Only requires PowerShell 1.0 installed
Lines 5 & 6 have paths that need to be changed to fit your environment.
Line 5 is an intermediary output file from certuil.exe.
Line 6 is the final output file that is selectively rewritten based on your match criteria.
Line 12 is the path to the certutil.exe file.
Line 35 contains the NETBIOS domain name of your domain, which is used to remove the MYDOMAIN\ portion of any usernames that are exported in that format.
Line 43 & 53 start loops to remove the mydomain.local (or whatever your AD FQDN is) from the usernames that are exported. Be sure to change both places and also count how long the FQDN is for lines 49 & 58.
The length of your AD domain FQDN so it can be trimmed.
You can put extra cases in the loop starting at line 77 depending on what other certificates you don’t want to appear in the final export. My goal was to get only certificates issued to users, not computers.
Line 103 contains the path to copy the final file to, in the case of if you wanted to use it for another process (such as some Identity Management solution).

Use at your own risk and test!

Download here: Export-ActiveCertificates


#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#+++++ HEADER SECTION +++++

# Define the input and output files to work with
$CertFile = "c:\scripts\certs.csv"
$OutFile = "c:\scripts\certificates_active.csv"

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
#+++++ WORK AND OUTPUT SECTIONS +++++

### Use the Server 2008 R2 certutil.exe utility to export the certificates in CSV format
./certutilR2.exe -view -out "RequestID,RequesterName,NotBefore,NotAfter,CommonName,DispositionMessage,RevokedWhen,CertificateTemplate" csv > $CertFile

### Prepare the cleaned list for output
Write-Output "Certificate ID,Requester Name,Certificate Effective Date,Certificate Expiration Date,Issued To" | Out-File -filePath $OutFile

### Import the CSV and create the cleaned file
$CertList = Import-Csv $CertFile

### For each line in the CSV file, perform the following actions
foreach ($Cert in $CertList)
{

# Assign the values from the line just read in to variable for scripting
$Field_IsusedRequestID = $Cert."Issued Request ID"
$Field_RequesterName = $Cert."Requester Name"
$Field_CertificateEffectiveDate = $Cert."Certificate Effective Date"
$Field_CertificateExpirationDate = $Cert."Certificate Expiration Date"
$Field_IssuedCommonName = $Cert."Issued Common Name"
$Field_DispositionMessage = $Cert."Request Disposition Message"
$Field_RevocationDate = $Cert."Revocation Date"
$Field_CertificateTemplate = $Cert."Certificate Template"

# Manipulate the Requestor Name, remove "MYDOMAIN\"
If ( $Field_RequesterName -match "MYDOMAIN" )
{
# Just list the sAMAccountName
$Field_RequesterName  = $Field_RequesterName.split('\')[1]
}
Else {}

# Manipulate the Common Name, remove "mydomain.local"
If ( $Field_IssuedCommonName -match "@mydomain.local" )
{
# Get length of the string value
$Field_IssuedCommonNameLength = $Field_IssuedCommonName.Length
# Count how many characters you want to trim, say 19 for example...
# Trim the last 15 characters "@mydomain.local"
$Field_IssuedCommonNameLength = $Field_IssuedCommonNameLength - 15
$Field_IssuedCommonName = [string]$Field_IssuedCommonName.substring(0,$Field_IssuedCommonNameLength)
}
ElseIf ( $Field_IssuedCommonName -match ".mydomain.local" )
{
# Get length of the string value
$Field_IssuedCommonNameLength = $Field_IssuedCommonName.Length
# Count how many characters you want to trim, say 19 for example...
# Trim the last 15 characters "@mydomain.local"
$Field_IssuedCommonNameLength = $Field_IssuedCommonNameLength - 15
$Field_IssuedCommonName = [string]$Field_IssuedCommonName.substring(0,$Field_IssuedCommonNameLength)
}
Else {}

# Manipulate the Common Name, convert DisplayName into sAMAccountName
If ( $Field_IssuedCommonName -match ", " )
{
$Search = New-Object DirectoryServices.DirectorySearcher([ADSI]"")
$Search.filter = "(&(objectClass=user)(DisplayName=$Field_IssuedCommonName))"
$SearchResults = $Search.Findall()
Foreach($result in $SearchResults)
{
$User = $Result.GetDirectoryEntry()
$Field_IssuedCommonName = $User.sAMAccountName
}
}
Else {}

# Write line out to new file if it is for an active cert, otherwise do not write it out
# Match and eliminate CA exchange certificates
If ( $Field_IssuedCommonName -match "-Xchg" ) {}
# Match and eliminate Web Server certificates
ElseIf ( $Field_CertificateTemplate -match "Web Server" ) {}
# Match and eliminate Web Server certificates
ElseIf ( $Field_CertificateTemplate -match "WebServer" ) {}
# Match and eliminate OCSP responder certificates
ElseIf ( $Field_CertificateTemplate -match "OCSP Response Signing" ) {}
# Match and eliminate SCEP proxy certificates
ElseIf ( $Field_CertificateTemplate -match "EnrollmentAgentOffline" ) {}
# Match and eliminate SCEP proxy certificates
ElseIf ( $Field_CertificateTemplate -match "CEPEncryption" ) {}
# Match and eliminate denied certificates
ElseIf ( $Field_DispositionMessage -match "Denied" ) {}
# Match and eliminate revoked certificates
ElseIf ( $Field_RevocationDate -ne "(null)" ) {}
# Write what's left
Else
{
Write-Output "$Field_IsusedRequestID,$Field_RequesterName,$Field_CertificateEffectiveDate,$Field_CertificateExpirationDate,`"$Field_IssuedCommonName`"" | Out-File -filePath $OutFile -append
}
}

### Copy the file to some location.

Copy-Item -Path $OutFile -Destination "\\MyServer\MyLocation\certificates_active.csv" -force:$true

#++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

July 24, 2011

Issue a digital certificate and get the private & public keys in PEM Files

I recently had an occasion to create a Subordinate CA (SubCA) certificate within my Public Key Infrastructure for a Secure Web Gateway. The SWG needed the SubCA certificate to be able to perform SSL/TLS decryption of all Web traffic passing through it. This is a fairly common practice now. This article details the steps you can follow to manually issue a SubCA certificate for a non-Windows SubCA instance and get the both the private and public keys for the SubCA certificate into .pem files, which are fairly standard in many security appliances and other non-Windows implementations of SSL/TLS.

NOTE: This procedure requires the installation of the OpenSSL toolkit on your local PC. For Windows users, I’d recommend getting the Win32 Open SSL binary (pre-compiled) from Shining Light Productions.

NOTE: This same procedure can be followed (more or less) to get any other type of certificate from a .PFX into two .PEM files. Say for example that you need to import your own internally issued Web server certificate into an appliance running some flavor of UNIX…follow the same basic steps except you’d not be issuing a SubCA certificate.

Here is how you do it:

Install the Win32 OpenSSL toolkit on your PC. Note that you must first install the Visual C++ 2008 32-bit redistributable package. You can get that from the same location as the Win32 OpenSSL toolkit.

Ensure that you install all of the files into the OpenSSL directory when asked.

Modify the local user PATH environmental variable as follows:

Open the System Properties applet.
Select the Advanced tab.
Click the Environment Variables button.
In the “User variable for…” section, add the full path listed here to the end of the PATH variable, use a semi-colon before the entry if there are currently values in the PATH variable. C:\OpenSSL-Win32\bin
Log out of your PC and log back in again.

If you do not already have one, create a new MMC console that has the Certificates snap-in added for the Local Computer.
Prepare a request.inf file. See MSKB 321051 for a sample .inf file you can (and should) use.

You will need to change the “Subject“, which is the FQDN of the server.
You will need to change the “KeyLength“, which is the key strength. Choose 2048 if possible.

On your local PC, open an administrative command prompt.
Issue the following command (you do not have to be in any specific directory to issue this command, but for simplicity, it is best to do so from the location where your request.inf file is located):

certreq -new [request template, such as request.inf] [request out file, such as serverA_request.req]
You should place the .req file in the same location as the .inf file was located.
The “serverA_request.req” that is created can be opened in Notepad for viewing.

Expand the “Certificate Enrollment Requests” node of the Certificates (Local Computer) snap-in and locate the request that corresponds to the one created in step 6.
Export the request to a .pfx file as follows:

Right-click on the request and select All Tasks > Export.
Click Next to dismiss the opening page of the Certificate Export Wizard.
Select the “Yes” option to export the private key. Click Next to continue.
Under the PKCS #12 options, check the “Export all extended properties” option. Click Next to continue.
Provide a simple password. This password is only used for this file and will be removed in step 10.
Navigate to the same location where you saved the .inf and .req files earlier.
Give the exported certificate a meaningful name, such as “serverA_privateKeys_password”.
The “_privateKeys_password” label indicates that the private keys are included and the file is still password protected. This will be changed in step 10.
Click Next to continue and then click Finish to complete the Certificate Export Wizard.
Click OK when notified that the export completed successfully.

Save (if not already done) and close your custom MMC console.
Extract the private keys from the exported .pfx file created in step 8 as follows:

Open a command prompt and change locations to where you exported the .pfx file.
Enter the following command:
openssl pkcs12 -in [.pfx file name, such as serverA_privateKeys_password.pfx] -out [.pem file name, such as serverA_privateKeys_password.pem]
Enter the import password when prompted. This is the password you created previously in step 8.
Enter the PEM export password when prompted. Again, this should be a simple password as it will be removed shortly.
Confirm the PEM export password.
The command completes with no further prompting if you entered all passwords correctly.
Now you have a .pem file that is password protected. Enter the following command to extract that into a new .pem file that is not password protected:
openssl rsa -in [.pem file name from step 10.b.i, such as serverA_privateKeys_password.pem] -out [.pem file name, such as serverA_privateKeys_NOpassword.pem]
Enter the PEM password when prompted.
You will get the output of “writing RSA key” and nothing else if you entered the correct password.
The file you just created, such as serverA_privateKeys_NOpassword.pem is the .pem file that contains the private keys for your requested certificate.

Next you will need to obtain the public keys for the certificate.

For the SubCA certificate, you will need to take the .req file created in step 6 and place that on the RootCA, such as in C:\temp\Manual_Issue_SubCA (or wherever you want).
To issue the request against the SubCA certificate template, open a command prompt on the RootCA and enter the following command:
certreq -submit -attrib “CertificateTemplate:SubCA” [.req file name, such as serverA_request.req]
When prompted which CA to use, select your RootCA (it will most likely be the only one in the list).
You will get feedback similar to the following:

RequestId: 12
Certificate request is pending: Taken Under Submission (0)

Open the Certificate Authority console on the RootCA and navigate to the Pending Requests node.
Locate the submitted certificate request. Right-click on it and select All Tasks > Issue.
Go to the Issues Certificates node.
Select the newly issued SubCA certificate. Right-click on it and select All Tasks > Export Binary Data.
Select Export Binary Certificate from the drop-down list.
Select the Save binary date to file option. Click OK to continue.
Save the file in the same location as the request file was placed (i.e. C:\temp\Manual_Issue_SubCA) as a .cer file, such as serverA_certificate.cer.
Copy the newly saved .cer file back to your local PC into the same location as you worked from previously in steps 6, 8 and 10.
You can extract the .cer file into a .pem file for the public keys using the following command:
openssl x509 -in [mycert.cer] -inform der -out [mycert.pem] -outform pem

Now import the public key .pem file and the private key .pem file (without the password protection) into your appliance or application and you’re in business.

You’re all done!!

July 15, 2011

Quick and easy: Configure EAP-TLS Wi-Fi on OS X

If you’ve got an EAP-TLS secured Wi-Fi network, and have Mac computers you want to get on that network, here’s some quick and easy steps to get them configured. This should work for 10.5 and above…but your mileage may vary!

Ensure the root and intermediate certificates have been imported into the keychain. Use the procedure here.
Import the user certificate into the Mac, double click it and input the password when asked, add to the “login” keychain.
Open the network utility, select the AirPort item, click the Advanced button.
Click the + button at the bottom left, and add a new User Profile, name it something intuitive.
Enter the information like seen in the following fields:

User Name: the part of your user name before the SPN, for example joe@mycorp.local is entered as jdoe.
Check prompt for password.
Select TLS, ensure all other authentication methods are deselected.
Enter the network name in the Wireless Network space.
Select WPA2 Enterprise as the Security Type.

Click the Configure button under the Authentication section.
Validate the certificate is correct (i.e. it belongs to you, double check the name entered matches the Common Name, minus the SPN portion).
Click Continue.
Click Apply. If you don’t automatically start connecting to the network click Connect.
When prompted to allow the eapolclint to sign using your key, click Always Allow.
You should now be connected to the EAP-TLS Wi-Fi network.

This page on the Apple site was the source for this, and has some other information as well: http://support.apple.com/kb/ht3326

July 5, 2011

Import internal PKI certificates into Mac keychain

I’m pretty sure this is probably published somewhere else, including likely being on the Apple KB somewhere…but since we just went through the work of figuring this all our lately I thought I’d share.

If you have an internal PKI and you have Macs in your network than you have the (not) enjoyable task of getting the certificate chain onto those Macs so that they will trust your PKI issued certificates. You can use the steps and the script below to get your internal root CA certificate (and however many levels of intermediate and issuing CAs you have as well) imported into the keychain. This has the nifty effect of causing the Safari and Chrome browsers to immediately trust those CAs and thus all certificates that are otherwise valid that are issued by those CAs. FireFox, being FireFox, is the difficult one so you’ll have to import the CA certificates into its cert store some other method. On Windows, we have a batch file that uses the Mozilla certutil command (not to be confused with the command of the same name that is part of Windows)…haven’t gotten that method translated yet to Mac.

Anyhow…here is a sample script you can save as something like import_certs_mac.sh:

ftp ftp://certimport:certimport@10.1.1.1/root_CA_cert_der.cer
ftp ftp://certimport:certimport@10.1.1.1/intermediate_CA_cert_der.cer
security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "root_CA_cert_der.cer"
security add-trusted-cert -d -r trustRoot -k "/Library/Keychains/System.keychain" "intermediate_CA_cert_der.cer"
rm root_CA_cer_der.cer
rm intermediate_CA_cert_der.cer

What this script does is use some limited permission account (certimport with a simple password of certimport, for example) and connects to some internal FTP server you have (10.1.1.1, for example) and downloads the appropriate DER binary encoded certificates (.cer extension) for your PKI CA chain from that location. It then uses the security add-trusted-cert command to import the certificates into the Mac systems keychain as trusted roots. Lastly, it deletes the certificates from disk in an effort to cleanup a bit.

You can use a set of steps like the following to run and clean up after this script:

Log into the Mac as root (or open a shell as root)
FTP the import_certs_mac.sh script
ftp ftp://certimport:certimport@10.1.1.1/import_certs_mac.sh
Make the script executable
chmod +x import_certs_mac.sh
Run the script
./import_certs_mac.sh
Delete the script
rm import_certs_mac.sh

That’s about it. Too bad you can’t have the script delete itself as well.

Now your Macs will trust certificates issued by your internal PKI when using Safari or Chrome. This will work with all current (10.5 and 10.6) versions, and maybe 10.4 and older.

June 20, 2011

Working around BIND’s DDNS limits for multi-homed hosts

If your organization is like most today, then you have a good number of laptop computers in use that have both wired and wireless interface configured, enabled and connected all of the time. Unfortunately for those users and the BIND admins that support them (but fortunately from a security perspective), BIND’s implementation of DDNS (dynamic DNS) is pretty much cut straight from RFC 4701. The problem at hand is that the host A record can only belong to one interface in a machine–DDNS was never designed to be utilized on a host with multiple interfaces. Note that the corresponding PTR records for both IP addresses will be created assuming the correct reverse lookup zones exist and are properly configured.

Section 3.6.3 of RFC 4701 explains in technical details how the issue comes to be:

A DHCP server allocating the IPv4 address 192.0.2.3 to a client with
 the Ethernet MAC address 01:02:03:04:05:06 using domain name
 "client.example.com" uses the client's link-layer address to identify
 the client.  The DHCID RDATA is composed by setting the two type
 octets to zero, the 1-octet digest type to 1 for SHA-256, and
 performing an SHA-256 hash computation across a buffer containing the
 1-octet 'htype' value for Ethernet, 0x01, followed by the six octets
 of the Ethernet MAC address, and the domain name (represented as
 specified in Section 3.5).

client.example.com.   A       192.0.2.3
client.example.com.   DHCID  
     ( AAABxLmlskllE0MVjd57zHcWmEH3pCQ6VytcKD//7es/deY= )

What you’ll see in the syslog is something like this:

ns42:/var/log# zgrep "no DHCID" /var/log/syslog*
/var/log/syslog.#.gz:May 25 07:11:19 ns42 dhcpd: Forward map
    from host.mycorp.local to 10.1.8.164 FAILED: Has an A record but no
         DHCID, not mine.

That example above was found using zgrep on the tarballed older syslog files, but you can also use grep for the current file or tail -f /var/log/syslog | grep “no DHCID” to watch the syslog in real time. The key text you are looking for to indicate that you are in this situation is the “Has an A record but no DHCID, not mine.”

Here’s a description of the scenario and the problem that results for some users and admins that I wrote up when explaining the problem and its solution to less BIND savvy people:

Both interfaces have DHCP and had valid IP addresses, but the host A record is only available for one interface—whichever interface comes online first. As the computer roams between VLANs, the interfaces would get new DHCP leases as appropriate, but again depending on which interface registered the host A record first, DNS might or might not be current.

This behavior is by design and is a security feature of BIND DNS. BIND creates a hashed tracking record when a dynamic DNS event occurs for a client. Pieces of data that are used to calculate this hash value include the MAC address and parts of the host name of the client. As such, should the wired interface happen to create the host A record first, the wireless interface would not be able to update it to add an additional IP since the MAC address would be different. Or, if the wireless interface was up first, the same issue would occur for the wired interface.

Initially, it seems like the solution to this problem is to allow clients to perform their own dynamic updates using the allow client-updates option (BAD IDEA!). This does have the intended effect of allowing the DDNS registration of multiple IP addresses with the single host A record, but it really creates a security nightmare where any client can update any host record by simple virtue of having the same client name. That’s certainly not what you want to have happening.

The better way to go about this is to use a custom option in dhcpd.conf file: ddns-hostname = concat(option host-name ,”-wifi”); for those network segments (VLANs, subnets, etc.) that contain Wi-Fi only connections. This only works if you have a dedicated IP space for your wireless clients. For example, you might use the 10.1.0.0/20 network for your wired clients and the 10.100.0.0/20 network for wireless clients.

An example entry for the 10.100.0.0/20 network in the dhcpd.conf file might look like this (your mileage will vary!):

subnet 10.100.0.0 netmask 255.255.240.0
{
 option subnet-mask 255.255.240.0;
 option broadcast-address 10.120.15.255;
 default-lease-time 691200;
 ping-check true;
 ddns-updates true;
 ddns-rev-domainname "in-addr.arpa";
 ddns-domainname "mycorp.local";
 max-lease-time 691200;
 min-lease-time 345600;
 client-updates false;
 option time-servers 10.1.1.1, 10.1.1.2, 10.1.1.3;
 option domain-name-servers 10.1.1.101, 10.1.6.102, 10.1.1.103;
 option routers 10.100.0.1;
 ddns-hostname = concat(option host-name ,"-wifi");
 pool
 {
 range 10.120.8.1 10.120.15.254;
 }

The net result is that the laptop, with both of its adapters enabled and connected, would still get two DHCP leases but it would also now get two host A records. The records would be like host.mycorp.local and host-wifi.mycorp.local, or whatever you picked for your concatenated value, etc.

As a disclaimer: none of this will help you if the host in question has multiple interfaces in the same VLAN or subnet (i.e. a multi-homed server for example). In that case, you’re best off configuring the host’s various interfaces with static IP addresses and the corresponding A/PTR records.

Thanks to Scott O and Scott L for their help in working this one out!

April 28, 2011

New malware downloader

We’re working on several systems currently that have a new malware variant, almost certainly a root kit, that we’ve yet to identity. All we’ve been able to identify as of yet is what the malware is doing: downloading massive amounts of Web page content under the context of the Network Service (running under svchost.exe), most likely for click fraud.

Given the massive amount of svchost.exe malware being discussed right now, it’s likely that this is one of them…but which one remains to be seen. Finding the offending file changes on the system would help…we have what we believe is the original infecting file, still on disk, on one of the systems. Perhaps its time to get a VM fired up and sacrifice it to see what changes when that file is run…

April 28, 2011

New (and exciting!) versions of old malware

About a month ago (I’m behind on posting!) we ran into some new variants of the Bloodhound and Silly.FDC malware. Specially, SEP11 reported them as Bloodhound.Exploit and W32.SillyFDC.BDP. Unfortunately, it seems that SEP11 seemed to not be able to catch and prevent infection from this malware in about 50% of the cases…perhaps due to slow systems with insufficient resources, etc.

The malware appears to have been injected via a malicious phishing email (is there any other kind of phishing email) purporting to be a tracking notification from UPS. This in itself has been a somewhat popular injection method over the past few months. The user in question of course followed the link and downloaded the executable since she was actually expecting a UPS delivery that very day (not a big stretch of the imagination). At this point, it’s worth noting that a current generation security web gateway product (such as the Finjan product from M86) would have probably stopped this malware then and there, but that was not in place (yet) so the malware entered and started to spread rapidly by enumerating and crawling the network looking for open Windows shares.

The malware was actually accurately described (except for a few points I will point out in a bit) by Microsoft as Win32/Rorpian.gen!A and the files listed are pretty much going to be in line with that article. Cleanup is pretty simple, just find and delete the offending files and registry settings and use the sc command to delete the associated service.

Files that are expected to be seen (the number value can and will change) with this variant:

pornmovs.lnk
setup50039.lnk
setup50045.lnk
setup50039.fon
setup50045.fon
myporno.avi.lnk
autorun.ini

The .lnk files try to invoke the exploit via the MS10-046 vulnerability, which can invoke the malware simply by viewing a listing of the files…no clicking of the file is required (though that method of invocation certainly works!). The autorun.inf file will of course get the infection invoked easily for mapped drives and USB drives.

What the article missed completely (and continues to do so even though it’s been revised since we had this outbreak) are the following bits that we determined:

The malware is memory resident, so even if you clean it up by removing the indicated files in the article, you still need a reboot right away to put a complete stop to the incident. Note that this malware is cleanable (at least this variant) by deleting all of the associated files, registry keys and the service.
The malware appears to be causing buffer overflows in the explorer.exe process and the print spooler process. If the malware is not intentionally doing it, then DEP is itself crashing the processes as a result of the malware being memory. We only saw this on Server 2003 systems that had been infected and were attempting to spread the malware to other systems. We did not ever see a DEP error in the infected Windows XP hosts.

Based on our observations, there are two methods by which the malware spreads within a network:

The first method is via an open share where an “infector” workstation (one that is actively infected and spreading the malware to other workstations) “drops” the malware into the open share in an uncompressed form. That uncompressed form is actually multiple files, including the .lnk files, .fon files and typically an autorun.inf file. When someone accesses this share after the drop has occurred, their workstation will then become infected.
The second method is by accessing a share that has already had the files dropped in it previously. The malware has two invocation methods, the autorun.inf file (which can be prevented from functioning by a Group Policy setting in Active Directory or via a recent hotfix) and the .lnk link files which on an unpatched workstation (MS10-046) can be invoked simply by the act of viewing them, no clicking required. Should someone actually click on the link, however, even on a patched workstation, the malware will then attempt to execute itself and install itself on the local workstation. Attempting to make that workstation an infector and also phoning home to 82.192.88.10. SEP has been observed to catch the malware when it has been intentionally invoked (via clicking the link) in some tests, but the speed at which this detection and quarantining occurs may vary depending on the speed and capabilities of the workstation.

Once a machine has become infected, several additional file system, registry and service changes are made. The malware copies itself to the %TEMP% directory, which is unique to the account logged in as two files, srv###.tmp and srv###.ini. There are multiple registry changes made to cause a newly created service named srv### to run, likely maintaining the worm on the workstation after reboots.

April 7, 2011

April is a big month for Microsoft security bulletins

Looks like there will be 17 updates issued next Tuesday by Microsoft, with 9 rated as critical and the remaining 8 rated as important. The products being updated include:

Windows Server 2003 SP2 (32-bit, 64-bit and Itanium)
Windows Server 2008 RTM & SP2 (32-bit, 64-bit and Itanium)
Windows Server 2008 R2 RTM & SP1 (64-bit and Itanium)
Windows XP (32-bit SP3 and 64-bit SP2)
Windows Vista SP1 & SP2 (32-bit and 64-bit)
Windows 7 RTM & SP1 (32-bit and 64-bit)
Office XP SP3
Office 2003 SP3
Office 2007 SP2
Office 2010 (32-bit and 64-bit)
Office 2004 for Mac
Office 2008 for Mac
Office for Mac 2011
Open XML File Format Converter for Mac
Excel Viewer SP2
PowerPoint Viewer 2007 SP2
PowerPoint Viewer
Office Compatibility Pack for Word, Excel, and PowerPoint 2007 File Formats SP2
Office Web Apps
Visual Studio .NET 2003 SP1
Visual Studio 2005 SP1
Visual Studio 2008 SP1
Visual Studio 2010
Visual C++ 2005 SP1
Visual C++ 2008 SP1
Visual C++ 2010

Full details here.

If you want to read the full email bulletin, you can view if after the jump.

Continue reading →

April 6, 2011

.com TLD now supports DNSSEC

Last Thursday (3/31/11), the .com TLD (Top-level Domain) has finally joined the ranks of some 50 other TLD’s in participating in DNSSEC. Way to go Verisign!

DNSSEC was (finally) jump started as direct result of Dan Kaminsky’s 2008 cache poisoning attack discovery.

Read more about cache poisoning on Dan’s blog and at Wikipedia.

If you operate DNS servers that are Internet exposed, it’s past time now to start putting together your DNSSEC plan. Doubly so if your company is involved in any way, shape form with online monetary transactions (financial institutions, e-commerce, etc.)

← Older posts