Mittwoch, 1. Februar 2017

Ruleset-Update: WordPress API Content Injection (GET/POST)

Today sucuri reported a new critical vuln in Wordpress, allowing an attacker to alter articles and with the potential for privilige escalation, remote code execution and content injection

for more details please check the refs below

Updates already pushed to the ruleset-repository

  42000459 :: web_apps.rules       :: WordPress API Content Injection (POST)
  42000460 :: web_apps.rules       :: WordPress API Content Injection (GET)

MainRule negative "rx:^\d+$" "msg:WordPress API Content Injection (POST)" "mz:$URL:/wp-json/wp/v2/posts/|$BODY_VAR:id" "s:$ATTACK:8" id:42000459  ;

MainRule negative "rx:^\d+$" "msg:WordPress API Content Injection (GET)" "mz:|$URL:/wp-json/wp/v2/posts/|$ARGS_VAR:id" "s:$ATTACK:8" id:42000460  ;





Montag, 14. Dezember 2015

Ruleset-Update: Jenkins-Exploits, Joomla 0-Day

added some sigs against known exploits for jenkins and wp,
the rules itself might be found here:

for the latest joomla-vuln + exploit (see
you might want to look at 42000343
that detects generic PHP-Object-Attacks.
i modified this rule to check headers now as well,
updates are pushed to the repo already

MainRule "rx:O:\d+:.*:\d+:{(s|S):\d+:.*;.*}" "msg:possible PHP Object
Injection" "mz:BODY|ARGS|HEADERS" "s:$ATTACK:8" id:42000343  ;


[+] new sigs:
  42000443 :: web_apps.rules       :: WordPress XMLRPC Enumeration
  42000444 :: web_apps.rules       :: WordPress XMLRPC Enumeration
  42000445 :: app_server.rules     :: Possible Jenkins/Hudson RCE-Exploit
  42000446 :: app_server.rules     :: Jenkins User-Credentials-Access (POST)
  42000447 :: app_server.rules     :: Jenkins User-Credentials-Access (GET)
  42000448 :: app_server.rules     :: Possible Jenkins/Hudson RCE-Exploit
  42000449 :: app_server.rules     :: Possible Jenkins/Hudson
RCE-Exploit (/script)

rules are available here:

Sonntag, 18. Oktober 2015

Ruleset-Update: 42000442 Wordpress XMLRPC possible Password Brute Forceand some more

just updated the doxi-rules with a rule to detect and block
wp-pw-brute-force via xmlrpc (which shoudl be blocked anyway)

credits goes to sucuri:

MainRule  "str:system.multicall" "msg:Wordpress XMLRPC possible
Password Brute Force" "mz:$URL:/xmlrpc.php|BODY" "s:$ATTACK:8"
id:42000442  ;

there has been a couple of rules added too, mostly JAVA.* - stuff to detect generic attacks against java-based app, inspired by the latest elasticsearch - exploits

Donnerstag, 16. April 2015

Ruleset-Updates: Possible IIS Integer Overflow DoS > (CVE-2015-1635) and some scanner-sigs

[+] new sigs:
  42000428 :: app_server.rules     ::  Possible IIS Integer Overflow DoS > (CVE-2015-1635)
  42000421 :: scanner.rules        :: Joomla Googlemap-Reflection - Scan
  42000422 :: web_server.rules     :: PHP 5.x User-Agent detected in Request, possible flood
  42000423 :: web_server.rules     :: PHP 4.x User-Agent detected in Request, possible flood
  42000424 :: web_server.rules     :: Acunetix PHPSensor-File-Scan
  42000425 :: scanner.rules        :: SQLiteManager - Exploit
  42000426 :: scanner.rules        :: SQLiteManager - Exploit
  42000427 :: scanner.rules        :: JMXConsole-Access

most interesting sig: 41000428  Possible IIS Integer Overflow DoS > (CVE-2015-1635)

MainRule  "str:18446744073709551615" "msg:Possible IIS Integer Overflow DoS > (CVE-2015-1635) " "mz:$HEADERS_VAR:Range" "s:$ATTACK:8" id:42000428  ;


credit goes to emerging threats ml

Dienstag, 10. März 2015

Protect from ElasticSearch RCE (CVE-2015-1427) & JetLeak with Naxsi

there had been some buzz about the latest
elasticsearch-rce-vuln recently, but all exploits i've seen
so far are getting blocked if you run the naxsi_core.rules
wirth high  XSS/SQL-scores due to many brackets, quotes
and backslashes.

there exists a generic signature in the doxi-rules that was designed to detect
such kinds of attacks against java-based applications: 

MainRule "str:java.lang." "msg:Possible Java.Lang - Injection
(URL-Args & POST-Body)" "mz:BODY|ARGS" "s:$UWA:8" id:42000348  ;


about the vuln:

the POC:

btw and IMHO: whoever runs elasticsearch NOT protected by firewalls and/or reverse proxies deserves to get 0wned,  given the elasticsearch-vuln-trackrecord including various RCEs in the last 2 years.


on JettyLeak: who runs Jetty behind nginx is safe, since nginx itself
blocks any request as malicious, so no naxsi-sig needed.
apachy btw happily forwards the mailicious request.

more info:



Mittwoch, 28. Januar 2015

Ruleset-Update: Signature for GHOST exploit-attempt in ARGS/HEADER/BODY

Credit Goes to Emerging-Threats, this Rule is inspired by ET-Rule 2020327

MainRule "rx:[\d\.]{1023}" "msg:Possible GHOST exploit-attempt in ARGS/HEADER/BODY" "mz:BODY|ARGS|HEADERS" "s:$ATTACK:8" id:42000414  ;

Updates has been pushed to Doxi-Rules already: 

Freitag, 31. Oktober 2014

Ruleset-Update: Reflected File Download

ruleset-update with a testing-signature for Reflected File Download; beware of False-Positives; this sig is heavily untested and might break existing downloads

for the vuln itself please read the following artikles from Oren Hafif:
- Blog: Reflected File Download - A New Web Attack Vector
- Paper: Reflected File Download a New Web Attack Vector

[+] new sigs:
  42000408 :: Drupal SQLI & RCE-Exploit Attempt #2 (rx)
  42000410 :: Windows-Exe/Command - File download (cmd, bat, exe,...)
MainRule "rx:[\w*]\.(bat|cmd|vbs|wsh|vbe|wsf|hta)[\W]{0,}$" "msg:Reflected File Download / Windows-Command - File download (cmd, bat, exe,...)" "mz:URL" "s:$ATTACK:8" id:42000410  ;

sigs are already pushed and available: