The Importance of Small Files, (Fri, Apr 30th)

Malware Forensics at Large Firms
The malware forensics work-cycle is fairly tight at the day job. It focuses more on answering questions like:



What are we dealing with? (e.g. an adware like Monkif, or an information stealer like Zeus?)

Grab a sample to submit to the AV vendor

Identify network behavior so we can identify infected machines on the wire

How did it get in?



Depending on the workload, resources, etc. we dont always get to answer all of the questions before the demands of keeping the business running or more severe incidents reallocates the response staff.


Smells Like Zeus
Last week, a sharp-eyed user noticed that their on-line bank was asking more questions than they usually do when they log in. During the initial triage I noted that it smelled like Zeus. Once we had got onto the box with EnCase we immediately looked for, and found, c:windowssystem32sdra64.exe on the system. Sure, case-closed. Submit the sample to AV to get them to update their signatures, examine the users proxy logs to identify the phone-home behavior and make signatures from that. There, the organization is protected.


But How Did It Get In?
The final-step in incident handling and the most-often ignored is the root-cause analysis or lessons-learned. With this particular case, I had a timestamp of when sdra64.exe was dropped on the box (if I trusted the MAC times) and could start digging through the web proxy logs for that machine at that time. That sounds like a lot of something-that-isnt-much-fun.



You know what sounds like more fun? Timeline analysis.



