The Glider

It seems that every time I do a security assessment or pentest, the findings include problems with access controls for things like routers, switches, fiber channel switches, bladecenters and the like. And when I say every time, I really mean EVERY TIME. So, what kind of problems are common, and what can you do to prevent them?



Default Credentials



People love default credentials. I've actually had a customer tell me if we forget the password, we can just google for it - like somehow that's a good thing. Even for gear that comes with default credentials that force you to change them on login (for instance, fiber channel switches), I've seen other engineers then change the password back to the default - their rationalle being that it reduces their support calls later.



The number of bladecenters that I've seen that have changed the default admin user and password I think I can count without taking my shoes off (ie - it's a small number - almost nobody changes their bladecenter admin password). This access gives the right to power off servers, decommission servers, unpatch servers, hack windows or linux passwords, almost everything is possible - the bladecenter admin access gives you the near-equivalent of physical access, and we all know that physical access trumps almost every control in the book.



People - default credentials are BAD. If you are using default userid and password, and someone compromises you, we don't call that hacking, we call it logging in. You don't need an uber-hacker to target you in this situation, ANYONE WITH GOOGLE can compromise you. Change the admin password on your gear, and if possible, change the admin userid. Better yet, back end admin logins with another directory (read on ...)



Prevent Access in the First Place - Access Classes

Many products will allow you to restrict administrative access in the configuration. For instance, Cisco gear has the access-class config statement. HP, Brocade, Juniper and others all have an equivalent construct. The commands you'd put in your switch or router config might be:



first, define the subnet or ip addresses of authorized administrative workstations
ip access-list standard ACL-ACCESS-CLASS

permit host 192.168.72.10

permit 192.168.68.0 0.0.0.255


next, apply the ACL to your access
line vty 0 15

access-class ACL-ACCESS-CLASS in





Prevent Access in the First Place, Reloaded - Define a Management Network



Even with all the other controls we'll talk about, implementing a management network is a good move. It zones all infrastructure admin into one place, you can control access to this netowrk using VPN controls or a jump box. The VPN approach is a neat one - it means that if you are an authorized admin, you can use an IPSEC or SSL VPN solution to get an IP that has access to admin your network from anywhere in the company. This is really handy for admins that are mobile within the company or have to provide support from home (or the cottage, the beach, or anywhere else they can find you).



Encrypt all Administrative Accesses

I still see LOTS of admin access over standard HTTP and Telnet. And there are LOTS of tools that will strip passwords out of this type of traffic - you can do this with CAIN if you want a GUI, but really even doing it with wireshark or tcpdump is pretty simple. Be sure to force SSH (Version 2 if you can, Version 1 can be decrypted), or HTTPS for administration of critical network infrastructure.



Even what you might consider non-critical infrastructure should see the same protections. I've done a pentest on a company that used telnet to administer their UPS gear (to monitor temperature and humidity as well as power characteristics and remote control of power etc). Unfortunately for them, they used their AD admin password to login to their UPS, which they accessed using plaintext HTTP and Telnet. Doubly unfortunate, as a standard procedure they logged in each morning to check logs etc.



Checking logs daily would normally be a really good thing if they had other controls in place (for instance, using HTTPS or SSH for administration), but since they were being pentested, I had their admin password within 10 minutes of starting the actual process !



On a cisco router or switch, the commands you need to set up SSH are:



first, define a hostname and domain name
hostname yourdevicename

ip domain-name yourcompany.com



next, generate the key

(use some number equal or greater than 1024 for stronger key strength)



crypto key generate rsa general-keys modulus 1024


next, force SSH version 2 and force SSH for access

ip ssh version 2


line vty 0 15

transport input ssh






