I Love You Virus

I Love You Virus

• LoveLetter is a Win32-based e-mail worm. It overwrites certain files on your hard drive(s) and sends itself out to everyone in your Microsoft Outlook address book.

• LoveLetter arrives as an email attachment named: LOVE-LETTER-FOR-YOU.TXT.VBS though new variants have different names including VeryFunny.vbs, virus_warning.jpg.vbs and protect.vbs

LoveLetter was found globally in the wild on May 4th, 2000. At the beginning of the code, the virus contains the following text:

rem barok -loveletter(vbe) 
rem by: spyder / ispyder@mail.com / @GRAMMERSoft Group / Manila,Philippines 

VBS/LoveLetter is a VBScript worm. It spreads over email as a chain letter. The worm uses the Outlook e-mail application to propagate. Additionally, LoveLetter is also an overwriting VBS virus, and spreads itself using mIRC client. When executed, it copies itself to the Windows system directory as: MSKernel32.vbs / - LOVE-LETTER-FOR-YOU.TXT.vbs and to Windows directory as Win32DLL.vbs. Afterwards, it adds itself to the registry, so that it is executed when the system is rebooted. The worm also replaces the Internet Explorer home page with a link that points to an executable program "WIN-BUGSFIX.exe". If the file is downloaded, the worm adds this to registry, causing the program to be executed when the system is restarted.

Threat

The executable part that the LoveLetter worm downloads from the web is a password stealing Trojan. On startup the Trojan tries to find a hidden window named 'BAROK...' If present, the Trojan exits immediately, otherwise, the main routine takes over. The Trojan checks for the WinFAT32 subkey in the following Registry key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

If the WinFAT32 subkey key is not found, the Trojan creates it, copies itself to the Windows system directory as WINFAT32.EXE and then executes the file from there. The above registry key modification activates the Trojan every time Windows starts. The Trojan sets Internet Explorer startup page to 'about: blank'. Later, the Trojan tries to find and delete the following keys:

Software\Microsoft\Windows\CurrentVersion\Policies\Network\HideSharePwds
Software\Microsoft\Windows\CurrentVersion\Policies\Network\DisablePwdCaching
.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Policies\Network\HideSharePwds
.DEFAULT\Software\Microsoft\Windows\CurrentVersion\Policies\Network\DisablePwdCachin
g

The Trojan proceeds to register a new window class and creates a hidden window titled 'BAROK...' and remains resident in the Windows memory as a hidden application. After startup when the timer counters reaches certain value, the Trojan loads MPR.DLL library, calls WNetEnumCashedPasswords function and sends stolen RAS passwords and all cached Windows passwords to 'mailme@super.net.ph' e-mail address. The Trojan uses the 'smpt.super.net.ph' mail server to send e-mails. The e-mail's subject is 'Barok... email.passwords.sender.trojan'.

There is the author's copyright message inside the trojan's body:

barok ...i hate go to school suck ->by:spyder @Copyright (c) 2000 GRAMMERSoft Group
>Manila,Phils.

There is also some encrypted text messages in the Trojan's body used for its internal purposes. After that, the worm creates a HTML file, "LOVE-LETTER-FOR-YOU.HTM", to the Windows System directory. This file contains the worm, and it will be sent using mIRC whenever the user joins an IRC channel. The worm will then use Outlook to mass mail itself to everyone in each address book. The message that it sends will be as follows:

Subject: ILOVEYOU
Body: kindly check the attached LOVELETTER coming from me.
Attachment: LOVE-LETTER-FOR-YOU.TXT.vbs

LoveLetter sends the mail once to each recipient. After a mail has been sent, it adds a marker to the registry and does not mass mail itself any more.

The virus then searches for certain filetypes on all folders on all local and remote drives and overwrites them with its own code. The files that are overwritten have either "vbs" or "vbe" extension. For the files with the following extensions: ".js", ".jse", ".css", ".wsh", ".sct" and ".hta", the virus will create a new file with the same name, but using the extension ".vbs". The original file will be deleted.

Next the the virus locates files with ".jpg" and ".jpeg" extension, adds a new file next to it and deletes the original file. Then the virus locates ".mp3" and ".mp2" files, creates a new file and hides the original file. For above two cases, the new files created will have the original name added with the extension ".vbs". For example, a picture named "pic.jpg" will cause a new file called "pic.jpg.vbs" to be created.

What is SQL Insertion Vulnerability?

• User Controlled Data is placed into an SQL query without being validated for correct format or embedded escape strings.

• Affects majority of applications which use a database backend and don't force variable types.

• At least 50% of the large e-commerce sites and about 75% of the medium to small sites are vulnerable.

• Improper validation in CFML, ASP, JSP and PHP are the most frequent causes.

