危险漫步博客
新鲜的“黑客思维”就是从全新的角度看待黑客技术,从更高的层面去思考;专注于黑客精神及技术交流分享的独立博客。
文章2307 浏览21469912

记一次定点入侵

新手黑客是拿着扫描工具对准一个IP段狂扫一通,逮着哪个算哪个(漏洞啊、空/弱口令啊什么的),收效快且有不错的成就感;老鸟黑客则是针对某个特定的目标下手,可能是使用多个扫描器进行信息的收集,或者是用工具甚至手工检测是否存在注入点,最终可能极费周折找到后台登录进而拿下整站的最高权限。

掐指算来,自己接触“黑界”也有7个年头了,虽然各种黑客工具用了不少但总觉得自己离老鸟黑客还差一截——不能对特定目标直接打个漂亮的攻击战,于是特别想找个机会练练手。要不说机会总是给那些有准备的人留着呢,前些天,经朋友的朋友的介绍,让我为一个网站作一下友情检测,看看是否能拿下来。呵呵,正好手痒得很,开工!

一、首战失利

先在360浏览器中输入对方的网址粗略地看了下,还算漂亮,随便点击打开几条新闻看看,URL后缀基本上是“readnews.asp?newsid=15913”之类的形式,呵呵,不会有注入漏洞吧?要是有就省事多了,赶快拿出“啊D注入工具”,在“扫描注入点”中“注入连接”处粘贴上,然后点击后面的“检测”按钮。很快结果就出来了,郁闷,“啊D”居然提示“这个连接不能SQL注入!请试别的连接!”。不过别灰心,再试试“啊D”的“管理入口检测”吧,说不定会有惊喜呢!但很快我又失望了,虽然“啊D”扫描出两个“可用连接和目录位置”,但经过试验,一个是test.asp(估计是网管刚建站时的测试文件),一个是无效的“找不到IDQ文件.idq”。

二、再战又败

关掉“啊D”,再拿X-Scan,我就不信扫不出个“洞洞”来!先来设置扫描参数,将在命令行窗口下PING对方域名得到的IP地址(61.xxx.xxx.163)输入到“指定IP范围”,接着在“全局设置”中将“开放服务”、“NT-Server弱口令”以及“漏洞检测脚本”全部选中(“踩点”得到的信息越详细越好,定点扫描不怕慢,就怕得不到想要的,呵呵),然后将“跳过没有响应的主机”设置为“无条件扫描”,差不多了,点击“确定”按钮开始扫描。十多分钟的漫长等待过程之后,我得到了X-Scan的扫描报告,真是大失所望——X-San侦察到的信息是:开放的端口只有21、53和80,基本没戏;“漏洞数量”为0,用户名和空/弱口令一个也不存在。看来,对方还真不简单,防护非常到位,赞一个先!

三、遭遇bfpms

不过我当然不死心了,再试“流光”进行全方位扫描,结果与X-Scan基本上是大同小异,没得搞。难道,难道无路可走了么?算了,还是在人家网站上随便逛逛吧,说不定能发现些重要线索呢!于是,我开始有针对性地“浏览”该网站的各分支信息,也算是缓解一下自己的紧张心情。若干杯茶工夫之后,我发现该网站有一个“科技特派员”链接,打开之后看到风格跟目标主站比较相似但又不太一样(颜色都换了),呵呵,难道在此会有转机?是不是在一个IP地址上挂有多个网站呢?如果是的话也可以剑走偏锋进行曲线渗透啊!但经过PING命令测试后我发现二者的IP地址并不一样!不过,既然关系这么亲密,再加上目前似乎也实在是没什么路可走了,我何不拿这个来“跑跑路”呢?

仍然是先检查一下是否存在注入漏洞,直接点击主页“最新动态”中的一条新闻记录,弹出的新闻页面链接显示正常的内容。在它的后面添加“and 1=1”并回车,显示仍正常;再将“and 1=1”修改为“and 1=2”再次回车,这次虽然没直接提示出现什么什么错误,但是新闻的主体内容消失了——还是出现问题了。简单的手工测试之后,我得到了答案:这个分支网站存在注入漏洞!还等什么?上“啊D”啊!二次打开熟悉的界面,不用扫描注入点(原因后面奉上),直接在“SQL注入检测”的“注入连接”、中将刚才的新闻页面粘贴进去,然后点击后面的“检测”按钮;很快,“啊D”就检测出三个表段:“Manage User”、“user”和“book”;接着再点击后面的“检测字段”,出现“username”、“password”和“id”三项内容,呵呵,都是敏感度较高的字眼儿。三项全部选中后,继续点击后面的“检测内容”按钮,两分钟后,跑出来了:一个user是“admin”,password为“bfpms;79:<;@”;另一个user是“tiedan”,password为“Sc6f7i”。

重点当然是超级用户admin了,铁蛋”——tiedan恐怕是个测试账号吧?且慢,它的密码怎么这么BT呢?“bfpms;79:<;@”,一点儿也不好记啊!强度倒是可以,字母、数字加特殊符号,呵呵,12位呢!管它呢,直接在网站主页的最右下角点击一个名叫“管理进入”的按钮,还记得刚刚所说的不使用“啊D”进行注入点的扫描么?原因就在这几,根本用不着费劲去猜解后台地址,人家为了管理的“方便”已经明晃晃的把登录人口放在这儿了(网管切忌如此做啊!)。在弹出的“后台管理系统登陆”中,将“管理账号:”和“管理密码:”处分别填入“admin”和“bfpms;79:<;@”,然后信心(本文来自危险漫步博客)满满的“啪”地敲一下回车一一“登陆系统”!谁知,人家马上回敬一个大灰脸儿:.“您输入了错误的账号或口令,请再次输入!”晕,怎么回事呢?按理说,“啊D”不会骗人的,那问题空间出现在哪儿呢?我又把思路重新整理了一下,没发现什么异常,且慢,应该还是这个BT密码“bfpms;79:<;@”有问题!因为怎么看这都不像是一个好记忆的密码,而且输入起来也很麻烦,是不是其中隐藏了什么呢?但左思右想也没想出来,还是问“谷歌”吧。

