[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [suse-security] Re: Backdoor over http(s)??



So,

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 
the update??

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.

Tibor



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
> questions.
> 
> > 
> > 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:
> 
> 218.234.171.84 - From where the files are downloaded
> 163.17.51.8    - 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 163.17.51.8 will be the address that the 
application
> 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 218.234.171.84 is just a storage location for the 
> files. If this is correct then both machines are the origin, however 
> the 163.17.51.8 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://218.234.171.84/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
> JavaScript or something. Just because the file ends in .c, does not mean
> that it is a 'real' c file.
> 
> > 
> > > The rest of the files:
> > > 
> > > httpREMOVE://218.234.171.84/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
> > > > > 218.234.171.84 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