Jenkins CVE-2017-2606 Information Disclosure Vulnerability
Jenkins CVE-2017-2607 HTML Injection Vulnerability
Libreswan CVE-2016-3071 Remote Denial of Service Vulnerability
Im a big fan of OSSEC[1]. This tools is an open source HIDS and log management tool.Although often considered asthe SIEM of the poor, it integrates a lot of interesting features and is fully configurable to solve many of your use cases. All my infrastructure is monitored by OSSEC for years.
One of the OSSEC feature that I like most if the FIM module or File Integrity Monitoring[2]. It allows you to report any change to directories or files. This is an excellent way to detect suspicious changes in your web server directory. If a change is detected on your index page, its time to create an incident and investigate! Another security feature that is available in more and more applications: automatic updates. No need to apply security patches, the system or application will apply patches when they are released. (Note: This technique as pro and con but, in most cases, it helps to reduce the surface attack of your applications). If you combine automatic updates with file integrity management, you can sometimes spot interesting stuff. Here is an interesting example.
A few days ago, the security firm Sucuri posted a early warning message (flagged as TLP:RED)on a trusted security mailing list about a new vulnerability they discovered in Wordpress and that will be fixed soon by the Wordpress team. Two days later, I got a notification from my OSSEC regarding changes that occurred on some files of my blog:
width:600px" />
OSSEC can be configured to report file changes but also to perform a diff between the old and new files (not stored in my Splunk). Looking at the raw OSSEC logs, I saw this:
** Alert 1485478430.1704280: mail  - ossec,syscheck,
2017 Jan 27 01:53:50 (xxxx) x.x.x.x-syscheck
Rule: 551 (level 7) - Integrity checksum changed again (2nd time).
Integrity checksum changed for: /xxxxxxxx/wp-includes/rest-api/endpoints/class-wp-rest-users-controller.php
Size changed from 43067 to 43621
Old md5sum was: 05388955522e536cd475bddc2ac2d7fe
New md5sum is : fbd03fc6811db1a5ebb66db48dd6f673
Old sha1sum was: 57f23ca13bb9a4bdaa2359b7348e42a48cdc9669
New sha1sum is : 4040a096641c51d8271b542801673414ade62bf9
What changed:
                       args = array(
                               id = array(
                                       description = __( Unique identifier for the user. ),
                                       type        = integer,
        * Get the user, if the ID is valid.
        * @since 4.7.2
        * @param int $id Supplied ID.
        * @return WP_User|WP_Error True if ID is valid, WP_Error otherwise.
       protected function get_user( $id ) {
               $error = new WP_Error( rest_user_invalid_id, __( Invalid user ID. ), array( status =
               if ( (int) $id = 0 ) {

More changes..
A few days later, when Sucuri released all the details about the vulnerability[3], it was clear that Wordpress silently released a patch that was installed by all servers configured to do it automatically.
Time line of events:
  • 20/01/2017 : Sucuri contacted Wordpress
  • 25/01/2017 : Sucuri notified trusted peers (TLP:RED)
  • 26/01/2017 : Wordpress released 4.7.2
  • 27/01/2017 : My wordpress fetched and installed the patch
  • 01/02/2017 : Sucuri published the research
The vulnerability was so critical that Wordpress decided to silently patch as many systems as possible before disclosing details. If this kind of silent patch can be spotted by tools and features as I did , bad guys can too! Its easy for them to deploy a fake wordpress and get updates. Once they detect the changes, its easy for them to find how to exploit the vulnerability...

Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
Internet Storm Center Infocon Status