Re: Tracking down the still infected hosts

From: Ryan Russell (ryanat_private)
Date: Tue Sep 25 2001 - 14:01:10 PDT

  • Next message: Duncan Hill: "Re: Tracking down the still infected hosts"

    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
    



    This archive was generated by hypermail 2b30 : Tue Sep 25 2001 - 14:15:23 PDT