Bypassing Web-Application Firewalls by abusing SSL/TLS

本文介绍了一种通过利用不受支持的SSL密钥来绕过Web应用防火墙(WAF)的方法。作者在部署WAF进行测试时发现,由于WAF无法识别某些特定的SSL密钥,攻击者可以利用这一点绕过防火墙的防护,成功访问目标网站。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Introduction

During the latest years Web Security has become a very important topic in the IT Security field. The advantages the web offers resulted in very critical services being developed as web applications. The business requirements for their web applications security has also changed a lot and apart from their good developing standards they add another layer of security. Web Application Firewall’s are L7 firewalls which inspect web traffic and “try” to protect from attacks. In this blog post I will explain an interesting bypass vector that I found recently during a deployment audit of a WAF.

 

The cause of the “vulnerability”

Recently I was assigned to do a deployment test of a WAF in a company. I won’t name the company and the product for obvious reasons but the principle stays the same. The architecture of the deployment was something like this:

WAF General Architecture

After I was provided with the required information I started to look for different ways to bypass it. I was given access to the WAF for different tests and apart from other methods I found to bypass it, an interesting one was by abusing SSL Ciphers. The first time I logged in the WAF the Unsupported SSL Ciphers alert caught my eye really quick. Once I saw the alert description I started digging more in the documentation of the product and managed to find all the supported SSL ciphers, but before continuing I want to give a quick explanation how an SSL connection works.

The SSL handshake is composed by 3 main phases:

ClientHello/ServerHello Phase.

The handshake begins by the client which sends a ClientHello message. This message contains all the information the server needs, like the various cipher suites and the supported SSL/TLS versions. After receiving the connection the server responds with a ServerHello message which contains similar information that is required by the client. The server also returns what cipher suite and SSL version will be used.

Certificate Exchange

After the connection is initialized the server needs to prove its identity to the client. The server sends the SSL certificate to the client and the client checks if it trust the certificate and continues the connection.

Key Exchange

Now that a secure tunnel is established the server and client exchange a key which will be used for both encryption and decryption of the data.

 

Attack idea

The idea that popped in my head was : What if I use an "unsupported" SSL Cipher to initialize the connection to the WebServer which supports that cipher, the WAF would not be able to identify the attack because it can't view the data.

So I started digging around and found out the documentation for the WAF vendor, from there I extracted all the SSL Ciphers that were supported. As can be seen below.

SSLv3

SSL_RSA_WITH_NULL_MD5
SSL_RSA_WITH_NULL_SHA
SSL_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_SHA
SSL_RSA_WITH_DES_CBC_SHA
SSL_RSA_WITH_3DES_EDE_CBC_SHA
SSL_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA

TLS/1.0-1.2

TLS_RSA_WITH_NULL_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_MD5
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_RC4_128_MD5 = { 0x000x04 }
TLS_RSA_WITH_RC4_128_SHA = { 0x000x05 }
TLS_RSA_WITH_DES_CBC_SHA = { 0x000x09 }

The next step is to identify the SSL Ciphers that are supported by the webserver.

There are a lot of ways to identify the supported ciphers but I used sslscan because it’s easy to install and gives a lot of detailed information.

pwn@thinkpad:~$ sudo apt install sslscan 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following NEW packages will be installed:
  sslscan
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 26,7 kB of archives.
After this operation, 81,9 kB of additional disk space will be used.
Get:1 http://al.archive.ubuntu.com/ubuntu bionic/universe amd64 sslscan amd64 1.11.5-rbsec-1.1 [26,7 kB]
Fetched 26,7 kB in 0s (73,8 kB/s)  
Selecting previously unselected package sslscan.
(Reading database ... 177002 files and directories currently installed.)
Preparing to unpack .../sslscan_1.11.5-rbsec-1.1_amd64.deb ...
Unpacking sslscan (1.11.5-rbsec-1.1) ...
Processing triggers for man-db (2.8.3-2) ...
Setting up sslscan (1.11.5-rbsec-1.1) ...
pwn@thinkpad:~$ sslscan http://target/ | grep Accept

The command above will list all the supported SSL/TLS versions and ciphers from the webserver.

Comparing the result from sslscan and the documentation of the product, I was able to identify some ciphers which were not supported in the Web Application Firewall but supported in the webserver.

Accepted TLSv1 256 bits ECDHE-RSA-AES256-SHA

The cipher supported on the webserver but not on WAF

To test my theory I created a WAF rule which blocked the request if the path of the request was /ssl-cipher-test.

Visiting the path will block the connection successfully.

Blocking the request

A quick way to exploit this “bypass” is by specifying the client ciphers, leaving only the one that will bypass the firewall.

You can specify the cipher using --ciphers command on curl, in this case I specified ECDHE-RSA-AES256-SHA.

pwn@thinkpad:~$ curl --ciphers ECDHE-RSA-AES256-SHA https://waf-test.lab.local/ssl-cipher-test
<html lang=en>
  <title>HELLO </title>
  <p>Bypass worked</p>
pwn@thinkpad:~$ 

As we see from the response above the Web Application Firewall was bypassed successfully.

 

Closing remarks

The main plan for me before publishing this blogpost was creating a scanner to scan all the supported ciphers, find one which is supposed to bypass the firewall and then start a proxy listener to forward all the requests with that cipher.

Since that will require a lot of time that I don’t have, I decided to release the blogpost and inspire someone to create something based on this research.

 

References

https://security.stackexchange.com/questions/67931/why-cant-i-decrypt-ssl-traffic-with-the-clients-private-key-only

https://www.owasp.org/index.php/TLS_Cipher_String_Cheat_Sheet

CURL Ciphers Document

在IT领域,尤其是地理信息系统(GIS)中,坐标转换是一项关键技术。本文将深入探讨百度坐标系、火星坐标系和WGS84坐标系之间的相互转换,并介绍如何使用相关工具进行批量转换。 首先,我们需要了解这三种坐标系的基本概念。WGS84坐标系,即“World Geodetic System 1984”,是一种全球通用的地球坐标系统,广泛应用于GPS定位和地图服务。它以地球椭球模型为基础,以地球质心为原点,是国际航空和航海的主要参考坐标系。百度坐标系(BD-09)是百度地图使用的坐标系。为了保护隐私和安全,百度对WGS84坐标进行了偏移处理,导致其与WGS84坐标存在差异。火星坐标系(GCJ-02)是中国国家测绘局采用的坐标系,同样对WGS84坐标进行了加密处理,以防止未经授权的精确位置获取。 坐标转换的目的是确保不同坐标系下的地理位置数据能够准确对应。在GIS应用中,通常通过特定的算法实现转换,如双线性内插法或四参数转换法。一些“坐标转换小工具”可以批量转换百度坐标、火星坐标与WGS84坐标。这些工具可能包含样本文件(如org_xy_格式参考.csv),用于提供原始坐标数据,其中包含需要转换的经纬度信息。此外,工具通常会附带使用指南(如重要说明用前必读.txt和readme.txt),说明输入数据格式、转换步骤及可能的精度问题等。x86和x64目录则可能包含适用于32位和64位操作系统的软件或库文件。 在使用这些工具时,用户需要注意以下几点:确保输入的坐标数据准确无误,包括经纬度顺序和浮点数精度;按照工具要求正确组织数据,遵循读写规则;注意转换精度,不同的转换方法可能会产生微小误差;在批量转换时,检查每个坐标是否成功转换,避免个别错误数据影响整体结果。 坐标转换是GIS领域的基础操作,对于地图服务、导航系统和地理数据分析等至关重要。理解不同坐标系的特点和转换方法,有助于我们更好地处
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值