Slashdot Mirror

Another good rootkit checker, which seems to have a more active development cycle, is Rootkit Hunter. Here's a Newsforge article on it, with a few more details.

A few other comments:

Virus scanners won't help on jot against a custom hack (as Valve found out, for instance). They can be helpful, but don't put full reliance on them.

Running an Intrustion Detection/Prevention System such as Snort, Samhain, Prelude, etc. will help you manage the monitoring side of things; more than a few machines becomes a pain without additional help. Also take a look centralising all your logs on a syslogng server or something similar, if you don't already (note that there are various solutions out there to get Windows boxes to log to a syslog server).

A honeypot may distract the hacker from your production servers for long enough for you to identify that there's a problem.

Also take a look at "HoneyTokens": specifically created database records that trigger alarms if they're accessed - usually high profile fictious targets that would make excellent trophy hacks - there's more info on this over at SecurityFocus.

If you suspect that a machine has been compromised, as other have said, the ONLY WAY TO BE SURE is to rebuild the box from scratch. While this may be a real pain, hopefully it'll help you get the procedures in place to make this as painless as possible, so it's not all bad.

Perform security audits/pentests every now and again. Tools like Nessus help: here's a good series on using Nessus (part 2, part 3).

Get familiar with security tools such as the top 75 recommendations at Insecure.org (home of Nmap).

Remember that security is a PROCESS, so be thorough; get an entire plan together and cover all the bases that you can, taking special care to identify and cover the weak points. Your company's security is only as good as its weakest link; for instance, priviledge escalation of weak user account passwords is a good one.

Read SecurityFocus, PacketStorm, CERT and the like, and try to get involved in their communities; they can be invaluable! They're also got a lot of good tutorials, such as how to lock down Apache, IIS; securing PHP, ASP; etc.

Are you too young to remember Pierre Trudeau using the War Measures Act to suspend civil liberties when Quebec terrorists kidnapped a British diplomat? Canada fought its own nasty little war with Quebec separatists in the 1960s and 70s and used many of the same tactics that we are currently using in the States. I remember an uncle of mine from New Brunswick lamenting the fact that the RCMP did not have the same kinds of files and data on Quebec radicals that the FBI had on US anti-war radicals.

Go look up the Act to Combat Terrorism (Bill C-36) and its companions.

Is High Times and other pro-marijuana literature still banned in Canada? Or has that sort of anti-free speech law that Canada used to be infamous for finally died out? Its been a while since I've been North to visit the relatives.

Sorry, I know that both Canada and the world have romantic notions about what an ideal place Canada is (kinda like Norway) and I don't really mean to piss in your Wheaties, but you need to read your own history. Canada has had many of the same fights over civil liberties vs security that the US has had. And civil liberties have lost many rounds in Canada.

I'm not sure which article it was, but perhaps it was referencing this study.

In it someone did phase-space analysis of the PRNGs used in DNS, and combined it with a birthday paradox style attack. In it, an attack on BIND 8 was shown to be 100% likely to succeed, BIND 9 20% and DJBDNS was 30%.

However, if you read the rest of the article, it points out that DJBDNS also uses a strongly random source port for the query, making it significantly more resistant to the attack, as the attacker would have to guess both the query ID and the source port simultaneously. (The two put together have about 1 billion possible combinations. The ID alone only has 64k.)

Unless there's some other DNS poisoning attack I'm unaware of, I think I'd prefer DJBDNS, as it's more resistant than bind 8 or bind 9, despite it's slightly less random output than bind 9.

