Paid Advertising
web application security lab

Nukecops Attempts To Shut Down

First of all I appologize to my existing readers. I never meant for this site to be non-technical (far from it). However, yesterday I got an email that really needs to be dealt with on this blog. So for this entire post I am going to keep this as non-technical as possible as to prove a useful tool to point people to when they find themselves with web application vulnerabilities. Yesterday, attempted to shut down

It all started on September 28th at 11PM PST when Ghozt disclosed a POST cross site scripting vulnerability in While Ghozt has been a member of the web application security forums for a while, he is not an administrator of the website. On the 29th we recieved this email forwarded to us by our upstream provider (forgive the formatting - it’s gone through a number of forwards):

whois indicates you are hosting the server at

A user is using this server in an attempt to exploit our server through the file

It is likely that they will continue to use this and attempt to hack other servers. This is a violation of your Acceptable Use Policy as stated here:

We hope you will remove this user and ban him from your service.

———- Forwarded message
———-Date: Sep 29, 2006 2:59 AM
Subject: Blocked abuse from
Date & Time: 2006-09-29
08:59:05 CEST GMT +0200
Blocked IP:
User ID: Anonymous (1)
Reason: Abuse-Filter——————–
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20060909 Firefox/
Query String:<script+src=http://ha.ckers
Get String:<script
Post String:
Forwarded For: none
Client IP: none
Remote Address:
Remote Port: 38026
Request Method: GET

– Evaders99 Webmaster of http://www.SWRebellion.comSWCIC - NukeCops admin -

Now for my retort: 1) I wish Evaders99 had emailed us directly, as I could have explained the whole thing. 2) Ghozt is not an administrator of this website as you can see on the about us page. 3) The file was bothered by is a flat piece of JavaScript, with nothing dynamic about it whatsoever. 4) Although the vector may not be benign the payload is (it cannot actually cause harm by stealing user accounts, credentials or otherwise). It’s only designed to show the security auditor that the vector was successful. 5) This site cannot go down by simply talking to our ISP - we make enough money we can host it anywhere (yes, even overseas). 6) This is simply the worst way to deal with a security vulnerability in your software. 7) I’ve never once been to prior to this email being sent to our upstream (even when Ghozt disclosed the issue).

I had thought after the fallout with Acunetix and F5, companies would wise up. But let me start by explaining my view on why this site exists. It’s a personal tale, but I think it’s one worth telling. I’ve been working on security for the last 12 years. That’s a lifetime in the security space. In that time I’ve seen countless security holes and countless ways to mitigate those holes (build a better firewall, or apply a patch and poof, you’re secure). For the first time in my life, I really don’t know how to solve these issues. Not from my own perspective, but from that of two people I happen to care about - my own parents.

My father is pretty tech savvy, but he’s by no means a security expert. My mom is more of the type who is happy she figured out how to send email at all. Years ago I spent a great deal of time trying to figure out the best advice I could give my parents to protect themselves. I did the obvious stuff - bought them a nice firewall, got anti-spyware and anti-virus installed and locked down their machines a little. But at the end of the day, anyone on this list knows that’ll do nothing against XSS. I thought about telling them to surf without JavaScript or switching their browser or otherwise crippling their computers, but at the end of the day it just would mean I’d be their tech support every time they wanted to send a JavaScript e-card to another family member and it wouldn’t work.

So I gave them the best advice I possibly could that I knew would stick. I told them to not open any spam they recieved. That is the single greatest conduit they have for getting malware on their system. They are not the type to go surfing around random places on the internet, or downloading pirated software or otherwise visiting the darker parts of the net. However, they ARE likely to visit their banks, or stock pages, or bulletin boards about their hobbies. In the end, for as smart as they are, they are also great candidates for XSS credential theft, or otherwise having their identities stolen. There’s nothing I can do to protect them that 0.1% of the time they are in danger that wouldn’t make the other 99.9% of their web surfing experience worse.

As a consumer (not of but of websites in general) I have some recourse - I am capable of defending myself. My parents and the millions of other people just like them have no such resources at their disposal. They are at the mercy of the software vendors whose products they use as well as the companies websites that they visit. Having worked in security for so long, I know companies are resistant to change unless it’s motivated by their pocketbook. What the forums have done is raise awareness to the public eye that the problem isn’t just about throwing up a JavaScript popup on a website, but of how the entire fabric of the internet is now exposed and getting worse as every new developer publishes their pet project without security review.

No one is perfect at application security, and the point of the full disclosure list is not to out companies, per se. It’s to raise awareness of the issue and get people thinking about how the attacks work in real life, as well as how to mitigate those attacks. All this for the eventual purpose of protecting those people who don’t have the means to do so themselves. This is a web application security lab. We run tests. We gather data. We report on that data. I’m not out stealing people’s credentials, their data or their livelihoods. That’s not my style. There are better ways to make money.

What I, and the others on the web application security forums are attempting to do is explain to companies where their holes are, and we are finding out a great deal of information by aggregating it all into one place. So much so, that at least two great findings have come directly from the posts that people have made and the research that goes into finding these issues. is not special. In fact, I don’t even consider them an especially interesting target. No, they aren’t good at security, and they are even worse at mitigating the risks, but they aren’t any different than any of the other sites. Frankly, if I never hear the word “PHPNuke” again in my life I’d be a happy man.