If you allow web administrative access (that's a whole different discussion), forcing https on network instrastructure is generally even easier:



disable plaintext HTTP
no ip http server



enable SSL encrypted HTTPS

entering this last line will generate the (self-signed) SSL cert to

encrypt the webmin sessions.



ip http secure-server





To go one better, I'd also suggest that you replace the self-signed certs that is used by default for HTTPS admin on most gear, using certs on SSH is also a really good mechanism. Without replacing the default certificates, tools like ettercap can still be used to mount a man-in-the-middle attack and recover passwords.



Back-end Authentication and Change Logging



After everything else is said and done, there's still way too much gear out there that has a single administrative account, or no account at all (only access passwords). This plays hob with managing change - since every config update is done using the single admin account, if a change goes bad everyone in your team can deny making that change. (Does your team have Ida Know as an honorary member?) If you don't take a stab at non-repudiation of changes, this WILL bite you eventually.



So, what to do? Should you define a userid for each and every user on all your infrastructure gear? Well, only as a lastresort. Most network infrastructure has the capability of back-ending authentication and access controls using some external source. Popular back-ends are what you'd expect - RADIUS, TACACS, Kerberos, LDAP and Active Directory. I'd say pick one and go with it. I often go with RADIUS back-ended with AD(IAS, now NPS)because it's simple, easy to troubleshoot, and supported by almost everything. Mind you, it's also likely that if you go with RADIUS you are then susceptible to other attacks, but you can mitigate that by setting your RADIUS server up in a private vlan or by using other intelligent design decisions to implement security controls.




Basic definition of AAA, as well as the definition of the RADIUSserver

(Note that the RADIUSserver config will need to match this)


aaa new-model

radius-server host 1.2.3.4

auth-port 1645 acct-port 1646 key randomcharkey



this line forces radius authentication for login by default. If radius is down (ie - no response is received from the radius server, or the radius keepalive is missed), then local authentication still works. Note that on one hand this leaves you open to attacks that involve DOSing your RADIUS server. On the other hand, you still have access to your network gear if your RADIUS servers or domain controllers are offline.
aaa authentication login default group radius local


defining the source interface is important, since the ip of the device is normally hard-coded on the radius server
ip radius source-interface Vlan1


on some gear you may also need to force authentication on individual lines:
line vty 0 4

login authentication radius

line console 0

login authentication radius

line aux 0

login authentication radius





Don't forget to LOG ALL ACCESSES (this is built into RADIUS and TACACS) and LOG ALL CONFIG CHANGES (lots of tools will do this for you - syslog will log that a change occurred and who made it, CATTOOLS and RANCID(thanks to our reader Bmac for this correction)are 2 that come to mind for more complete change logging, I've also written shell scripts to do this. Feel free to suggest others that you use as a comment to this diary). In some cases, you may also want to log all commands as well (most gear will let you do this in syslog).
What does this give you? As changes occur, you are notified that a change happened, who made it, and what it was. You can then compare this to the CHANGE REQUEST FORM that you have in your CHANGE CONTROL SYSTEM, to be sure that:

the change made was both requested and approved
the change happened during the change window
the person making the change was the one authorized to do it

if it was an unauthorized change, you have the culprit identified and can have, shall we say, a discussion that's appropriate to the situation.
Basic commands for simple logging and NTPtime sync are, well, pretty simple (as with most examples in this diary, it can get more complicated)



Basic Syslog logging is a one-liner
logging 192.168.5.7


Similarly, setting a target host to get time from is also very simple
ntp server 192.168.5.6





I've phrased this discussion in the context of network infrastructure gear, but really many of these points extend to other datacenter infrastructure components as well. Replacing default certificates used for RDP to critical Windows servers is a good move, as is certificate updates for things like VMware vSphere (both vCenter servers and ESX Hosts). Using a Management network is an important part of designing a virtual infrastructure from any vendor, as well as bladecenters (for the same reasons). Management networks can also be used to protect things like RADIUS authentication, syslog, NTP and SNMP based network management, all of which are sent in cleartext. Back-end authentication to an enterprise directory (often AD) is a common solution for authentication, is useful as we discussed for managing and auditing change for both Linux and VMware servers, as well as for lots of other gear besides just routers and switches.



I'm hoping that you find these suggestions to be a helpful starting point. There's lots more that can be done in this area, please use the comment feature to let us know if you've found this useful, have your own stories in this area, or if I've missed (or messed up) anything in this diary.
=============== Rob VandenBrink, Metafore ===============

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

-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander | http://manuel.santander.name | msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Charlie Miller discovered a integer overflow error in CoolType.dll when parsing the maxCompositePoints field value in the Maximum Profile table of a TrueType font. PDFs containing specially crafted TrueType fonts can trigger this vulnerability.
Want more information? Check the following document from pages 51 to 58: http://securityevaluators.com/files/papers/CrashAnalysis.pdf
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

