Security Incidents mailing list archives
Re: Tracking down the still infected hosts
From: Ryan Russell <ryan () securityfocus com>
Date: Tue, 25 Sep 2001 15:01:10 -0600 (MDT)
Below is the relevent code section, the one that checks the result of the HTTP requests. Earlier in the code, it will bail out of it can't connect to you at all, and won't bother trying any more attacks against that IP. If it is every able to complete a connect, it sends an HTTP request, and stores the results in a buffer. It passes the buffer to the proc shown below. If the results were "200" or "502", then it thinks it has found a vulnerable box, and it sends the tftp command to download admin.dll. Any other result will cause it to try the next attack string. So, unless I'm reading the code wrong, the only way to get it to "leave you alone" is to not answer requests to port 80. Question for the people who are experiencing a decline when using a redirect.. does your network listener "fork", or the Windows equivalent? If not, the next connect attempt would fail, which will also cause your IP to be given up on. I suspect replying with "go away" would work just as well as a redirect in that scenario. Anything that acts like a real web server will keep the requests coming. Ryan .text:361732F5 check_http_result proc near ; CODE XREF: http_scan+12Cp .text:361732F5 ; http_scan+266p .text:361732F5 .text:361732F5 attack_result = dword ptr 4 .text:361732F5 .text:361732F5 mov eax, [esp+attack_result] .text:361732F9 mov cl, [eax+9] ; HTTP replies look like: .text:361732F9 ; HTTP/1.1 404 Not Found .text:361732FC cmp cl, 32h ; 2 .text:361732FF jnz short check_502 ; 5 .text:36173301 cmp byte ptr [eax+0Ah], 30h ; 0 .text:36173305 jnz short check_502 ; 5 .text:36173307 cmp byte ptr [eax+0Bh], 30h ; 0 .text:3617330B jz short return_1 .text:3617330D .text:3617330D check_502: ; CODE XREF: check_http_result+Aj .text:3617330D ; check_http_result+10j .text:3617330D cmp cl, 35h ; 5 .text:36173310 jnz short return_0 .text:36173312 cmp byte ptr [eax+0Ah], 30h ; 0 .text:36173316 jnz short return_0 .text:36173318 cmp byte ptr [eax+0Bh], 32h ; 2 .text:3617331C jnz short return_0 .text:3617331E .text:3617331E return_1: ; CODE XREF: check_http_result+16j .text:3617331E push 1 .text:36173320 pop eax .text:36173321 retn .text:36173322 ; --------------------------------------------------------------------------- .text:36173322 .text:36173322 return_0: ; CODE XREF: check_http_result+1Bj .text:36173322 ; check_http_result+21j ... .text:36173322 xor eax, eax .text:36173324 retn .text:36173324 check_http_result endp .text:36173324 ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
Current thread:
- RE: Tracking down the still infected hosts, (continued)
- RE: Tracking down the still infected hosts Fulton L. Preston Jr. (Sep 24)
- RE: Tracking down the still infected hosts Ryan McDonnell (Sep 25)
- Re: Tracking down the still infected hosts Kyle R. Hofmann (Sep 25)
- Re: Tracking down the still infected hosts Tina Bird (Sep 25)
- Re: Tracking down the still infected hosts Skip Carter (Sep 25)
- Re: Tracking down the still infected hosts Kyle R. Hofmann (Sep 25)
- Re: Tracking down the still infected hosts Dale Lancaster (Sep 25)
- Re: Tracking down the still infected hosts Duncan Hill (Sep 25)
- Re: Tracking down the still infected hosts Josh Burroughs (Sep 25)
- Message not available
- Re: Tracking down the still infected hosts Nicole Haywood (Sep 25)
- RE: Tracking down the still infected hosts Fulton L. Preston Jr. (Sep 24)
- Re: Tracking down the still infected hosts Ryan Russell (Sep 25)