Using OSSEC to monitor ModSecurity and Wordpress

As the October ISSA Journal begins to make the rounds, readers will note OSSEC as the topic of my toolsmith column.
The topic was chosen by Doug Burks of Security Onion as part of the Pick a Toolsmith Topic contest (we'll do it again).
As a result Doug won Zero Day Threat: The Shocking Truth of How Banks and Credit Bureaus Help Cyber Crooks Steal Your Money and Identity. Thanks again, Doug.
The article is available for all readers here.

While I discussed OSSEC as it pertains to Snort logs, PCI compliance, application (misuse) monitoring and auditing, as well as malware behavioral analysis, I spent very little time discussing the use of OSSEC with ModSecurity or Wordpress.
So here's where I magically tie it all together. ;-)
Given the title of the book Doug won, what's one way we might help prevent cyber crooks from stealing our money and identity?
Monitor our web applications, of course! With OSSEC. See how I did that?

OSSEC and mod_security

As an example, on an Ubuntu server running Apache generating mod_security audit logs, include the following in ossec.conf (var/ossec/etc):



OSSEC will then alert on mod_security events.
You'll need to tune and filter; you may receive quite a few alerts, but once optimized the results will be quite useful.



OSSEC and Wordpress

Using OSSEC HIDS with Wordpress is already nicely documented.

Highlights from OSSEC pages:
WPsyslog2 is a global log plugin for Wordpress that keeps track of all system events and writes them to syslog. It tracks events such as new posts, new profiles, new users, failed logins, logins, logouts, etc.
It also tracks the latest vulnerabilities and alerts if any of them are triggered, becoming very useful when integrated with a log analysis tool, such as OSSEC HIDS.



No matter what you wish to monitor, even if it's simple server well being, you'll find OSSEC indispensable. Making use of it as part of your web application security arsenal is a giant step in the right direction.

Feedback welcome, as always, via comments or email.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

CSRF attacks and forensic analysis

Cross-site request forgery (CSRF) attacks exhibit an oft misunderstood yet immediate impact on the victim (not to mention the organization they work for) whose browser has just performed actions they did not intend, on behalf of the attacker.
Consider the critical infrastructure operator performing administrative actions via poorly coded web applications, who unknowingly falls victim to a spear phishing attack. The result is a CSRF-born attack utilized to create an administrative account on the vulnerable platform, granting the attacker complete control over a resource that might manage the likes of a nuclear power plant or a dam (pick your poison).

Enough of an impact statement for you?

There's another impact, generally less considered but no less important, resulting from CSRF attacks: they occur as attributable to the known good user, and in the context of an accepted browser session.
Thus, how is an investigator to fulfill her analytical duties once and if CSRF is deemed to be the likely attack vector?

I maintain two views relevant to this question.
The first is obvious. Vendors and developers should produce web applications that are not susceptible to CSRF attacks. Further, organizations, particularly those managing critical infrastructure and data with high business impact or personally identifiable information (PII), must conduct due diligence to ensure that products used to provide their service must be securely developed.

The second view places the responsibility squarely on the same organization to:
1) capture verbose and detailed web logs (especially the referrer)
2) stored and retained browser histories and/or internet proxy logs for administrators who use hardened, monitored workstations, ideally with little or no internet access
Strong, clarifying policies and procedures are recommended to ensure both 1 & 2 are successful efforts.

DETAILED DISCUSSION

Web logs
Following is an attempt to clarify the benefits of verbose logging on web servers as pertinent to CSRF attack analysis, particularly where potentially vulnerable web applications (all?) are served. The example is supported by the correlative browser history. I've anonymized all examples to protect the interests of applications that are still pending repair.

A known good request for an web application administrative function as seen in Apache logs might appear as seen in Figure 1.


Figure 1

As expected, the referrer is http://192.168.248.102/victimApp/?page=admin, a local host making a request via the appropriate functionality provided by the application as expected.

However, if an administrator has fallen victim to a spear phishing attempt intended to perform the same function via a CSRF attack, the log entry might appear as seen in Figure 2.


Figure 2

In Figure 2, although the source IP is the same as the known good request seen in Figure 1, it's clear that the request originated from an unexpected location, specifically http://badguy.com/poc/postCSRFvictimApp.html as seen in the referrer field.
Most attackers won't be so accommodating as to name their attack script something like postCSRFvictimApp.html, but the GET/POST should still stand out via the referrer field.

Browser history or proxy logs
Assuming time stamp matching and enforced browser history retention or proxy logging (major assumptions, I know), the log entries above can also be correlated. Consider the Firefox history summary seen in Figure 3.


Figure 3

The sequence of events shows the browser having made a request to badguy.com followed by the addition of a new user via the vulnerable web applications add user administrative function.

RECOMMENDATIONS

1) Enable the appropriate logging levels and format, and ensure that the referrer field is always captured.

For Apache servers consider the following log format:
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-agent}i\"" combined
CustomLog log/access_log combined

For IIS servers be sure to enable cs(Referer) logging via IIS Manager.
Please note that it is not enabled by default in IIS and that W3C Extended Log File Format is required.

2) Retain and monitor browser histories and/or internet proxy logs for administrators who conduct high impact administrative duties via web applications. Ideally, said administrators should use hardened, monitored workstations, with little or no internet access.

3) Provide enforced policies and procedures to ensure that 1 & 2 are undertaken successfully.

Feedback welcome, as always, via comments or email.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

OffVis 1.1 now available