(Note: bind 9 can be configured to use non-fixed query ports, but you'd need an kernel level random source-port patch to get good security out of this.)

The likelihood of getting nailed behind a Linksys while you're patching the system is pretty slim.

I would respectfully disagree with this statement. Please see this article regarding Linksys routers or this article concerning Netgear routers.

Just set up a VPN and start patching. It's a more realitic approach than all the other singing and dancing.

Is it really? This idea of "I have a firewall and I am OK" is very problematic. There are several layers of defense that must be employed to provide a reasonable amount of protection. Simply relying one firewall with somewhat limited capablities is folly.

I had a similar problem with Firefox 0.9...

I installed it on a new Windows XP box I am setting up (I hate XP... if you have to deal with Windows... Win2k is a lot easier to deal with.)

It installed OK, but crashed every time I tried to run it. (In fairness to Firefox, XP is probably to blame -- see comment above.)

Anyway, I uninstalled 0.9, and installed 0.8 in its place, and everything seems to work ok now.

I am VERY GLAD that there are articles like THIS to direct the PHBs to, whenever any of them second guess the decision to move everyone off of Internet Explorer, Outlook, and Outlook Express.

Security Focus has a posting about the 5 Boroughs CD installing some copy protection software if you put the CD in a Windows or Mac system. There's much griping on a Beastie Boys message board, but few details. A Google search indicates that this is not the case in US and UK, though someone picked one up in Manahattan that's copy protected. Since this album just came out a couple of days ago, it'll be interesting to hear how this pans out.

which apparently tries to install copy-protection software on your computer when inserted (Win and Mac obviously). Hell, while they're at it, why not install Gator or Bonzi Buddy?

Free Tibet, my ass...

I suppose that if it does become an issue they'll just address it with something like a good old fashioned shrinkwrap license on the CD -- "by opening this CD you are giving us permisssion to install whatever the hell we want on to your computer."

Oh, well...in the meantime, is there anybody in Utah with some free time on their hands and a desire to be a test case? :)

Nice column about the flaws of IE compared to Mozilla.

Microsoft does patch their OS quickly. The only problem is that many many people don't install the patches they provide. The vulnerability that CodeRed exploited was patched three months before the worm was released. The only reason it caused so many issues was because of incompetent Windows sysadmins.

Have you heard of this Outlook 2003 vulnerability (Script Execution Vulnerability) ?
It was discovered on May 17, but no patche today.
And this Internet Explorer exploit does no have a patche too.
If you look at this, you'll see that it took them more than 6 monts to release their patche on the LSAS vulnerability (used by Sasser).
Is that what you call "patch their OS quickly" ?

In every case where there has been a problem with Windows security, it's been AFTER they released a patch for the vulnerability.

That sounds great, except you're completely wrong. There are plenty of unpatched MS vulnerabilities that are being actively exploited. For example:

Microsoft Internet Explorer ADODB.Stream Object File Installation Weakness

And this certainly isn't the only example. They've earned their reputation for ignoring known vulnerabilities:

pivx list of unpatched IE vulnerabilities from 9/2003

And before you say that these are IE vulnerabilities, not "Windows" vulnerabilities, you might want to consider Microsoft's own position in a certain court case.

According to SecurityFocus, the virus was recieved by anti-virus firms from its creators, and has not yet been seen in the wild.

• 
  http://www.safecenter.net/UMBRELLAWEBV4/ie_unpatch ed/
• http://www.guninski.com/browsers.html
• http://www.malware.com

Whatever happened to this lawsuit?

Another problem is how they "investigate".

Almost a year ago Poulson told us, "Backed by a legion of lawyers and empowered by the Digital Millennium Copyright Act, former FBI agents in the company's Office of Signal Integrity have staged raids against businesses that deal in piracy equipment, seizing customer lists and inventory with armed law enforcement officers as backup."
He was not the only one to report that some of the lawsuits were filed against people who didn't even own a satellite dish. (I think Wired News also had an article about this, but I can't dig up the hyperlink at the moment. This boneheaded move predates Murdoch's takeover, by the way.)

I've been making friends and family aware of this fiasco ever since I first heard of it, hoping that none of them will reward with their business what could be described as "extortion".
I wish the names of those who made this decision could be posted somewhere, and archived, before they move on to other employers and continue spreading the contempt.

Of course, a company has every right to resist "criminal" acts. But there is good reason to believe, here, that this firm knew they'd cast the net too widely.
It smells like a money-grab - the easy way out (compared to seeking relief in criminal courts, where there are laws on the books to protect them from the real baddies).
By the same logic they could've been suing anyone who made anything that could have been used to facilitate the "theft". Charming.

<grrr>