Cisco Security Advisory: Multiple Vulnerabilities in Cisco ASA 5500 Series Adaptive Security Appliances, impact is DoS.

Advisory ID: cisco-sa-20100804-asa

http://www.cisco.com/warp/public/707/cisco-sa-20100804-asa.shtml
Cisco Security Advisory: Multiple Vulnerabilities in Cisco Firewall Services Module, impact is DoS.

Advisory ID: cisco-sa-20100804-fwsm

http://www.cisco.com/warp/public/707/cisco-sa-20100804-fwsm.shtml


Cheers,

Adrien de Beaupr

EWA-Canada.com

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

A comment to my earlier lightning diary pointed out that NOAA warned of a large solar eruption that happened on Sunday (August 1st). NOAA monitors Space Weather [1] in an effort to protect satellites. In this case, the effect may be large enough to cause some problems on the ground as well.
These events are not all that unusual, and in most cases there is little ground based damage if any. Long distance radio transmissions and satellite communications are usually affected first. Given our reliance on systems like GPS, an outage may have indirect ground based affects. Sensitive electronics may be affected and outdoor radiation levels may be higher then normal. Long distance power lines may also be affected by the associated changes in earths magnetic field as well as charged particles.
On the fun side: This may lead to more northern lights. Maybe check them out after dark for the next couple of days.
[1] http://www.swpc.noaa.gov/today.html

------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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

This weekend, I had a pretty bad lightning strike hit my house. The kind of where you see spark hitting the street in front of the house and your dog jumping in your lap lightning strike. Overall, lightning is a pretty common phenomenon around here. I live in Florida, which appears to be #1 in lightning strikes and casualties in the US [1] . For the 5+ years I live here, the power grid has actually been rather stable during lightning storms, but lately, I had a string of bad luck and would like to share some lessons learned:
So far, I had no damage to equipment completely protected by a UPS/surge protector. I use various types of UPSs, and all performed well so far. Some are rather old and have hardly any battery life left. But they do still work well enough for power spikes/dips as they show up during electrical storms.
The damage I had, in particular in the last storm, affected exclusively network equipment and networking interfaces. I assume that the surge entered the network. Ilost two switches and the wired network interfaces in two PCs. Otherwise, the PCs work fine. So far Ihad not used any network surge protectors, but now started to use the surge protectors provided by the UPS. This appears to work fine, but in some cases, the network now works as half duplex and no longer in duplex mode. I looked into stand alone network surge protectors for some devices, and it turned out to be a bit hard to find one that supports gigabit ethernet. But they are available. The UPS network surge protection is only supposed to work up to 100 Base-T but synced fine at Gigabit (no duplex).
A thunderstorm a couple months ago, caused some interesting damage to my cable modem. Iwas only able to upload 1MByte in a single connection. This was very weird as it also applied to connections inside VPN tunnels, the cable modem shouldn't really see what was happening. But sure enough, swapping the modem fixed the problem. Iadded a surge protector for the cable line as well. One reason I had not done this before was that I had bad experience with surge protectors and cable modems in the past. But my new cable modem (like many others) provides a status screen and the signal-to-noise number did not suffer significantly after adding the surge protector. The surge protector replaced a simple straight through connector which may have caused a similar loss.
Couple other hints:
- do not plug surge protectors into a UPS. If the UPS runs on batteries it will usually generate a steep sine wave which may destroy surge protectors (in particular tricky to find power strips without surge protector)

- do not plug a UPS into a UPS (same reason as above)

- lightning damage can be subtle. None of my equipment has any visible damage

- proper grounding of all lines entering the house is important (around here, I find that utility companies are pretty good about that)

