Cupfighter.net

The Key to My Mind (11/12) a CC image from Tony the Misfit's Flickr stream

The private key is supposed to be private. It is what proves that the services and the certificate belong to each other. As an attacker you want to obtain this key in order to spoof the identity of the service.

When you import a certificate with private key or generate a private key via the Microsoft Crypto API (CAPI) you can mark it as non-exportable. But are these keys really non-exportable or is this just a GUI option to give administrators a false sense of security?

In order to find out how an attacker can export a non-exportable key RSA key, we need to dive into the CAPI calls.

Disassembling the CAPI functions shows that there are flags in memory that specify that the key is not exportable. It appears that these flags are stored on the same memory location and user the same function. And you can actually temper with this information and set these flags back to being exportable.

The situation is a bit different in the CAPI: Next generation (CNG). Again a disassembly of these functions shows that the CliCryptExportKey() via the c_SrvRpcCryptExportKey function get the private key from the KeyISO or KeyIsolation RPC service that is meant to isolate the RSA keys from the client memory.

Read more…

ESXi over NFS works just great!

But what if you have an issue with NFS and you need a network dump? 

In ESXi tipically you don’t have a local datastore where you can write files from the network dump and your datastore over NFS is not availabe!

Before running into the Data Centre and stick a USB disk or even better a SCSI disk you might want to try this.

One trick I used that worked out pretty well for me, with a little help of my a linux machine, is to send the tcpdump output to a FIFO and from a remote host (might be a VM in a different ESXi host) over SSH cat the FIFO to a local file.

How To:
On the ESXi host logon via SSH as root and create a named pipe:

root@yourESXihost# mkfifo /tmp/pipe.dmp

and from a remote linux machine launch the following:

you@yourlinuxhost > ssh root@youresxihost "cat /tmp/pipe.dmp" > capture-for-wireshark.cap

Now from a new ssh session to ESXi as root lauch

root@yourESXihost# tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp

OR even better from the remote machine:

