I’m trying to writeup something for the users at work to disabuse them of the notion that wireless security at home means turning on WEP, turning off ssid broadcast and using HW address filtering.
I ran accross “Cracking 10 WEP in 10 minutes” which is a nice little blogcast if you haven’t seen it before. I think I ignored it when it was in the news a while back. too academic. So its nice to see this styled more after the underground.
On a similar note, I’d like to get my TiVo up on my 802.11g network. I really cant hardwire it, and I want to take advantage of multiroom viewing. I don’t think they currently support WPA. I’m not sure they even support WEP right now. I”m not willing to downgrade my security for it. Too many neighbors with wireless networks.
Ok, enough rambling, I’m running out for some ice cream.
Archive for July 2005
Cracking WEP
More SenderID Bashing
Looks like another company wants to generate some good PR buzz by bashing Microsoft and bashing SenderID. This is just like my article from last fall. A company has breathlessly reported that spammers are using SenderID. Its not that bad.
MXLogic’s press release is parroted by techwebnews (parent of SecurityPipleline). They say that spammers use SPF to get an air of legitimacy to their email. I would argue that any spam filter that determines legitimacy by the presence of an SPF record is flawed. Its like the old spam assassin problem. SA automatically whitelisted anyone who signed their mail with a digital signature. Does that indicate a problem with the digital signature? No its indicates a bad implementation.
SPF is about reputation and accreditation. A domain owner publishes who is allowed to send mail from that domain. Everyone else is considered questionable. That cuts down on spam and viruses using common domain names or your own company domain name. So the spammer registers throwaway domains and creates an SPF record. You still have your other spam filters. You still have the ability to blacklist.
Meng Wong provides an illustration.
ISS SiteProtector
ISS RealSecure Workgroup Manager hit its end-of-life back in January, I was asked to work on upgrading that to their new product SiteProtect 2.0.
Its always kind of funny when an upgrade is not only mandatory but it makes like more difficult. Siteprotect seems to similar to Cisco VMS. The idea is that we should be able to manage everything from one location. The scanners, the host sensors, the network sensors all come together in one lovely stew.
I guess I should start with the things I like. Unlike Cisco, they provide a console in addition to an administrative website. Its nice to have that option. Also the website doesn’t use up all available memory unlike Cisco’s java loving beast of a website. Updates were rather simple. It is also possible to schedule recurring updates.
I am rather perturbed about reporting. Under the old version, I was able to create graphs based on tops senders and receivers of attacks as well as the top attacks. I could then filter down and create more focused reports such as what were the top attacks attempted on server X.
The new system has reporting as an add-in module (ca-ching). I thought the analysis tab could be useful for creating a report but it has a limit of 500 lines by default. Not so helpful.
I may be able to create the reports but querying the SQL database. But the hardest part there looks like figuring out what base number system they are using to store the IP addresses so I can convert them back.
At least its something to work on as we start the new workweek.
SANS @Risk Downplays risk of javaprxy.dll exploit
SANS @RISK is a bulletin summarizing recent vulnerabilities and recommendations/actions taken by unnamed member companies. Their text related to the javaprxy.dll exploit follows. It sounds like one company has a default stance to disallow activeX from running in IE and others are just waiting on the real patch which will hopefully come out on Tuesday.
__
Description: An exploit for the Internet Explorer flaw discussed in last
week’s issue of @RISK, has been publicly posted. The flaw was rated
“LOW” last week because the discoverer reported that Microsoft team
could not reproduce the flaw at that time. Microsoft has now issued an
advisory for this vulnerability. The advisory also lists workarounds on
how to disable the javaprxy.dll COM object and how to prevent this
object from running in Internet Explorer. Note that even if javaprxy.dll
is not installed on a user’s machine, an attacker can force its download
via the “codebase” attribute while instantiating this object.
Council Site Actions: Several of the council sites are still reviewing
the workarounds from Microsoft and waiting to see if a specific patch
for this problem is released next Tuesday. One site commented that
their default configuration for IE included the recommended patches and
workarounds. Another site has a large number of vulnerable systems,
about 12,000. In some cases, the end users are manually visiting the
Microsoft Download Center to obtain the registry update that disables
javaprxy.dll. They have not yet made an attempt to roll out this
registry update on a widespread basis, and have not yet sent a general
announcement to Windows users about the vulnerability. At a minimum, the
great majority of their systems will obtain an update through the public
Windows Update site, or through their local SUS server, whenever
Microsoft happens to release a patch for this.
Bloodhound.Exploit.40 (more javaprxy.dll)
Symantec finally got detected the exploit file I created over the weekend for javaprxy.dll. They are calling it bloodhound.exploit.40. http://www.symantec.com/avcenter/venc/data/bloodhound.exploit.40.html They don’t think its in the wild either. Note that although the 7/7 rev 17 defs will detect this, it will not necessarily keep the exploit from occurring. It does help keep any webserver clean that is running antivirus.
Of course with attackers shifting towards more targeted models, they wont be noticed as quickly. A while back my webhosting provider got hacked and 10,000 sites had a iframe added that loaded malicious code. The vulnerability was 9 months old so I was well patched. Imagine if they were able to hack my web provider again and use this newer exploit to install spyware or bots. While it wouldn’t make the news since its doesn’t effect Microsoft, Yahoo or Ebay, it would still infect an impressive number of computers.
You dont just need to worry about malicious websites. Sites that you trust can be made to serve up viruses if the server is compromised. You wont necessarily hear about it in the news or from the ISC if it only effects a small group of people. Take the mitigating steps that Microsoft recommends. Hopefully the real patch will be available on Tuesday, but why wait until then to have a measure of protection.
More mitigating the jajvaprxy.dll exploit
Still working on deploying the activeX kill bit. That is the mitigation for the javaprxy.dll exploit. A SMS advertizement did not get migrated over to 2003 at work so we’re playing hit or miss in guessing what the syntax should be to deploy a .reg file. We have a reg file that we normally push out monthly with over 1000 activeX controls to disable.
Microsoft created exe files to make it easy for users to disable the javaprxy.dll activeX control. I had heard this would be available on Windows Update, but I dont see it available there. It would be a good idea if they pushed this mitigation to everyone with auto-update turned on. Otherwise the average user just isn’t going to be protected.
I think this mitigation should also be deployable as a patch in SMS SUS.
By the time we get mitigation deployed the real patch will be available. I haven’t seen much chatter from the peeps at myitforum regarding getting mitigation deployed. Either it went smooth as silk for them, they cant talk about work anymore, or they aren’t worried about it. As I’ve mentioned, I’ve downloaded the exploit code and it is childsplay. I think making this lowering the corporate exposure to this vulnerability is exceedingly important.
Javaprxy.DLL COM Object Instantiation Heap Overflow Vulnerability
Microsoft put out a bulletin last week warning of a denial of service in javaprxy.dll (part of the Microsoft JVM). Exploit code has been posted to the Internet which show that this vulnerability is more than a denial of service, it can allow an attack to run code in the context of the logged on user.
Microsoft has posted several mitigating steps at http://www.microsoft.com/technet/security/advisory/903144.mspx. The easiest such step is to set the activeX kill bit. With this method you dont have to worry about loss of functionality in other applications which use the MS JVM. The downside is that from my testing the denial of service exploit still occurs (memory usage) although it does not allow the malicious code to run.
Check out the MS article for other mitigation techniques.