(For more on doing your own Timeline Analysis in your environment, I recommend starting here: http://blogs.sans.org/computer-forensics/2010/03/19/digital-forensic-sifting-super-timeline-analysis-and-creation/)



In EnCase its not too hard to organize the view of the file system to track what files were modified or added around the time of sdra64.exe. I was at first interested in the files in the Temporary Internet Folders location of the user, since it will help me narrow down what website was hosted the exploit.


Java Applet Cache Files
In addition to the HTML and image files in the Temporary Internet Folders there were also files created in c:Documents and Settings[victim]Application DataSunJavaDeploymentcache[numbers]



There were files that had hash-like names, some with no extension, some with .idx, some with .hst.



The extentionless file is a zip archive of the .class files or bytecode of the java applets downloaded to the system. The .idx file looks suspiciously like the HTTP session used to pull it down, and .hst was the IP of the source.



Thats pretty handy information to have on hand. But what is the significance of java applet? On a whim, I submitted it to virustotal and it tells me that its an exploit for CVE-2009-3867. Neat, now I know how it got in and where it came in from.


Prefetch Files
With the tight deadlines, and the rushed process of identifying the process generating the bot-net traffic, or what dll is getting injected into iexplore.exe I know that Im missing a lot of the other files that get dropped onto the system. If were lucky enough to get a memory snapshot of the system while its doing its evil I can use something like volatility to tell me what files a process has open. If its after-the-fact, I can glean some of that information from the prefetch files. In our zeus case while jumping into look directly for sdra64.exe I also saw SDRA64.EXE-[hash].pf.



The normal forensic value of prefetch files is it will tell you how many times an executable has been run and the last time that it was executed (I refer you to Harlan Carveys Windows Forensic Analysis DVD Toolkit pp 226 in the first edition, pp296 in 2nd ed) The real purpose of a prefetch file is to improve the efficiency of the OS so it tracks what files are opened by the executable. Using something like BinText you can see the list of files open by the application. This gives me an additional list of files to check against the whitelist for. In this particular example the .pf file also had a bit of HTML in there that looked like an iframe, Im not sure if thats a fluke or not, but it held additional clues about the exploit.

(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Opera 10.53 Released to Address Security Issue, (Fri, Apr 30th)

A reader reports that a new version of the Opera browser has been released today for Mac and Windows. The release notes are available here: http://www.opera.com/docs/changelogs/windows/1053/
The notes are simple, this is a security update to address a security vulnerability detailed here: http://www.opera.com/support/kb/view/953/
This is likely handled as an auto-update in most installations. (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Who needs exploits when you have social engineering?, (Thu, Apr 29th)

For last couple of years we have been all witnessing a huge rise in number of social engineering attacks. Rogue/Fake anti-virus programs (see my old diary at http://isc.sans.org/diary.html?storyid=7144) is just one example of such very successful social engineering attacks.
About a week ago a friend of mine e-mailed me about a very suspicious Fan page in Facebook. Since Facebook is so popular, it is not surprising that the bad guys are crafting new attacks that use or abuse various interfaces on Facebook (while we're on that, Facebook has an excellent security team that does not only quickly deals with new attacks/abuses but also has a nice, informative web page at http://www.facebook.com/security that I encourage everyone to check).
Anyway, this suspicious Fan page promised to reveal The Truth about text messaging, as you can see in the picture below:


So, the user is asked to become a fan. Once that is done a special screen is revealed that contains a bunch of obfuscated JavaScript and the user is asked to copypaste this into his browser's address bar! You can probably guess what the encoded JavaScript does. Below you can see two screenshots (shortened) one with the original, obfuscated JavaScript and one with final, deobfuscated JavaScript:

Deobfuscated JavaScript:







This is what the attackers do:
- first they modify the FB application's HTML (the Truth fan web page that the user adds),

- then they select all contacts (the setTimeout fs[select_all()] call which gets executed after 3 seconds).

- then they invite all user's friends to the group

- finally they display the text in that application
Luckily the final web page, at least when I checked it, didn't contain any malicious code so attacker's goal was probably to create some kind of viral-looking code similar to clickjacking, but in this case they relied on social engineering and users actually copying their code into the browser.
While I was testing this, I noticed that the javascript: command in browser's address bar works only in Mozilla Firefox and Google Chrome (you can easily test this by writing javascript:alert(test-). (it wasn't :)

UPDATE:Thanks to all readers who sent an e-mail and those that posted the comments below - Giorgio was right, Itested it in a blank tab in IE and it works without any problems on a page. Now that Ithink about this attack, it makes it even scarier since the web page had about 100.000+ fans before it got shut down by Facebook!
As this, and many other attacks show, social engineering can go a long way which again reminds us that we must not ignore security awareness.
--

Bojan

INFIGO IS (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Microsoft Security Advisory (983438): Vulnerability in Microsoft SharePoint Could Allow Elevation of Privilege

Revision Note: V1.0 (April 29, 2010): Advisory published.Summary: Microsoft is investigating new public reports of a possible vulnerability in Microsoft Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. The vulnerability could allow an attacker to run arbitrary script that could result in elevation of privilege within the SharePoint site, as opposed to elevation of privilege within the workstation or server environment.

Opera 10.52 is released, most updates are for stability ==> http://www.opera.com/docs/changelogs/, (Wed, Apr 28th)

=============== Rob VandenBrink Metafore (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Layer 2 Security - L2TPv3 for Disaster Recovery Sites, (Tue, Apr 27th)

It's been a while since we talked about Layer 2 Security, I thought that today we might talk about how this applies to Disaster Recovery Sites and processes.



A common requirement for today's Datacenters is a DR (Disaster Recovery) site - a secure, remote location that has a full copy of the critical servers in the primary Datacenter. The DR site is generally kept to some level of currency, usually the IT group tries to keep the DR servers either within 15, 30 or 60 minutes of the primary servers, or replication happens in the evening when WAN traffic is light, and the DR Servers are at last night's timeframe. Replication can use things like replication tools for virtual or physical hosts, stretch clusters or SAN mirroring.



Replication aside, a common problem with DR sites is that you can't have a discontiguous subnet in a routed network. What is meant by that is - if your datacenter is 192.168.10.0/24, you can't have your DR site use that same subnet if you have a routed network between the two sites. So in a routed network the DRsite and the Primary Datacenter need to use different subnet addresses. There are three main implications for DR that this drives out:

a/ if you declare a disaster, you need to take the primary datacenter offline, and give the DR site that subnet address

b/ this means that there's a significant manual effort to re-address and re-route all the affected subnets

c/ this also means that it's next to impossible to declare a disaster that only affects one or a few servers.


So, is there a way around this, besides buying a new network that will allow you to bridge rather than route between the two subnets? As you've guessed from the title of this article, yes, you can use L2TPv3 (Layer Two Tunnelling Protocol, Version 3) to do exactly this. On a routed network, L2TPv3 will build a virtual bridge between the two sites.
Let's run through an example configuration, then discuss how it's built - - first, the network diagram:



You can see that the primary and DRDatacenters have the same ip subnet (10.17.10.0/24), but are separated by some arbitrary WANnetwork
The config snips that build the tunnel that bridges the two datacenters are:




Router R1:





pseudowire-class DRPATH
Define the pseudo wire that will link the two sites and carry the bridged traffic


encapsulation l2tpv3
Encapsulate it using l2tpv3


ip local interface Loopback0
Which interface is this tied to? Loopbacks are normally used, in this

example we could have used F0/1 as well.






interface FastEthernet0/0
This is the insideinterface, facing the primary datacenter vlan


no ip address
Remove the ip address (remember that this is a bridged solution)


xconnect 10.17.101.13 101 pw-class DRPATH
Cross connect the pseudo-wire to the ip address at the far end






interface loopback0
Define and address the loopback used to tie the PW to


ip address 10.17.101.9 255.255.255.252







iInterface FastEthernet0/1
This is the outside interface, facing the WAN


ip address 10.17.101.1 255.255.255.252
The outside interface needs a routable ip






ip route 10.17.101.4 255.255.255.252 10.17.101.2
Define the routes to the far end (the DR site). On most networks you would

do this with a routing protocol such as OSPF or BGP


ip route 10.17.101.12 255.255.255.252 10.17.101.2











Router R3:






pseudowire-class DRPATH

encapsulation l2tpv3

ip local interface loopback0








interface FastEthernet0/0

no ip address

xconnect 10.17.101.9 101 pw-class DRPATH







interface FastEthernet-/1

ip address 10.17.101.5 255.255.255.252







int Loopback0

ip address 10.17.101.13 255.255.255.252







ip route 10.17.101.0 255.255.255.252 10.17.101.6

ip route 10.17.101.8 255.255.255.252 10.17.101.6





As you'll see, the L2Tpv3 tunnel is usually tied to a loopback address. Because loopbacks are logical interfaces, they are not subject to media failures, they remain up no matter what (unless you shut them down manually)This allows you a simple way of handling backup and load balanced paths - as long as the respective loopback ip's are routed through both a primary and backup path, the config is tremendously simplified.



Almost every networking vendor supports L2TPv3 - it's standards based, described in RFC3931, and is pretty easy on the router/switch CPU. L2TPv3 is also encryptable - so if the goal is to communicate to the DR site over a public network (like the public internet for instance), the data in transit can be encrypted using standard VPN algorithms (we hope that you're using at least AES256). L2TPv3 can also be prioritized - so, using time based access lists (TBACL), you can for instance run replication at a lower priority during the day, giving priority to VOIP and business apps, then crank the priority up in the evening to catch up on replication of larger servers - just be sure that your time services are solid before you take this route ! Authentication and a truckload of other features are also supported - none of these are covered in this article, what we're describing here is a very basic configuration only.



Things to watch out for - as in any protocol, compromises are made as the protocol is designed, and you'll want to be aware of some of these when you implement. L2TPv3 has some overhead (it varies, depending on how you implement it). Also, L2TPv3 is perfectly happy to carry spanning tree BPDU's (Bridge Protocol Datagram Units) - so if you have a potential loop built with a fiber primary and L2TPv3 backup for instance, be sure to factor that into your layer two design.



Other protocols that could be used to deliver similar functions are Ethernet over MPLS and 802.1QinQ tunnelling (commonly called QinQ). The downside of these is that they both require support from the service provider. This means that they'll typically cost money, and generally can't be deployed over public internet. They're also tough to troubleshoot if you provider makes a config change that breaks things on you a few months after it's running (guaranteed at least a few hours of finger pointing before you start fixing anything!).



L2TPv3 allows you to dramatically simplify the networking requirements for DR. With the prevalence of Virtual Datacenters now, it's very common to see a rack of servers running VMs as a primary datacenter, and a smaller rack of servers running the DR site. Given the replication tools, and now simplified networking, the technical delivery of a DR site can easily be a short 1-2 week project.



Just be sure that you don't treat DR as a purely technical IT project. Be sure to involve other groups in the business, have them dictate the SLA's for server currency, what services are critical, when to declare emergencies and the rest. Also be sure not to go overboard on using old gear at the DR site. Remember, everything data-wise that is at the primary site is also at the DR site - you need the same security controls, change control and the rest at the DR site as you have at the primary, or you've just spent a large effort building a nice backdoor for whoever wants to use it !



=============== Rob VandenBrink, Metafore ================ (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

MS10-025 - Critical: Vulnerability in Microsoft Windows Media Services Could Allow Remote Code Execution (980858) - Version:3.0

Severity Rating: Critical - Revision Note: V3.0 (April 27, 2010): Revised bulletin to offer the rereleased security update for Windows Media Services running on Microsoft Windows 2000 Server Service Pack 4. Microsoft recommends that customers running the affected software apply the rereleased security update immediately.Summary: This security update resolves a privately reported vulnerability in Windows Media Services running on Microsoft Windows 2000 Server. The vulnerability could allow remote code execution if an attacker sent a specially crafted transport information packet to a Microsoft Windows 2000 Server system running Windows Media Services. Firewall best practices and standard default firewall configurations can help protect networks from attacks that originate from outside the enterprise perimeter. Best practices recommend that systems that are connected to the Internet have a minimal number of ports exposed. On Microsoft Windows 2000 Server, Windows Media Services is an optional component and is not installed by default.

Microsoft Security Bulletin Summary for April 2010

Revision Note: V3.0 (April 27, 2010): Revised to offer the rereleased security update for MS10-025.Summary: This bulletin summary lists security bulletins released for April 2010.

Snort 2.8.6 is released!, (Mon, Apr 26th)



Snort 2.8.6 is finally out. It's been in beta and RC for awhile now, but here it is! Sourcefire (the company I work for), the makers of Snort have been working on several of the features you see below for awhile, and we have plenty more in store. So go update now!
[*] New Additions

* HTTP Inspect now splits requests into 5 components -

Method, URI, Header (non-cookie), Cookies, Body.

Content and PCRE rule options can now search one or more of these buffers.
HTTP server-specific configurations to normalize the HTTP header and/orcookies have been added.
Support gzip decompression across multiple packets.
* Added a Sensitive Data preprocessor, which performs detection ofPersonally Identifiable Information (PII). A new rule option is availableto define new PII. See README.sensitive_data and the Snort Manualfor configuration details.
* Added a new pattern matcher and related configurations. The new patternmatcher is optimized to use less memory and perform at AC speed.
[*] Improvements

* Addressed problem to resolve output obfuscation affecting packetswhen Snort is inline.
* Preprocessors with memcap settings can now be configured in a disabledstate. This allows you to configure that memcap globally, but only enablethe preprocessor in targeted configurations.
Go tohttp://www.snort.orgto download the latest release! I have two more posts that will be coming out later today with further updates, so make sure you read those as well. One of the posts, about rule updates, is huge and will affect everyone who uses Snort, so make sure you stay tuned! Also, make sure you read the VRT blog for further information:http://vrt-sourcefire.blogspot.com

-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

PulledPork v0.4.1 is released!, (Mon, Apr 26th)




PulledPork is the 'newest' Snort rule updater. Written by JJ Cummings, a Sourcefire guy like myself, and maintainer of https://www.openpacket.org, is a great way to keep your Snort rules up to date. In addition to all the wonderful things that PulledPork does already (namely, it updates and auto-maintains Snort's SO rules!), the new version has these features:
New Features/changes:
- Flowbit tracking! - This means that all flowbits are not enabled whena specific base ruleset is specified (security etc...) but rather allflowbits are now tracked, allowing for only those that are requiredto be enabled.
- Adjusted pulledpork.conf to account for new snort rules tarball namingand packing scheme, post Snort 2.8.6 release.
- Added option to specify all rule modification files in the masterpulledpork.conf file - feature request 19.
- Added capability to specify base ruleset (see README.RULESETS) in masterpulledpork.conf file.
- Handle preprocessor and sensitive-information rulesets
Bug Fixes:
- 18 - non-rule lines containing the string sid:xxxx were being populatedinto the rule data structure, added an extra check to ensure that thisdoes not occur
- Cleaned up href pointers, syntatical purposes only...
- Modified master config to allow for better readability on smaller consolebased systems
- Error output was not always returning full error
Be sure and go here to download the newest update!
http://code.google.com/p/pulledpork/
Be sure and read myothertwoposts in order to make sure you are fully up to date with everything going on.


-- Joel Esler | http://blog.joelesler.net | http://twitter.com/joelesler (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Honey, my laptop is acting funny again, (Sun, Apr 25th)

It's a phrase that causes dread in the hearts and minds of many a security professional, including myself.
The firewall is on and tightly configured, AV is is installed .. all the usual precautions are in place but inevitably, somehow, every few months, the system becomes infected.
With three family laptops in the house ... well I think you see where this is going.
My wife and kids have been resistant to move to linux systems so I've been considering running a linux hosts with Windows VMs that I just revert to snapshot as needed.
I know I'm not the only one who is in this situation so if you have a better solution, send it in and I'll add it to the diary.
If you're in the same boat that I am, check back as someone may have a solution for you.
Oh, and, uh .. in addition to fixing the laptop, I have a honey-do list so I may take a bit to get back to you, but I will.
Anyone know how to install a built in dishwasher?)
Christopher Carboni - Handler On Duty (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Manual Verification of SSL/TLS Certificate Trust Chains using Openssl, (Sun, Apr 25th)

/*This is a blog cross-post from a two-part article published on Taddong's Security Blog */
This week, during my Internet Storm Center (ISC) shift, Firefox 3.6.3 (the latest available version) displayed a digital certificate error when accessing the ISC login page through SSL/TLS: https://isc.sans.org/myisc.html. I confirmed this on a couple of Firefox instances running on Mac OS X and Windows XP.


We also got a few reports from ISC readers on the same issue, although other people running the same browser version, and even language (EN), on the same OS platforms, didn't get any error message. Finally, the reason was a new ISC digital certificate had been recently installed, and the required intermediate certificate was missing in some web browsers. As a result, the browser couldn't validate the full digital certificate chain to ensure you were really connecting to the website you intended to connect to.
This is a common scenario on security incidents, where Man-in-the-Middle (MitM) attacks or direct web server breaches modify the SSL/TLS certificate offered to the victim, and when accidentally accepted, the attacker can intercept and modify the secure HTTPS channel. As you may find yourself dealing with a similar situation in the future... how can you (as I did) check what is the real reason behind the SSL/TLS certificate validation error? By manually verifying the SSL/TLS certificate trust chain, or certificate hierarchy, through openssl.
The goal is to manually follow all the validation steps that are commonly performed it an automatic way by the web browser.
Step 1: Check the certificate validation error and download the controversial digital certificate.



$ openssl s_client -connect isc.sans.org:443

depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

verify error:num=27:certificate not trusted

verify return:1

depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

verify error:num=21:unable to verify the first certificate

verify return:1

CONNECTED(00000003)

---

Certificate chain

0 s:/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIGATCCBOmgAwIBAgIQOxCOI6FirgnSgN/fCRi57jANBgkqhkiG9w0BAQUFADB/

MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBD

aXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxKjAoBgNVBAMTIVVT

RVJUcnVzdCBMZWdhY3kgU2VjdXJlIFNlcnZlciBDQTAeFw0xMDAzMzEwMDAwMDBa

Fw0xMTAzMzEyMzU5NTlaMIH5MQswCQYDVQQGEwJVUzEOMAwGA1UEERMFMjA4MTQx

ETAPBgNVBAgTCE1hcnlsYW5kMREwDwYDVQQHEwhCZXRoZXNkYTESMBAGA1UECRMJ

U3VpdGUgMjA1MRowGAYDVQQJExE4MTIwIFdvb2Rtb250IEF2ZTEbMBkGA1UEChMS

VGhlIFNBTlMgSW5zdGl0dXRlMSgwJgYDVQQLEx9OZXR3b3JrIE9wZXJhdGlvbnMg

Q2VudGVyIChOT0MpMSYwJAYDVQQLEx1Db21vZG8gVW5pZmllZCBDb21tdW5pY2F0

aW9uczEVMBMGA1UEAxMMaXNjLnNhbnMub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOC

AQ8AMIIBCgKCAQEAvYLqphsusuyiVDookRrfsZDx0T1SOf1EQmzUFSK0qVTv+RKM

VanUSwsbWuMYrS6W7bGld2/qCGuk2rxMjwtiNE1x2rtaXUkngoKfnQKH+zGErbmc

Ead2IjY5OANT6xnxfJS8a29XTqRrKJW8c/PR9NYCGUmq1X+0EnB4+wPZbDsebZ3h

2wISxDaEJlOYbc3MzNyKwbTkwsyn1uwqZS0DQyKqVGL4hZeVmy5OwW9b8/RLYOov

NYxTH0bHlbiaOuwakm4cx/ZJMELSBhbgwjt2sLkD8CShdES6fHPPAeMLW//ir3em

RMXABEnF1wE5CmvMDe9e6b/joHurw34BISM8twIDAQABo4IB/DCCAfgwHwYDVR0j

BBgwFoAUr6RAr58W/qsx/fvVl4v1kaMkhhYwHQYDVR0OBBYEFN6hBRDWEgv4hVZI

hR1/CjtAx8k2MA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQW

MBQGCCsGAQUFBwMBBggrBgEFBQcDAjBCBgNVHSAEOzA5MDcGDCsGAQQBsjEBAgED

BDAnMCUGCCsGAQUFBwIBFhlodHRwczovL2Nwcy51c2VydHJ1c3QuY29tMEsGA1Ud

HwREMEIwQKA+oDyGOmh0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RM

ZWdhY3lTZWN1cmVTZXJ2ZXJDQS5jcmwwfQYIKwYBBQUHAQEEcTBvMEYGCCsGAQUF

BzAChjpodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVNFUlRydXN0TGVnYWN5U2Vj

dXJlU2VydmVyQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1

c3QuY29tMGkGA1UdEQRiMGCCDGlzYy5zYW5zLm9yZ4IRaXNjLmluY2lkZW50cy5v

cmeCDGlzYy5zYW5zLmVkdYINaXNjMS5zYW5zLm9yZ4INaXNjMi5zYW5zLm9yZ4IR

d3d3LmluY2lkZW50cy5vcmcwDQYJKoZIhvcNAQEFBQADggEBAGBhcG/MGgAsiwsB

AAg4ZYndAEukeYXpIbXzU5T9ZqkqHPWiUearWDzBgWKJcpgF+v9ZCqCrKuYbXXnv

zqZi+BPKX3BSMxHlDUZ0C6tU/G6+FqcV4j19S+xPjAVvk28yqaZc9BNpLnCogAc/

F3gHL7SwCDFowP+RaqUlbUr1UtQgKDILWSOM4ukoVMbCt5nNmyXu0eDFb9tlWkJK

KdPYzuKCYfWS7/9bQ868fML3m1xCZqG7L0t/XAFSZYN3ytqtbRTyOjcjdEwSxwA5

O3gV+dW6qM7/AmGZu+0/Grw3WMwiXzO8tRAHYliNz9PDqnK2k5NE0VbKKhndsoRc

oAA+AfY=

-----END CERTIFICATE-----

subject=/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA

---

No client certificate CA names sent

---

SSL handshake has read 2233 bytes and written 325 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 2048 bit

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA

Session-ID: 08BED94D2BBA7E525FB37BFE20DCD155CE62C93871B41ABBDF810D663FFC4A61

Session-ID-ctx:

Master-Key: 620F10AF948333D43BCC2656E4493563C4A827A8BFAD46AF0815CF3643C602C0E1EBA3CD5DBFE0C4BA65F2DBD9762DF2

Key-Arg : None

Start Time: 1271777232

Timeout : 300 (sec)

Verify return code: 21 (unable to verify the first certificate)

---

closed



From the output, ans specifically the verify return code at the end, you can see that the server certificate cannot be verified.
First of all, create a certs directory to put all the required files in. Copy and paste to a file (ISC.pem) the digital certificate, that is, the text between -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- (including both lines).

Step 2: Identify the issuer and get its certificate.
Open the ISC.pem certificate file (by double-clicking on it on most operating systems) and inspect the following fields:

The certificate thumbprint or fingerprint that identifies the server certificate: bd:95:df:ac...46:aa (SHA1).
Issuer (under the Certificate section): Who did generate and issue the server certificate? USERTrust Legacy Secure Server CA from The USERTRUST Network.
The Certificate Authority Key Identifier or fingerprint (under Certificate - Extensions): af:a4:40:af...86:16.
The Authority Information Access (under the same section): It contains a pointer to the digital certificate of the issuer certification authority (CA): URI: http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt.

Obtain a copy of the issuer certificate. The most secure option would be to get its certificate through HTTPS and not HTTP, but this only depends on how the CA decided to make it available. Double check with the CA website that the URL and the fingerprint are valid. In this case, USERTrust was acquired by Comodo, and the issuer certificate is available here (https link) and referenced in its list of certificates. This certificate belongs to the USERTrust intermediate CA and was the one not available in Firefox 3.6.3 by default, hence, the root cause of the initial SSL/TLS error on the ISC website.
Although you might be tempted to perform the manual verification all from the command line, it is not the most secure option, as you could be forced to use http vs. https when using wget or curl. Depending on the version and platform of these tools, they may be distributed without a default list of trusted root certificates or do not use the list available on the system. Therefore, ** this is NOT the way to get the intermediate certificate **, use a web browser instead:



$ wget http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt

--2010-04-20 17:32:44-- http://crt.usertrust.com/USERTrustLegacySecureServerCA.crt

...

2010-04-20 17:32:45 (32.0 MB/s) - `USERTrustLegacySecureServerCA.crt' saved [1073/1073]

$




Step 3: Try to verify the digital certificate again, but this time make use of the previously downloaded certificate (USERTrustLegacySecureServerCA.crt exemplified later), and build the certificates directory required by the openssl -CApath option. The Unix c_rehash script helps to create the appropriate directory structure and certificate hash symbolic links. Be sure to rename all the certificates in PEM format to .pem, such as USERTrustLegacySecureServerCA.crt:



$ c_rehash ./certs

Doing ./certs

ISC.pem = fc1aa8ab.0

USERTrustLegacySecureServerCA.pem = cf831791.0

$



If we try to validate the certificate again, and if we already have the certificates for all the intermediate and root CA's identified in the trust certificate chain stored on the certs directory, we will get a positive response: Verify return code: 0 (ok).



$ openssl s_client -CApath ./certs -connect isc.sans.org:443

CONNECTED(00000003)

depth=2 /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority

verify return:1

depth=1 /C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA

verify return:1

depth=0 /C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

verify return:1

---

Certificate chain

0 s:/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

i:/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA

---

Server certificate

-----BEGIN CERTIFICATE-----

MIIGATCCBOmgAwIBAgIQOxCOI6FirgnSgN/fCRi57jANBgkqhkiG9w0BAQUFADB/

...

oAA+AfY=

-----END CERTIFICATE-----

subject=/C=US/postalCode=20814/ST=Maryland/L=Bethesda/streetAddress=Suite 205/streetAddress=8120 Woodmont Ave/O=The SANS Institute/OU=Network Operations Center (NOC)/OU=Comodo Unified Communications/CN=isc.sans.org

issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST Network/CN=USERTrust Legacy Secure Server CA

---

No client certificate CA names sent

---

SSL handshake has read 2233 bytes and written 325 bytes

---

New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 2048 bit

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1

Cipher : DHE-RSA-AES256-SHA

Session-ID: C898C8DB5CD9CDFEE404451BA3E19A440951A1960DAC1BA62FD35F23D9772B30

Session-ID-ctx:

Master-Key: EC4D939A112112AAAB01DFF5FA0A5F6C26C568C8DEBBDF3A61515E8CD83F257DAB5894BC450A97A7EE5ABAB0B1893795

Key-Arg : None

Start Time: 1271778616

Timeout : 300 (sec)

Verify return code: 0 (ok)

---

closed



If the certificate chain or hierarchy contains additional certificates, that is, there are multiple intermediate CA's involved, you may need to repeat the same process and download the certificates for all the other intermediate CA's and the root CA (omitted for brevity). For example, the intermediate USERTrust certificate was issued by Entrust.net Secure Server Certification Authority. This root CA certificate can be manually obtained in DER format from Entrust website, with a fingerprint of f0:17:62:13...d0:1a.
Once again, this DER file must be converted to PEM format using openssl:



$ openssl x509 -in entrust_ssl_ca.der -inform DER -outform PEM -out entrust_ssl_ca.pem



Finally, you will need to rebuild the certificates directory again, using c_rehash, once it contains all the intermediate and root CA certificate files that belong to the certificate chain being tested, and try to verify the certificate again.

We used the Internet Storm Center certificate as an example, whose chain has three elements: the ISC (isc.sans.org) certificate, an intermediate USERTrust CA, and the Entrust root CA.


A quick look in the Firefox Preferences (Mac OS X) or Options (Windows and Linux), and specifically on the Advanced - Encryption - View Certificates - Authorities section, confirms the intermediate CA certificate from USERTrust was the one missing on Firefox 3.6.3 and, therefore, the one invalidating the certificate trust chain. None of the available USERTrust certificates has the right fingerprint, af:a4:40:af...86:16.


The client browser does not have the intermediate certificate to be able to verify the full certificate trust chain, and generates the error.
The most common method to avoid this type of certificate validation errors at the web server level, thus for all the web server clients, is by delivering the missing intermediate certificate from the web server itself to the client at connection time.
In the Apache web server world, you simply need to get a copy of the intermediate certificate, in this case USERTrustLegacySecureServerCA.crt (see Part 1), and enter a reference to it through the SSLCertificateChainFile directive in the Apache configuration file, httpd.conf, and specifically, in the section associated to the virtual host. Example for the ISC web server (not the real config file):



virtualhost 10.10.10.10:443

DocumentRoot /var/www/html

ServerName isc.sans.org

SSLEngine on

SSLCertificateFile /path/to/isc.sans.org.crt

SSLCertificateKeyFile /path/to/isc.sans.org.key

SSLCertificateChainFile /path/to/USERTrustLegacySecureServerCA.crt

/virtualhost



These three mod_ssl directives point to the server certificate, the server private key, and the intermediate CA certificate, respectively.
End-user awareness regarding the acceptance of invalid digital certificates is a must!
----

Raul Siles

Founder and Senior Security Analyst with Taddong

www.taddong.com (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Shadowserver botnet rules , (Fri, Apr 23rd)

Earlier today the shadowserver.org botnet rules were not included in the emergingthreats.org rule set. If you notice that they are missing download the rulset again.
Cheers,

Adrien de Beaupr adriendb // atsymbol // whitehats.ca

EWA-Canada.com
(c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

More Articles...

Page 4 of 26

4

Security News

Feed Source

Information mostly from: http://isc.sans.org

User Login



Login using Facebook Login Using Facebook