Not true. MS's implementation of IPSEC doesn't support multicast because MS's implementation of IP filtering doesn't support it. But a proper IPSEC implementation /does/. See here and here.

Employers don't want walking encyclopedias they want projects finished on time and on budget for their clients. What I am trying to say is a degree is more than a cert in knowledge it is a cert in the abilities to get the job done and done right. A professional and ethical attitude and behavior

RMS (extremist),
All members of Cult of Dead Cow (H4x0R5),
Phil Zimmerman (PGP is used to encrypt kiddie pr0n)
Linus Torvads (Linux may destroy Micro$oft ad Sun, major Fortune50 stocks, collapsing the value of all 401k in the US, forcing old people into poverty)
All degree-holders that worked for VIA (for infringing IP)
Jon Johansen (for writing DeCSS)

The only people that should have degrees are boring people that tow the company line, ask no questions, you are a number, not a free man, otherwise lose your degree.

Yeah, IE is so much more superior, I can't imagine why anyone would use Mozilla/Firefox...

Here is the BugTraq Archive link.. WARNING.. The link to this site contains OTHER links to the ACTUAL exploit as well as the source code and a non-harmless display. Use at your OWN risk. Just thought I would put out the disclaimer.

I couldn't find the exact link at first glance, but this one is a reply to it: http://www.securityfocus.com/archive/1/365292/2004 -06-05/2004-06-11/0

Not sure if anyone has read the updated news about this little vulnerability.

It still exists, albeit in a different account and password that I have verified on my WG602v1.

http://www.securityfocus.com/archive/1/365230

Ummm... WRONG! Account name and password changed with new firmware.

http://www.securityfocus.com/archive/1/365230

Account name got changed to superman with a new password and yes, my AP is vulnerable to this new account. Which leads to question, why the account in the first place?

Like this one?

Not a separate computer, just a separate service. If you're running a public DNS service, you really should allow only recursive or authoritative queries. If you must service both, have the authoritative service listen on a 127.0.0.x IP and have the recursive one query that for the domain in question. But unless you're an ISP, there's really not a good reason to have your public nameserver handle recursive queries.

Here's a bit more discussion of why it's a good idea to split your DNS. But like I said, it doesn't have to be a separate computer, just a different interface :-)

That's what I call a secure DNS server!

I've been following this on BugTraq. As others in this discussion have pointed out, it's not that big a deal, since most people turn the firewall on. There's also an interesting post about someone who bought a few of them and checked whether the firewall was enabled by default--it turns out that two of the three units he tested came with the firewall enabled.

Much more terrifying, though, is the fact that Netgear WG602 Access Points have a default admin account that can't be turned off, with the username "super" and the password "5777364". So expect anyone on the WLAN/LAN to be able to own your router if you have this product and enable the admin interface.

I've been following this on BugTraq. As others in this discussion have pointed out, it's not that big a deal, since most people turn the firewall on. There's also an interesting post about someone who bought a few of them and checked whether the firewall was enabled by default--it turns out that two of the three units he tested came with the firewall enabled.

Much more terrifying, though, is the fact that Netgear WG602 Access Points have a default admin account that can't be turned off, with the username "super" and the password "5777364". So expect anyone on the WLAN/LAN to be able to own your router if you have this product and enable the admin interface.

I have made the effort to grab three additional units, all v2 hardware, off-the-shelf, and here is what I have found: Two of three units came with the firewall enabled, while one of the three came with it disabled. The packaging leaves no evidence as to whether any of these items were previously opened and returned.

Interestingly, all three units from local resalers came with v2.02.2 firmware, while the second unit from CDW I tested in March came with v2.02.7. BOTH of the units which came off-the-shelf with v2.02.7 behaved as previously described in my original notice; I do not have records of the firewall setting of the units from March, although they both did behave as predicted after a factory reset.

I would like to assume that the one-of-three v2.02.2 firmware units which came with the firewall disabled was an anomoly, and possibly a customer return. Nicely, flashing these units to v2.02.7 retains all settings, including the firewall status.

Now the catch. In v2.02.7 with the firewall disabled and remote admin turned off, the admin page becomes available on ports 80 and 443 on the WAN. This works whether the unit is in DHCP or PPPoE mode.

