新手园地& & & 硬件问题Linux系统管理Linux网络问题Linux环境编程Linux桌面系统国产LinuxBSD& & & BSD文档中心AIX& & & 新手入门& & & AIX文档中心& & & 资源下载& & & Power高级应用& & & IBM存储AS400Solaris& & & Solaris文档中心HP-UX& & & HP文档中心SCO UNIX& & & SCO文档中心互操作专区IRIXTru64 UNIXMac OS X门户网站运维集群和高可用服务器应用监控和防护虚拟化技术架构设计行业应用和管理服务器及硬件技术& & & 服务器资源下载云计算& & & 云计算文档中心& & & 云计算业界& & & 云计算资源下载存储备份& & & 存储文档中心& & & 存储业界& & & 存储资源下载& & & Symantec技术交流区安全技术网络技术& & & 网络技术文档中心C/C++& & & GUI编程& & & Functional编程内核源码& & & 内核问题移动开发& & & 移动开发技术资料ShellPerlJava& & & Java文档中心PHP& & & php文档中心Python& & & Python文档中心RubyCPU与编译器嵌入式开发驱动开发Web开发VoIP开发技术MySQL& & & MySQL文档中心SybaseOraclePostgreSQLDB2Informix数据仓库与数据挖掘NoSQL技术IT业界新闻与评论IT职业生涯& & & 猎头招聘IT图书与评论& & & CU技术图书大系& & & Linux书友会二手交易下载共享Linux文档专区IT培训与认证& & & 培训交流& & & 认证培训清茶斋投资理财运动地带快乐数码摄影& & & 摄影器材& & & 摄影比赛专区IT爱车族旅游天下站务交流版主会议室博客SNS站务交流区CU活动专区& & & Power活动专区& & & 拍卖交流区频道交流区
空间积分0 信誉积分1637 UID阅读权限50积分4435帖子精华可用积分4451 专家积分0 在线时间1905 小时注册时间最后登录
小富即安, 积分 4435, 距离下一级还需 565 积分
帖子主题精华可用积分4451 专家积分0 在线时间1905 小时注册时间最后登录
论坛徽章:0
错误你们不也看到了吗?
math and technology is my lover.
空间积分0 信誉积分222 UID阅读权限50积分3296帖子精华可用积分3296 专家积分0 在线时间451 小时注册时间最后登录
小富即安, 积分 3296, 距离下一级还需 1704 积分
帖子主题精华可用积分3296 专家积分0 在线时间451 小时注册时间最后登录
论坛徽章:0
就是没这个文件存在
空间积分0 信誉积分149 UID阅读权限50积分4340帖子精华可用积分4340 专家积分0 在线时间110 小时注册时间最后登录
小富即安, 积分 4340, 距离下一级还需 660 积分
帖子主题精华可用积分4340 专家积分0 在线时间110 小时注册时间最后登录
论坛徽章:0
就是文件不存在呗
拉不紧的窗帘
空间积分0 信誉积分1362 UID阅读权限100积分39146帖子精华可用积分39146 专家积分0 在线时间17655 小时注册时间最后登录
帖子主题精华可用积分39146 专家积分0 在线时间17655 小时注册时间最后登录
论坛徽章:4
我还以为有别的什么原因，原来就是文件不存在……
Crosstool 交叉编译工具链：
男性it民工
空间积分805 信誉积分5310 UID1730385阅读权限100积分238908帖子精华可用积分198353 专家积分563 在线时间22979 小时注册时间最后登录
帖子主题精华可用积分198353 专家积分563 在线时间22979 小时注册时间最后登录
认证徽章论坛徽章:346
& & 楼主的错误很奇怪,/users不知道是怎么出来的
好读书,不求甚解;每有会意,便欣然忘食
非淡泊无以明志，非宁静无以致远。
空间积分1 信誉积分1324 UID491441阅读权限100积分27089帖子精华可用积分27107 专家积分68 在线时间5492 小时注册时间最后登录
帖子主题精华可用积分27107 专家积分68 在线时间5492 小时注册时间最后登录
论坛徽章:1
& & 打错了呗。
甲午耻，犹未雪。国人恨，何时灭。驾长车，踏破富士山缺。壮志饥餐日虏肉，笑谈渴饮倭奴血。待从头，收拾旧山河，朝天阙。
我累了，想睡觉
男性it民工
空间积分805 信誉积分5310 UID1730385阅读权限100积分238908帖子精华可用积分198353 专家积分563 在线时间22979 小时注册时间最后登录
帖子主题精华可用积分198353 专家积分563 在线时间22979 小时注册时间最后登录
认证徽章论坛徽章:346
但是楼主的命令里面看不出有输入错误啊.
好读书,不求甚解;每有会意,便欣然忘食
非淡泊无以明志，非宁静无以致远。
拉不紧的窗帘
空间积分0 信誉积分1362 UID阅读权限100积分39146帖子精华可用积分39146 专家积分0 在线时间17655 小时注册时间最后登录
帖子主题精华可用积分39146 专家积分0 在线时间17655 小时注册时间最后登录
论坛徽章:4
他执行了那么多命令，怎么忘记了pwd？
Crosstool 交叉编译工具链：
空间积分0 信誉积分149 UID阅读权限50积分4340帖子精华可用积分4340 专家积分0 在线时间110 小时注册时间最后登录
小富即安, 积分 4340, 距离下一级还需 660 积分
帖子主题精华可用积分4340 专家积分0 在线时间110 小时注册时间最后登录
论坛徽章:0
这个问题好诡异啊……路径怎么变那样了
北京皓辰网域网络信息技术有限公司. 版权所有 京ICP证:060528号 北京市公安局海淀分局网监中心备案编号：
广播电视节目制作经营许可证(京) 字第1234号
中国互联网协会会员&&联系我们：
感谢所有关心和支持过ChinaUnix的朋友们
转载本站内容请注明原作者名及出处江苏电信中兴阉割猫zxa10 f460 3.0破解 CP: db_backup_cfg.xml，提示 No such file or directory ，谢谢_百度知道
江苏电信中兴阉割猫zxa10 f460 3.0破解 CP: db_backup_cfg.xml，提示 No such file or directory ，谢谢
等待您来回答
下载知道APP
随时随地咨询
出门在外也不愁Linux/HackingTeamRDorks.A, a “new” and improved version of Linux/CDorked.A - 推酷
Linux/HackingTeamRDorks.A, a “new” and improved version of Linux/CDorked.A
Disclaimer:
This malware sample is not in any way related to Hacking Team (as far as I know) other than me making some jokes about them related to a future presentation about their OS X malware product.
Two months ago (maybe three) I started noticing a sporadic redirect when I accessed this blog pages. It wasn’t anything malicious as far as I just a redirect to adult friend finder site. A friend did some initial research on the site pages and content and could not find anything relevant there, other than a very old Zen encoded backdoor (LOL!). I also poked around the database contents and it appeared clean. Having read about some recent Linux rootkits injecting iframes and that kind of stuff I was convinced the shared server had been hacked. Other tasks were calling for my attention and so this matter got sidetracked.
Last week some readers started complaining about the redirects and it was finally time to find out what was really happening. I asked my great hosting friends at
to give me r00t and find the problem. My instinct was right and I found out a new variant of Linux/CDorked.A that made headlines beginning of 2013. Unfortunately I have no idea how the breach started but I bet in a local root exploit (server was running KSplice). Shared servers are a pain to manage with all kinds of vulnerable scripts being installed.
For some background on Linux/CDorked.A you should have a look at the following articles:
The two warning signs are a modified httpd binary linked against the open_tty symbol and a shared memory segment 6118512 bytes long. This server httpd binary had no signs of compromise and that specific shared memory segment did not exist. Running the ipcs command revealed a very suspicious shared memory, slightly bigger than the one mentioned in those articles and detection tools.
sh-4.1# ipcs -m
------ Shared Memory Segments --------
0x01006cab
&- the backdoor segment
0x00000a6a
A CPanel support technician was also poking around the server and recompiled Apache. He declared victory because the redirect wasn’t happening anymore. Too soon my friend! The next day the redirect was still active and this time I was sure the httpd binary wasn’t modified – I stored the checksums so I could compare them. Ok, we have some mistery here. Something is definitely being injected into httpd server& but the binary is not modified (in the filesystem). It could be either a kernel rootkit (Crowdstrike’s analysis of such rootkit
), an Apache module, or something else. Under these assumptions my first task was to gather a memory dump and analyse with Volatility. Nothing suspicious was found in the kernel side so I temporarly ruled out the kernel rootkit hypothesis. Apache has support for
so this would be a good spot for injection and my next step. I did some brief tracing into this but couldn’t find anything. Keep in mind this was a live server with many hits so I needed to be careful to avoid downtime. Goold old habits from managing the Portuguese ATM network.
Next hypothesis: assuming the httpd binary is ok at disk, is the binary in memory is the same?
Time to memory dump httpd binary. Volatility had some problems finding the original binary using linux_find_file command. I could dump individual segments but that is a mess to analyse in IDA.
How the hell do you (easily) dump a full binary in Linux? I left Linux 5 years ago! Hum… let’s core dump httpd. The first time it worked ok and I got the core dump to load in IDA. Later I tried again and this time it failed.
sh-4.1# gcore 74765
core.JgKHE6:4: Error in sourced command file:
(deleted)/usr/local/apache/bin/httpd: No such file or directory.
gcore: failed to create core.74765
Now this is a good clue& for what is happening here. It might explain some of the Volatility issues finding the httpd process (this is something I have to try later, if deleted binaries can fool Volatility analysis). Let’s take a look at procfs to see what’s happening:
sh-4.1# ls -la /proc/456404/
dr-xr-xr-x
6 root root 0 Feb
dr-xr-xr-x 358 root root 0 Oct
9 16:35 ..
-r--------
1 root root 0 Feb
2 18:00 auxv
-r--r--r--
1 root root 0 Feb
2 18:00 cgroup
--w-------
1 root root 0 Feb
2 18:00 clear_refs
-r--r--r--
1 root root 0 Feb
1 19:08 cmdline
-rw-r--r--
1 root root 0 Feb
2 18:00 coredump_filter
-r--r--r--
1 root root 0 Feb
2 18:00 cpuset
lrwxrwxrwx
1 root root 0 Feb
2 18:00 cwd -& /
-r--------
1 root root 0 Feb
2 18:00 environ
lrwxrwxrwx
1 root root 0 Feb
1 19:09 exe -&
(deleted)/usr/local/apache/bin/httpd
dr-x------
2 root root 0 Feb
2 04:09 fd
dr-x------
2 root root 0 Feb
2 18:00 fdinfo
The original binary has been deleted! Definitely a good clue to understand why the httpd binary checksums are always ok. Let’s look at the memory map and verify the inode information:
sh-4.1# cat /proc/456404/maps
39000 r-xp
fd:00 3277341
(deleted)/usr/local/apache/bin/httpd
45000 rw-p
fd:00 3277341
(deleted)/usr/local/apache/bin/httpd
4a000 rw-p :00 0
01a00 rw-p :00 0
04e00 rw-p :00 0
We can use debugfs to poke at that inode and recover the original binary! This
is a good reference on how to do this. The first time I tried this I could not find the original binary, it was overwritten by some other file. Meanwhile I had noticed some strange behavior by httpd:
sh-4.1# ps aux | grep htt
0.2 129792 35792 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.1 128528 32196 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 129704 32644 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 129932 33984 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 130056 35088 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 131812 35864 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 130236 35440 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 130464 34500 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 130192 34236 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.0 103232
0:00 grep htt
sh-4.1# ps aux | grep httpd
0.2 129828 35832 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.1 128564 32188 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 129876 32780 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137940 34880 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 139968 36876 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 140196 37068 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 139320 36260 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137812 34768 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137812 34384 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 139292 36112 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137404 34092 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137548 34140 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137812 34356 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137412 34088 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137808 34344 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.2 137412 34000 ?
0:00 /usr/local/apache/bin/httpd -k start -DSSL
0.0 103236
0:00 grep httpd
After I restarted Apache, minutes later it would be restarted again and this time the original binary would show up deleted. My hypothesis here was a cron job responsible for reloading the trojaned httpd binary. Verified all the cron jobs and nothing suspicious was found. I made an assumption that there was a twice an hour reload of the backdoor but this was wrong as I will explain later on. At this point I just needed to restart Apache, wait for the backdoor to be activated, and immediately recover the trojaned binary. Got the binary, load into IDA and compare with the Linux/CDorked.A sample. Bingo, it’s very similar. The functions names are not the same (hashes like names in known variant, single letter names on this one) but the code is very similar – have a look at “ap_read_request” Apache function, which is where the backdoor has its modified code to filter requests.
Next big question: how is the trojaned binary started and where it is in the filesystem? At this point I knew something is executed after the legit Apache is restarted, replaces it with a trojaned version and restores the original file.
What is the easiest way to detect this? Trace the process activity! I have some very cool tricks in OS X to do this (other than DTrace) but had no idea what was new in this area in Linux. A quick web search got me into this
. It has a small example of a process tracer using netlink proc events. I gave it a try and it was good enough for this purpose.
Now I could see a strange incoming ssh connection executing commands and after that the trojaned Apache was running. Modified the code sample to something that dumps the binary being executed and its command line parameters. Code sample availablehere. Other solutions such as ttysnoop and so on could have been used. I wanted to disrupt as less as possible the server.
This allowed me to easily find out what was happening. Here is a sample output of an older version of the modified tracer utility (not the whole chain of commands, just a few selected ones):
now: 2014-1-31 11:21:43
PID: 181941 uid: 0 gid: 0
181941 cmdline:/usr/sbin/sshd-R
exec: tid=181941 pid=181941 /usr/sbin/sshd
fork: parent tid=181941 pid=181941 -& child tid=181942 pid=181942
gid change: tid=181942 pid=181942 from 74 to 74
uid change: tid=181942 pid=181942 from 74 to 74
fork: parent tid=37151 pid=37151 -& child tid=181943 pid=181943
exit: tid=181943 pid=181943 exit_code=0
exit: tid=181942 pid=181942 exit_code=0
fork: parent tid=181941 pid=181941 -& child tid=181944 pid=181944
now: 2014-1-31 11:21:50
PID: 181944 uid: 0 gid: 0
181944 cmdline:bash-cecho GOOD
exec: tid=181944 pid=181944 /bin/bash
fork: parent tid=181944 pid=181944 -& child tid=181945 pid=181945
fork: parent tid=181945 pid=181945 -& child tid=181946 pid=181946
now: 2014-1-31 11:21:50
PID: 181946 uid: 0 gid: 0
181946 cmdline:whoami
exec: tid=181946 pid=181946 /usr/bin/whoami
exec: tid=181964 pid=181964 /bin/bash
fork: parent tid=181964 pid=181964 -& child tid=181965 pid=181965
now: 2014-1-31 11:21:51
PID: 181965 uid: 0 gid: 0
181965 cmdline:/usr/bin/md5sum/usr/local/apache/bin/httpd/usr/sbin/arpd
exec: tid=181965 pid=181965 /usr/bin/md5sum
now: 2014-1-31 11:21:53
PID: 181978 uid: 0 gid: 0
181978 cmdline:cp-a/usr/bin/s2p /tmp/X3Cm2rXtncgR7scn_m.tmp
exec: tid=181978 pid=181978 /bin/cp
now: 2014-1-31 11:21:53
PID: 181980 uid: 0 gid: 0
181980 cmdline:mv-f/tmp/X3Cm2rXtncgR7scn_m.tmp/usr/local/apache/bin/httpd
exec: tid=181980 pid=181980 /bin/mv
now: 2014-1-31 11:21:53
PID: 181981 uid: 0 gid: 0
181981 cmdline:/bin/sh/sbin/servicehttpdstop
exec: tid=181981 pid=181981 /bin/bash
now: 2014-1-31 11:22:0
PID: 182017 uid: 0 gid: 0
182017 cmdline:cp-a/usr/sbin/arpd /tmp/X3Cm2rXtncgR7scn_m.tmp
exec: tid=182017 pid=182017 /bin/cp
now: 2014-1-31 11:22:0
PID: 182018 uid: 0 gid: 0
182018 cmdline:mv-f/tmp/X3Cm2rXtncgR7scn_m.tmp/usr/local/apache/bin/httpd
exec: tid=182018 pid=182018 /bin/mv
now: 2014-1-31 11:22:0
PID: 182019 uid: 0 gid: 0
182019 cmdline:touch-r/usr/sbin/arpd /usr/local/apache/bin/httpd
exec: tid=182019 pid=182019 /bin/touch
now: 2014-1-31 11:22:0
PID: 182020 uid: 0 gid: 0
182020 cmdline:/usr/sbin/tunelp -r/usr/sbin/arpd /usr/local/apache/bin/httpd
exec: tid=182020 pid=182020 /usr/sbin/tunelp
An incoming sshd connection stops the original Apache, copies over the trojaned version, starts it again, and replaces again the trojaned binary with the original copy. Three foreign binaries are installed in the filesystem, all three ending in space to hide in plain sight:
“/usr/bin/s2p “, the trojaned httpd.
“/usr/sbin/arpd “, the original httpd.
“/usr/sbin/tunelp “,
to restore time of original apache.
sh-4.1# ls -la /usr/sbin/arp*
-rwxr-xr-x
1 root root
42704 Nov 23 21:26 /usr/sbin/arpd
-rwxr-xr-x
1 root root 1501046 Jan 29 17:37 /usr/sbin/arpd
sh-4.1# ls -la /usr/sbin/tunelp*
-rwxr-xr-x 1 root root 12536 Nov 24 18:58 /usr/sbin/tunelp
-rwxr-xr-x 1 root root 10648 Nov 24 18:58 /usr/sbin/tunelp
sh-4.1# ls -la /usr/bin/s2p*
-rwxr-xr-x 2 root root
53325 Nov 24 14:32 /usr/bin/s2p
-rwxr-xr-x 1 root root 1546321 Nov 24 14:32 /usr/bin/s2p
This made easy to find out the remote IP where the ssh connection was coming from, 41.77.114.49, located in Morocco. You probably want to add this IP to your firewall(s) rules :-).
Next question: how is the sshd connection happening?
I started by disabling the different authentication methods in sshd configuration. One curious detail is that if you disable PermitRootLogin the remote login will fail. Someone forgot to patch that i-). Sshd logs didn’t reveal much about what was happening so the system logger or sshd were obviously patched. Enabling DEBUG3 mode in sshd logging only got this output:
Jan 31 17:51:31 sr71 sshd[240566]: debug3: fd 5 is not O_NONBLOCK
Jan 31 17:51:31 sr71 sshd[240566]: debug1: Forked child 240955.
Jan 31 17:51:31 sr71 sshd[240566]: debug3: send_rexec_state: entering fd = 8 config len 647
Jan 31 17:51:31 sr71 sshd[240566]: debug3: ssh_msg_send: type 0
Jan 31 17:51:31 sr71 sshd[240566]: debug3: send_rexec_state: done
Jan 31 17:51:31 sr71 sshd[240955]: debug3: oom_adjust_restore
Jan 31 17:51:31 sr71 sshd[240955]: Set /proc/self/oom_score_adj to -1000
Jan 31 17:51:31 sr71 sshd[240955]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jan 31 17:51:31 sr71 sshd[240955]: debug1: inetd sockets after dupping: 3, 3
Jan 31 17:51:31 sr71 sshd[240955]: Connection from 41.77.114.49 port 54399
After connection from line there was no logging related to this connection, which was obviously a strong indicator something was wrong with sshd or syslogd. The RPMs signatures appeared to be ok for both. Another web search revealed some clues about the potential sshd backdoor:
Again the mentioned clues could not be found in the library installed in the system, although its size was twice as big versus the version in a clean system. To find out if this was true, I attached gdb to sshd process and waited for the backdoor connection. I had a breakpoint in the logging function and traced it. Voil&,& __syslog_chk was hooked and redirect into libkeysutils.so.1.3 library. This is an upgraded sshd rootkit version.
sh-4.1# ls -la /lib64/libkeyutils.so*
lrwxrwxrwx 1 root root
2012 /lib64/libkeyutils.so.1 -& libkeyutils.so.1.3
-rwxr-xr-x 1 root root 35320 Jun 22
2012 /lib64/libkeyutils.so.1.3
sh-4.1# rpm -qf /lib64/libkeyutils.so.1.3
keyutils-libs-1.4-4.el6.x86_64
sh-4.1# rpm -V keyutils-libs-1.4-4.el6.x86_64
This time the strings are obfuscated and function pointers are hijacked instead of the usual inline hooking. A sample list of hooked symbols from a memory dump:
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,connect in section .text of /lib64/libc.so.6
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,__syslog_chk in section .text of /lib64/libc.so.6
0x7f,write in section .text of /lib64/libc.so.6
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,No symbol matches $ptr.
0x7f,MD5_Init in section .text of /usr/lib64/libcrypto.so.10
0x7f,MD5_Update in section .text of /usr/lib64/libcrypto.so.10
0x7f,MD5_Final in section .text of /usr/lib64/libcrypto.so.10
0x7f,PEM_write_RSAPrivateKey in section .text of /usr/lib64/libcrypto.so.10
0x7f,PEM_write_DSAPrivateKey in section .text of /usr/lib64/libcrypto.so.10
0x7f,hosts_access in section .text of /lib64/libwrap.so.0
0x7f,refuse in section .text of /lib64/libwrap.so.0
0x7f,SHA1 in section .text of /usr/lib64/libcrypto.so.10
0x7f,MD5 in section .text of /usr/lib64/libcrypto.so.10
0x7f,sysconf in section .text of /lib64/libc.so.6
0x7f,mprotect in section .text of /lib64/libc.so.6
0x7f,waitpid in section .text of /lib64/libc.so.6
0x7f,fork in section .text of /lib64/libc.so.6
0x7f,exit in section .text of /lib64/libc.so.6
0x7f,tmpfile@@GLIBC_2.2.5 in section .text of /lib64/libc.so.6
0x7f,shmget in section .text of /lib64/libc.so.6
0x7f,shmat in section .text of /lib64/libc.so.6
0x7f,shmdt in section .text of /lib64/libc.so.6
0x7f,dlinfo in section .text of /lib64/libdl.so.2
0x7f,dlopen@@GLIBC_2.2.5 in section .text of /lib64/libdl.so.2
0x7f,getsockname in section .text of /lib64/libc.so.6
0x7f,socket in section .text of /lib64/libc.so.6
0x7f,bind in section .text of /lib64/libc.so.6
0x7f,getnameinfo in section .text of /lib64/libc.so.6
0x7f,getpeername in section .text of /lib64/libc.so.6
0x7f,gethostbyname in section .text of /lib64/libc.so.6
0x7f,send in section .text of /lib64/libc.so.6
0x7f,sleep in section .text of /lib64/libc.so.6
0x7f,getenv in section .text of /lib64/libc.so.6
0x7f,geteuid in section .text of /lib64/libc.so.6
0x7f,inet_ntoa in section .text of /lib64/libc.so.6
0x7f,ssignal in section .text of /lib64/libc.so.6
0x7f,siglongjmp in section .text of /lib64/libc.so.6
0x7f,__sigsetjmp in section .text of /lib64/libc.so.6
0x7f,BIO_new_mem_buf in section .text of /usr/lib64/libcrypto.so.10
0x7f,BIO_free in section .text of /usr/lib64/libcrypto.so.10
0x7f,PEM_read_bio_RSAPublicKey in section .text of /usr/lib64/libcrypto.so.10
0x7f,RSA_public_decrypt in section .text of /usr/lib64/libcrypto.so.10
0x7f,RSA_free in section .text of /usr/lib64/libcrypto.so.10
0x7f,__res_query in section .text of /lib64/libresolv.so.2
0x7f,__res_state in section .text of /lib64/libc.so.6
And a quick IDC script to deobfuscate the XOR’ed strings:
#include &idc.idc&
auto start, end;
auto xor1, xor2;
auto a, b;
start = 0x;
xor1 = 0x253882E;
xor2 = 0x39FD3C83;
ea = start;
while (ea &= end)
PatchDWord(ea, Dword(ea) ^ xor1);
PatchDword(ea+4, Dword(ea+4) ^ xor2);
ea = ea + 8;
Message(&End!\n&);
The RSA public key found inside the library (used to login?):
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAO9KdhaD9i6C8DdK4a1KFLwc7FvqdKPpw+qTZU2rMBFr1ZuSQavMdm++
K6yhjdEmI0k9e3g8GLGn62tFPMBKALCiakkAGcIFoHk+eyMGY6KEiZP4/st/PBFK
J7mBB0HOJHjMxZIrlgIGWEc8LzDWQK5m2/8gWvOBfNSmDprWKI49AgMBAAE=
-----END RSA PUBLIC KEY-----
The code for the syslog hook:
And a screenshot of the startup code of the library where it deobfuscates the XOR’ed strings and calls dlsym to solve the to be hooked symbols addresses:
The final question other than how the initial breach was made, is how the remote sshd connection is signaled. The backdoor tries to stay low profile by having a delay between the restart of legit httpd and the backdoor version. It is annoying when you try to test some hypothesis – you need to wait for the restart, which usually takes around 10 to 15 minutes. I haven’t reversed this part but my assumption is that httpd signals the remote system when it is started. This is because the backdoored library& is also linked in httpd so it appears to me to be a good assumption. This is the reason why I initially assumed there was a twice an hour cron job.
This new version tries to fix some of the flaws of the previously found sample by encoding strings and keeping a clean httpd binary in the system. The problem is that it also leaves important clues when it tries to hide its tracks. The logging and deleted binaries are very good clues that something wrong is happening in the system, and good starting points to understand and track the trojaned binaries. Delayed operations are an effective old malware trick to delay and frustrate a bit the analysis.
I am leaving here all the binaries in case in want to reverse it and maybe find some additional interesting facts. I did not look up at the shared memory segment. It should be very similar to previous sample. I am not posting a copy of it because there might be some private information inside it.
This was a fun adventure! I stopped using Linux five years ago when I left my position at
. Chasing rookits is as much fun as writing them :-).
What else is new? I left
(a big thank you to everyone there, in particular to Thomas, one of the greatest in this industry) and joined
. We are developing what I hope to be some nice products to help in the malware war. The OS X version is advancing pretty fast and I hope it will be the best in the market. Aim high or fail, middle g-).
I think this briefs most of the important details about this backdoor. I will update this post in case I missed something. The binaries are below so feel free to poke around.
Sample binaries:
(Password is: infected!)
Signature:
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQEcBAABAgAGBQJS8msAAAoJEAADGo6F9Uj3t2cH/jJR1uqfhBK4biTaHuZvjP6Y
ZZfdwCZZh264kxu2doLsrVU3qEdceHqUevKkA9Zo3tHBlA+e3T5nXIA2z/DTKzMs
VIct+MR9mvhRtAEWZ7krhUuSd3+HAm2Vb+gAiy3KzjmEw33Luox0FYQvLoCjU3qD
0CTaE61naeUBFivwQYsDyoHFNYqFnTCYpCzG6a1cO31ITj8JZhSSHMoOLNuj7Ljq
R2LHGZLBU1n7eRKscVGP1qV8S91qQNkAmamN1x5AKVrFZnGSkn9US23Rzu0lsc6Z
cyW3pmAxQ24/giSz6pjUS75aPAmLD50QJwwz82VHc2Mnf4b6m8+TErWqn7SRxPQ=
-----END PGP SIGNATURE-----
已发表评论数()
&&登&&&陆&&
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见}