you@yourlinuxhost > ssh root@youresxihost "tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp"
(replace the # with the proper vmk port number)

Reproduce your issue and when you finished just hit  “Cotrol+C” to stop the network dump and the cat.
Now you can open your file directly in wireshark (that’s what I use at least!)

This little trick of course can be used to troubleshoot network problems in a VM as well, dumping the traffic from a VMK# nic for the entire dvPortGroup. You just need to make sure that the the VM’s vNIC and the vmk# nic are connected to the same dvPortGroup and you must remember to allow promiscuous mode (not allowed by default)

Good Luck!

Please note: your network can be very chatty so the file can grow very fast and/or your ESXi host might not like the tcpdump so use it at your own risk and only if you really know what you are doing!

The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template. Read more…

Last night I attended the Microsoft Security Response Team webcast regarding the Out Of Band patch for the ASP.net padding Oracle vulnerability discovered by Juliana Rizzo and Thai Duong 11 days before.

My main objective in watching the webcast (which is not my usual habit) was to find out if systems that have the described workaround applied still need to apply the patch. The webcast did not give a definitive answer but this YouTube video and the Netifera website and the twitter accounts Thai Duong provide the answer: Yes you should apply the patch a.s.a.p!

However the Q&A section of the talk did give me, as a security operations guy, quite some food for thought. I made some notes in my own Twitter feed, which I have summarized here.

Q: Why did Microsoft release and OOB update for a vulnerability rated “only” as important?
A: The vulnerability itself is rated as Important because it is not a vulnerability that directly leads to remote code execution on the vulnerable system, however exploitation of the vulnerability will lead to disclosure of all information in the webroot including web.config. This information can be used for session hijacking, compromising backend databases and to attack associations between websites, e.g. the association of a website with PayPal. Hence an out of band patch was warranted.

Q: Why only release to the download center and not to WSUS etc?
A: We felt we needed to get this update out quickly, the people that need to apply this patch quickly are mainly enterprises who are capable of applying patches without the aid of WSUS. Developing the WSUS capabilities would add another few days of delay to the deployment of this patch.

Q: Is the attack actively used?

Read more…

By Yaniv Miron

lolcat adaptation #3, a Creative Commons Attribution No-Derivative-Works (2.0) image from kevinsteele's photostream

Exploit wednessday ois the day after patch Tuesday, the second Tuesday of the month when Microsoft releases its patches. While some people say it’s impossible to write an attack in one day, Yaniv has seen it happen and tries to explain how.

This process is based on diffing. Diffing means finding the differences between the old and the patched version of the binary file.

This could be done on the same machine, or between two different versions of the OS (e.g. Windows XP and Vista).

The toolkit for a typical patch analysis consists of:

• Diff programs
• Compare programs
• Decompiles  and compilers
• Different versions of windows

Yaniv, then went off to demonstrate a to us the creation of an exploit for MS10-005.

First of all information from public source was gathered to find out which program was effected, what the root cause of the vulnerability was and in which version of Windows the problem is present.

The next part is extracting the patch and analyzing it. First this that needs to be done is finding the files that will be updated. The these files will be compared against the original file, just to find which functions have been changed.

Read more…

In less than 3 weeks John Craddock (XTSeminars) will visit Schuberg Philis for the first 100% Technical session: ‘Mission Critical Windows Infrastructures: Decompressing the Challenges of 100% Uptime’. You only have one week left to get invited. Don’t know anyone at Schuberg Philis yet? No problem, invite yourself at Meet John Craddock. You have to come up with very good reason why you need to be there! It might be easier invent a new operating system or hack the NASA web site ( NASA hacked ). But hey, we are talking about John Craddock here, a very experienced man on security, Active Directory and cloud computing. If you can’t make it to the 100% Technical session, you can still visit John Craddack at Deep Dive.
Hope to see you June 2nd.

For whatever reason Microsoft removed the accessible way of removing hardware profiles in Vista and Windows 7. To help out a collegue with a corrupt profile I made a tiny Powershell script to perform this action. It’s easily done by hand in the registry, the downside is you won’t see the profile descriptions which is a tad errorprone. Also, feel free to use this but I will take no responsibility whatsoever if you use this and you break your Windows install

# 20091218 – vo.o1 – PZO    – Initial hack to delete hardware profiles in Windows Vista/7
#
#————————————————————————————————————————————–
# Let’s see which profiles exist..
#————————————————————————————————————————————–
$i = 0
Write-Host “”
Write-Host “The following hardware profiles have been found on this computer:” -f white
foreach ($profile in (ls -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\”) ) {
Write-Host 000$i – (get-itemproperty -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\000$i”).FriendlyName
$i++
}
#————————————————————————————————————————————–
# Now we can ask which to remove..
#————————————————————————————————————————————–
Write-Host “”
Write-Host “You are strongly advised not to remove profile 0000 – New Hardware Profile” -f red
Write-Host “”
$input = read-host “Which profile is causing you headaches and should be removed?”
Write-Host “deleting.. “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”"
Remove-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”

Finally: do _not_ remove profile 0000 unless you know what you are doing. YMMV!

[BBG]

While doing a performance test on one of our customer environments we observed the impact of TCP offload and “Receive Side Scaling” (RSS) settings on the interface card on Windows web servers in combination with traffic handling.

Setup:

1. 2x Mercury Load Runner generators hitting public URL of customer

2. Served by 3x Windows2003 SP2 servers, running IIS6

3. Load being balanced by Cisco CSS11503 to web farm.

The CPU performance graph of the web servers with TCP offload and RSS enabled on the internet facing (FRONT) interface:

Similarly but a more outdated graph even more clearly showing that traffic is alternating from one web server to another:

Most interesting right!?

What makes this traffic to alternate if the load balancer has been set up to distribute the load evenly across the farm resp each Load Runner vuser to clear its cookies and session cache after each request?

We then stumbled over this read, knowing that TCP offload to network card is a classic one , but still:
http://blogs.msdn.com/psssql/archive/2010/02/21/tcp-offloading-again.aspx

And found out the characteristic that when TCP offload and RSS were disabled, the load is more evenly spread across the web farm:

I find this pretty cool.

Any comments?

In System Center Operations Manager 2007 you can choose an action account per server. Some management packs provide the possibility to choose a different account for some tasks. However, if you just want to run a specific script with a specific user account, the SCOM environment doesn’t provide default options to choose an account. There is a way to bypass the default behaviour in SCOM 2007 and provide your own account for a specific check.

Find out how
Read more…

After the latest patchround, I had WSUS3.0 break on me. The management snapin kept failing with ‘not responding’, and remote MMC connections weren’t accepted anymore either.

I figured to remove and reinstall, keeping the database and logs, but every reïnstall kept failing and bombing at about 90% out with a dialogue box stating ‘there is something wrong with your installation package’. As I knew for sure the package was fine (I did try both the SP1 and SP2 install..) it must be something else.

The logfile MWusSetup.log located in the Windows temp folder mentioned: ERROR CustomActions.Dll  RemovePsfsip: Failed to load dll  (Error 0x8007007E: The specified module could not be found.)

After a little googling, I found a lot of references, but not one fully working solution.

What worked for me is this (reboot after every step):

Removed all dotnet installs using a MS utility cleanup_tool.exe
(http://blogs.msdn.com/astebner/attachment/8904493.ashx)

Stop and remove the WsusCertService using the 2003 resource kit utility instsrv.exe
(http://www.microsoft.com/downloads/details.aspx?FamilyID=9D467A69-57FF-4AE7-96EE-B18C4790CFFD&displaylang=en)

Cleaned the registry using ccleaner.
(http://www.ccleaner.com)

Reïnstalled .Net3.5SP1
(http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe)

Removed the wsus mmc cache files in my profile directory.

This finally allowed me to reïnstall WSUS.

[BBG]