- once the power is out, turn off the main fuse to the house. But be aware the main fuse can be hard to flip. Depending on the nature of the outage you may have some surges and unstable power until the damage is repaired (if you want to know when power comes back, just flip all the individual fuses other then one or two that only power lights)
If you consider a backup generator: Ilooked at many options, but haven't been able to justify one so far. This last outage was 10 hrs long and was by far the longest I have seen. My backup plan is a well charged laptop and a 3G data card to keep me connected. If you consider backup power for a server room, don't forget the AC! For the generators I looked at, the cost to install was almost as much if not more then the cost of the generator. If you do use a portable generator to power individual devices, make sure you do NOT plug the generator into your house wiring before disconnecting the main fuse.
As a quick summary: Surge protectors work. They will probably not save your equipment if the lightning storm rips the electrical wiring out of your walls, but they can help against some pretty nasty strikes. Unplugging your equipment (and WiFi :) ) is better, but not always feasible.
[1] http://www.srh.noaa.gov/mlb/?n=lightning_stats
------

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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

A way back in June I started a discussion on Vulnerability Assessment Testing Automation Part I. isc.sans.edu/diary.html?storyid=9091

In it I mainly focused on one of the primary port scanning and fingerprinting tools in use today, nmap. More importantly getting nmap data parsed and in a nice cozy database where we can query our hearts out, then correlate data points, and pump out snazzy reports. In this diary I'll extend the discussion to include Nessus, also a mainstream tool for performing network vulnerability assessment scanning. One of the issues I have had with Nessus for a long time is the reporting, and most of us write or use other tools to make sense of the reams of data you get from multiple Nessus runs. This one is no different. What it does is parse the newer .nessus V2 file format and import it into a database.



The script is here:

handlers.dshield.org/adebeaupre/parsenessusv2mysql.pl

It makes us of XML::DOM and DBI.



Usage: parsenessusv2mysql.pl xmlfile {dbname dbuser dbpassword}

The database name, database username, and password are all optional cli parameters, they can also be set by editing the appropriate values within the script.



I had been using a different script to parse .nessus v1 files, and was going to add it to this script as well, but changed my mind as I am currently finding it easier to bulk upload v1 files to the Nessus XMLRPC interface and then download them converted to v2.



Unfortunately it also needs some more work, but does the trick. I am more than open to suggestions, or better ways of doing things. Part III will be tips and tricks to using the Nessus XMLRPC interface from the command line. Part IV will be parsing other tool outputs for database import that don't have a fancy XML format. Part V will be the scripts and techniques to wrap all of the other parts together following a reasonable methodology. Let us know if you use this script, something like it, or some other technique to manage security test data. Contact us or use the comment fields below.
Cheers,

Adrien de Beaupr

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

Considering reporting an incident?
Have you just received an incident report?
My, oh my... what are you to do?
Since I am unquestionably the arbiter of all that is good and right on the highways and byways we lovingly call the Internet, Iput together a handy little guide to help you through these trying times. Just think of me as the Miss Manners of Incident Handling. Only I don't wear a dress...
Very often...
Anymore...
What *NOT* To Do When Reporting An Incident

