君に会いたい ...Sprinter

​​一台机器 通过端口扫描发现 对外开了80 , 8080 , 22端口

1. 22端口只支持公钥登录

2. 8080架设了某CI服务

3. 80架设了某BLOG服务

某CI服务需要登录，但是能够注册（手动滑稽），并且注册后的用户有权运行某高性能虚拟机上的动态语言脚本。

发现某CI服务权限比较低。尝试sudo id，需要输入密码，猜测没有sudo权限或者需要输入密码才能sudo

翻了翻某CI服务项目的配置，发现了一条有趣的命令 sudo /etc/init.d/XXXX start

尝试执行该命令不需要密码并且成功执行，看来是在sudoer里设置了只能sudo执行 /etc/init.d/XXXX

查看该脚本后，发现是一个用jsvc运行某CI服务编译好的项目的jar的服务脚本，jsvc可以指定--user 来降权执行，但是他指定了root，非常漂亮。

于是想到了替换jar文件为我们的反弹shell来获得一个root权限的shell，然后进行后续操作。

反编译他的jar或者直接在某CI服务里看代码，参考了jsvc的文档，实现了跟原始jar一致的接口的反弹shell的jar。

起服务，齐活，成功拿到Shell。查看sudoers验证猜想正确。

然后就是信息收集

1. 某CI服务的里拿到某代码托管服务的用户名和密码

2. 从某BLOG服务连接某数据库服务的以世界上最好的语言的编写的配置文件里拿到了数据库用户密码

3. 拿某代码托管服务的用户名 和 某数据库服务密码 猜出从某BLOG服务的用户名密码

4. 根据IP知道主机提供商是某著名以二次元形象吸引宅男程序员氪金的主机提供商，然后拿某BLOG服务的用户名密码登录

以上故事提醒我们

1. 这个主机提供商的端口限制白名单功能是非常坑爹的。

   该机器勾选了 22 和 web服务(80,443) 结果没想到自己在8080上的服务暴露出去了。

   所以以后买了机器架好服务，要自己端口扫一下或者通过iptables增加自己的限制，防止被主机提供商坑一把。白名单是好的，但是跟描述不一样的白名单就。。。

2. sudo只能执行一个命令这个设置说明用户有一定安全习惯，没有ALL ALL NOPASSWD，但是运行的程序如果提供了降权功能，也是要用上的。此外要将服务脚本指向的程序的所有者改成root以防止被第三方随便修改。

3. 通用密码害死人。

以上故事纯属虚构，如有巧合概不负责