[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [suse-security] Re: Backdoor over http(s)??
my machine is a SuSE 8.2,
with firewall (Shorewall), chkrootkit, tripwire, etc.
I check for updates fast every day(..)
My SuSE runs since 7 days with the newest kernel (and patches).
I don't know to much about the latest kernelbug, maybe was I too slow with
To be shure, I got a new chkrootkit tarball, but the machine is clean.
Nothing is corrupted in /etc /var /usr /lib /bin /dev /root /sbin etc....
/srv ?? I don't check it with tripwire. Maybe in the future I should.
I have made a grep for wget in cgi-bin/ --> nothing.
On Tue, 13 Jan 2004 16:27:40 -0000, Retallack, Mark (Siemens) wrote
> > -----Original Message-----
> > From: Tobias Weisserth [mailto:tobias@xxxxxxxxxxxx]
> > Sent: Tuesday 13 January 2004 04:04 PM
> > To: suse-security@xxxxxxxx
> > Subject: RE: [suse-security] Re: Backdoor over http(s)??
> > Hi Mark,
> > I'm not sure I can follow everything concerning this issue. Maybe you
> > could clarify this somehow so that a n00b liek me can follow ;-)
> I am afraid that I am a nOOb as well, but I will try to answer the
> > Am Die, den 13.01.2004 schrieb Retallack, Mark (Siemens) um 16:20:
> > > It looks like the source was left on the server (along with
> > other things):
> > Is this just another compromised machine or the origin? A
> > portscan shows
> > several open ports and the machine seems to be a Solaris 8 with an
> > estimated uptime of 33 days according to nmap.
> As far has I can tell there are 2 IP address that we have:
> 126.96.36.199 - From where the files are downloaded
> 188.8.131.52 - Where the application connects to when it is run on
> the compromised machine.
> If you assume that the rs.c source file is contains the code for the
> rhs/.do application then 184.108.40.206 will be the address that the
> connects to on the internet and opens a shell for the remote hacker
> to use.
> >From looking at the code, it is not a worm/virus type of application, it
> requires a human to infect the destination computer.
> I think that 220.127.116.11 is just a storage location for the
> files. If this is correct then both machines are the origin, however
> the 18.104.22.168 computer is the more important one because it is the
> one that the hacker would use to communicate to the compromised
> machine (directly or via a proxy of some sort).
> > > httpREMOVE://22.214.171.124/manual/.x/rs.c
> > >
> > > Only follow the link if you know what you are doing (and
> > remove the REMOVE
> > > text)
> > I don't quite understand why displaying rs.c in a browser window could
> > be harmful or am I missing something here and this URL initiates
> > something else inside the browser?
> No real reason. I just like to be paranoid, just in case the file contains
> that it is a 'real' c file.
> > > The rest of the files:
> > >
> > > httpREMOVE://126.96.36.199/manual/.x/
> > I've given them a look. Has anybody ever heard of a "pokemon squadron
> > hacking team"?!
> Not me. I did notice the name in the html file. Google does not give
> any information ether.
> > > > > Some CGI at your webserver did run wget to receive some
> > file from
> > > > > 188.8.131.52 and save it on your disc as "/tmp/.do".
> > Do you know how this CGI ended up on the machine? By some
> > Apache exploit
> > maybe?
> Not sure, I don't know much about apaches. It does look like an
> exploit. The best think to do is check for patch updates from SuSE
> and Apache. And if that fails, the apache message board.
> > > > > wwwrun:nogroup are standard user and group used for apache.
> > Can such a CGI do any harm by running as this user? Or are CGI scripts
> > run by Apache given initiated by another user?
> Any "foot in the door" is a foot in the door. So Although the script
> should not have access to the important sections of the computer
> (for example fstab, passwd, etc..), this is why it is important to
> run services in non-root mode. But the script might allow the hacker
> to find other security holes. A bit like an onion, lots of layers
> that can be removed if given enough time.
> > kind regards,
> > Tobias
> > --
> > Check the headers for your unsubscription address
> > For additional commands, e-mail: suse-security-help@xxxxxxxx
> > Security-related bug reports go to security@xxxxxxx, not here
> Siemens Traffic Controls is a division of Siemens plc. Registered No.
> 727817, England.
> Registered office: Siemens House, Oldbury, Bracknell, Berkshire,
> RG12 8FZ.
> This communication contains information which is confidential and
> may also be privileged. It is for the exclusive use of the
> addressee. If you are not the addressee please note that any
> distribution, reproduction, copying, publication or use of this
> communication or the information in it is prohibited. If you have
> received this communication in error, please contact us immediately
> and also delete the communication from your computer.
> Check the headers for your unsubscription address
> For additional commands, e-mail: suse-security-help@xxxxxxxx
> Security-related bug reports go to security@xxxxxxx, not here
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help@xxxxxxxx
Security-related bug reports go to security@xxxxxxx, not here