有人12月份发了小米科技渗透的过程。仔细看了看,非常经典的一次渗透过程,其中注入,上传,社工基本上是无缝结合。
 
现在渗透在外面,有些人看来似乎没有什么技术含量,有些人则认为高不可及,那么从这个渗透的案例,我来解答下相关的技术点。
看看大家掌握了多少。
首先,作者是从?do=list2&choice=sms&category=x%27%20and%201=2%20union%20select%201,2,3,host,user,password,7,8,9,0,1,2,3%20from%20mysql.user%23&orderby=m_hot这个注入点开始的。我想SQL注入这个东西,就不用说了,大家可能都比较熟悉。说到这里,随便的提下盲注。上面的注入点,很显然是一个普通的注入点,但如果是一些不显错,甚至是跳转的注入点,需要进行盲注什么的,一般的穿山甲之类的可能很难做,推荐sqlmap,或者webinsepct自带的那个SQL注入工具。作者通过这个注入点获取到那些信息.
1.mysql的版本,链接账户,权限,数据库列表,数据库所在路径等等.具体看数据库用户的权限是否够大,他这里是mysql的root用户链接的,所以只要内置函数可以获取的环境都可以获取到。
2.当前库的表,字段,数据等等。
以上两点,是初步可以获取的信息。这些信息直接影响到后面的渗透。这里作者通过mysql的root用户,使用into outfile来导出一个webshell到web目录。
这里要说下,首先你链接的mysql用户必须有file_prv才可以使用into outfile来导出文件,因此这里在后面加固的时候或者说前期进行安全配置的时候,使用什么权限的用户进行数据库链接非常重要。其次,web路径的获取,可以是用load_file来获取。当然,可能有些系统直接通过暴错等就可以获取到web系统的路径。
这里关键点,数据库链接用户的权限过大。
简单来说通过注入点->mysql的root可以操作文件->通过load_file等手段获取web应用的物理路径->通过into outfile导出webshell
到这里,已经有一个webshell了。就是作者提到的
这里我还要说下,还是权限的问题。一般来说,在配置linux服务器的时候,web目录不应该对所有用户都有读写权限的。也就是说,启动mysql服务的那个用户,不应该对web目录可以写的。但是悲剧的是,这种不可写的情况比较少见。
通常有webshell后,我们会作得事,无非是以下几样
1.通过webshell来提权,linux下,应该都会有bash shell的。不管是通过python还是c,还是perl来反弹。当然,还有一些更高级的反弹shell的办法。
2.收集一切可能有用的信息,包括类似数据库数据,数据库链接用户密码,当然可能还有bash_histroy等等,能收集到什么信息,完全靠平时渗透的时候,你掌握了多少知识,所以说渗透的价值也在这里,渗透是有价值的工作!
通过上面的webshell,然后再通过mysql的root用户,作者首先想到的是查看数据库的数据。且好,数据库里残留了老版本的用户库,这个库虽然是遗弃的,但是里面有很多信息仍然非常有用,这时候,社会工程学就开始发挥重大的作用。
 
到了这里我们应该注意下,作者想渗透的目标不是这个已经遗弃的服务器,而是他现在在使用的电商站。
 
3.由于数据库链接用户是root,作者通过root跨库到残留在服务器上的用户库ucenter。从uc库里,作者通过查询xiaomi.com的域名信息,然后反查注册邮箱,找出了库里用户的密码hash。这步属于社会工程学。
 
这里作者有一点没提,discuz的密码hash好像没那么好破,不知道是什么手段。
 
通过反查snowhilloldman@gmail.com,作者找了域名管理员的uc库中的用户名,然后破解在此地的密码,社工进入用户gmail邮箱。
 
到这里,应该是可以控制用户的域名了,起码可以通过找回密码的方式重新设置域名的A记录。xiaomi.com似乎并没有做什么域名保护~
 
4.由于通过找回密码等方式获取域名控制权比较的危险,所以作者进行了下一步的渗透,通过上面的邮箱通讯录,找到了,wanghaizhou@gmail.com这个邮箱。我估计wanghaizhou就是他在UC库里的用户名,因此黑客认定此邮箱是同一个人。还是一样的密码,进入这个gmail里。从这个邮箱里读到了大量的敏感信息,比如服务器密码,内网VPN等等。从而控制到了整个服务器。
 
渗透就完成了。
 
以上是对作者渗透小米的过程的一个描述,我只是添加了一些自己的看法。
 
那么就这件事来说,那些地方是小米没有做足功夫的呢?
 
1.没有做审计就上线产品。这点是肯定的,不然那么明显的注入点,肯定是不可能出现的。
 
2.不用的应用不及时的删除或者限制访问。总认为这个链接我不用了,就没人知道。侥幸心理。
 
3.服务器配置不当,应用配置不正确。使用权限过大的用户配置环境。应用环境安全配置,是很重要的一块。现在估计有2/3的安全问题都是出现在配置不当导致的。坦率的说,也是运维做安全的一个悲剧。
 
4.多处使用同一个密码,并且在重要业务领域也使用同一个密码。这点很不应该。
 
5.在网络上,或者说非控制区域,存储敏感信息。
 
总的来说,运维人员犯了所有能犯的错误,安全意识差,黑客只是尽量多的挖掘了这些信息而已!
 
惭愧的说,我之前也尝试渗透过小米,只是没有找到这个注入的入口点。这是比较关键的一点。

摘自 Robert's Blog