RE: [suse-security] Re: Backdoor over http(s)??
-----Original Message----- From: Tobias Weisserth [mailto:tobias@weisserth.de] Sent: Tuesday 13 January 2004 04:04 PM To: suse-security@suse.com 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@suse.com Security-related bug reports go to security@suse.de, 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.
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@weisserth.de] Sent: Tuesday 13 January 2004 04:04 PM To: suse-security@suse.com 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@suse.com Security-related bug reports go to security@suse.de, 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@suse.com Security-related bug reports go to security@suse.de, not here
Hi Mátyás, Am Die, den 13.01.2004 schrieb Mátyás Tibor um 17:46:
So,
my machine is a SuSE 8.2, with firewall (Shorewall), chkrootkit, tripwire, etc.
What does your tripwire log say? Shorewall isn't too useful in this case because when a daemon (like apache) that is allowed to receive connections from the outside has a weakness this is beyond any firewall. As for chkrootkit: you simply cannot rely on it when it uses executables on your system to determine whether it is compromised. Imagine there is a rootkit on your machine and it simply exchanges the system tools chkrootkit uses with modified versions? You may want to mount some live CD like Knoppix and use its unmodified chkrootkit along with the unmodiefied binaries from the clean Knoppix CD.
I check for updates fast every day(..)
Which doesn't affect software like PHPNuke which you didn't install via yast. Yast can only update those packages maintained by SuSE.
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??
The latest kernel bug was a local one and required a local account to exploit it.
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....
You can't be sure since chkrootkit kind of depends on a clean system to say it's clean. See above.
/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.
If you want to have reliable results with tripwire in the future you'll have to reinstall cleanly ;-) kind regards, Tobias
Hi again, Am Die, den 13.01.2004 schrieb Tobias Weisserth um 18:18: ...
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....
You can't be sure since chkrootkit kind of depends on a clean system to say it's clean. See above.
This is from the chkrootkit FAQ: ************************* Which commands does chkrootkit use? The following commands are used by the chkrootkit script: awk, cut, echo, egrep, find, head, id, ls, netstat, ps, strings, sed, uname ________________________________________________________________________ Can I trust these commands on a compromised machine? Probably not. We suggest you follow one of the alternatives below: 1. Use the `-p path' option to supply an alternate path to binaries you trust: # ./chkrootkit -p /cdrom/bin 2. Mount the compromised machine's disk on a machine you trust and specify a new rootdir with the `-r rootdir' option: # ./chkrootkit -r /mnt ************************** cheers, Tobias
Hello Mark, Am Die, den 13.01.2004 schrieb Retallack, Mark (Siemens) um 17:27:
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.
Ah. I didn't notice there are two machines involved here. Is there a way to find out who is running those machines and send along a message to shut down one of them so that this scriptkiddy has to look for another victim?
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.
Which requires another remote exploit. So when I don't run dynamic content on my webserver and the yast online update installs the latest fixes automated every night, the risk should be marginal, right?
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).
[fun]I'm bored. Let's DOS that machine list! :-)[/fun] Seriously. When such a "hack" can be traced back by simply looking into network traffic and source code why are folks not going after those machines or their owners?
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.
That's what I was wondering about... if maybe you already found some malicious content behind that URL.
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.
The name suggests some 13 year old script kiddy though ;-) kind regards, Tobias
Hi Well, actually the 218-machine has an open smtp-port, and accepts whatever You can imagine.. I sent already a message to "all" there about these findings... And the domain where this IP is, is somewhere in far-east, at least what I can tell about the bird-feet chars that comes up there... Jaska. Tobias Weisserth kirjoitti viestissään (lähetysaika Tiistai 13. Tammikuuta 2004 18:52):
Hello Mark,
Am Die, den 13.01.2004 schrieb Retallack, Mark (Siemens) um 17:27:
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.
Ah. I didn't notice there are two machines involved here. Is there a way to find out who is running those machines and send along a message to shut down one of them so that this scriptkiddy has to look for another victim?
<SNIP>
218.234.171.84 - From where the files are downloaded
Korea - not sure what it is but whois returns some useful information along with a whole lot of korean stuff: IP Address : 218.234.170.0-218.234.171.255 Network Name : HANANET-HIGHBAN-PUSANINFORMATION Connect ISP Name : HANANET [ Organization Information ] Orgnization ID : ORG251097 Org Name : PUSANINFORMATION State : PUSAN Address : 364-5 DEOKPO2-DONG SASANG-GU Zip Code : 617-815 [ Admin Contact Information] Name : YONGSU JEONG Org Name : PUSANINFORMATION State : PUSAN Address : 364-5 DEOKPO2-DONG SASANG-GU Zip Code : 617-815 Phone : +82-51-303-7575 Fax : +82-51-303-7575 E-Mail : jys@hananet.net [ Technical Contact Information ] Name : YONGSU JEONG Org Name : PUSANINFORMATION State : PUSAN Address : 364-5 DEOKPO2-DONG SASANG-GU Zip Code : 617-815 Phone : +82-51-303-7575 Fax : +82-51-303-7575 E-Mail : jys@hananet.net
163.17.51.8 - Where the application connects to when it is run on the
Taiwan Academical (Script kiddies?) inetnum: 163.17.0.0 - 163.17.255.255 netname: TANET descr: Taiwan Academic Network descr: Ministry of Education computer Center descr: 12F, No 106, Sec. 2, Heping E. Rd., Taipei country: TW admin-c: TA61-AP tech-c: TA61-AP mnt-by: MAINT-TW-TWNIC changed: hostmaster@twnic.net.tw 20030620 address: Ministry of Education computer Center address: 12F, No 106, Sec. 2, Heping E. Rd., Taipei address: Taipei Taiwan country: TW phone: +886-2-2737-7010 ext. 305 fax-no: +886-2-2737-7043 e-mail: tanetadm@moe.edu.tw nic-hdl: TA61-AP mnt-by: MAINT-TW-TWNIC changed: hostmaster@twnic.net 20020507 source: APNIC May be worth dropping some emails to the technical contacts - The advantage of it being academical they may be more interested in keeping their networks clean. Regards Hubba
Hello Hubertus, There is more. If you take a closer look into that big zipped file, then you'll also find those: 195.147.204.250 203.141.167.9 199.106.212.3 203.121.0.13 203.121.0.8 192.115.8.147 148.233.173.86 195.8.0.234 202.192.196.6 61.251.131.241 kind regards, Tobias
I sent an email to the technical contact of the IP the domain resolves to. The abuse address listed in the arin lookup bounces (shocking). I urge everyone to contact the admins at this domain and ask them to fix their problem. When you have an admin who ignores abuse complaints (especially rootkits),...well, the closest comparison I can make is that it's like sending your kids to school with infectios diseases--only complete jackasses do that. On Tue, 13 Jan 2004, Tobias Weisserth wrote:
Hello Hubertus,
There is more. If you take a closer look into that big zipped file, then you'll also find those:
195.147.204.250 203.141.167.9 199.106.212.3 203.121.0.13 203.121.0.8 192.115.8.147 148.233.173.86 195.8.0.234 202.192.196.6 61.251.131.241
kind regards, Tobias
-- -linux_lad ICQ 115601915 pub key on request
Retallack, Mark (Siemens) wrote:
...
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).
...
I agree that rs.c is used to get a shell on the "remote" computer, probably then to exploit some local root weakness. However, rs.c does not produce rhs, I tried and it's the wrong size. Can't tell if it produces ".do", I don't care to try on my machine. :-) This is definitely an injection type attack (stating the obvious here aren't I? :-) If you do a wget on the dir, you get an index.html back that shows others files there, including a couple of text files (i.txt, ii.txt) and a coupld of perl files (r.pl, do.pl) with other IP addresses in them (other than the ones listed in this thread). Not sure yet what they're trying to inject this into. All very interesting... I've never had a chance to see how this sort of thing is done before. Kevin
participants (7)
-
-linux_lad -
Hubertus Haniel -
jaska -
Kevin Brannen -
Mátyás Tibor -
Retallack, Mark (Siemens) -
Tobias Weisserth