The Slammer worm targets versions of Microsoft SQL Server 2000 products, as well as MSDE 2000 and related packages. The outbreak began on 25 January 2003 (GMT). According to early reports, the worm had a very significant presence around the world in less than one hour, and the peak time of the worm lasted for about three hours. During the worm's initial outbreak, Internet users experienced large percentage packet drops that developed into a large-scale DoS attack.

Threat

The worm exploits a stack-based overflow that occurs in a DLL implementing the SQL Server Resolution Service. This DLL (ssnetlib.dll) is used by the SQL Server service process called SQLSERVR.EXE. The vulnerability had been reported to Microsoft by David Litchfield (NGSSoftware), along with a few others. Furthermore, exploit code was made available at a BlackHat conference in 2002 and it is clear that this code was used as a base from which to develop the worm.

Exploit Setup

The SQL Server process listens on TCP as well as UDP ports. The worm targets U DP port 1434, sending a special request (0x04) specified as the first character of the payload. In the datagram this is followed by a specially crafted 'string' that contains the worm code. The worm code is 376 bytes, which is the shortest binary worm known today. (376 bytes is the length of the UDP datagram without the protocol headers.)

Since the worm can use a UDP packet for the attack, it is probable that the source IP address of the original attacker was spoofed. The worm spreads to randomly generated IP addresses and, as a result, it is very difficult to determine from which country the attack originated.

The vulnerable function in ssnetlib.dll (as implemented in SQL Server 2000) is nested two levels deep inside a thread associated with the incoming request. The function is supposed to build a string for a Registry access by concatenating three strings into a 128-byte buffer. This string will be built on the stack and there are no input validations for the size of the middle string parameter. Strings 1 and 3 are constant and located in the ssnetlib.dll.

(String 1) 'SOFTWARE\Microsoft\Microsoft SQL Server\'
(String 2) String passed in the datagram (starts after the 0x04 type field)
(String 3) '\MSSQLServer\CurrentVersion'

As a result, whenever a string that is too long is passed to the function, the stack is corrupted (smashed). String 2 is an SQL Server instance name. According to the Microsoft Knowledge Base this string should be 16 characters long at most. However, this is neither enforced in the server , nor even in some of the common clients.

The worm has been crafted carefully. Its code is not only compact but it contains no zeros. This is because the buffer is used as a string parameter to a sprintf () library function call. As a result of the overflow a concatenated string will build on the stack where string 2 is the worm body itself.

Getting Control

Since the worm cannot contain zeros the author uses a lot of 01 filler bytes. Furthermore, attempts are made to use addresses that do not contain any zeros and, in some cases, the code uses XOR to mask zero bytes, which is a known shell code technique.

The worm starts with a header posing as local variables of the buggy function. A new return address (0x42B0C9DC) follows these filler bytes. This address is a pointer to a JMP ESP instruction inside SQLSORT.DLL, another module of the SQL Server process.

To make sure the vulnerable function will give control to the worm body, the header section of the worm also uses dummy ('crash test dummies') values (0x42AE 7001) to replace function arguments on the stack. It is necessary to do this because these arguments are used after the call to sprintf () triggering the overflow. Failure to replace these arguments would cause an exception and thus the function would not return normally. When the function returns, control flows to the JMP ESP instruction which jumps on the stack to the location immediately after the hijacked return address. The first instruction will be a short jump around fake function arguments to the main worm code.

Initialization

The local variables within the worm header section could change during the time between the actual faulty sprintf () and the function return to the worm body, which means that the worm's header could become corrupted. Thus the worm will rebuild this area first to make sure that its header section remains constant for the next attack. Since the query type field (0x04) is missing from the top of the worm on the stack it is also rebuilt by pushing a 0x04000000 DWORD whose high byte is referenced by the replication code later.

Now the worm needs only a few functions to call. Following the original exploit code the worm's author uses the import address directory of SQLSORT.DLL to make calls to LoadLibraryA () and GetProcAddress () function calls. This routine is compatible with different Service Pack releases and patches of SQL Server. Therefore GetProcAddress ()'s code is checked first to be sure that it is the proper function entry point.

Then the worm gets access to the handles (base addresses) of WS2_32.DLL and KERNEL32.DLL. Next it gets the addresses of socket (), sendto () and GetTickCount () APIs, which is all it needs to replicate.

Replication

The replication method is extremely simple. The worm sends 376 bytes to UDP port 1434 to randomly generated IP addresses in an endless loop. This will cause the server CPU usage to increase and thousands of packets will be sent, effectively causing a DoS attack and at the same time compromising a large number of new systems around the world. The random number used to generate IP addresses is a variant of the Microsoft Basic random number generator. It uses the same multiplier. This results in sufficient randomness in the distribution of targeted systems.