I hate to bring up the Visa redirect issue again (I find it annoying to call people out for their mistakes when they make good on them), but I was so impressed by them that I think it’s worth mentioning once more. From start to finish the issue was disclosed, they verified the hole, and fixed it all within 30 minutes. Not only that but they forwarded the users to an anti-phishing page to help educate them. That’s exactly the right way to deal with the issues. Fix them and move on. Protect your consumers by taking responsibility for your website and fixing the known issues as expeditiously as possible, not by shutting down the single greatest repository for the information on how to protect them from those very same holes.

The problem with XSS is that each hole I find (with only a few very rare exceptions) is ridiculously easy to fix if you look at it under a microscope. The problem is that fixing one issue won’t stop any bad guy from looking for the other one that wasn’t fixed. So without proper tools to locate and diagnose every hole on the Internet, the best we can do is catalogue the cross site scripting vectors, and discuss mitigation concepts. The only way to do that is to proactively find issues in real web applications by testing their filters for real world mitigation circumvention. Additionally, I poke at every browser for how they interact with websites for the possibility of finding ways in the browsers themselves to protect users or new holes that need further consideration.

No, I don’t work in security - I do this out of my own interest in it. I don’t directly benefit from it. In fact it is very difficult to run this site. I do it for my parents. I do it for your parents. I do it for the millions of consumers who make up the financial future of the Internet that we all use. I know the futility in the concept, as there will always be security holes, but by shutting me up you are only making that problem worse - not better. The holes don’t go away when people like Ghozt don’t have a place to post them, all it does is lessen the pressure on websites like to take responsibility. And who knows, without a place to post, perhaps out of frustration, he or others would resort to more malicious activity after having been ignored once too many times - having lacked a proper constructive outlet.

So even as I put Evaders99 on my list of people who clearly don’t “get” it, there is still hope for him and other people like him to take the correct approach and solve their issues and protect us as consumers. This doesn’t mean they need to issue a press release, they simply need to fix their own known issues so people like my parents can use the Internet without risking their financial security in doing so.

12 Responses to “Nukecops Attempts To Shut Down”

  1. maluc Says:

    Ah, well said .. and the hole still exists sadly. However, it worked once. when i tried it the second time two minutes later i get this:

    If they were able to filter out these requests and IP ban them.. i can’t imagine why they haven’t just filtered >

  2. RSnake Says:

    I guess it’s not a real time IPS, but lagged…. that’s not fixing a hole, that’s simply closing it down from the user who clicked on it once from clicking on it twice.

    Anyway, it’s not about the hole, which I think is pretty ho-hum, it’s about the disclosure and their reaction to it. Hopefully this opens some eyes.

  3. id Says:


  4. WhiteAcid Says:

    Depressing isn’t it? *sigh*
    Out of curiosity, I wonder if that error is prone to XSS via the user agent, which can be foracbly changed using flash.

  5. id Says:

    You know, it can only be exploited by the one guy you blocked, no no, really.


  6. maluc Says:

    well crap, it cut off the rest of my comment after typing %.3.C unencoded.. and i don’t feel like rewriting it

    and oddly enough, i’m not banned.. i guess its meant to scare people away?

    but yes, that’s a terrible way to handle the situation [insert poignant argument here]


  7. maluc Says:

    and you might want to back up the site to be on the safe side .. assuming you don’t do so regularly already. ISPs are not always known for their intelligent reactions either..

  8. The Teklow Group » Blog Archive » Nukecops Attempts To Shut Down Says:

    […] Last week posters on RSnake’s forum found XSS problems in the sites of vendors F5 and Acunetix. A silent fix on both sites was followed by a lot of discussion and both vendors denying there ever were any problems to begin with. Now that, in itself, is neither good disclosure nor a good way to inspire trust in your web vulnerability scanner. Just fix it, admit it and learn from it, you’ll get a lot more kudos for it in the end. Some people just have to go the extra mile though and now is actually trying to get shut down over the posting of a similar issue in their site. […]

  9. alf. Says:

    great article, rsnake
    keep on your good work here on this page =)

  10. id Says:

    No worries Maluc, I own the server, it’s safe and secure in my closet. And (our provider) are cool, they sent a very resonable message after they checked out the complaint simply stating that they didn’t see a violation of the AUP, but that I might want to check it out. I have in the past, and continue to, recommend them as an ISP in California.

  11. Guardian Says:

    I see your first retort is;
    “I wish Evaders99 had emailed us directly, as I could have explained the whole thing”

    Was that out of professional courtesy?

    Perhaps you could have emailed the website owners before looking for vulnerabilities?

    Script vulnerabilities are a definite issue and any site owner would work with you I’m sure to resolve the sort of issues you are trying to uncover.

  12. RSnake Says:

    Well, Guardian, perhaps I would have had I been the one to do the test in the first place, however I wasn’t. Should I email every company in the world just in case someone decides to include a benign peice of my JavaScript on their page?

    “any site owner would work with you I’m sure to resolve the sort of issues you are trying to uncover” That’s incorrect as any implies all, and I’ve definitely not found that to be true in my own experience. Some would, but as I said, I didn’t audit his website, it was someone else so it would be them working together, not me working with them - I had nothing to do with this other than we were almost taken offline for hosting benign JavaScript and being called within a test.