Cop a 'tude: Ok, I can certainly understand that you're feeling a little miffed 'bout the fact that someone took a whack at one of your machines, but really, in my experience, most (i.e. ~99%) of the time the responsible party is many steps removed from the people you'll be contacting-- so venting your spleen on the dude at the receiving end of your email or phone call is just bad form. Save that stuff for telemarketers. (Note: Yes, I understand that telemarketers are often good, wholesome, hardworking folks trying to make ends meet. I just don't care.) If you're all wound up and ready to take names and kick butt, then you're clearly an amateur at incident response. More than likely, that evil Eastern-block hacker with the slicked back hair and bad teeth that you're imagining kicking over your webserver is actually just an unpatched WinXP machine owned by someone's Great Aunt Margaret that got whacked by the latest version of SDBot. Keep the vent-plug locked down tight on your spleen... no one wants you gettin' Great Aunt Maggie all spleeny.
Get All Litigious: This is a subgroup of #1. In this case, instead of questioning whether the 'leet hax0r's parents were married at the time of his/her conception, you whip out the big guns, 'splainin' that you'll rain down all manner o'lawsuits, IRS investigations, and Papal excommunication on the responsible party. Trust me, if the FBI was interested in investigating your incident, you wouldn't be writing about it in an email to abuse@. Doing this just makes you look silly. Stop it.
Look Stupid: A good incident report tells a story: it tells exactly *what* happened and exactly *when* it happened. Stop hacking me! is not an incident report -- it's an exclamatory sentence that reeks of idiocy. Include IP addresses (and, if they resolve, machine names) in your report. Include port numbers. Include times (synchronized to something besides your best stab at clicking Ok while staring at Mickey's hands...). Include (or offer to provide) packet captures. You need to do the work so that the people on the receiving end of your report don't have to... or you'll be ignored. Notice: All of these things imply that *you* actually have a dang clue, have done your homework, and are monitoring your network at some sort of reasonable level. Wow. Who would have thought that you actually needed to know what you're talking about to report an incident?
Plant Your Flag: The Internet sucks when it comes to attribution. WHOIS tells you little and is often wrong about what it *does* tell you, IP addresses rarely reverse resolve, abuse@ email often appears to black-hole, and most ISP support staff gave up caring when they realized that I work in IT isn't really the chick-magnet phrase they thought it would be. With those kinds of odds against you, you're not gonna win many of these... I know it's frustrating when you have someone dead-to-rights and they simply dismiss you, saying, It's not us. Let it go. You've taken the time to try to warn someone about an incident, and sometimes, that's the very best you can do. Persistence isn't a virtue here, and if you cross the line and get abusive about an incident yourself, it can get you in really deep, really fast.
Blame TheVictim: Not everyone is as 'leet as you... nor are they as good looking, suave, sophisticated and debonair. (Very few of us are...) But, because you're also as intelligent as you are attractive, you know that you shouldn't look down on someone who got 0wned. It's bad karma, and as these things always happen, you'll undoubtedly be next. Offer help if the situation warrants it. Explain what they need to do if they seem clueless. But why am I telling you this? You're also kindhearted and generous to a fault. Aren't you?
Give up: We've all been there-- you look at the stream of evil stuff constantly raining down on your network, and you despair. All I can say is don't give up. You've reported incident after incident, and it appears to go nowhere. Trust me, I know. I run a honeypot system... I get attacked on purpose, and I've probably sent thousands of emails reporting incidents. It never fails: just when I get to the point where I'm feeling like I'm trying to sop up the ocean with a paper towel (and I'm ready to throw in said towel), someone will actually reply and say thank you. They come in all kinds of ways: I had a guy call me back about an hour after I originally talked to him when he was... well... a bit rude. He explained that he was very suspicious when I initially called, but when he actually checked out what I had told him and found out that he *did* have an infected machine on his network, he just had to call back and say thanks. Years ago, I actually got a very nice Harry and David gift basket from a company I contacted when they had a server compromised. While I wouldn't sit by the front door waiting for the UPS guy to bring you largess, trust me, someone out there does appreciate what you're doing.

What *NOT* To Do When Someone Reports An Incident

Cop a 'tude: While I fully support you being skeptical/wary when someone calls you out of the blue to report an incident, skeptical and rude are two different things. If the person reporting an incident seems to be asking intrusive questions, feel free to say I really don't feel comfortable answering that and ask them politely to provide whatever information they can. If it's someone trying to scam you, well... you've been polite to a scammer... certainly not the end of the world. But if the incident turns out to be real, you're gonna feel really, REALLY bad if you were rude and demeaning to someone who was just trying to help you out. (And, if you don't feel bad, then you should seriously start looking around for your soul... 'cause it must've fallen out of you recently. Look over in the corner, behind the filing cabinet.)
Get All Litigious: I once called up the Superior Court of an unnamed California county to report that their website had been whacked and was currently advertising both erectile dysfunction medications and hot teens (i.e. they had the sex and the drugs... all they needed was some rock n'roll...). After the normal shuffling back and forth to various people who assured me that this issue wasn't their responsibility, somehow I ended up being palmed off on some County attorney who proceeded to explain all of the legal hell he was going to rain down on me for hacking their website. My opinion of Mr. Lawyer wasn't improved by the fact that he was clearly in negative-clue territory in his understanding of how the Intertubes worked. I finally silenced him when he asked me How could you possibly know that this existed on our site if you didn't do it? by giving him a very simple string of text to type into the mythical oracle of all knowledge known as Google. Don't even think of accusing someone who *contacts you* of being the bad guy. Doing this just makes you look silly. Stop it.
Look Stupid: If I had a nickel for everyone who told me they couldn't be the source of an attack because they run a) a firewall or b) antivirus, I would have... well... a lot of nickels. (Probably not enough to buy me another nice Harry and David gift basket, but still... a lot of nickels.) Come on... antivirus? A firewall? Really? If you're in IT and you truly believe that the fact that you're running a firewall or AV has any bearing on whether one of your machines could be infected and attacking others on the 'Net, then I have a bridge for sale. Really. I do. It's very pretty. Trust me.
Plant Your Flag: Liston's Law of 'Net Karma: If you're stupid enough that, without checking, you would actually tell someone that an attack couldn't possibly be sourcing from your network, then the attack *is* sourcing from your network. Don't get cocky, 'cause you never know. If someone tells you that you have an issue, ESPECIALLY if that someone provides you with detailed information, check it out -- do NOT just dismiss it. Look at it this way: if your network is reasonably well-monitored, its not going to take you *that* long to confirm or deny... if it does, well then, your network isn't as well-monitored as you thought, now is it? Someone out there in Internet-land took the time to tell you that they think your network may be spewing badness -- the very *least* you can do is to look at some logs.
Play The Victim: You got 0wned. Something, somewhere went wrong. Man up (or woman up, but that just sounds weird...) and take 0wnership of the 0wning. It happened. Learn a lesson, fix something, and move on. Yes, you are a victim, just don't act like one.
Forget To Say Thank You: What? When your momma 'splained about manners were you spending your time pickin' your nose? (If so, you should've picked a better one... have you seen that thing between your eyes? Eeeesh!) Someone just did something nice for you. they just took the time to deliver it to you, and the least (the VERY least) you can do is acknowledge them for it. No one likes to learn that their network has been 0wned, but would you really rather NOT know? And for those of you in the if-I-don't-acknowledge-it,-it-didn't-happen camp, come on! (And yes, I know that this is actually POLICY in some organizations...) Remember: THEY KNOW! They told YOU! Do you really think that the mind on the other end of that email or phone call you received will fall prey to the Jedi mind game you THINK you're perpetrating by not responding? Oh, I guess since they never replied, those 5000 SSH login attempts never really happened... No! They're just sitting back and thinking that you're a pretty big jerk for not even acknowledging their effort to let you know 'bout the problems you have. Seriously folks, tell your corporate counsel to go play with their briefs and send out a thank you... you don't need to admit to anything: just say thank you for telling about this issue, we're looking into it. A little common courtesy goes a long way, and for those of us in the trenches who actually take the time to let people know about these things, a thank you email is a lifeline. Harry and David gift baskets are nice too.

Tom Liston - Handler - SANS Internet Storm Center

Senior Security Analyst - InGuardians, Inc.

Director, InGuardians Labs

Chairman, SANS Virtualization and Cloud Computing Summit

Twitter: @tliston

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

There are many companies that are using windows kiosk to provide people an alternate way to provide automated customer service. These kiosk are even developed sometimes by the same company.
How to tell if they provide enough security level? When I have had to answer that question, I have found useful iKAT, which is a tool to test how secure is a Kiosk by telling if it can spawn a shell or other programs, crash the browser, navigate to forbidden sites, among many other interesting plugins. You can also find iKAT for Linux.
Please note that the link has some advertising banners which may be deemed not suitable for working envrionments.
-- Manuel Humberto Santander Pelez | http://twitter.com/manuelsantander| http://manuel.santander.name| msantand at isc dot sans dot org (c) SANS Internet Storm Center. http://isc.sans.org Creative Commons Attribution-Noncommercial 3.0 United States License.

As announced on Friday, Microsoft released an out-of-band bulletin to address the recent Shortcut/LNK exploits. As confirmed in Microsoft's announcement, various malware is now attempting to exploit this vulnerability. The vulnerability is rather easy to exploit in particular given the tools available to craft necessary shortcuts.
Clients are the main target but servers are as vulnerable and should be patched as soon as possible. Please report any issues you have with the patch !





#
Affected
Contra Indications
Known Exploits
Microsoft rating
ISC rating(*)


clients
servers





MS10-046
Vulnerability in Windows Shell (LNK/Shortcut)


Windows Shell

CVE-2010-2568
KB 2286198
actively exploited.
Severity:Critical

Exploitability: 1
PATCH NOW!
PATCH NOW!






-----

Johannes B. Ullrich, Ph.D.

SANS Technology Institute

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