Somebody, Turn off That Tap!

I recently attended a keynote address by the CTO of a leading anti-virus firm. His company is fighting the good fight. Having recognized that signature-based malware detection no longer suffices, they have turned to a combination of detection and prevention to find and weed out bad actors. Big Data is crunched in The Cloud to find the malware which is then manually investigated to find out what it does. Once identified, sites serving malware are blacklisted for the benefit of this firm’s customers. The CTO proceeded to show an example of a piece of malware that changed the Windows hosts file to point a list of banking URLs to a single IP address, where one presumes the unsuspecting user would find a rogue copy of their banking website intent on stealing the user’s credentials or worse.

Now, this is only one example of the forty-thousand-odd unique malware infestations spotted in a depressingly short time, but my question is thus: why was a piece of malicious software running (inadvertently one assumes) on behalf of a user allowed to change a system-wide file like hosts? Shouldn’t there be a sandbox for code downloaded from the network that, if it needs to be run at all, prevents it from damaging the underlying operating system?

This situation paints for me the following picture: a tap is running, malware flowing like water into a sieve and onto the floor. The security industry is frantically mopping the floor, trying to stem the flow of malware. They are paid well for their trouble, but meanwhile the expensive rug that represents your business is getting awfully wet. It would be nice if someone could turn off the tap, or design an operating system that doesn’t leak like a sieve.

Speaking at SofTECH

I will be speaking next Wednesday at the monthly meeting of SofTECH. The topic will be Security and Open Source Software:

Many software choices are available to professionals who need to run applications in their business. Some of these will be delivered by conventional vendors who have full control over the product and its development. However, over the past decade many Open Source applications have emerged as viable alternatives, developed using an open process by volunteers from many different companies.

Speaking from his experience as an Open Source Software developer, Sander will compare some security aspects of Open Source and Closed Source software, likely debunking some myths along the way. We will examine the security vulnerability mitigation process used by the Apache Software Foundation and discuss how an open development process can provide enhanced security.

See the meeting page for details. An RSVP link is at the bottom of the page.

File System Permissions for Apache

I don’t spend a lot of time on The Apache HTTP Server Users mailing list, but a discussion sprang up there this week on which I think I should share my response. The issue was why the server in question did not have permission to show a particular file. The initial response was “just chown your document root to the Apache user” and, when pointed out that this introduced security issues,

Oh man an experienced sys admin told me to do it that way.
Please tell me what is wrong in this and where is this documented on Apache 
I want to read.

Here is my response reproduced: read on.

The Apache HTTP Server needs read access to its configuration files and the files it serves. In and of itself, the server does not need write access anywhere on the system: even its log files are opened for write when the server is still root, and the open file descriptors passed to the child processes which change their user id to the lesser privileged user.

Read access only. The web server user should not own, or be able to write to, its configuration files or content.

Content, other than CGI scripts, generally does not need Execute permissions. Even PHP files that are interpreted by the server do not need to be Executable.

Certain applications, especially publishing platforms and Content Management Systems that you manage and populate through the web server itself using a browser, require that certain directories on the system be made writable by the web server user. You can do this by changing the owner of the directory to that user (usually www but ymmv), or by making the directory group-writable and changing the group to the group as which Apache runs.

Making directories writable by the web server should be done only with care and consideration. The usual threat model is that someone manages to upload (for instance) a PHP script of their own making into the document root, and simply executes that by accessing it through a browser. Now someone is executing code on your machine. Google for ‘r57’ for an example of what such code can do.

If a web app needs writable directories, it’s often better to have those outside the DocumentRoot: that way the uploads can’t be accessed from the outside through a direct URL. Some applications (WordPress for instance) support this, others do not.

In many cases, writable directories are not strictly necessary even though the web app might like them: rather than upload plugins (which contain code that gets executed or interpreted, yech!) through the web browser, upload them through ssh and manually unpack them on the server. The CMS Joomla! likes to write its configuration file to the Document Root on initial install (which promptly becomes a popular attack target) but if it can’t write to the Document Root, it will output the config to the browser to the user can manually upload it.

