Detecting Undisclosed Vulnerabilities with Security Tools & Features
I’m a big fan of OSSEC[1]. This tools is an open source HIDS and log management tool. Although often considered as the "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, it’s 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:
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:
67a68,73
> 'args' => array(
> 'id' => array(
> 'description' => __( 'Unique identifier for the user.' ),
> 'type' => 'integer',
> ),
> ),
328a335,356
> * 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' => 404 ) );
> if ( (int) $id <= 0 ) {
> return $error;
> }
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! It’s easy for them to deploy a fake wordpress and get updates. Once they detect the changes, it's easy for them to find how to exploit the vulnerability...
Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant
PGP Key
×
![modal content]()
Diary Archives
Comments