Port State Service
80/tcp open http
443/tcp open https
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20

So part of the original notice is valid, with the exceptions noted. I don't have any more v2.02.2 units to test as they have all now been flashed with v2.02.7, I have no more unmolested v2.02.7, and I am out of petty funds to purchase more :)

So, I will eat some crow on the original notice. To sum up, the admin page is most definitely available to the WAN if the firewall is disabled, regardless of the remote admin setting. And at best the potential for getting a unit off-the-shelf with this behavior is somewhat like an Easter egg hunt. I have received an even mix of responses positive and negative to the original notice, so others are reproducing this OTS.

Some thoughts...

It could be resonable that units which come v2.02.2 OTS then flash to v2.02.7 may not experience this behavior due to stored factory settings from original v2.02.2 system carried over to v2.02.7. That would explain the exception of the OTS behavior of the v2.02.7 units received in March.

Now I am also aware that other LinkSys items I have received have come with firmwares not yet available on the website -- most recent example, a WPS54GU2 which came with firmware 6032 while only 6031 was available on the website. It may be more reasonable that since the firmware v2.02.7 is dated March 17, my order for the WRT54G was placed on March 23, maybe a pre-release of the firmware? I cannot imagine that there would be such a diverse distribution of this product direct from LinkSys?

I have made the effort to grab three additional units, all v2 hardware, off-the-shelf, and here is what I have found: Two of three units came with the firewall enabled, while one of the three came with it disabled. The packaging leaves no evidence as to whether any of these items were previously opened and returned.

Interestingly, all three units from local resalers came with v2.02.2 firmware, while the second unit from CDW I tested in March came with v2.02.7. BOTH of the units which came off-the-shelf with v2.02.7 behaved as previously described in my original notice; I do not have records of the firewall setting of the units from March, although they both did behave as predicted after a factory reset.

I would like to assume that the one-of-three v2.02.2 firmware units which came with the firewall disabled was an anomoly, and possibly a customer return. Nicely, flashing these units to v2.02.7 retains all settings, including the firewall status.

Now the catch. In v2.02.7 with the firewall disabled and remote admin turned off, the admin page becomes available on ports 80 and 443 on the WAN. This works whether the unit is in DHCP or PPPoE mode.

Port State Service
80/tcp open http
443/tcp open https
Remote operating system guess: Linux Kernel 2.4.0 - 2.5.20

So part of the original notice is valid, with the exceptions noted. I don't have any more v2.02.2 units to test as they have all now been flashed with v2.02.7, I have no more unmolested v2.02.7, and I am out of petty funds to purchase more :)

So, I will eat some crow on the original notice. To sum up, the admin page is most definitely available to the WAN if the firewall is disabled, regardless of the remote admin setting. And at best the potential for getting a unit off-the-shelf with this behavior is somewhat like an Easter egg hunt. I have received an even mix of responses positive and negative to the original notice, so others are reproducing this OTS.

Some thoughts...

It could be resonable that units which come v2.02.2 OTS then flash to v2.02.7 may not experience this behavior due to stored factory settings from original v2.02.2 system carried over to v2.02.7. That would explain the exception of the OTS behavior of the v2.02.7 units received in March.

Now I am also aware that other LinkSys items I have received have come with firmwares not yet available on the website -- most recent example, a WPS54GU2 which came with firmware 6032 while only 6031 was available on the website. It may be more reasonable that since the firmware v2.02.7 is dated March 17, my order for the WRT54G was placed on March 23, maybe a pre-release of the firmware? I cannot imagine that there would be such a diverse distribution of this product direct from LinkSys?

"OSI is currently looking for nominations for the Q3 awards to be announced at OSCON."

If the operators at TMI had known about the Davis-Besse incident they might have recognized the situation and let the plant take care of itself.

Which Davis-Besse incident are you referring to? The stuck valve incident? The corrosion incident? Or the Slammer incident? Is there a lemon law for nuclear reactors? How about for energy companies?

:w

Security focus provided the following good explanation:

