How CRS contributes to PCI DSS compliance
The Payment Card Industry Data Security Standard (PCI DSS) applies to all organizations that store, process, or transmit cardholder data or sensitive authentication data, as well as any systems, people, or processes that could affect their security. This includes not only merchants and service providers, but also supporting components such as authentication servers, access controls, and Web Application Firewalls (WAFs). The OWASP CRS (Core Rule Set) is a widely adopted, open-source set of WAF rules designed to detect and block a broad range of web application attacks. When properly deployed, CRS provides robust, customizable protection against many threats relevant to PCI DSS compliance. In recent updates, the CRS team decided to remove PCI DSS specific tags from individual rules. As the PCI standard has evolved, at the time of writing it is at version 4.0.1, maintaining a rigid mapping of requirements to specific CRS rule IDs became impractical and potentially misleading. The focus has then shifted to showing how CRS, as a whole, reinforces your PCI DSS compliance posture. This post contributes to that effort by illustrating how CRS adds a critical layer of real-time inspection for web-facing applications.
Open WAF Day Barcelona 2025
After coming back from Barcelona, it took me a bit to adjust to my normal timezone. It took me a while to just get my head on this post. First of all, we would like to thank again our Open WAF day Barcelona 2025 sponsor, Harness 👏 👏 👏 Without them setting this up would have been extremely difficult. Now, we had around 20 people stopping by in our assigned room at the magnific CCIB. The agenda ended up being:
False Negatives, False Positives – How the CRS team decide when to add or modify rules, and when we decide not to add them
My name is Michela, and I’ve quite recently and gradually begun participating in the CRS project – a group of very sharp and incredibly welcoming people, who work to make the Internet safer. Needless to say, it’s been very interesting, and fun, so far! As part of my onboarding, so to speak, I’ve been reading lots of documentation on how the project is run, official rule syntax and formatting guidelines, collaborations with other teams like those of ModSecurity and Coraza, and of course, how decisions are made about rule-making.
Meet the CRS team: Matteo, the Italian Coraza user with a strong sense of community
At 14, he chose computer science over Latin in high school, at 17 he found a bug in Facebook—and he knew most of the CRS team in person before he met them online. As a predominant user of Coraza rather than ModSecurity, Matteo Pace brings a much welcome outsider’s perspective to the CRS team. Community and shared purpose define his professional and private life. Matteo Pace likes the social aspects in everything he does – like here during the CRS developer retreat 2023 in the Hungarian capital Budapest
First CRS community call
CRS is the world’s leading open source WAF rule set. A very large part of this success is thanks to our amazing community who report problems with the rules and tell us about real world issues they experience. Due to its nature, CRS is also quite complex and first (or even second) contact with using CRS can be quite daunting. We constantly try to reduce the level of complexity: we want make it easier for people to start working with CRS.
CRS Welcomes Max Leske as New Leader
For some months after Christian leaving his position in the project’s leadership, we discussed the future of the project internally about opportunities for people to step up and fill up the leader position that was left empty. After the devastating news for the team we had the past year, being the sole leader for a project as crucial as CRS was a big concern. My personal idea was to start the discussion while at the OWASP Summit in Woburn Forest, with a shortlist of people who were interested in stepping up and filling up the leadership position. Sadly not everyone was able to attend the summit, so I wasn’t able to have this one on one conversation with the people in the shortlist.
Securing the Maintenance of a CRS 4 LTS release
OWASP CRS is a cornerstone in the cybersecurity landscape, providing essential protection against web application attacks. With the release of CRS 4 earlier this year, the project has reached new heights in terms of rules and functionality. As the project continues to evolve, the need for long-term support (LTS) becomes crucial to ensure its sustainability and effectiveness. Many organizations are planning a migration of their extensive CRS 3.3 setups to the stronger CRS 4, but they are waiting for an LTS release as a signal that CRS 4 has reached the stability they are seeking for their installation. In this blog post, we explore the significance of CRS 4 LTS and the call for sponsorship to support this essential initiative.
The core team of the CRS project meets among squirrels and deer
“With child-friendly breaks for families of all ages, there’s something for everyone on a Center Parcs break. Discover the forest and enjoy precious family time together in our picturesque lodges,” reads the description on the Center Parcs website. Does this also apply to open source projects? The OWASP CRS project is about to find out, as the CRS core team is meeting from November 1st to 8th for the annual developer retreat at the Woburn Forest site of this traditional British institution for young family holidays.
CRS versions 4.8.0 and 3.3.7 released
The OWASP CRS team is pleased to announce the release of two new CRS versions: v4.8.0 and v3.3.7. For downloads and installation instructions, please refer to the Installation page. These are security releases which fix a recently discovered partial request body bypass of CRS. On some platforms running CRS v3.3.6 and earlier on the v3 release line or v4.7.0 and earlier on the v4 release line, it is possible to submit a specially crafted multipart or JSON request whose body content will bypass the inspection of the majority of CRS rules on a default installation. CRS users are strongly encouraged to update to a fixed version to resolve this issue.
Meet the CRS team: Max, the Kiwi-German software developer from the Swiss Alps
Max Leske is not a security expert per se. And maybe that’s exactly what makes him such an important CRS core team member. Max is perhaps the most global member of the team: after a brief detour to the other side of the globe, the Berlin native grew up in the Swiss mountains. In everything he does – and he does a lot – he attaches great importance to having fun. For him, the most important thing about the CRS project is the people. Whether it’s work or sports – he just wants to enjoy what he’s doing: Max Leske aka theseion
United Security Providers becomes Gold Sponsor of CRS
We are excited to announce Swiss IT security specialist United Security Providers (USP) as new Gold Sponsor of OWASP CRS. As a software manufacturer and specialist for application and network security products, USP has been using CRS for a long time: it is an important component of the company’s commercial web access management solution. “With their enhancements and bug fixes, our developers contribute to the further development of the project and thus give something back to the community,” emphasizes Christoph Koch, CEO at USP. “An even closer exchange between our software developers and the CRS project team is equally beneficial for both sides. The CRS benefits from the experience of our developers in customer contact and we can pass on the power of the open-source community to our customers. In this way, we complement each other.” For USP, supporting the CRS project underlines its strategic importance in maintaining the quality and security of its own products at the highest level.
CRS versions 4.6.0 and 3.3.6 have been released
We have recently released version 4.6.0 for CRS 4, fixing a serious problem. As this problem affects CRS 3 as well, we also did a backport release for v3. (3.3.6). All users are requested to update to the new releases. The new releases tackle two multipart file upload bypass methods that were reported by @luelueking: Wrapping the Content-Disposition with non-printable characters like \x0e (e.g. “%0e Content-Disposition %0e”) may allow the header to go undetected by the WAF engine as it may not be correctly parsed. Inserting the character \ in a filename (e.g. “1.j\s\p”) may let the filename go undetected. The fixes introduced in both versions are the same:
Felipe named OWASP’s Project Person of the Year 2024
The 2024 OWASP Waspy Awards winners are here – and CRS co-leader Felipe Zipitría has been awarded “Project Person of the Year”! This win is a well-earned confirmation for Felipe’s hard work for the CRS project and the open-source community in general. The purpose of the WASPY Awards is to bring recognition to those individuals who are passionate about OWASP, who contribute hours of their own free time to the organization to help improve the cyber-security world, yet seem to go unrecognized. Individual members of the OWASP Foundation were invited to vote by e-mail. Further winners of a WASPY are Martin Knobloch (Chapter Person of the Year) and Shruti Kulkarni (Event Person of the Year).
Registration for the OWASP CRS Community Summit 2024 - Lisbon, June 26
We had previously announced the date and the location of our 2024 community summit. But it’s about time to start the formal registration so we can finalize our planning. We’re meeting in the on Wednesday June 26 at the Hyatt Regency for the 2024 CRS Community Summit. This is right next to the Lisbon Conference Center where the OWASP AppSec conference is happening Thursday and Friday. REGISTRATION We will start at 09:30 local time in the room Alfama III with coffee and then talks and workshops from 10:00.
Meet the CRS team: Jozef, the cat loving father from Slovakia
Programming and entrepreneurship run in Jozef Sudolsky’s family. When he’s not working for his own web hosting company or for the CRS project, you can find him working out at the gym or in his large garden - or just playing with his daughter. His office is at the same time his daughter’s playroom. His own company, his daughter, four cats, a house, a large garden, and the CRS project keep him busy: Jozef Sudolsky aka azurit
Save the date: CRS Community Summit on June 26 in Lisbon
The CRS project will once again hold its Community Summit the day before OWASP’s Global AppSec Conference – this year in the capital of Portugal. The whole CRS community – users, developers, integrators, and sponsors – is invited to meet on Wednesday, June 26 for an exchange of thoughts, technical talks, and networking. The program is still in the making. We plan a variety of talks about CRS 4, ModSecurity and Coraza. The following items will be part of the summit program:
CRS version 4.1.0 released
Last week, we have released CRS v4.1.0. The new release is the first according to the new monthly release schedule and brings a couple of new features and fixes. It includes quality improvements via better rule linting and fixes for false positives across a handful of rules. And: new developer Esad Cetiner has joined the team intime for the 4.1 release. Read the changelog here.
New feature spotlight: Early Blocking
One of the new features added in CRS 4 is Early Blocking. This optional new setting allows blocking decisions to be made earlier than usual. How it works CRS request detection rules take place in two phases. The rules of the first phase are executed after the server has received the HTTP request line and the request headers. The rules of the second phase are executed once the request body has been received and parsed.
The OWASP CRS project mourns the death of Co-Leader Walter Hop
Walter died last week and we are at a loss of words. For CRS, he has been a wonderful friend, a strong colleague, a developer with an impressive knowledge of PHP and WordPress in particular, a very smart thinker and one of very few regex wizards. He was also a dedicated Pokemon Go player and I remember how he would go for walks in the afterhours of IT conferences to hunt for some rare beasts. He enjoyed nature that way and the occasional catch in remote places.
Let CRS 4 be your valentine!
What a Valentine’s Day present we have got for you: today, the Core Rule Set project is releasing CRS 4! Finally, you may say – and would be absolutely right: it took us a long time to get there. But we wanted to do it right, especially after the bug bounty program we took part in left us with over 500 individual findings in roughly 180 reports. Fixing all these needed more time than we originally thought. But the result is a CRS that has never been more secure.
Welcome the newest addition to the OWASP family: ModSecurity!
With the new year comes good news: last week, Trustwave and the OWASP Foundation have announced the agreement to transfer ModSecurity to OWASP. The transition will commence on January 25. The incubation phase of the new OWASP ModSecurity project will focus on the establishment of a development community to lay the basis for a successful continuation of the project under the new stewardship. This entails the three areas: communication, administration and development. OWASP calls all interested parties to join hands and help with the future development of ModSecurity.
A new silver sponsor for CRS: Swiss Post
We are proud to present Swiss Post as new silver sponsor for the OWASP ModSecurity Core Rule Set. Swiss Post is one of the longest-standing and best-known brands in Switzerland since its establishment in 1849. The company uses many open-source solutions for development and operation and in turn supports the community where possible. Ties between Swiss Post and the CRS project team have traditionally been strong with different core team members having worked for the premier Swiss provider of mail and logistics services.
Meet the CRS team: Felipe, the team player on the other side of the Atlantic
As a South American, Felipe Zipitría has a special status in the CRS core team. The sociable Uruguayan played basketball which taught him all about the value of teamwork. Automation and standardization are key issues for Felipe in the CRS project. “The CRS project offers exciting problems that can make any techie happy”, he says. Our man in South America: Felipe Zipitría enjoys the views of Budpest at the CRS Developer Retreat 2023
Discussions, excursions and hard work – CRS Developer Retreat 2023, days 2–7
After the lofty ideas of Sunday (keyword: universe domination), things got a little more down-to-earth on Monday. After the participants had split up into the four projects, work began on them. Things got more exciting again in the afternoon when the next steps and the project roadmap were discussed. Two results from the intensive discussion about the long-term development of the project should be mentioned here in particular: Firstly, in order to not being restricted by the SecRule language the project decided to slowly start preparing an alternative structured format for a rule language. Secondly, as a lesson from the delayed release of version 4 as a result of the bug bunty program, we agreed on a new and faster serial release – without getting rid of the LTS releases. There were many other points to discuss, which we will report on in due course when things are ready.
Meet the CRS team: Andrew, the technical writer who loves Eurovision and Doom II
When invited to join the Core Rule Set project, Andrew Howe felt a bit intimidated by the highly talented team at first. Today he is a valued member of the CRS core team, bringing his experience as a technical writer and a CRS integrator. “Having people onboard with experience of running CRS at a large-scale would be very useful,” he says. What else he said, you can read in this interview. Full steam ahead: CRS core team member Andrew Howe lives in the same place where the Titanic started
Universe domination plans in Budapest - The CRS Developer Retreat 2023, day 1
It’s hard to believe that it’s already been another year since the last OWASP ModSecurity Core Rule Set Developer Retreat in Varese near Milan in northern Italy. This year, the core team is meeting in the Hungarian capital Budapest from November 5th to 12th. The team members travelled from all directions – some got up inhumanly early, others flew across the Atlantic and still others had been travelling by train for two days … but not even the Deutsche Bahn could prevent all registered participants from arriving at the Hotel Nádas Pihenőpark by late afternoon on Sunday.
CRS version 4.0.0 release candidate 2 available
The OWASP ModSecurity Core Rule Set (CRS) team is proud to announce the availability of release candidate 2 (RC2) of the upcoming CRS v4.0.0 release. The release candidate is available for download as a ‘release’ from our GitHub repository: https://github.com/coreruleset/coreruleset/releases/tag/v4.0.0-rc2 This new release candidate includes over 230 changes. Some of the important changes include: Add new rule 920620 to explicitly detect multiple Content-Type abuse (CVE-2023-38199) (Andrea Menin) Extend definition of restricted headers to include Content-Encoding and Accept-Charset by default (Walter Hop) Migrate application exclusions and less-used functionality to plugins (Christian Folini, Max Leske, Jozef Sudolský, Andrew Howe) Add support for HTTP/3 (Jozef Sudolský) Add enable_default_collections flag to not initialize collections by default (Matteo Pace) Switch to using wordnet instead of spell for finding English words in spell.sh utility (Max Leske) Refer to the CHANGES.md file in the release for the full list of changes.
CRS Performance Framework - A GSoC 2023 Project
This year, the OWASP ModSecurity Core Rule Set for the second time took part in the Google Summer of Code initiative. Google Summer of Code (GSoC) is a global online program focused on bringing new contributors into open-source software development. GSoC contributors work with an open-source organization of their choice on a 12+ week programming project under the guidance of the mentors from the organization. Dexter Chang had applied to the CRS project with a proposal for a performance framework. We spoke to Dexter about his GSoC experience with the Core Rule Set.
libmodsecurity3 CVE-2023-38285 affecting CRS users
Many CRS users have probably read Trustwave’s recent announcement about the new version of libmodsecurity3 (aka ModSecurity v3) and the reason for the release: https://www.trustwave.com/en-us/resources/blogs/spiderlabs-blog/modsecurity-v3-dos-vulnerability-in-four-transformations-cve-2023-38285/ The new version of the WAF library fixes a CVE described issue, namely: “DoS Vulnerability in Four Transformations”. We would like to draw the attention of all CRS users who also use libmodsecurity3 to update the library as soon as possible. CRS uses one of the mentioned transformations (removeNull) in several rules. Unfortunately, after analyzing the patch that fixes the bug, we were able to construct a payload that overloaded the libmodsecurity3 engine which many people use with CRS.
CRS version 3.3.5 released
The OWASP ModSecurity Core Rule Set (CRS) team is pleased to announce the release of CRS v3.3.5. For downloads and installation instructions, please refer to the Installation page. This is a security release which fixes the recently announced CVE-2023-38199, whereby it is possible to cause an impedance mismatch on some platforms running CRS v3.3.4 and earlier by submitting a request with multiple Content-Type headers. Aside from the security fix, a few other minor, non-breaking changes and improvements are also included in this release. The full changes are as follows:
CVE-2023-38199 – Multiple Content-Type Headers
The OWASP ModSecurity Core Rule Set (CRS) v3.3.4 does not detect the presence of multiple HTTP “Content-Type” header fields. As a result, on some platforms, it is possible to cause a CRS installation to process an HTTP request body differently (because of the different Content-Type) to how it would be processed by a backend web application. See the advisory at https://nvd.nist.gov/vuln/detail/CVE-2023-38199. Update: CRS version 3.3.5 has now been released to address this vulnerability.
Follow the CRS project on YouTube
The OWASP CRS project has opened a YouTube channel. Here we plan to gather all videos that are relevant to the project. In the meantime, feel free to contact us if you think you have fitting content. And don’t forget to give a thumbs up to the videos and subscribe to the channel if you don’t want to miss any new content.
What we learnt from our bug bounty program: It's not for the faint of heart
A bug hunter’s collection with some nice specimens (Photo: FreeImages.com/pi242) OWASP CRS is the dominant open source web application firewall (WAF) rule set that powers countless servers, commercial WAFs and runs on many CDNs and cloud platforms. Yahoo and Intigriti helped OWASP CRS organize a three week bug bounty program in Spring 2022. A well prepared earlier attempt had not given any results, literally zero reports, so CRS walked into this 2nd round in a somewhat naive way. But an avalanche of reports and the professionalism of our partners woke us up real quick. Still, fixing all the findings took us very, very long and we had moments where I feared it would kill our project. Here is a somewhat lengthy report about our journey.
A brief report on the CRS Community Summit 2023.
Question: What do programmers, security specialists and other IT nerds do on Valentine’s Day? Answer: they get together for the CRS Community Summit in Ireland. As in previous years, we used the OWASP Global AppSec Conference, which this year was held in Ireland’s capital, as an opportunity to call for our Community Summit on February 14, 2023. The plan was that two of the three co-leads would be present on site. Unfortunately, Christian Folini was caught out at short notice - the poor sap turned back just before boarding the plane - so Felipe Zipitria had to represent the project lead alone. From the CRS core team, Andrew Howe, Manuel Spartan and Ervin Hegedüs were also on hand, as well as Juan Pablo Tosso and Matteo Pace from Coraza. Unfortunately, compared to past Summits, only a few members from the extended community were in attendance. What that was due to is hard to say. Possibly an after-effect of the COVID-related interruption. Or maybe more IT nerds have a girlfriend than we thought …
A new rule to prevent SQL in JSON
Team82 has published an exciting research article about bypassing web application firewalls using a specific SQL syntax that uses JSON. More information about their research can be found here. An example payload described by Team82 could be: 1 OR JSON_EXTRACT('{"foo":1}','$.foo')=1 The OWASP Core Rule Set is blocking all payloads reported by Team82 at paranoia level 2 basically just with the rule 942110 "SQL Injection Attack: Common Injection Testing Detected". Though blocking this at paranoia level 2 is great, we decided to define a new rule to block all “JSON in SQL” payloads at the default level (paranoia level 1). More information about the new rule can be reached by visiting the related pull request page on the CRS GitHub repository.
CRS Welcomes Edgio as Gold Sponsor
We’re excited to announce a new partnership with Edgio, a leading provider of edge security solutions, that was formed by the combination of Limelight and Edgecast. Edgio is a trusted partner for organizations looking to protect their digital assets. Its holistic suite of security solutions protects the confidentiality, integrity and availability of web applications and APIs. And it addresses that need with high performance security solutions sitting on the edge of the internet.
Registration for the OWASP CRS Community Summit 2023 - Dublin, Feb 14
On February 14, the CRS community will meet at the Dublin Convention Center for the 2023 CRS Community Summit, the first summit after the pandemic. REGISTRATION It has been a while since last we met and many things have happened since. So, there is a lot to talk about. We start at 9 am local time in Liffey Hall 1 of the Convention Center. The program is still in the making, but please expect a variety of talks about CRS, ModSecurity and Coraza. Here is what we know:
Meet the CRS team: Fränzi, the puzzle-loving hard worker with a mission
Franziska Bühler doesn’t feel too comfortable in the limelight. The CISO of a Swiss mid-sized IT company rather likes to work through lists of hundreds of bypasses than being at the forefront. Talking to her, it gets clear quickly: Fränzi loves a challenge. “Once I set my mind to something, I follow through,” she says. She was always fascinated by great heights: Franziska Bühler aka Fränzi on top of the Milan cathedral
Microsoft Supports CRS as Gold sponsor
The OWASP ModSecurity Core Rule Set project is very happy to announce Microsoft as new GOLD sponsor. There have been sporadic contacts with the Azure WAF engineering team for several years and we are now taking the next step. Microsoft and OWASP CRS are establishing a formalized partnership in the form of a sponsoring agreement. There is never a lack of ideas in a florishing open source project like ours. But as a lot of open source projects, we lack the user perspective to a wide extent. We write rules, but we do not really know how they behave in the real world outside of the few sites we control at our day jobs.
Save the Date: CRS Community Summit on February 14, 2023
Let the CRS project be your Valentine: The OWASP ModSecurity Core Rule Set project will hold the first post-pandemic Community Summit at the Dublin Convention Center in Ireland on Tuesday, February 14, 2023. We invite the whole CRS community, users, developers, integrators, and sponsors to meet with us for an exchange of thoughts, technical talks, and networking. After the “official” part of the meeting we will go out for dinner and drinks.
Bug Bounty Switzerland supports CRS as Silver sponsor
The OWASP ModSecurity Core Rule Set (CRS) project is proud to announce a new sponsoring partner: Bug Bounty Switzerland – a startup that has pioneered the collaboration with ethical hackers in Switzerland and today is Switzerland’s leading provider of bug bounty programs and public trust initiatives. Since 2022, they are the strategic partner of the National Cyber Security Centre NCSC and help to establish bug bounty programs for the whole Federal Administration. Their customer base includes Swiss and international clients from various fields, as well as regulated industries like banking, insurance, healthcare and providers of critical infrastructures.
The CRS Developer Retreat 2022
Pizza, pasta, pesto … pineapple? This was one of the many important topics (and one of the most controversial) discussed at the CRS developer retreat 2022 in Italy. The annual CRS developer team retreat is always a highlight of the year, finally meeting face-to-face again and not just via chat. This time, the backdrop for the meeting from October 29 to November 5 was the southern foothills of the Alps near Lake Varese, close to the Swiss border. Here, in Villa Cagnola, there was not only good food and drink – there was also a lot of work. The focus was on two items: preparing the rule set for the CRS v4 release and defining a strategy for the future of the project.
Meet the CRS team: Ervin, the gardening radio amateur in the background
Astronaut? Garbage truck driver? Electrical engineer? Metalsmith? In the end, Hungarian Ervin Hegedüs became a software developer. Within the Core Rule Set project, he contributes primarily to tool development and packaging. “New team members should above all be team players,” says Ervin. A man of many talents and names: Ervin Hegedüs aka AirWeen aka HA2OS Ervin Hegedüs has had no shortage of interesting career ideas in his 51-year life. While the usual childhood dreams of becoming an astronaut or a garbage truck driver vanished as he grew older, Ervin still today sometimes wonders what would have become of him if he hadn’t found his way to IT. He thinks he might have become an electrical engineer since he is a HAM radio operator in his spare time (callsign: HA2OS). More about that later.
Meet the CRS team: Andrea, the musical man-in-the-middle
He likes to play board games and the guitar, and he loves to fix bypasses to CRS rules: Italian Andrea Menin joined the Core Rule Set team in 2018. The most important requirement for anybody joining the project, he says, is to enjoy it. Andrea Menin with the famous DeLorean: “*Back to the Future *sparked a love of technology and music in me“
CRS Version 3.3.4 and 3.2.3 fix a regression
Yesterday, we released CRS versions 3.3.3 and 3.2.2 with important security improvements. Unfortunately, backporting the fixes from our development branch 4.0 introduced a regression which was only found after publication. As a result, some Paranoia Level 2 rules would activate even when running in Paranoia Level 1. This did not harm security but may introduce false alarms for those running in Paranoia Level 1. We have fixed this in two new releases:
CRS Version 3.3.3 and 3.2.2 (covering several CVEs)
Release announcement covering fixes for CVE-2022-39955, CVE-2022-39956, CVE-2022-39957 and CVE-2022-39958, additional security fixes and security fixes in the latest ModSecurity releases 2.9.6 and 3.0.8. The OWASP ModSecurity Core Rule Set (CRS) team is pleased to announce the release of two new CRS versions. Edit: Updated download links now to refer to the fixed versions. Version 3.3.4 — https://github.com/coreruleset/coreruleset/releases/tag/v3.3.4 Version 3.2.3 — https://github.com/coreruleset/coreruleset/releases/tag/v3.2.3 This is a security release fixing several partial rule set bypasses with HIGH or even CRITICAL severity described in the following CVEs:
Update on CRS 4.0 release delay
Dear all, A few months ago we happily announced the first Release Candidate for Core Rule Set 4.0. Our original plan was to finish the 4.0 release as fast as possible. However, we found ourselves in a unique situation for our project. After the Release Candidate, a large CRS user organized a CRS Bug Bounty event, where advanced WAF hackers were tasked to bypass our ruleset to earn prizes. Since a similar earlier event did not uncover any findings, we were expecting to only get a small number of bug reports. But the hackers turned out to be amazing and created more than 100 malicious payloads that bypassed our detection!
Core Rule Set v4.0.0 Release Candidate 1 available
The OWASP ModSecurity Core Rule Set team is proud to announce the Release Candidate 1 for the upcoming CRS v4.0.0 release. The release candidate is available from our installation page; see also the upgrade notes on that page. CRS 4 contains many important changes, such as: A plugin architecture for extending CRS and minimizing attack surface. Application exclusion sets and less-used functionality have been migrated from the CRS to plugins. (See our plugin registry for the extensive list of existing plugins.) Early blocking Granular control over reporting levels All formerly PCRE-only regular expressions have been updated to be compatible with Re2/Hyperscan WAF engines We now publish nightly packages of the development branch We refactored and renamed the anomaly scoring variables and paranoia level definitions HTTP/0.9 support has been dropped to resolve false positives. CRS 4 contains many new detections:
CRS names Felipe Zipitría as third Co-Lead
The OWASP ModSecurity Core Rule Set project is very happy to announce Felipe Zipitría as a new and third Co-Leader. Felipe joins Walter Hop and Christian Folini in his new role. Felipe Zipitría holds a master of computer science from the University of the Republic in Montevideo, Uruguay. He worked as a system administrator for the faculty of engineering for several years and also lectures on security at the University.
The Case for Early Blocking
Early Blocking is a feature that CRS will deliver with the next major release, probably Spring 2022. You can use it immediately when deploying the latest dev / nightly build. This blog post will explain the feature, how to enable it and why it is very useful. What is Early Blocking? ModSecurity, the engine below CRS, processes requests in multiple phases. The phase 1 is the request header phase, the phase 2 is the request body phase. Normal blocking of attacks happens at the end of phase 2. Now if CRS identifies an attack in phase 1, it will wait until the end of phase 2 to block the request. That is obviously a waste of resources (even if that waste is relatively small). But it is also a missed chance to finish off an attacker in time. But I’ll come to that later.
Introducing the Fake Bot Plugin
In one of my previous blog posts, I introduced the CRS plugin mechanism that we are rolling out for the next major release. Check out the blog post to learn how you can start using plugins immediately, without waiting for the next release (hint: really simple). Several plugins are already available. One of them is the Fake Bot Plugin that I put into production recently. It’s a neat little plugin written by CRS dev Azurit / Jozef Sudolsky and it can serve as a perfect illustration of the capabilities of CRS plugins.
Comprehensive View of the WAF Market From an Open Source Perspective
The log4j mess allowed everybody to see security shortcomings of the IT industry on a big scale. It also shed light on the shortcomings of the WAF market, a highly contested field with a myriad of commercial players and - well - us, the OWASP ModSecurity Core Rule Set (CRS), the only general purpose open source Web Application Firewall option. This blog post will describe the WAF market from a CRS perspective, it will explain what we see as lacking and how we plan to improve the situation.
The CRS Plugin Mechanism
Plugins are not part of the CRS 3.3.x release line. They will be released officially with the next major CRS release 4.x. In the meantime, you can use them with one of the stable releases by following the instructions below. What are Plugins? Plugins are sets of additional rules that you can plug in to your web application firewall in order to expand CRS with complementary functionality or to interact with CRS. Rule exclusion plugins are a special case: these are plugins that disable certain rules to integrate CRS into a context that is otherwise likely to trigger certain false alarms.
Talking about ModSecurity and the new Coraza WAF
It’s time to talk about the ModSecurity engine and to introduce you to Coraza, a new contender on the WAF front. Any rule set is nothing without a WAF engine to run it, so even if our project is focused on the rules, we need to look at the underlying engine(s) from time to time. On August 26, 2021, Trustwave, the owner of ModSecurity, announced the end of Support for ModSecurity for 2024 in a blog post. The blog also states that Trustwave plans to “let the open-source community continue the project.”
Public Hunt for log4j / log4shell Evasions / WAF Bypasses
We have been updating our detection for the infamous CVE-2021-44228 vulnerability and its siblings for several days now. With the new experimental rule 1005, we think we really have decent detection capabilities now. Read up on this development in the separate blog post CRS and Log4j / Log4Shell / CVE-2021-44228. Right before the log4j CVE was published, we took up our CRS Sandbox that lets you test payloads against various CRS installations.
CRS and Log4j / Log4Shell / CVE-2021-44228
This is an evolving blog post with infos about the role of CRS in defending against the log4j vulnerabilities that threatens quite all logging JAVA applications. We believe the mitigations and rules suggested below will have you covered up to and including CVE-2021-45105. In January 2022, we have consolidated our knowledge into a pull request with new rules to be merged into CRS for the next major release. The pull request can be applied to your existing installation for immediate use of the new rules.
Introducing the CRS Sandbox
The OWASP ModSecurity Core Rule Set project is very happy to present the CRS Sandbox. It’s an API that allows you to test an attack payload against CRS without the need to install a ModSecurity box or anything. Here is how to do this: $ curl -H "x-format-output: txt-matched-rules" "https://sandbox.coreruleset.org/?search=<script>alert('CRS+Sandbox+Release')</script>" 941100 PL1 XSS Attack Detected via libinjection 941110 PL1 XSS Filter - Category 1: Script Tag Vector 941160 PL1 NoScript XSS InjectionChecker: HTML Injection 949110 PL1 Inbound Anomaly Score Exceeded (Total Score: 15) 980130 PL1 Inbound Anomaly Score Exceeded (Total Inbound Score: 15 - SQLI=0,XSS=15,RFI=0,LFI=0,RCE=0,PHPI=0,HTTP=0,SESS=0): individual paranoia level scores: 15, 0, 0, 0 As you can see, curl is calling our sandbox with an XSS payload and the sandbox returns the list of CRS rules that the request triggered. If you are unfamiliar with CRS, then the important part is that there are several rules that triggered / detected something. And the total “anomaly score” of 15, which is far beyond the default anomaly threshold of 5 that gets a request blocked for looking like an attack.
CRS Developer Retreat 2021
The OWASP ModSecurity Core Rule Set team met for a one week developer retreat in the Swiss mountains to hack away at CRS together. We worked on several larger projects and ran seven additional workshops, all documented on our GitHub wiki. Why Switzerland? Switzerland is an expensive place, but most of our active developers live in Europe and then Switzerland becomes central. And we found the Hacking Villa ran by local ISP Ungleich. Villa is a funny description, since it’s more like a very old alpine hostel equipped with the latest IPv6. But the main reason we settled on this offering was the great price that hotels in European cities could not compete with (and then of course the 10Gb/s fiber!) If you are looking for a cheap, no-bullshit offering to host a camp, then look into the Hacking Villa.
Working with Paranoia Levels
Paranoia Levels are an essential concept when working with the Core Rule Set. This blog post will explain the concept behind Paranoia Levels and how you can work with them on a practical level. Introduction to Paranoia Levels In essence, the Paranoia Level (PL) allows you to define how aggressive the Core Rule Set is. Very often, I explain this with the help of a dog. In the default installation, you get a family dog that is really easy going. It is a breed that causes no trouble. Bring your neighbour’s kids and have them pull the dog by its tail and he won’t bite.
CRS protecting users from Apache CVE-2021-41773
Version 2.4.49 of the Apache webserver is affected by a path traversal vulnerability. This caught a lot of people on the left foot. Well not those who protect their services with CRS. CRS has your back for this new exploit too - as very often. There are a lot of proof of concept exploits for this vulnerability around now. All proof of concepts I saw work via hex encoding the dot-character as %2e. That means you can disguise a classical path traversal using dots as follows:
CVE-2021-35368 - CRS Request Body Bypass (Update)
There is a severe security issue in our rule set. It has been present since the release of CRS 3.1.0 and was recently brought to our attention. Here is the official advisory that we are also publishing as CVE-2021-35368 via MITRE (as usual, MITRE will take a few days until they publish this). Offical Advisory for CVE-2021-35368 The OWASP ModSecurity Core Rule Set (CRS) is affected by a request body bypass that abuses trailing pathname information. A backend vulnerability can thus be exploited despite being protected with the CRS Web Application Firewall rule set when an application server accepts additional path info as part of the request URI. All known CRS installations that offer the predefined CRS rule exclusion packages are affected. This applies to end-of-life CRS versions 3.0.x, 3.1.0, 3.1.1 as well as the currently supported versions 3.2.0 and 3.3.0. Integrators and users are advised to upgrade to 3.1.2, 3.2.1 and 3.3.2 respectively.
Upcoming CRS Security Releases
A security problem with the OWASP ModSecurity Core Rule Set has been brought to our attention recently. The CRS team is now working on a fix that will be released on Wednesday as 3.1.2, 3.2.1 and 3.3.2. We will make sure to keep the changeset of these bugfix releases minimal in order to allow fast patching. MITRE has assigned the number CVE-2021-35368 to this weakness. We consider the severity of the vulnerability to be HIGH.
A new attempt to combine the CRS with machine learning
The following is a contributing blog post by Floriane Gilliéron. You can reach Floriane via firstname dot lastname at gmail.com. My Master Thesis from EPFL tackled the challenge of using machine learning to improve the performance of a ModSecurity web application firewall, used with the OWASP Core Rule Set. The initiators of the project were concerned about the high number of false alerts (around 90 per day) issued by their WAF, which from a business point of view did not allow the use of blocking mode. The project was also motivated by the fact that it’s now a common thing to rely on machine learning in web application security, like big WAF vendors such as F5 or Fortinet do.
Introducing the Dev on Duty Program
CRS is an open source project that struggles to address the issues reported by the community just like so many other open source communities. Everybody enjoys to develop new features (rules!), but grinding away at solving false positives is not necessarily a favorite past time for us. We are falling behind with providing solutions to reported shortcomings of the rule set, we lose sight of feature requests and unfortunately there are even queries that go unanswered.
Announcing a partnership with NGINX
The OWASP ModSecurity Core Rule Set (CRS) project is proud to announce its first Gold Sponsor: NGINX. CRS is a set of generic attack detection rules for use with ModSecurity or compatible web application firewalls that is distributed under an Open Source license. Dubbed the first line of defense, CRS is the most widspread WAF rule set on the internet protecting more than 100 TBit/s of traffic globally. NGINX is the Open Source (OSS) web server, reverse proxy and API gateway, that today powers over 400 million websites. NGINX provides a number of solutions bundled with NGINX OSS, including web application firewalls (WAFs), a Kubernetes Ingress Controller, a Service Mesh, and a controller with Application Delivery Controller (ADC), Application Security and API-Management capabilities.
Disabling Request Body Access in ModSecurity 3 Leads to Complete Bypass
If you are running ModSecurity 3 with request body access disabled, then I have some bad news. Please sit down, this will be a while. If you are running ModSecurity 2, or you give the engine access to the request body, then you are not affected. But maybe you want to read this post nevertheless. I’ll be discussing a new ModSec3 vulnerability an upcoming new CRS feature and some fundamental problems affecting existing ModSecurity rule sets.
Introducing msc_retest
Debugging CRS and more generally debugging ModSecurity can be nasty. False Positives are the worst, but also nagging performance problems can spoil the fun. Sometimes you have network problems or the whole architecture is botched. But equally often it’s simply your server or ModSecurity that’s misbehaving. This blog post is about msc_retest, a small family of tools that lets you performance test the regular expression engine used inside various ModSecurity versions. As of this writing, the engine is PCRE everywhere, but we expect more options in the future.
OWASP ModSecurity Core Rule Set v3.3.1 Release Candidate 1 available
The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 1 for the upcoming CRS v3.3.1 release. The release candidate is available at: https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.1-rc1.zip This is a maintenance release, containing the following changes: Run rules as early as possible, by decreasing phase:2 to phase:1 and phase:4 to phase:3 where the variables allow it (Ervin Hegedüs) Add early blocking mode (tx.blocking_early) to block at the end of phase:1 and phase:3 (Christian Folini) There are no changes to attack detections, so this release is mostly a “drop-in” replacement for our former release 3.3.0. If you are already running v3.3.0, you can simply extract the files over your existing files.
CVE-2020-15598 - ModSecurity v3 Affected By DoS (Severity HIGH)
The OWASP ModSecurity Core Rule Set (CRS) team has identified a Denial of Service vulnerability in the underlying ModSecurity engine. This affects all releases in the ModSecurity v3 release line. The vendor Trustwave Spiderlabs did not release an update yet. However, we are providing users with a patch for ModSecurity and a workaround if they can not patch. Likewise, we are coordinating the patching with the Linux distributors. This blog post tries to give you a comprehensive overview of the problem with all the resources you need to cope with the situation.
Introducing msc_pyparser
Let us present msc_pyparser to you. It is a python library that lets you manipulate ModSecurity rules configuration files. ModSecurity has decent capabilities to manipulate rules at runtime, but msc_parser lets you manipulate the config files themselves. This is useful in many situations and the longer we use it, the more use cases pop up. We will walk you through four example use cases in this blog post. This is enough to get you inspiration and help you get started.
OWASP ModSecurity Core Rule Set v3.3.0 available
The OWASP ModSecurity Core Rule Set team is proud to announce the final release for CRS v3.3.0. For downloads and installation instructions, please see the Installation page. This release packages many changes, such as: Block backup files ending with ~ in filename (Andrea Menin) Detect ffuf vuln scanner (Will Woodson) Detect Nuclei vuln scanner (azurit) Detect SemrushBot crawler (Christian Folini) Detect WFuzz vuln scanner (azurit) New LDAP injection rule (Christian Folini) New HTTP Splitting rule (Andrea Menin) Add .swp to restricted extensions (Andrea Menin) Allow CloudEvents content types (Bobby Earl) Add CAPEC tags for attack classification (Fernando Outeda, Christian Folini) Detect Unix RCE bypass techniques via uninitialized variables, string concatenations and globbing patterns (Andrea Menin) Many improvements to lower the number of false positives and improve attack detections Important upgrade notes:
OWASP ModSecurity Core Rule Set v3.3.0 Release Candidate 2 available
The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 2 for the upcoming CRS v3.3.0 release. The release candidate is available at: https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc2.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc2.zip This release packages many changes, such as: Block backup files ending with ~ in filename (Andrea Menin) Detect ffuf vuln scanner (Will Woodson) Detect SemrushBot crawler (Christian Folini) Detect WFuzz vuln scanner (azurit) New LDAP injection rule (Christian Folini) New HTTP Splitting rule (Andrea Menin) Add .swp to restricted extensions (Andrea Menin) Allow CloudEvents content types (Bobby Earl) Add CAPEC tags for attack classification (Fernando Outeda, Christian Folini) Detect Unix RCE bypass techniques via uninitialized variables, string concatenations and globbing patterns (Andrea Menin) Important note: The format of configuration setting allowed_request_content_type has been changed to be more in line with other variables. If you had manually changed this setting, then you need to update this configuration setting. Please see the example rule 900220 in crs-setup.conf.example. If you didn’t change this setting, you don’t need to do anything.
Overhauling the CRS Tags
Tagging rules is a great feature of ModSecurity since it allows you to add information to your ModSec alert messages. In my tutorial on Embedding ModSec over at netnea.com, I use the tag feature in the default action to add a tag to every alert message from a given service. I do this as follows: SecDefaultAction "phase:2,pass,log,tag:'Local Lab Service'" One of my customers uses a shortcut URI as the tag. So when an alert pops up, the SoC person can click on the tag, the URI is being expanded (redirection service) and she ends up on a wiki page giving her all the infos about a given service with purpose, architecture, host IDs, security classification and contact information.
OWASP ModSecurity Core Rule Set v3.3.0 Release Candidate 1 available
The OWASP ModSecurity Core Rule Set team is proud to announce the release candidate 1 for the upcoming CRS v3.3.0 release. The release candidate is available at: https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc1.tar.gz https://github.com/coreruleset/coreruleset/archive/v3.3.0-rc1.zip This release packages many changes, such as: New rule to detect LDAP injection New HTTP Splitting rule Block backup files ending with ~ in filename Detect ffuf, Semrush and WFuzz scanners Updated exclusion profiles for Nextcloud, WordPress and XenForo Improvements to many patterns to improve detection and lower false alarms Important note: The format of configuration setting allowed_request_content_type has been changed to be more in line with other variables. If you had manually changed this setting, then you need to update this configuration setting. Please see the example rule 900220 in crs-setup.conf.example. If you didn’t change this setting, you don’t need to do anything.
CRS Repository at New Location
We have successfully migrated our GitHub repository to a new location at https://github.com/coreruleset/coreruleset Trustwave SpiderLabs hosted the OWASP ModSecurity Core Rule Set project under their umbrella for many years. They acted as stewards of our project and also directed it via the former lead Ryan Barnett. Yet as a formally independent OWASP project, it is a bit odd to dwell under a commercial entity and for a commercial entity like Trustwave SpiderLabs, it is a bit odd to host a project that they do not control.
CVE-2019-19886 - HIGH - DoS against libModSecurity 3
The ModSecurity 3.0.x release line suffers from a Denial of Service vulnerability after triggering a segmentation fault on the webserver when parsing a malformed cookie header. All users of ModSecurity 3.0.0 - 3.0.3 should update to ModSecurity 3.0.4 as soon as possible. ModSecurity 2.x is not affected. The CVSS score for the vulnerability is 7.5 (HIGH). MITRE lists the vulnerability as CVE-2019-19886 (but as of this writing, it is only reserved). The OWASP ModSecurity Core Rule Set (CRS) project makes heavy use of unit tests. One of the goals is making sure that all our rules behave as intended on the underlying ModSecurity engine. ModSecurity 2.9 on Apache is our reference platform that passes our expanding list of over 2300 tests.
CRS Project News January 2020
It’s been a while since the last CRS project news. It’s not because there was nothing to report. It’s more like too much going on and no time to sit back and write it all down. Here are the most important things that happened since the last edition: ModSecurity 3.0.4 has been released for NGINX. This is a security release covering a problem our project members @airween and @theMiddle have discovered. Trustwave has asked us to withhold any details for the moment, but the release of the full CVE is planned for next week. Packaging is under way as far as we can tell. If you are running ModSec3, then we strongly advise you to update ASAP and we’ll probably follow up with a separate blog post once the details are published. Link: https://sourceforge.net/p/mod-security/mailman/message/36899090/
Running a few dozens of new magic XSS payloads against CRS 3.2
Earlier today, Gareth Heyes presented a very interesting talk with dozens of new XSS payloads at the OWASP GlobalAppSec conference in Amsterdam. The CRS developers in the audience immediately started to try out the payloads, but Gareth was so quick they lost track… But being the helpful person he is, he published the slides during the evening. Thank you. This allowed us to go to business. We extracted 73 payloads from the presentation, submitted them against a vanilla CRS installation with the new send-payload-pls.sh script, that comes with CRS 3.2 (released on Tuesday), and we found that there is indeed one new payload, that we are not catching in a CRS default installation:
Announcement: OWASP ModSecurity Core Rule Set Version 3.2.0
The OWASP ModSecurity Core Rule Set team is proud to announce the general availability of the OWASP ModSecurity Core Rule Set Version 3.2.0. The new release is available for download here. This release represents a very big step forward in terms of both capabilities and protections including: Improved compatibility with ModSecurity 3.x Improved CRS docker container that is fully configurable at creation Expanded Java RCE blacklist Expanded unix shell RCE blacklist Improved PHP RCE detection New javascript/Node.js RCE detection Expanded LFI blacklists Added XenForo rule exclusion profile Fixes for many false positives and bypasses Detection of more security scanners Regexp performance improvements preventing ReDoS in most cases Please see the CHANGES document with around 150 entries for a detailed list of new features and improvements: https://github.com/coreruleset/coreruleset/blob/v3.2.0/CHANGES
How the CRS protects the vulnerable web application Pixi by OWASP DevSlop
How could the functionality of a WAF be better demonstrated than with a vulnerable web application? In this blog post I introduce Pixi, an intentionally vulnerable web application by the OWASP project DevSlop. I show its known vulnerabilities and examine how the CRS protects against these vulnerabilities. What is Pixi? Pixi is a deliberately vulnerable web application that is part of the OWASP DevSlop project. Beside Tanya Janca, Nicole Becher and Nancy Gariché I am also part of this project. DevSlop is a training ground for DevSecOps. In addition to Pixi, DevSlop also offers many YouTube shows, blog posts and different modules on various security topics!
Announcement: OWASP ModSecurity Core Rule Set Version 3.2.0-RC2
The OWASP ModSecurity Core Rule Set team is proud to announce the general availability of release candidate 2 for the upcoming CRS v3.2.0. The new release is available at https://github.com/coreruleset/coreruleset/archive/v3.2.0-rc2.zip https://github.com/coreruleset/coreruleset/archive/v3.2.0-rc2.tar.gz This release represents a very big step forward in terms of both capabilities and protections including: Improved compatibility with ModSecurity 3.x Improved CRS docker container that is fully configureable at creation Expanded Java RCE blacklist Expanded unix shell RCE blacklist Improved PHP RCE detection New javascript/Node.js RCE detection Expanded LFI blacklists Added XenForo rule exclusion profile Fixes for many false positives and bypasses Detection of more security scanners Regexp performance improvements preventing ReDoS in most cases Please see the CHANGES document with around 150 entries for a detailed list of new features and improvements. https://github.com/coreruleset/coreruleset/blob/v3.2.0-rc2/CHANGES
How the CRS optimizes regular expressions
As many of you have noticed, the Core Rule Set contains very complex regular expressions. See for example rule 942480: (?i:(?:\b(?:(?:s(?:elect\b.{1,100}?\b(?:(?:(?:length|count)\b.{1,100}?|.*?\bdump\b.*)\bfrom|to(?:p\b.{1,100}?\bfrom|_(?:numbe|cha)r)|(?:from\b.{1,100}?\bwher|data_typ)e|instr)|ys_context)|in(?:to\b\W*?\b(?:dump|out)file|sert\b\W*?\binto|ner\b\W*?\bjoin)|... These regular expressions are assembled from a list of simpler regular expressions for efficiency reasons. See regexp-942480.data for the source expressions which were combined to form this expression. A single optimized regular expression test takes much less time than a series of simpler regular expression tests. By combining related patterns in one rule, we lower our number of rules, which helps to keep the code base compact. The downside is readability and ease of development.
CRS Project News August 2019
Life is interfering and the rhythm of the CRS news is not what I would like it to be. Three months since the last edition. But the advantage is of course, that there are more news to talk about once I get to write it all up. What has happened in recent weeks The OWASP Honeypot project that is based on CRS is running a Google Summer of Code project, that aims for an up do date containerization of the honeypot. O’Reilly is distributing a free 40 pages brochure about “Defense in Depth” by Stephen Gates. CRS is featured prominently on page 22: “Today, most WAF vendors have implemented the OWASP ModSecurity Core Rule Set (CRS), which contains generic attack detection rules for use with ModSecurity or compatible WAFs.” Link: https://www.oreilly.com/library/view/modern-defense-in/9781492050360 Zevenet has patched the traditional - but rather exotic - reverse proxy Pound to work with ModSecurity 3 and thus with CRS. Link: https://github.com/zevenet/pound The pressing ReDoS problems that resulted in 5 (!) CVEs issued against CRS could be solved with the release of 3.1.1 that is functionally equivalent to 3.1.0 and does not suffer from the problems. We also found out, that 4 of the 5 CVEs were bogus and the 5th is only exploitable in few installations. We are talking to Mitre, but they have not been really very forthcoming so far. A word of caution: This does not mean that there are no more ReDoS problems in CRS. We are working through the rules and we think we have identified most problematic rules, but ReDoS is nasty as long as you run on PCRE and we are not quite ready to support an alternative engine like RE2 (but we are working on it; see below). Link: https://coreruleset.org/20190627/announcement-owasp-modsecurity-core-rule-set-version-3-1-1/. There is a new, bi-monthly CRS / ModSecurity Meetup in Bern, Switzerland. The first edition ran on June 26 2019 and we got 14 people together in the room. Link: http://web.archive.org/web/20200807130543/https://www.puzzle.ch/de/blog/articles/2019/07/02/erstes-treffen-der-crs-community-in-bern Brian Krebs blogged about the CapitalOne breach and blamed it on an SSRF (server-side request forgery) on the ModSecurity WAF running CRS. However, this is likely wrong as a more detailed blog post at AppSecco explained. It’s rather a SSRF that CRS did not block. Either because it was not detected (that is quite likely, as SSRF is really hard to detect with generic rules) or because the WAF was in monitoring mode. Link: https://krebsonsecurity.com/2019/08/what-we-can-learn-from-the-capital-one-hack/ https://blog.appsecco.com/an-ssrf-privileged-aws-keys-and-the-capital-one-breach-4c3c2cded3af?gi=97a1dfb34c64 We did our monthly CRS project chats. Here are the agendas and the brief protocols. Link: https://github.com/coreruleset/coreruleset/issues/1402 (May) https://github.com/coreruleset/coreruleset/issues/1443 (June) https://github.com/coreruleset/coreruleset/issues/1471 (July) https://github.com/coreruleset/coreruleset/issues/1496 (August) Significant pull requests that were merged There have been several PRs that dealt with ReDoS problems in multiple rules. We are cleaning CRS from PCRE-specific back-tracking, that is not supported in alternative implementations like RE2, which is a lot safer with regards to ReDoS. The SQLi libinjection check has been added for the last path segment Link: https://github.com/coreruleset/coreruleset/pull/1492 A new rule exclusion profile for XenForo has been contributed: Link: https://github.com/coreruleset/coreruleset/pull/1403 Massive Updates for the CRS docker container that brings easier integration and easy configurability via ENV variables (Think Anomaly score limits, paranoia levels, backend address). Link: https://github.com/coreruleset/coreruleset/pull/1457 https://github.com/coreruleset/coreruleset/pull/1455 https://github.com/coreruleset/coreruleset/pull/1454 https://github.com/coreruleset/coreruleset/pull/1453 Things that are meant to happen in the coming weeks or thereafter We are planning to release CRS 3.2. Release manager Walter Hop confirmed the following plan: Freeze on August 19, RC1 on August 26, RC2 on September 8, release on September 24. Link: https://github.com/coreruleset/coreruleset/issues/1496#issuecomment-518348210 The next CRS / ModSecurity meetups in Bern, Switzerland, will be on August 28 and thereafter on October 30. On August 28, we’ll talk about Paranoia Levels in Practice. The program for October 30 has not been fixed yet. Link: https://www.meetup.com/CRS-ModSecurity-Meetup-Bern We are hosting a CRS Community Summit on September 25 at the RAI in Amsterdam. This is the last training day at the OWASP AppSec Global conference. This is meant for users of CRS, for integrators and committers of our project. Entry to the summit is free, but it makes sense to combine with the AppSec conference the next day (of course, if you make the trip to the Netherlands). The Summit will start in the early afternoon and we are going to have a dinner together afterwards. Please get in touch if you plan to attend, so we can accomodate enough seats at the RAI (and at the restaurant afterwards): Link: christian.folini / at / owasp.org Christian Folini is going to present at the OWASP AppSec Global conference in Amsterdam on September 26 / 27. His talk will be about Practical CRS in high security settings. Link: https://ams.globalappsec.org Important pull requests in the queue There is a PR for a new rule aiming at insecure unserialization in NodeJS. This is meant to be the first rule in a new rule group (REQUEST-934-APPLICATION-ATTACK-NODEJS.conf) that is going to be released together with CRS 3.2 according to plan. Link: https://github.com/coreruleset/coreruleset/pull/1487 Not much more of much importance is in the queue. We have been very active with merging those last few weeks. There are just a few bugfixes here and there plus more tests. News assembled by Christian Folini, CRS Co-Lead.
Announcement: OWASP ModSecurity Core Rule Set Version 3.1.1
The OWASP ModSecurity Core Rule Set team is pleased to announce the CRS release v3.1.1. This is a minor release fixing a Regular Expression Denial of Service weakness (CVE-2019-11387) as well as some minor bugs and false positives. The CVE is only affecting users of the libModSecurity 3 release line and only under special circumstances. However, we advise all users to upgrade to this latest stable CRS release. We have been notified of 5 ReDoS problems in our rules in April. Upon closer inspection, only 1 of them proved real (the others were found in the naked regular expression, not taking payload transformation and protection mechanisms of the engine into consideration). Once this was established, we had to fix the regex without changing the detection capabilities of the affected rules. And this is what took us so long.
CRS Project News May 2019
We are back with the CRS project news. There was not too much to talk about in recent weeks, but now there is real content. So here we go. What has happened in recent weeks Security researcher Somdev Sangwan has looked into Regular Expression Denial of Service attacks. It is a more or less well known fact, that CRS suffers from this problem. Usually, it is no big deal as ModSecurity 2 used to protect from this type of attack. However, this protection is gone with ModSecurity 3. Somdev Sangwan had 5 (!) CVE against CRS created. Yet we came to the conclusion, that only one of them (👉 CVE-2019-11387) is directly exploitable and only on ModSecurity 3 at paranoia level 2 or higher. The problem is situation in two separate rules. We are now working on a solution for this issue. Links: https://nvd.nist.gov/vuln/detail/CVE-2019-11387 https://github.com/coreruleset/coreruleset/issues/1359 https://portswigger.net/daily-swig/unpatched-modsecurity-crs-vulnerabilities-leave-web-servers-open-to-denial-of-service-attacks https://coreruleset.org/20190425/regular-expression-dos-weaknesses-in-crs/ CRS contributor Airween has made a big effort to make sure that ModSecurity 3 passes the CRS test suite. He fixed several ModSec bugs along the way (not all of them merged yet) and he has been 100% successful with ModSec3 in combination with the Apache connector. With the nginx connector, he is really close. Please note that this means, that none of the released ModSec 3 versions are able to pass the CRS 3 test suite so far. There was very little interest among the CRS developers to go to Tel Aviv in order to hold our CRS community summit during the OWASP AppSec Global conference there later in May. We have thus decided to shift our reunion to September and the OWASP AppSec conference in Amsterdam. James Walker from Portswigger / Daily Swig covered the ongoing development with ModSecurity in an online article. Link: https://portswigger.net/daily-swig/waf-reloaded-modsecurity-3-1-showcased-at-black-hat-asia We are very happy to welcome Andrea Menin / theMiddleBlue / MeninTheMiddle as a CRS developer with commit rights. The latter took a fair bit of time, but the joy is even bigger now. There is a fairly new ModSecurity integration into the Envoy Proxy on Kubernetes. We have not tested it yet, though. Link: https://github.com/octarinesec/ModSecurity-envoy Significant pull requests that were merged Extended the list of shell commands that we detect (Co-Lead Chaim Sanders) Link: https://github.com/coreruleset/coreruleset/pull/1325 New rule 942500: SQLi bypass via MySQL comments (Developer Franziska Bühler) Link: https://github.com/coreruleset/coreruleset/pull/1326 Fixed problems with SOAP encodings (Developer Christoph Hansen) Link: https://github.com/coreruleset/coreruleset/pull/1332 Added the gobuster security scanner (Contributor Brent Clark) Link: https://github.com/coreruleset/coreruleset/pull/1375 Things that are meant to happen in the coming weeks or thereafter Tin Zaw from Verizon is presenting CRS at the OWASP project showcase at the AppSec conference in Tel Aviv. 3.1.1 is meant to be released with a backported fix for CVE-2019-11387 as soon as we have the fix. Important pull requests in the queue Several PRs to solve the open CVEs. Yet many of these PRs come with a change of behaviour and we would like to avoid that. Link: https://github.com/coreruleset/coreruleset/pull/1355 https://github.com/coreruleset/coreruleset/pull/1361 https://github.com/coreruleset/coreruleset/pull/1362 Remove Warning from php-errors.data as all the warnings are already covered by other strings. Link: https://github.com/coreruleset/coreruleset/pull/1343 Add AngularJS client side template injection #1340 Link: https://github.com/coreruleset/coreruleset/pull/1340 SQLi bypass detection: ticks and backticks #1335 Link: https://github.com/coreruleset/coreruleset/pull/1335
Regular Expression DoS weaknesses in CRS
Somdev Sangwan has discovered several Regular Expression Denial of Service (ReDoS) weaknesses in the rules provided by the CRS project. They are listed under the following CVEs: CVE-2019–11387 CVE-2019–11388 CVE-2019–11389 CVE-2019–11390 CVE-2019–11391 The fact that CRS is affected by ReDoS is not particularly surprising and truth be told, we knew that was the case. We just have not solved it yet - or have not been able to solve it yet.
CRS Project News February 2019
We are back with the CRS project news. The news are running very, very late in the month as I’ve been held up with other projects. What has happened in recent weeks Miyuru Sankalpa has started to publish a transformed GeoIP database in the legacy format readable by ModSecurity 2.x under a creative commons. This seems to be based on the MaxMind databases and it is not clear if MaxMind endorses this initiative. Link: https://www.miyuru.lk/geoiplegacy CRS developer Andrea Menin has released a set of ModSecurity rules that complement CRS when protecting WordPress. Link: https://github.com/Rev3rseSecurity/wordpress-modsecurity-ruleset Andrea Menin has also written a tutorial about DNS over HTTPS and how to protect and integrate it using ModSecurity. Link: https://www.secjuice.com/modsecurity-web-application-firewall-dns-over-https/ Microsoft has forked ModSecurity 2.x on github and it is (according somebody working on the project) working on patches that allow better integration with the Azure Cloud. Link: https://github.com/Microsoft/ModSecurity CRS developer Franziska Bühler has integrated CRS together with the Pixie learning app into a new docker container. This allows for easy training sessions and checking out attacks against the naked Pixie and the one protected by CRS. Link: https://github.com/DevSlop/pixi-crs-demo Significant pull requests that were merged CRS developer Andrea Menin contributed a rule to prevent PHP rule bypasses via variable functions. Link:https://github.com/coreruleset/coreruleset/pull/1294 Github user siric1 contributed a rule exclusion that brings support for the WordPress Gutenberg editor. Link: https://github.com/coreruleset/coreruleset/pull/1298 CRS co-lead Walter Hop added the “Jorgee” to the list of security scanners detected by CRS. Link: https://github.com/coreruleset/coreruleset/pull/1307 CRS co-lead Walter Hop added the “ZGrab” to the list of security scanners detected by CRS. Link: https://github.com/coreruleset/coreruleset/pull/1305 Things that are meant to happen in the coming weeks or thereafter The Core Rule Set project will participate at the Cloudfest Hackathon in Germany from March 23 - 25 under the direction of Walter Hop and Christoph Hansen. The idea is to develop rules, rule exclusions and documentation to allow easier integration of CRS for internet hosters. Registration is open. Link: https://www.cloudfest.com/hackathon The Core Rule Set project will hold a Community Summit on Tuesday May 28, the day before the OWASP AppSecGlobal in Tel Aviv. This will follow the same format of the Community Summit we did at AppSecEU in London in 2018. Details pending. Swiss Post is runing a public intrusion against its Online-Voting system, that is protected by the Core Rule Set as a first layer of defense. The test runs from February 25 to March 24, 2019. Link: https://www.evoting-blog.ch/en/pages/2019/public-hacker-test-on-swiss-post-s-e-voting-system The next Monthly Community Chat will be held on Monday March 4, 2019, at 20:30 CET in the #coreruleset channel in the OWASP Slack. A link to a slack invite can be found in the agenda linked below. Please use this agenda issue on github to schedule topics for discussion. Link: https://owasp.slack.com Link: https://github.com/coreruleset/coreruleset/issues/1314 Important pull requests in the queue CRS developer Federico Schwindt contributed a rule to detect when Content-Length and Transfer-Encoding are sent in the same request. Link: https://github.com/coreruleset/coreruleset/pull/1310 CRS developer Federico Schwindt wants to add the request path to the targets of rule 941110 (XSS Filter - Category 1: Script Tag Vector). Link: https://github.com/coreruleset/coreruleset/pull/1306 CRS developer Federico Schwindt contributed a patch where he aims to improve the java detection rules. Link: https://github.com/coreruleset/coreruleset/pull/1287
CRS Project News January 2019
We are back with the CRS project news. We’re attending the Cloudfest Hackathon in March in Germany and we have plans for another CRS Community Summit at the new OWASP AppSec Global conference in Tel Aviv at the end of May (formerly OWASP AppSecEU). What has happened in recent weeks We have reached 1500 stars on GitHub and adding more every day in a nice exponential curve. This makes us one of the most popular OWASP projects on GitHub. Link: https://seladb.github.io/StarTrack-js/?u=SpiderLabs&r=owasp-modsecurity-crs CRS contributor Ervin Hegedüs, supported by Andrea Menin and Walter Hop, is working hard to get the CRS FTW tests to pass with ModSecurity 3 on NGINX and ModSecurity 3 on Apache. These tests are important for including Nginx with ModSecurity 3 in the next Debian release. CRS is currently using ModSecurity 2.9 on Apache as reference platform, but we need to open up for ModSecurity 3 as it is slowly maturing. Ervin and Andrea have now reached a state where over 90% of the tests pass, but they may have also discovered a bug or two in ModSecurity 3. When the work on Debian is done, we will set up our Continous Integration via Travis to run our tests against multiple platforms. Angelo Conforti published an interesting piece of code that allows to generate ModSecurity Whitelisting rules based on a Swagger definition. This could be very interesting for securing APIs on top of CRS. This is a work in progress, but it looks promising and I am sure testing is welcome. Link: https://github.com/angeloxx/swagger2modsec Significant pull requests that were merged When we stated development had picked up nicely after the release 3.1 the statement contained a lot of hope. But looking over the last four weeks makes it clear that we have indeed accelerated.
CRS Project News December 2018
I hope everybody has a few calm days to finish the year. CRS is finishing the year enjoying the 3.1 release and an adjustment to the PHP rules that closes a nasty hole in the detection. What has happened in recent weeks CRS 3.1 has been released bringing new rules to detect Java injections and an easier way to deal with paranoia levels. More changes in the announcement. Link: https://coreruleset.org/20181128/announcement-owasp-modsecurity-core-rule-set-version-3-1-0/ CRS Co-Lead Christian Folini taught two CRS crash courses together with David Jardin from Siwecos in Bern and Zurich, Switzerland. The course was sponsored by Switch (The Swiss NIC) and addressed internet hosters. One result was a new initiative to run a workshop at the Cloudfest conference in late March to come up with a CRS profile that works for internet hosters. There will be a separate announcement, when we know more. CRS committer Franziska Bühler pubished a blog post introducing the extensions for the official CRS docker container that she developed. The extensions allow you to configure a CRS container including the backend connection from the command line. Link: https://coreruleset.org/20181212/core-rule-set-docker-image/ CRS Co-Lead Christian published an asciinema demo video illustrating Franziska’s work. Link: https://asciinema.org/a/0JDnaO1Wi42sIYpgJzoYbCdtn The American company Gridvision published a success story how they secured their WordPress setup with CRS. Link(Outdated): “gridvision.net/projects/nginx-modsecurity-and-project-honeypot” CRS contributor TheMiddle published a blog post with WAF bypasses aiming for PHP. As usual, CRS was doing better than many other WAFs, but there is a particularly sinister bypass we did not detect in lower paranoia levels (more news about this below). Link: https://www.secjuice.com/php-rce-bypass-filters-sanitization-waf/ Significant pull requests that were merged With the 3.1 release out the door, the development for 3.2 was immediately revived. Pull requests are coming in nicely now.
Core Rule Set Docker Image
The Core Rule Set is installed in just four steps, as described in the Installation Guide. Now, it’s even easier using the CRS Docker container. The effort to start the CRS in front of an application is reduced to a few seconds and only one command. Franziska Bühler, one of the CRS developers, enhanced the official CRS container. Various CRS variables and the backend application to be protected can be configured using this enhanced container.
Announcement: OWASP ModSecurity Core Rule Set Version 3.1.0
The OWASP Core Rule Set team is happy to announce the CRS release v3.1.0 at last. A wee bit over 2 years in the making, this major release represents a big step forward in terms of capabilities, usability and protection. Key features include: A new set of rules defending against Java injections Initial set of file upload checks Add built-in exceptions for Dokuwiki, Owncloud, Nextcloud and CPanel Easier handling of the paranoia mode Many false positives fixed Successful source code archaeology with regular expressions Detailed rule cleanup for easier maintenance Speed improvements via the removal of unneeded regex capture groups Regression tests for rules, Travis support CRS docker image based on Ubuntu For a complete list of new features and the changes in this release, see the CHANGES document: https://github.com/coreruleset/coreruleset/blob/v3.1/dev/CHANGES
CRS Project News November 2018
The plan is to do this newsletter every month, but it’s already November. The reason is the pending 3.1 release, so I waited for the release to happen and then it did not and suddenly October was over. But now we have a 3.1-RC2 and a strong belief that 3.1 will come out for good on Sunday November 24. What has happened in recent weeks CRS 3.1 RC2 has been released. It brings few bugfixes over 3.1 RC1 and we think it will be very close to the eventual stable 3.1 release. Download: https://github.com/coreruleset/coreruleset/releases/tag/v3.1.0-rc2 The CRS project has decided to prioritize 3.1 and abandon the 3.0 release line. So there won’t be a 3.0.3 release. The development has been slow with picking up again. We’re working on the 3.2/dev branch but it feels like the pending 3.1 is keeping the project back. Link: https://github.com/coreruleset/coreruleset libModSecurity 3.0.3 has been released. This is a release focues on code readability, resilience and performance. This is an important move as ModSecurity 3.0.2 has been breaking CRS 3.1 and we worked very hard on the ModSecurity developers to have them release 3.0.3 before we do our 3.1. (The delay with our 3.1 release is entirely our fault, though.) Link: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.3 Link: https://github.com/SpiderLabs/ModSecurity/releases/tag/v3.0.3/CHANGES We shifted the monthly community chat from IRC to the #coreruleset channel on the OWASP Slack. CRS developer Christoph Hansen has published a script to convert the modern GeoIP database into the legacy format that ModSecurity 2.x supports. This solves a major problem for many users. https://github.com/emphazer/GeoIP_convert-v2-v1 Linux Journal article on ModSec / CRS on NGINX Link: https://www.linuxjournal.com/content/modsecurity-and-nginx Mikhail Golovanov has published an article about ModSecurity rule verification. Among many interesting ideas, he also demonstrates a way to create payloads from a regular expression in a rule. Link: https://waf.ninja/modsecurity-rules-verification/ The Company Approach from Belgium has released the source code for an Apache module that brings a new transformation to ModSecurity: t:bash. Ideally, this source code will be integrated into ModSecurity, and ultimately be supported by CRS, but we are quite far from that. You can use it immediately for your own rules, though. Link: https://www.approach.be/en/modsecurity.html Significant pull requests that were merged Java rules bug that the last news reported about has been fixed. Link: https://github.com/coreruleset/coreruleset/pull/1198 Link: https://github.com/coreruleset/coreruleset/issues/1185 Several typos in variable names have been spotted and fixed (Victor Hora) Link: https://github.com/coreruleset/coreruleset/pull/1187 Dropped the keyword “exit” from both, Unix and Windows RCE rules (Federico Schwindt) Link: https://github.com/coreruleset/coreruleset/pull/1204/files Bugfix with new paranoia level counters (Federico Schwindt) Link: https://github.com/coreruleset/coreruleset/pull/1196 Things that are meant to happen in the coming weeks We plan to release CRS 3.1 on Sunday November 24. There are going to be two separate one-day ModSecurity / CRS courses for ISPs / Hosters focusing on CMS. Christian Folini and David Jardin from SIWECOS will teach both courses on invitation by SWITCH. The first course will be on December 5 in Bern, Switzerland and the second course will be on December 6 in Zurich, Switzerland. Link: https://swit.ch/CMS_Bern Link: https://swit.ch/CMS_Zurich CRS developer Franziska Bühler is working on her docker container. She is adding CLI support for all the CRS variables during “docker create”. This means you will be able to create and configure a CRS WAF container on the fly with a one-liner. This is meant to be merged into the official CRS docker container eventually. Link: https://hub.docker.com/r/franbuehler/modsecurity-crs-rp/ The next Monthly Community Chat will be held on December 3, 2018, at 20:30 CET in the #coreruleset channel in the OWASP Slack. A link to a slack invite can be found in the agenda linked below. Please use this agenda issue on github to schedule topics for discussion. Link: https://owasp.slack.com Link: https://github.com/coreruleset/coreruleset/issues/1238 CRS developer Felipe Zipitria has volunteered to come up with a proposal to have CRS swag produced via an online print-on-demand shop. Desired items include posters, stickers, buttons, T-Shirts, ideally the full program. Link: https://github.com/OWASP/owasp-swag Important pull requests in the queue TheMiddleBlue suggests to add additional PHP wrappers to our data file. Still not merged. Link: https://github.com/coreruleset/coreruleset/pull/1172 Manuel Spartan suggests to add missing Java Classes. Link: https://github.com/coreruleset/coreruleset/pull/1156
Join us on the OWASP Slack!
Are you interested in hanging out with the CRS developers? Giving your input on CRS development issues? Chatting about the wonderful world of WAFs? Then this is your chance! At OWASP AppSecEU 2018, we have started the #coreruleset channel in the OWASP Slack. This has turned out to be a good place for exchanging ideas and working together in real time. So, we’ve settled in and we invite anyone to join us there.
CRS Project News September 2018
We skipped the monthly news in August as the 3.1-RC release had been delayed into September. But here we go again with the mostly monthly newsletter of the CRS project. The most important news is the publication of the release candidate 1 for CRS 3.1. What has happened in recent weeks CRS 3.1 RC1 has been released. The most important changes: Protections against common Java attacks Support for blocking in one paranoia level while logging in a higher level. More pre-made exclusion packs for popular web applications Reconstructed and improved SQL injections protections Various bug fixes and optimizations Announcement: http://web.archive.org/web/20230830054004/https://lists.owasp.org/pipermail/owasp-modsecurity-core-rule-set/2018-September/002586 Download: https://github.com/coreruleset/coreruleset/releases/tag/v3.1.0-rc1 The development has been moved to the 3.2/dev branch, some changes will be backported to 3.1. Link: https://github.com/coreruleset/coreruleset Interview with CRS project co-lead Christian Folini on the AppSec podcast Link: https://coreruleset.org/20180809/appsec-podcast-interviewing-crs-project-co-lead-christian-folini/ Webinar on ModSecurity and CRS3 with Owen Garett, Head of Products at NGINX: The webinar covered installation of ModSec3 and CRS3, but also integration and tuning for false positives and performance. It can be watched on demand after registration (link no longer available) There is a missing feature in ModSecurity 3.0.x that makes it choke on the upcoming CRS 3.1 release. There is an official patch available and the development tree of ModSecurity has the fix. But Trustwave has not yet released the ModSecurity with the fix anew. This may mean that users of the officially release ModSecurity 3 software will fail to run CRS 3.1 after our release. Link: https://github.com/SpiderLabs/ModSecurity/issues/1797 Maxmind, the company behind the popular GeoIP database used by ModSecurity ceased to release the legacy format of the database. ModSec 2.9 only supports this legacy version, so users are in a bad position. CRS developer Christoph Hansen posted on the ModSec mailinglist he was able to transpose the new GeoIP database into the old format so he could continue to use it. A blog post is in the making. Link: https://github.com/SpiderLabs/ModSecurity/issues/1727#issuecomment-423612546 The OWASP slack changed the place to get invites. If you want to join us, please get in touch via mail and we’ll send you the link. OWASP says the are overhauling the setup. Significant pull requests that were merged Development has been shifted to the new 3.2 branch, that has been declared master Walter Hop contributed 2 new strings to the list of Java Struts namespaces for use in the new 944130 rule Link: https://github.com/coreruleset/coreruleset/pull/1177 Other than that, everybody is waiting for new issues popping up with the 3.1-RC release but it has been quiet on that front so far. Things that are meant to happen in the coming weeks We plan to release CRS 3.1 in October unless we see any road blockers. There is a strange bug that a PL2 rule among the new Java rules in CRS 3.1-RC1 triggers. If it is a bug, it’s rather a ModSecurity bug, but it’s completely unclear how this is happening as reproduction has been very cumbersome so far. What is clear it happens in connection with chunked transfer encoding of JSON payloads at PL2 and higher. So it is a rather peculiar situation that is relatively rare. Link: https://github.com/coreruleset/coreruleset/issues/1185 Important pull requests in the queue Victor Hora discovered typos in CRS variable names and a discussion about streamlining lower- and uppercase variable names evolved. Link: https://github.com/coreruleset/coreruleset/pull/1187 Franziska Bühler has fixed a relatively annoying bug in the docker image of CRS. Link: https://github.com/coreruleset/coreruleset/pull/1168 TheMiddleBlue suggests to add additional PHP wrappers to our data file. Link: https://github.com/coreruleset/coreruleset/pull/1172
Some Thoughts on why Web Application Firewalls Really Make a Difference
This is a guest piece by Jamie Riden / @pedantic_hacker. Jamie has been doing penetration tests, secure development training and security code review since 2010 - and other kinds of computer-wrangling for much, much longer. Having been a systems engineer, a coder and now a pen-tester, I’d like to take a brief moment of your time to talk about layered defenses; specifically in this case why running a web application firewall is a good idea. In my current job I get engaged to do various forms of pen-testing. Relatively often, we turn up something in a web application that could have been prevented in a couple of ways. Last week for example, I found a lovely old-school OS command injection bug in a single parameter of a reasonable-sized website.
Web Application Firewall (WAF) Evasion Techniques #3 [x-post]
This article explores how to use an uninitialized Bash variable to bypass WAF regular expression based filters and pattern matching. Let’s see how it can be done on CloudFlare WAF and ModSecurity OWASP CRS3.
AppSec Podcast Interviewing CRS Project Co-Lead Christian Folini
Chris Romeo from the AppSec Podcast did an interview with our own Christian Folini during the AppSecEU conference in July. The 25min interview has been published lately. The interview discusses the project itself, the upcoming 3.1 release, plans to expand beyond ModSecurity and CRS fits into agile development. Here is the link to the interview: https://www.securityjourney.com/blog/crs-and-an-abstraction-layer-s04e02/
CRS Project News July 2018
We are launching the monthly news anew. The idea is to look beyond the pure CRS development again and to bring you additional information that touch on our project. As the editor, I (-> Christian Folini) am planning to release this in the first half of the month. This did not work in July, though, but I have a very cute excuse: She’s called Giovanna and she is only a couple of days old. We’re going to be a bit earlier in August, but also less news apparently.
Reporting from the First CRS Community Summit in London
This is a brief coverage of the CRS Community Summit during AppSecEU in London last week. Over 25 people followed our call for this first face to face meeting of the CRS developer team (6 of 10 developers with commit rights in the same room!) and the community. We have been very happy to have several end users, Trustwave representing the ModSecurity development, but also some of the big integrators in the room. There was AviNetworks, BitSensor, cPanel, Fastly, Kemp, Microsoft, NGINX, Verizon, etc. Finally also researchers and a representative from KISA, the Korean Internet Security Agency, and Ivan Ristić, original developer of ModSecurity for old times sake.
CRS Community Summit next week: Call for Posters and the Program is Ready
The very first meetup of the CRS community is only one week away now and it’s time to announce our program. As stated here on the blog before, this is meant as an opportunity to build ties, to get inspiration from the community and to understand what people are doing with CRS. So there are going to be talks, but there is a lot of room for talking and discussion. So we are going to do a networking / poster session that lives on your contributions. You are invited to bring along a poster, put it up on the wall in our room and we will give you time to present it to our audience. We are interested in use cases, success stories or unique approaches to integrating CRS3. Also ideas and pitches for new projects within our community are welcome. Standard flipchart format. Please be aware you should bring it along in physical form: we can’t print it on site. But we will have tape available for you.
The Core Rule Set as Part of DevOps (CI pipeline)
A Web Application Firewall (WAF) raises concerns that it does not fit into the DevOps methodology. The problem is that when a WAF is added to production, the impact on the application is tested too late. The application developer gets extremely late feedback and the WAF could break the application. This can lead to production issues. But what if a WAF is involved in the DevOps process very early on and not just at the end, at production?
Registration Open for the CRS Community Summit on July 4
The organisation of the CRS community summit at the OWASP AppSecEU conference is coming along nicely. Remember, we are going to meet in London on Wednesday, July 4 at 4pm, to talk about CRS, and about the way our users, our integrators and their users work with CRS. The program will include information about CRS 3.1, a recent proposal for a rule meta language above CRS (to give the rule set a wider audience) and the most important thing: Time to meet and talk to fellow users!
Save the Date: CRS Community Summit on July 4, 2018
The OWASP ModSecurity Core Rule Set project will meet on Wednesday July 4, at 4pm in London to hold it’s first community summit. We scheduled this for the night before the AppSecEU conference in London on Thursday and Friday so people would have a real incentive to make the trip. {{ figure src=“images/2018/03/16367769605_dec3772aa8_k.jpg” caption=“London Tower Bridge by night (Photo by Arijit_Roy; flickr)” >}} Truth be told, the three project leads, Chaim, Walter and me have never met in person and physical contact is similarly rare between the committers, let alone the commercial suppliers or the thousands of users worldwide.
CRS Project News March 2018
This is the CRS newsletter covering the period from Early February until today. We held our monthly community chat. We had quite a few people stop by. csanders lifeforms franbuehler emphazer dune73 agi squared fzipi spartantri Our agenda from before the chat is available here. During the chat we discussed the following: We added support for ModSecurity-v3/Apache and Modsecurity-v2/Nginx to the CRS Support ModSecurity Docker Repos. These will be used when testing before a release. Additionally, we will be adding testing with Nginx+FTW in addition to Apache+FTW.
Creating an OpenWAF solution with Nginx, ElasticSearch and ModSecurity [x-post]
So many technologies in one title! Recently I’ve been spending quite a bit of time investigating ModSecurity as a potential replacement Web Application Firewall, and I’ve had some really positive results. The purpose of this post is to share with you how I’ve set this up, so you can do something similar yourself. After all, who wouldn’t want to be alerted to suspicious behaviour on their site in slack:
Building the WAF test harness [x-post]
To help our customers secure their sites and applications — while continuing to give their users reliable online experiences — we’ve built a performant, highly configurable, and comprehensive Web Application Firewall (WAF). In our last post, we shared some of the tech behind our WAF, including how we chose our ruleset and leverage our findings. In order to provide a fully comprehensive solution for securing your infrastructure, it’s critical to continuously test that solution. Because technology and threats are constantly evolving, the rulesets also need to evolve to ensure proper visibility and mitigation into emerging attacks methods.
CRS Project News February 2018
This is the CRS newsletter covering the period from Early January until today. We held our monthly community chat. We had quite a few people stop by. csanders airween franbuehler lifeforms spartantri dune73 allanbo Our agenda from before the chat is available here. During the chat we discussed the following: Issue #989 status: Currently waiting on canders to fix Dockerfile before it can merged. The Dockerfile’s point to csanders-git’s personal repository instead of CRS repo. This is done in error. csanders will change config default for docker to build on ubuntu and not fedora.
CRS Project News January 2018
This is the CRS newsletter covering the period from Early December until today (Now in 2018, Happy New Year!!). We held our monthly community chat. We had quite a few people stop by. Special thanks to lifeforms for leading the chat. csanders fzipi spartantri dune73 emphazer fgs franbuehler Our agenda from before the chat is available here. We had a short chat, during the chat we discussed the following: The OWASP CRS Mailing list seemed to be broken for a bit, we confirmed that it is currently working, and who the administrators are (dune73, lifeforms, and csanders) csanders committed to making changes to FTW necessary to get azhao155’s PR’s (and #989 which deals with FTW) merged. A number of folks are testing the Java protections PR that is slotted for 3.1 The Java rules (#990), that are a key feature of 3.1 need some attention We’d like to see correct formatting before merger And a number of FTW tests added for it. There was interest expressed in a format checker script A reminder the required format is available via https://github.com/coreruleset/coreruleset/blob/v3.1/dev/CONTRIBUTING.md OWASP_TOP_10 tags are outdated with new release and will be updated as part of rule cleanup 2.0 The older versions are available here: https://github.com/coreruleset/coreruleset/blob/95e7e6b3982eca93989c7948faca4a961737eace/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf A new ticket will be opened taking into account discussions from https://github.com/coreruleset/coreruleset/pull/881/files Dune73 will review #983 and #982 and merge if ready. csanders will write some of the documentation from #986 and provide a space on coreruleset.org for the information to live. #974, which deals with transfer encoding, is awaiting a PR, this change requires both correctly evaluating the TE RFC and the extensions. For 3.1 we’re going to do basic abuse checks in PL and any extension checks will be in PL minimum with further review planned for 3.2. We’d like to add the PR for CPanel exclusion to 3.1, due to how CPanel sets up their system it causes false positives, ideally CPanel would fix this but they haven’t yet so we’ll add a class exclusion similar to how we did with WordPress, Drupal, etc. emphazer said he could take this on. We reviewed spartantri’s idea for filetype checking based on STREAM_INPUT_BODY. It is unclear if this feature will be exposed as part of libmodsecurity. A PR will be prepared with the known compatible stuff enabled and the other stuff commented out and possibly enabled over time. Dune73 discussed a project for a volunteer who would shift rules that only require Phase 1 variables to use the phase:1 action for performance reasons. AppSecEU has been moved from Israel to UK and shifted to match the dev summit two weeks earlier. This would thus be perfect for our planned little CRS summit. @dune73 is in charge of this. dune73 is doing a ModSec/CRS/NGINX webinar with O’Reilly on January 9. Subscription is free, the slides will be shared afterwards. The next community chats will be held on the following dates:
Core Rule Set: The evolution of an OWASP Project [x-post]
Let me put one thing straight: there are two things when we talk about ModSecurity. There is the naked ModSecurity engine running inside NGINX or Apache and there is the rule set that instructs the engine what to do. Many different rule sets exist. But the rule set with the largest user base (and longest name) is the OWASP ModSecurity Core Rule Set or CRS for short.
Practical FTW: Testing the Core Rule Set or Any Other WAF
Back in August and September, Chaim Sanders introduced FTW, a Framework to Test WAFs via two blost posts. Existing unit testing frameworks are not really suitable for this purpose as they do not grant you enough control over the requests and the ability to look at the WAF log that needs to be bolted on. Chaim teamed with Zack Allen and Christian Peron from Fastly to create this. So FTW was developed with exactly our use case in mind. Time to really understand this and to start using it.
CRS Project News December 2017
This is the CRS newsletter covering the period from Early November until today. We held our monthly community chat. We had quite a few people stop by. Special thanks to lifeforms for leading the chat. lifeforms emphazer franbuehler spartantri fzipi hamlet_ Our agenda from before the chat is available here. We had a short chat, during the chat we discussed the following: @dune73 will be attending German Open Source Business Awards. Chances look good that CRS will a top performer. More information can be found here Using t:lowercase versus (?i) performance and best practice. There is currently no definitive answer A benchmark can be done using ModSecurity debug logs @spartantri will reach out to contacts to determine best approach for measuring and update us next meeting. There are an excessive amount of open PRs and Issues All but three PRs have been assigned reviewers, we have to make a dent this month. The Java rules, that are a key feature of 3.1 need some attention The older versions are available here: https://github.com/coreruleset/coreruleset/blob/95e7e6b3982eca93989c7948faca4a961737eace/rules/REQUEST-944-APPLICATION-ATTACK-JAVA.conf A new ticket will be opened taking into account discussions from https://github.com/coreruleset/coreruleset/pull/881/files Badging We may remove the gitter badge because we don’t feel big enough for two chats and IRC is preferred (more discussion next chat) We should investigate other functional badges using https://github.com/OWASP/github-template as an example. General question about determine if it is possible to determine if user is accessing via HOSTS file. It is not Travis and FTW PRs assigned to csanders #957 rule split Move part to PL3 to prevent JSON false positives PR #896 awaiting fgs update on the PR we think if the comments were taken into account it would be a quick and nice merge, but for now it’s stalled Fzipi resolved the conflict 896 resolving the conflict on this one The next community chats will be held on the following dates:
Core Rule Set Project Won a German OSBAR Award!
The OWASP ModSecurity Core Rule Set Project is very excited about winning one of the OSBAR awards of the German Open Source Business Alliance. The prize is awarded to projects, start-ups and outstanding ideas from the open source environment. The increased attention should make it easier for the award winners to attract users, developers and supporters. CRS hackers Christian Folini and Franziska Bühler with the OSBAR award trophy (photo Fridolin Zurlinden)
New ModSecurity / CRS Courses Announced
Feisty Duck announced two new ModSecurity / Core Rule Set courses: Zurich, February 19/20, 2018 Frankfurt, March 5/6, 2018 Additional trainings in Spring are likely to happen in Geneva and Amsterdam (on popular request). Additionally, teacher Christian Folini, will also be holding a ModSecurity on NGINX Webinar with O’Reilly on January 9. The subscription is no yet online, but will be announced shortly (I plan to update this blog post with the link as soon as it is available).
Disassembling SQLi Rules
Introduction I would like to explain my work disassembling highly optimized regular expressions. A project like this might discourage many people, but to me, it is very exciting work! I like this kind of investigative work and want to explain what, exactly, I did, why I did it and how! What’s the problem? The SQLi rules in the core rule set consist of 43 rules. 25 of them have been optimized with the Perl module Regexp::Assemble. This module assembles multiple regular expressions into one regular expression. The source patterns were lost over the years as they were taken from the old CRS project and partly from other projects, and source code management migrations led to the situation we are facing now. Unfortunately, there is no tool for disassembling an optimized regex, so we did not have a chance to undo this optimization process and regain the original patterns.
CRS Project News November
This is the CRS newsletter covering the period from Early October until today. We held our monthly community chat. We had quite a few people stop by. Special thanks to our active participants: dune73 fzipi csanders franbuehler emphazer spartantri luketheduke techair jose_ airween athmane bostrt During the chat we discussed the following Promotion of 3 heavy contributors to developers (@fgsch, @fzipi and @spartantri) Docs will be updated to reflect their promotion, congrats and thank you!!! CRS Summit at AppSecEU in June in Tel Aviv (?) dune73 will setup a project and let us know the status as we move along. fzipi spoke at OWASP Dev Summit about WAF test data. A new license is available (https://cdla.io/) Testing (FTW is working when using with CRS-support/ftw#14) PR is awaiting merge but seems to be working well. dune73 plans to write a blog. Idea to update release poster (with logo in the center) We had some great press about the poster. Need to check balance but Dune73 will finance privately changes. Shooting for by AppSecEU Idea to start to sell the release poster via a printing service like Redbubble Info: CRS nominated for the German Open Source Business award (https://osbar.it) Everyone is excited thank you to Dune73 for nominating us Plans for new blog posts Franbuehler writing up about SQL disassembly dune73 writing about FTW csanders-git writing about Apache vulnerability breakdown. [PR #881] : Java Attacks Will be assigned to csanders-git [PR #884] : SQL injection probing rule split 942370 emphazer is working on a PR for this so it’s in line with franbuelers comments. [PR #896] : Command substitution backquoted version support Splitting into two and fixing conflict when available. [PR #899] : Dokuwiki and Nextcloud exclusion packages (work in progress) Will be done when submitter has time. [PR #905] : Duplicated header bypass fix and chunk support csanders-git and fzipi are going to take the helm on getting this one through. [PR #922] : New developers (see above) Merged, need to add other testers also. remove spratantri from 905 as contributor Many PRs / test updates by @azhao155 (which are awesome). Bring up a question about what to do with Apache versus Nginx behaviors when the underlying engine ‘fixes’ and issue. Going to add support for multiple return status. This should take care of all the test updates. [Issue #924] Tagging of CVE/CWE The conversation centered around the if adding these added increased complexity of writing rules it may also muddy logs Everyone agreed additional information would be nice, CVE CWE, WASC, CAPEC Pushed the conversation back to the issue with regard to CVE. Release 3.1 planning Possible after Java fixes are done. Stickers and maybe shirts (for appsec eu) using Redbubble New ModSecv3 t-shirt were made, current order is empty but more may be coming The next community chats will be held on the following dates:
CRS Project News October 2017
This is the CRS newsletter covering the period from Early September until today. We held our monthly community chat. We had quite a few people stop by. Special thanks to our active participants: dune73 fzipi csanders franbuehler lifeforms emphazer fgs squared spartantri ossie buddyleer During the chat we discussed the following We will be moving our agenda document to GitHub. In this way all active participants will be easily able to add comments and tag PR’s in an efficient manner. We’ll open the “Agenda Issue” one week before out next meeting. There has been a bottleneck in terms of reviews. In order to address this we’ll be assigning responsible contributors to oversee the smooth flow of issues through the PR process. These contributors will be assigned at monthly meetings. Additionally, in order to give more timely feedback we are encouraging the system of using Github’s reaction system. A number of PR’s were given responsible overseers: #899: Dune73 #905: lifeforms: Should be a quick merge #896: lifeforms #894: Merged #890: Dune73 and lifeforms #887: Dune73 #883: csanders and franbuehler #907 franbuehler, emphazer and lifeforms #881: lifeforms #879: lifeforms: should be a quick merge #871: Closed: Changes only applied to 3.1 Some recognition was given to franbuehler for a whopping PR on the disassembly of SQLi rules (PR #907) We are 13% done with the technical milestone work for CRS 3.1. However given the amount of contributed PR’s we will likely release prior to all that work being completed. There is interest in starting a project to measure rule performance automatically as part of acceptance testing. This will be undertaken soon. Verizon Digital Media Services graciously offered to host coreruleset.org behind their CDN. While we don’t have a tremendous amount of users, we are going to test out the functionality The next community chats will be held on the following dates:
CRS Project Nominated for Swiss DINACon Award
The Core Rule Set project (CRS for short) has been nominated for the Swiss DINAcon Awards. I do not think any of you understand what awards I am talking about, so let me explain. It is hard to promote Open Source Software in Switzerland. This is not necessarily different from any other place, but let’s say there are strong commercial players that effectively block market entry for many open source software projects around here (Christian Folini / @ChrFolini writing this).
OptionsBleed Defenses
This week we saw the release of another named vulnerability (-_-). This time it was entitled: Optionsbleed. While the name provided is meant in reference to Heartbleed, this vulnerability isn’t nearly as far reaching. The vulnerability only affected Apache hosts with a very particular configuration and as a result only 0.0466% of the Alexa top one million sites were detected as vulnerable. Additionally, considering the requirements for exposing the vulnerability is dependent on a complex and unusual configuration it is less likely to be seen on less popular pages that tend to stick more closely to stock configuration.
Writing FTW test cases for OWASP CRS
A little background Last month we announced the general availability of the Framework for Testing WAFs (FTW) version 1.0. You can read the whole post here, but this is only the beginning of the story. With the release of OWASP CRS v3.0 we started integrating a more agile, test driven development methodology that we believe has resulted in better quality output. As of the OWASP CRS 3.0 release, all new rules and most modifications to the rules undertaken will require accompanying unit tests. But how does one use the FTW framework in order to write these tests?
How You Can Help the CRS Project
When I looked into my inbox lately, I found a very kind message where a new user asked how he could support the project. He had listened to a clip on the OWASP 24/7 podcast, got really excited and was now installing CRS3. I responded with a fairly lengthy message covering all the areas where I think his support would be welcome if not vital. On a second thought, there might be more people who are wondering how to join us, so why not publishing my response if it is of such a general nature.
CRS Project News September 2017
This is the CRS newsletter covering the period from mid August until today. What has happened during the last few weeks: We held our community chat last Monday. Chaim was high in the air so we were only six of us, but Manuel was back so I get the feeling we are slowly growing the project. The big project administration and governance discussions seem to be over for the moment. So we spent a lot of time talking about development, possible roadblocks and code policies. The next community chats will be held on the following dates:
Running CRS rules only on certain parameters
Hi, I’m a newcomer to the ModSecurity community and am currently learning about how ModSecurity works with the Core Rule Set and can be used to perform “Virtual Patches” against vulnerable web applications. I have learnt lots reading the rules in the CRS and reading the ModSecurity Handbook written by Christian Folini and Ivan Ristić. The OWASP ModSecurity Core Rule Set has a lot of protections for common web attacks built in, and is tuned to cause a minimum of false alerts. Use the guidance in the documentation, a high anomaly score threshold, a low paranoia level setting and you’re unlikely to have legitimate traffic blocked when you first install and set up ModSecurity with the CRS.
CRS Project News August 2017
This is the CRS newsletter covering the period from July until today. What has happened during the last few weeks: We held our community chat last Monday. There were eight people including Manuel Spartan who participated on the development of the paranoia mode. The big topic was disassembly of the optimized regular expressions that are very hard to read. See below for details. The next community chats will be held on the following dates:
Testing WAFs, FTW Version 1.0 released
The OWASP Project maintains an open source set of rules known as the the OWASP Core Rule Set (CRS). The CRS implements protections for the well known, broad classes of web application vulnerabilities identified by OWASP. Over time, this set of rules has become the most popular ruleset for ModSecurity and also found its way into many other popular WAFs. During this same timeframe we have seen Quality Assurance (QA)/DevOps techniques adjust to new Agile development methodologies. To a large extent this Agile pattern matches the historical development practices of CRS. As a result, during the development of the latest CRS version 3.0, the development team decided that a serious overhaul of the regression/unit tests was overdue. While some existing Perl regression tests existed, these were incomplete and considered difficult for the average user to run. The CRS development team also concluded that a more refined testing methodology commits to a higher quality product and allows for a demonstration of the effectiveness of OWASP CRS compared to many other rule sets and WAFs.
ModSecurity version 2.9.2 released
Trustwave has released ModSecurity version 2.9.2. This is an important update for users of the Core Rule Set. To detect SQL and XSS injections, CRS relies in part on the libinjection library by Nick Galbreath. This library is bundled with ModSecurity. It is regularly updated to address new types of injections. Therefore, to have optimal protection against SQL and XSS injections, you should always keep ModSecurity updated. The update also fixes two security vulnerabilities and contains various other improvements.
CRS3 presentation at OWASP London
OWASP London informed me that my CRS3 presentation will be live-streamed on the OWASP London Facebook page. My talk will begin around 8pm UK time. The presentation will be very similar to the one I held at AppSecEU in Belfast, but this time, we have a backup plan for the installation demo which failed due to beamer issues back in May. A record of the stream will be available on YouTube afterwards, likely the OWASP London channel.