有人12月份发了小米科技渗透的过程。仔细看了看，非常经典的一次渗透过程，其中注入,上传,社工基本上是无缝结合。
 
现在渗透在外面，有些人看来似乎没有什么技术含量，有些人则认为高不可及，那么从这个渗透的案例，我来解答下相关的技术点。
看看大家掌握了多少。
首先,作者是从http://xshare.api.xiaomi.com/xShare?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.当前库的表,字段,数据等等。www.2cto.com
以上两点，是初步可以获取的信息。这些信息直接影响到后面的渗透。这里作者通过mysql的root用户,使用into outfile来导出一个webshell到web目录。
这里要说下，首先你链接的mysql用户必须有file_prv才可以使用into outfile来导出文件，因此这里在后面加固的时候或者说前期进行安全配置的时候，使用什么权限的用户进行数据库链接非常重要。其次,web路径的获取，可以是用load_file来获取。当然,可能有些系统直接通过暴错等就可以获取到web系统的路径。
这里关键点,数据库链接用户的权限过大。
简单来说通过注入点->mysql的root可以操作文件->通过load_file等手段获取web应用的物理路径->通过into outfile导出webshell
到这里,已经有一个webshell了。就是作者提到的http://xshare.api.xiaomi.com/rso/1.php
这里我还要说下，还是权限的问题。一般来说，在配置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