A quick update on OffVis as September's toolsmith on the same topic begins to arrive in ISSA Journal subscriber's mailboxes.
MSRC Engineering Security Research & Defense has released OffVis 1.1, along with a detailed and insightful video (best viewed with IE) on the OLESS Office legacy binary file format.
The new release includes bug fixes, enhancements, and additional detected CVEs.
Download OffVis 1.1, watch the video, and read the article if you spend any time analyzing Office malware.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

Disclosure standards and why they're critical

If you've read this blog over the last couple of years you've likely made note of the varying degrees of success I've had disclosing vulnerabilities.
You've seen the best of breed in AppRiver and SmarterTools.
You've also seen lessons in how to not handle disclosures in the likes of American Express and Ameriprise. I believe Ameriprise is Pwnie-worthy for Lamest Vendor Response given that Benjamin Pratt, Ameriprise’s vice president of public communications, said "There's no one at risk here." and that there are no plans to review any of the mechanisms the company may have in place to receive notifications from the public about website vulnerabilities. Wow. The Consumerist clarified those statements aptly with "we assume he means, "No one important on our side of things. Our customers can suck it."

I take disclosure very seriously. I believe it is a deep seated, inherent responsibility that rests squarely on the shoulders of vendors and site operators. Equally, disclosure must be responsible, even when efforts to advise the vendor have come up empty. To that end: ReportSecurityFlaws.com, the result of a recent interview I gave to by Ira Victor of the Data Security Podcast on the topic of mishandled disclosures. We decided on a joint project, thus ReportSecurityFlaws.com.

Report Security Flaws exists to increase awareness and responsiveness in Internet vendors and web site operators when they receive security-related disclosures.
It is our hope that all vendors/operators maintain an email alias that exists for the sole purpose of receiving disclosure notices from parties reporting noted security flaws on the vendor/operator’s web site.

Further, said email alias should be monitored by individuals with an understanding of web application security issues and business logic flaws, while maintaining a close working relationship with the site developers and operations engineers. This relationship should allow for the quick escalation of reported issues for mitigation and remediation.
Examples of such email alias might include:
security@domain.com
websecurity@domain.com
webreports@domain.com

Too often vendors and web site operators fail to manage the proper intake and escalation of reported security flaws, leading to lapses in web application security for days, weeks, and even months.

Report Security Flaws will provide resources and guidance for vendors and site operators facing such challenges, with the hope of improving internet security posture for vendor/operators and consumers alike.

If you, dear reader, have tried to no avail to drive a site operator/web vendor/cloud provider to fix flaws, and received no reply, let us know. ReportSecurityFlaws intends to serve as a public motivator to close such gaps and promote improved vendor response, complete with standards.

NOTE: ReportSecurityFlaws is not intended to out vendors who fail to fix. Rather, it is to use all means necessary to ensure they do fix, and promote better standards and practices.

With standards in mind, I've been participating in discussions regarding ISO/IEC 29147, which will hopefully be embraced globally as the ISO standard Security
techniques – Responsible vulnerability disclosure.
We also believe there is an opportunity for the PCI Council to incorporate stringent disclosure practices in the PCI DSS.

Disclosure can and must be handled properly. This week's reading included a remarkable and detailed public incident report from Apache to the compromise they'd suffered the week prior. This kind of transparent, open response does, as they clearly state, make the internet a better place. Well done, Apache.

Stay tuned for more....
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)

toolsmith: OffVis 1.0 Beta - Office visualization tool

My monthly toolsmith column in the September 2009 edition of the ISSA Journal features OffVis, a tool for detecting malicious Microsoft Office documents. This tool was created by MSRC's Engineering team, a group that spends a great deal of time looking for ways to detect exploitation of given vulnerabilities, in particular those that are Office-related.
Their efforts led to the creation of OffVis, starting in November 2008. First released in beta to MAPP participants, it has matured into a UI-based tool that analyzes a very specific set of vulnerabilities in order to better help defenders. MSRC Engineering’s work allows them to build detection logic, and then reuse it as part of ongoing analysis efforts.

Excerpt:
A typical targeted attack often includes an email sent to an intended victim with a malicious Excel document attached. When the victim opens the Excel document the following sequence might occur. First, it exploits a vulnerability to force Excel to run embedded shellcode. The shellcode then extracts an XOR’d, well-formed XLS file, and an EXE. The XLS opens in Excel, and the extracted EXE is executed which installsa backdoor as a service.9 This actual limited targeted attack resulted in Microsoft releasing KB 94756310 on January 15, 2008. The OffVis Excel parser includes detection logic for CVE-2008-0081,11 the National Vulnerability Database CVE released in accordance with KB 947563. We’ll look at a specific sample exploiting CVE-2008-0081 in Using OffVis.
Stepping through the exploit more specifically might appear as seen in Figure 2.


Figure 2




Typical exploit structure (Figure 3) ensures that everything is included in the document; please note that there can be variations including multiple shellcode stages, multiple Trojans, and obfuscation of both Trojan and the document.

For a much deeper dive into exploit structure, as well as disassembly and debugging techniques, see Bruce Dang’s topical Black Hat Japan 2008 presentation.





Figure 3

The article PDF is here.
Grab OffVis here.
Thanks to Dan, Kevin, Bruce, Robert, and Jonathan for the time and feedback that contributed to this month's article.
Cheers.

del.icio.us | digg | Submit to Slashdot

Please support the Open Security Foundation (OSVDB)