"...Grsecurity is a suite of patches (distributed as a single patch file) for the Linux kernel that are an attempt to improve the security of a Linux system. Grsecurity is based on a port of some previous patches for the Linux 2.2 kernel, including Openwall and PaX, which have never been ported to the 2.4 kernel. Grsecurity provides some updates to these patches and has been ported to the Linux 2.4 kernel..." continue reading SecurityFocus's review.

http://www.securityfocus.com/cgi-bin/sfonline/colu mnists-item.pl?id=215

Although I haven't read the Cringley article, I agree more or less with your assessment of the situation. SecurityFocus.com had a story on VoIP security issues and whether it was worth it for a business to take on the increased responsibility of not only securing their data network, but also their voice network. (Because in essence that responsibility shifts from the Baby Bell to you when you go to VoIP.) The general findings of that article was that VoIP was great, but not without some big risks and time and money spent maintaining such a phone network.

I don't think the Baby Bells will ever disappear, just like the RIAA won't ever disappear. Let's just vote for Congress critters that will be balanced in their voting and not swing wildly to one special interest or the other.

"The problem is that Secunia is entirely wrong. The removal of runscript left users less vulnerable. The exploit was much worse than any of the others, and even if it weren't, it is different, so the users are not just as vulnerable, because that exploit is removed (for those who updated)."

No, they are not "entirely wrong" they are absolutely right. The "fix" from Apple simply removed the Help Viewer ability to launch AppleScripts remotely, but did absolutely nothing to fix the parent exploit being the fact that any disk image can be mounted with the disk:// protocol, and that any application contained within automatically gets its custom protocol handlers assigned to it - silently. It just got worse with the ssh:// remote exploit able to execute proxy commands locally. Combine this with a recently discovered but as yet undisclosed email HTML handling vulnerability and it starts to get even worse.

As for Apple being "fairly responsive" I see absolutely no evidence that they were not notified on 23rd February as the original researcher wrote.

That's a clever idea, and it might even work.

Seriously, who lowered the bar this far. Since when is blocking the port such an awesome and creative idea? Maybe their automation is something to talk about but come on.. why does cnet pat itself on the back every time someone publishes something obvious.

They aren't the only ones though. (Patent office). The same thing happens all over the net. For instance remember the vulnerability that security focus screamed about a few weeks ago? The "vulnerability" is a function of any CSMA/CA system that anyone with a cursory understanding of the protocol would recognize. Why is this a "new" vulnerability?
Again, the "internet is going to crash" stuff about tcp sequence windows; All of this stuff is obvious to anyone who read the RFC. To me that seems a bit different than finding an obscure overflow, or unpublished error. Finding obvious aspects of a protocol is not.

My opinion is that it's part of the "alarm" mentality that we seem to love, and that the press jumps all over. But I'm curious what other opinions on the subject are.

That's a clever idea, and it might even work.

Seriously, who lowered the bar this far. Since when is blocking the port such an awesome and creative idea? Maybe their automation is something to talk about but come on.. why does cnet pat itself on the back every time someone publishes something obvious.

They aren't the only ones though. (Patent office). The same thing happens all over the net. For instance remember the vulnerability that security focus screamed about a few weeks ago? The "vulnerability" is a function of any CSMA/CA system that anyone with a cursory understanding of the protocol would recognize. Why is this a "new" vulnerability?
Again, the "internet is going to crash" stuff about tcp sequence windows; All of this stuff is obvious to anyone who read the RFC. To me that seems a bit different than finding an obscure overflow, or unpublished error. Finding obvious aspects of a protocol is not.

My opinion is that it's part of the "alarm" mentality that we seem to love, and that the press jumps all over. But I'm curious what other opinions on the subject are.

Isn't this the story line for some cheap porno film??

Oh yeah, ETTERCAP. I guess it's scarier if you put it in all CAPS, isn't it?

First of all, if you can't see a difference in security between any schmuck being able to sniff all your packets without any possibility of being found out, and an extremely dedicated attacker carefully crafting ARP replies to maybe get traffic from *one* machine that's not meant for him...

I guess I should give up. You should change places - you should go get yourself some banannas, and your shaved monkey should take over for you at the keyboard.

