【探讨】一次不算太成功的渗透 Secer's Blog - 记录互联网安全历程与个人成长经历

先整体说说目标的一个整体概况吧，此目标站点5年之前搞下过它的另外一台服务器，主服务器一直没有搞定，所以这次继续上次没完成的任务，go on 欢迎各位师傅探讨探讨各种姿势

目标站点：

单独服务器——美国加利福尼亚州洛杉矶 hostspaces
在线扫描了一下服务器大体端口开放情况如下，和实际效果应该有点偏差，后续再扫描

Starting Nmap ( http://nmap.org ) at 2017-12-27 18:17 EET
NSE: Loaded 29 scripts for scanning.
Initiating SYN Stealth Scan at 18:18
Scanning www.ro***.com (*.*.*.*) [100 ports]
Discovered open port 3306/tcp on *.*.*.*
Discovered open port 80/tcp on *.*.*.*
Discovered open port 22/tcp on *.*.*.*
Discovered open port 21/tcp on *.*.*.*
Discovered open port 9999/tcp on *.*.*.*
Completed SYN Stealth Scan at 18:18, 1.99s elapsed (100 total ports)
Initiating Service scan at 18:18
Scanning 5 services on www.ro***.com (*.*.*.*)
Completed Service scan at 18:18, 6.30s elapsed (5 services on 1 host)
Initiating OS detection (try #1) against www.ro***.com (*.*.*.*)
Retrying OS detection (try #2) against www.ro***.com (*.*.*.*)
Initiating Traceroute at 18:18
Completed Traceroute at 18:18, 2.13s elapsed
NSE: Script scanning *.*.*.*

[+] Nmap scan report for www.ro***.com (*.*.*.*)
Host is up (0.15s latency).
Not shown: 90 closed ports

PORT     STATE    SERVICE      VERSION
21/tcp   open     ftp          Pure-FTPd
22/tcp   open     ssh          OpenSSH 5.3 (protocol 2.0)
80/tcp   open     http         nginx      Scan with Web Server Scanner                                    
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
1025/tcp filtered NFS-or-IIS
3306/tcp open     mysql        MySQL (unauthorized)
5357/tcp filtered wsdapi
9999/tcp open     http         nginx      Scan with Web Server Scanner                                    

Aggressive OS guesses: Linux 3.1 (91%), Linux 3.2 (91%), Linux 2.6.23 - 2.6.38 (91%), Lexmark X644e printer (91%), AXIS 210A or 211 Network Camera (Linux 2.6.17) (91%), Linux 2.6.32 (91%), Linux 2.6.32 - 3.10 (91%), Asus RT-AC66U router (Linux 2.6) (90%), Asus RT-N16 WAP (Linux 2.6) (90%), Asus RT-N66U WAP (Linux 2.6) (90%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 11 hops

21/tcp   open     ftp
22/tcp   open     ssh
80/tcp   open     http
135/tcp  filtered msrpc
139/tcp  filtered netbios-ssn
445/tcp  filtered microsoft-ds
593/tcp  filtered http-rpc-epmap
1025/tcp filtered NFS-or-IIS
3306/tcp open     mysql
4444/tcp filtered krb524
5555/tcp open     freeciv
6129/tcp filtered unknown
9999/tcp open     abyss

80端口

运行的一套阉割版本的DeDe系统，很多文件都已经删除，只保留了基本的显示功能，通过以前的数据登录会员系统，发现只有一个充值的功能what fuck？

我一度的怀疑这个网站没有管理后台，那站长每天的更新是如何实现的？？？？或者是用的其他域名来作为管理后台的，我社工进入了管理员的51la统计系统，在每天的来源统计，访问页面等等翻来覆去的找啊，就是没有看到相关的有价值的内容

9999端口

主机宝linux版本，暂时没有0day无果，找朋友分析源代码中

社工

由于以前搞过一次，所以回忆一下以前的过程，目标站以前交易的时候还是支付宝，留意的一下支付宝的名称，当时kuzi还比较流行，用昵称和各种收集到的信息去茫茫数据中，寻找关联，后面顺利的关联出了站长的3个主要163邮箱，然后各种密码尝试进入了邮箱，虽然现在站长常使用的邮箱还是其中一个，然并卵。站长的所以信息我在上次的社区时候基本都已经拿到了（身份证、住址、电话、媳妇是谁、媳妇的qq等等）站长把主站相关的内容全部放在他的GM邮箱和QQ邮箱里面。。。。。what。。。懵逼。

邮箱

时间太过久远，估计上次也被站长发现了，所以站长修改了密码，当时的网易邮箱还是可以通过密保问题找回密码的，站长虽然修改了密码，但是密保的问题答案还是原邮箱的登录密码，为了不打草惊蛇所以当时就结束了那次的渗透没有继续下去。

最近继续渗透的时候，发现找回密码都是用手机了，没有其他方式找回。。。。在原有的信息当中寻找突破，突然人品爆测试了几次直接杀进去了。

看来还是支付宝关联的账号使用频率还是挺高的，，，每天都有交易