The Apache Documentation will merely tell you to make the server installation root-owned. The HTTP Server Documentation does not cover third party applications like WordPress or Joomla!, so it will not discuss their need to have some directories writable. I hope the above makes the picture a little more complete.

Attack on EMV Payment Cards

The BBC discusses a man-in-the-middle attack on EMV payment cards, also known as Chip-and-PIN. The attack was developed by a team at Cambridge University in the UK. Using a real card wired up to a laptop, connected to a fake card that is inserted in the POS terminal, this attack can authorize payments with an arbitrary PIN.

I am not sufficiently familiar with the cryptography in use for the EMV protocol, but my first thought is that astute observation by POS personnel should provide substantial defense against this entire class of attack: if someone shows up at your cash register with an EMV card wired to his backpack, something fishy is probably afoot.

My other thought has to do with the notion that banks might attempt to shift the responsibility for fraudulent Chip-and-PIN transaction to the consumer. “Since EMV is so secure,” the reasoning goes, “the PIN authorization is proof positive that the transaction is valid.” Except it has now been shown that PIN authorization can be spoofed.

Security is not black and white: it does not make fraud impossible, but makes it harder and more expensive to commit fraud. The protection level provided by a security feature should be commensurate to the value of the transaction it protects. Too high a protection level is likely to be more cumbersome, or more expensive, than the transaction in question justifies.

Web Hacking Incident Database Report

The The Web Hacking Incidents Database 2009: Bi-Annual Report is out. If I recall correctly, the first report Breach did, in 2007, did not mention any bi-annualness. Also, the eventual landing page has as HTML title “<title>The Web Hacking Incidents Database 2008: Annual Report</title>”. Is it possible that they simply didn’t get their act together last year and retroactively declared the report bi-annual?

I went in through the link above, gave up my e-mail, phone number and name of my first born, and downloaded the report. This will probably land me another copy of every marketing e-mail Breach sends out (guess how I learned of this report?), and a phone call from some poor guy in a cube who has to make 75 phone calls a day for a living. Oops, guess I put down a fax number. Sorry dude, hope your headset isn’t too loud.

Anyway, after you go though the lead generation form you land here and can follow a direct link to the PDF. This is fairly standard practice, but from a security company I would expect that they would make some more effort to not inadvertedly expose the goods.

ApacheCon US 2009I will give this report a read, and probably discuss it in my upcoming talk at ApacheCon US 2009. Oh, they just extended the early bird registration deadline… without changing their own website to tell you about it. Register now and experience the mayhem.

Firefox Overzealous… Or Is It?

Man In The Middle is defeated by context. — Bruce Schneier

As has been widely discussed, Firefox 3.0 is a little over-zealous when it encounters an unknown certificate on an SSL website. Where previous versions would just warn the user about the observed irregularities, the new version requires that the user add an exception for every certificate that has an unknown certification chain, is expired or for which the hostname does not match the information in the certificate.

Adding an exception takes four clicks, most met with a stern warning that will deter anyone but the most determined user. Folks who use self-signed certificates as a matter of habit are howling, because they have to tediously make exceptions for all of them. This Firefox features seems over the top, but is it? Continue reading

Security Roadmap for ApacheCon US 2008

ApacheCon US 2008
At the end of my conference presentations, I usually put a Conference Roadmap slide. This slide shows sessions at the conference that are related to mine, and that attendees may find worth while to check out. For my Hardening Enterprise Apache Installations session this coming Thursday, I would suggest the following related conference content:

Besides the training (which happened on Monday), this means that you can pretty much stay in the same room all Thursday and catch all the Security-related talks. In addition, of course, this track will be streamed live for a modest fee, so you can watch from the comfort of your own office if you find yourself unable to make it to ApacheCon this year.