Also, perhaps you've heard of the concept of "Port Security". Or perhaps it's occured to you that ARPwatch will send me an e-mail if a mac and ip association changes? Or perhaps you haven't a clue?

Here's a link, not that you'll read it.

Seriously, why did you come back for more?

Considering the speed improvements in both the interpreters for these languages, and general processors, I'm suprised more network services (smtp, web, ftp) aren't being written either entirely in these languages, or with a mixture of scripting and native C modules for the areas that need better performance.

There's a few examples that I've seen out there that already do this, like Zope and Aolserver (i think). Of course, this approach may only eliminate one type of vulnerability, and still leaves other things like these that appeared for Zope at the beginning of the year.

Microsoft can learn a lesson here? Especially in the light of this hole, from which a spammer can clearly see that you have opened their messages and validate your address...

Both parent posts are pretty much right, but you should *definitely check that you're complying with the law* regarding what you must keep.

I'd recommend reading this paper over at SecurityFocus as it covers a pretty similar remit: Destructive Influence By Scott Granneman

Basically what he says is that if you have a thoroughly designed and well implemented data destruction policy (that complies with local laws) it can be somewhat favorable should something bad, like a lawsuit, come your way.

First: You say don't install third party software, so you're really advocating for monopoly. Sure, there exists crap 3rd party software, but the OS should be able to protrect itself such that the system is not rendered unbootable.

Second: His main 2nd point is still valid, regardless of what forced the reinstall. Inability to fetch updates fast enough to avoid being hit by a worm attack, the inability to resume fetch, the inability fetch a cd image, etc. all makes it a pain to get the system up to date. It is a huge problem to maintain and update a vulnerable system when securityexperts claim that an unprotected pc will by hit by Sasser within aproximately 10 minutes.

Why is rpc on by default, on a stand alone machine? Ok, for interprocess communication - but only on the loopback interface!

Microsoft has sold an 'insecure by default' product for years, while they should follow a 'secure by default' philosophy: Disable all services by default. The main reason that windows is so widespread (still) is that this is what the home user knows, and hence companies saves money on training. If MS wants to stay in Buisness they should protect the home user - and the home user does not need all the services enabled by default.

Also, they would isolate kernel space and user space such that your system can boot and fetch updates, regardless of how many user space programs you install and deinstall. Only the OS should mess around in the kernel space.

Again and again people loose data and time because they inadvertendly do something that appears inocent everyday action, but tampers their system and renders it unuseable.

If you could at least get the system up to get backups - ofcourse it's always weeks ago - before you go on to reinstall, you might actually get as far as live (painfully) with the remaining problems.

Maintaining Windows is a pain, in particular for the average Joe.

I've never personally used it, but I've noticed what seemed to be a large number of security issues found in the product at a time when I was doing a security audit of a system that was using it.

That's not to say that the other CMS systems don't have their own security problems, and I know the couple that I've written probably had their own issues, but I didn't pull a Matt Wright [of FormMail fame] and go distributing crappy software all over the place, either.

Nuke Security seems to have some information about securing various versions of PHPNuke.

There may be moral issues with using illegally-made copies of proprietary software (it artificially reduces the perceived TCO of the software in comparison with competitors like free software, for example) but it's certainly not stealing.

You can find more information here, or by using a search engine.

Seem to depend on the state and the various software involved.

Odd that absolutely none of them mention that debug privlidges are required...

No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.

I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.

I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.

There are many many more that I could have gone through and listed...

Odd that absolutely none of them mention that debug privlidges are required...

No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.

I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.

I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.

There are many many more that I could have gone through and listed...

Odd that absolutely none of them mention that debug privlidges are required...

No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.

I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.

I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.

There are many many more that I could have gone through and listed...

Odd that absolutely none of them mention that debug privlidges are required...

No, I'd say 1 can be considered a DoS, the rest are privlidge escalation.

I have to disagree. There are some inherent problems with the NT design. Sure, most problems are implimentation issues, but there are certainly several design flaws as well.

I can't agree with that. If something must be run in kernel mode, it should be considered part of the kernel.

There are many many more that I could have gone through and listed...