在Google上以“啊D bfpms;79:<;”作为搜索关键字,一搜,还别说,马上得到了答案!原来,这真是一套后台密码二次转换的加密小伎俩:“admin”这五个字母对应的就是“bfpms”五个字母,也就是说,“a”对应“b”(加1)、1)、“d”对应“f”(加2)、“m”对应“p”(加3)、“i”对应“m”(加4)、“n”对应“s”(加5)。规律非常简单:第几位密码就在ASCII中顺序加上几,明白了这些再破解起来当然就容易多了,只要对照ASCII进行减法运算就可以查到对应的原密码了!前面的五位“bfpms”对应“admin”,后面的七位“;79:<;@”经过简单的对照,可以还原其密码为“5011204”,全部都是数字(像电话号码?其实就是!)现在我们得到了超级用户“admin”的密码应该是“admin5011204”,重新登录试一下,呵呵,果然顺利进入了后台管理界面!“管理员账号管理”下非常清楚地显示着两个管理员账号admin和tiedan的重要信息,顺便看了下“铁蛋”的管理员密码,原来是“4a3b2c”,同样是被bfpms过了的。

四、黎明之前

由于已被拿下的分支网站与主网站不在同一个IP地址上,因此检测到了这一步其实离目标还差很远,但毕竟这是成功的一步。回头再来仔细地看看主站,忽然发现在网站的最底端“技术支持”——“xxx信息研究所”的后面有一个联系电话:xxx-5011204。这串数字实在是太熟悉了,因为它就是刚才自己对照ASCII一个一个破解出来的密码的一部分啊!呵呵,看来这两个网站还真是有着千丝万缕的联系呢!照此推理,这个“xxx信息研究所”是同时为这两个网站做的技术支持,因此虽然主站暂时还未动之冰山一角,但这个技术支持者似乎在提示着我们什么——是不是网管的登录密码都与这个电话有关呢?

再次到主站上翻看新闻,不仅是最近的,更包括刚建站时的,最终查到了此网站共有三个管理员:hgf、nxkjt和xuxin(就是在每条信息发布的标题下面的“录入”者)。再根据它们各自出现的时间与频率,我将“hgf”锁定为最终目标,显然这是网管的姓名拼音首字母。那么,它的密码会不会就是自己的账户再加上这个电话号码呢?应该说,可能性非常大。正当自己感到看到了曙光之时,忽然发现了一个非常严重的问题——后台!主网站的后台登录地址还没找到呢!这可很关键,没有它,就算你知道了账户名和密码也白搭一一没地方进啊!怎么办?

五、最后的冲刺

既然开始就用“啊D”扫描后台登录地址没找到(“啊D”也是将一些可能存在的后台登录地址逐一排查的),那只能是手工试一下了,但我很快就失望了:manage、login、denglu统统都试过了,均宣告失败。看来,警觉的网管已经更改了系统的默认路径信息,不过,他能改到哪儿去呢?也一定是改成一个他自己能够记得住的、见名知义的缩写吧?否则自己管理起来也是极度不方便的,不是么?此时的感觉真可以用“山穷水尽疑无路”来形容了,不过怎样才能“柳暗花明又一村”呢?

到了黎明之前的最黑暗时刻了,出路到底在哪儿?要不,查查它的源码?调用记事本打开网站的源码之后,我准备开始从头开始浏览,只是太长了,晕!先试试Ctrl-F组合键查找“manage”,我猜想这样的字眼儿应该会有戏。果然,回车之后,光标定位于“xxxxx_Manage/uploadfile/jpg/2016-10/20161028111953619jpg”,是“xxxxx_Manage”,一定是!因为附近下面的好几个地方都是“xxxxx_Manage”。

在浏览器的地址栏中构造语句,回车,终于出来了,果然是后台网站管理系统!虽然有验证码把关,但由于先前的准备工作做得比较足,再加上自己的英明判断,因此在此仅试探了一个回合之后就把对方“拉下了马”一一帐户:“hgf”,密码:“hgf5011204”,与分析的完全吻合。点击“确定”按钮之后,成功地登录进入后台管理系统,到此,该网站的生杀大权终于拿下!

六、检测小结

在本次对特定目标的检测过程中,结果是可喜的,过程却是曲折的一一对其分支网站的注入、破解还原出bfpms密码似乎走了弯路,不过如果没有这个过程的话就不会联想到主站的账户密码会与技术支持电话号码关系会如此紧密。虽说网管防护工作做得不错,但可惜“百密难免一疏”,非常不经意的信息“录入者”和技术支持电话号码毁掉了整个“马奇诺防线”。试想一下,如果不与存在注入点的分支网站作“友情链接”,如果不显示技术支持的电话号码,如果将登录后台管理的入口地址再设置得隐蔽一些,如果将自己的密码后半部分换为自己的手机号码呢?结果还会是这样么?