freeBuf
主站

分类

漏洞 工具 极客 Web安全 系统安全 网络安全 无线安全 设备/客户端安全 数据安全 安全管理 企业安全 工控安全

特色

头条 人物志 活动 视频 观点 招聘 报告 资讯 区块链安全 标准与合规 容器安全 公开课

官方公众号企业安全新浪微博

FreeBuf.COM网络安全行业门户,每日发布专业的安全资讯、技术剖析。

FreeBuf+小程序

FreeBuf+小程序

左右互搏术的自我修养
2019-05-27 08:00:45

*本文原创作者:罹♛殇,本文属于FreeBuf原创奖励计划,未经许可禁止转载

0x01:前言

对类似《一个人的安全部之企业信息安全建设规划》,《左右互博:站在攻击者的角度来做防护》这样的一个人的安全部和左右互搏术的文章特别的有感觉,本文没有太多的技术含量,描述了一个安全从业人员在面对困惑的时候肉体上的菜鸡和思想上的菜鸡的交流。

0x02:问题发现

在某服务器,对服务做了基础的安全加固,并本着最小权限化原则,未开启过多的服务,启动了nginx做解析器

image.png

观察日志,这些日志成功的引起的了我的好奇:

image.png

先看下日志日志配置,会不会nginx日志配置错误导致的?

image.png

肉体上的小白开始第一次开始询问心灵上的小白:

1.nginx的access.log日志出现的日志不奇怪吗?

2.access.log中为什么会看到很多奇怪的第三方域名(下图截取第三方域名为百度的实例),没有一个域名是属于本地合法域名集的?

3.响应码大部分是404,但虽是404,但对应的URL却是可以访问的;

4.这样的日志格式合理吗?

由于本人在部门是站在金字塔最低端的人,没有强大的理论基础,只能进行简单的尝试猜想并进行验证:

image.png

根据以往对日志的理解,这个字段应该是uri,不符合情理,研读log_format的日志说明,对$request字段说明如下:$request用于记录请求URL与HTTP协议;额~~~,虽然是可以记录完整的url,但不符合常规的请求,正常的access.log发现正常的access日志的Request请求并不会包含http协议头和域名字段,而是只记录url路径

凭借的菜鸡经验,对不符合常规的请求作出猜想:

1.Nginx服务器在企业中常作为Web服务器,位于负载均衡设备、Squid、Nginx反向代理之后,通过$remote_addr变量拿到的将是反向代理服务器的IP地址,服务器被攻击者利用的一些“著名”且具有“攻击成本低”的“高危便携性”的漏洞,例如struts2,弱口令,利用中间件服务器的代理功能进行恶意代理攻击的事件,nginx服务器被人作为中间代理去访问其他站点。致使其在日志上记录下了代理日志?

2.SSRF漏洞?

3.被如花刺代理工具类似代理工具代理攻击?

0x03:复现过程

所有的猜想都需要依托数据做支撑。

1.服务器被黑了

image.png

根据日志,时间维度和IP身份维度出来了,针对以上攻击者溯源后发现,此IP对服务器并无其他请求,排除被攻击了的可能性。

image.png

nginx服务器被人作为中间代理去访问其他站点?

server {
        listen       80;
        server_name ceye.io;
        large_client_header_buffers 4 16k;
        client_max_body_size 500m;
        client_body_buffer_size 2048k;
        proxy_connect_timeout 600;
        proxy_read_timeout 600;
        proxy_send_timeout 600;
        proxy_buffer_size 512k;
        proxy_buffers  6 512k;
        proxy_busy_buffers_size 512k;
        proxy_temp_file_write_size 512k;
        fastcgi_buffer_size 1024k;
        fastcgi_buffers 6 256k;
        fastcgi_busy_buffers_size 1024k;
        error_page 500 502 503 504 /5xx.html;
        location = /5xx.html { root html; }
        location / {
            proxy_redirect off;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_pass http://ceye.io;
           }
}

看到尽管作为了反向代理服务器,日志字段依然是uri。image.png

被代理攻击?搞一搞不就知道了嘛,这个用metasploit的web服务器信息扫描模块:

auxiliary/scanner/http/open_proxy

image.png

达到和预期的效果了:

image.png

不应该吧?why?抓包看看发送的请求:

image.png

image.png

image.png

发现和平常抓包的差别在于uri前面少了个“/”,不会报错吗?

image.png

最后形成了HTTP代理攻击,客户端访问服务器,服务器再向指定的服务器发起请求,CC攻击就是利用多台僵尸机进行多线程http代理向目标服务器发起大量的真实http请求,使其消耗掉大量的并发资源,拖慢整个网站,造成拒绝服务。

image.png

0x04:原理探究

攻击测试

1.nmap的脚本测试nmap的http-open-proxy脚本可以用来探测HTTP代理是否打开:

image.png

nmap 目标 --script http-open-proxy socks-open-proxy --script-args proxy.url=[[www.baidu.com](http://www.baidu.com)]([http://www.baidu.com](http://www.baidu.com))

image.png

msfconsole的auxiliary/scanner/http/open_proxy模块测试过程查看如上。

.花刺代理工具或在线代理测试 http://web.chacuo.net/netproxycheck)。

攻击利用

1.扫描端口

CONNECT http://www.test.com:8080 HTTP/1.1
Host: www.test.com:8080

如果目标端口为开放的状态,会返回200;未开放的,代理服务器会返回503状态信息,大致分别如下。

在查资料的时候,顺便看到了一个反向代理的代理不当进内网的攻击案例,看的很津津有味,形式同上。

参考文献:代理不当进内网

防御

2.警用connect方法在HTTP中常用的方法有get,post,head。但也有很多不常用的method,其中就包括connect。image.pngconnect是通过TCP连接代理服务器的。加入我想告诉代理服务器向访问,首先建立起一条从我的客户端到代理服务器的TCP连接,然后给代理服务器发送一个HTTP报文:

image.png

CONNECT https://www.xxxxxx.com HTTP/1.1
Host: www.xxx.com:80
Proxy-Connection: Keep-Alive
Proxy-Authorization: Basic *
Content-Length: 0

发送的HTTP请求报文会通过代理服务器请求Internet服务器。然后返回给客户端。

嗯,凌晨四点的,肉体上的菜鸡告诉精神上的菜鸡,我熬不住了,快睡吧~~~

image.png

*本文原创作者:罹♛殇,本文属于FreeBuf原创奖励计划,未经许可禁止转载

# 肉鸡 # 左右互搏
本文为 独立观点,未经允许不得转载,授权请联系FreeBuf客服小蜜蜂,微信:freebee2022
被以下专辑收录,发现更多精彩内容
+ 收入我的专辑
+ 加入我的收藏
相关推荐
  • 0 文章数
  • 0 关注者