Last Updated: 2010-11-24 22:58:41 UTC
by Jim Clausing (Version: 1)
I have to admit, I've gotten a little lazy about reading through my firewall logs on my home machine every day, but today, I was looking back through my daily reports for the last 2 weeks and noticed a couple of odd port scans. I've been getting these scans from multiple IPs (2-4 of each per day) everyday for that period. I'll put up a netcat listener this evening to see if I can get some packets, but I was wondering if any of our loyal readers had any idea what is going on here? Based on some of the ports being scanned, I'm guessing they are looking for open proxies to use as relays among other things, but some of those ports are new to me. Has anyone else seen them or know what they are actually looking for?
From aa.bb.cc.dd - 252 packets
To my.home.machine - 252 packets
Service: snmp (udp/161) (IPTABLES UDP-IN:) - 36 packets
Service: 3389 (tcp/3389) (IPTABLES TCP-IN:) - 54 packets
Service: 5900 (tcp/5900) (IPTABLES TCP-IN:) - 54 packets
Service: http-alt (tcp/8080) (IPTABLES TCP-IN:) - 54 packets
Service: 40080 (tcp/40080) (IPTABLES TCP-IN:) - 54 packets
From ee.ff.gg.hh - 32 packets
To my.home.machine - 32 packets
Service: 73 (tcp/73) (IPTABLES TCP-IN:) - 1 packet
Service: socks (tcp/1080) (IPTABLES TCP-IN:) - 1 packet
Service: 2301 (tcp/2301) (IPTABLES TCP-IN:) - 1 packet
Service: 2479 (tcp/2479) (IPTABLES TCP-IN:) - 2 packets
Service: 3128 (tcp/3128) (IPTABLES TCP-IN:) - 2 packets
Service: 3246 (tcp/3246) (IPTABLES TCP-IN:) - 3 packets
Service: 6588 (tcp/6588) (IPTABLES TCP-IN:) - 1 packet
Service: 8000 (tcp/8000) (IPTABLES TCP-IN:) - 2 packets
Service: 8085 (tcp/8085) (IPTABLES TCP-IN:) - 4 packets
Service: 8090 (tcp/8090) (IPTABLES TCP-IN:) - 2 packets
Service: 8118 (tcp/8118) (IPTABLES TCP-IN:) - 1 packet
Service: 9000 (tcp/9000) (IPTABLES TCP-IN:) - 4 packets
Service: 9090 (tcp/9090) (IPTABLES TCP-IN:) - 4 packets
Service: 9415 (tcp/9415) (IPTABLES TCP-IN:) - 2 packets
Service: 27977 (tcp/27977) (IPTABLES TCP-IN:) - 2 packets
Jim Clausing, GSE #26
jclausing --at-- isc [dot] sans (dot) org
Last Updated: 2010-11-24 21:56:08 UTC
by Bojan Zdrnja (Version: 2)
Today proof of concept code (source code, with a compiled binary) of a 0-day privilege escalation vulnerability in almost all Windows operating system versions (Windows XP, Vista, 7, Server 2008 ...) has been posted on a popular programming web site.
The vulnerability is a buffer overflow in kernel (win32k.sys) and, due to its nature allows an attacker to bypass User Access Control (UAC) on Windows Vista and 7 operating systems.
What’s interesting is that the vulnerability exist in a function that queries the registry so in order to exploit this the attacker has to be able to create a special (malicious) registry key. Author of the PoC managed to find such a key that can be created by a normal user on Windows Vista and 7 (so, a user that does not even have any administrative privileges).
The PoC code creates such a registry key and calls another library which tries to read the key and during that process it ends up calling the vulnerable code in win32k.sys.
Since this is a critical area of the operating system (the kernel allows no mistakes), the published PoC only works on certain kernel versions while on others it can cause a nice BSOD. That being said, the code can be probably relatively easily modified to work on other kernel versions.
We are not aware of any exploitation of this vulnerability at the moment and, since it can be exploited only locally, it obviously depends on another attack vector, but knowing how users can be easy on clicking on unknown files, this is definitely something we will keep our eye on and post updates if we see exploitation.
The PoC has been in the mean time removed from the original site but now that it has been published I’m sure that everyone who wants to get it can do that easily.
I just wanted to confirm that the PoC works as advertised, as you can see below:
However, as expected (and stated by the PoC author), on my version of Windows 7, which has win32k.sys 6.1.7600.16667, it is unstable and causes a pretty nasty BSOD after couple of minutes (had even to restore the previous system state to get Windows to boot).