A while back I posted about my and others’ concerns about Firefox’s newly handled way of dealing with self-signed or unapproved certificates. It seems the folks over at Carnegie Mellon University have released an extension for Firefox to help deal with this exact issue.

My main issue with my last posting wasn’t directly tied to the error in the security model Firefox was introducing, but simply the intrusion factor of what was taking place, and the lack of information that FF was providing when denying access to the site. The extension provides two primary benefits:

1. If you connect to a website with an untrusted certificate (e.g., a self-signed certificate), Firefox will give you a very nasty security error and force you to manually install an exception. Perspectives can detect whether a self-signed certificate is valid, and automatically overrides the annoying security error page if it is safe to do so.


2. It is possible that an attacker may trick one of the many Certificate Authorities trusted by Firefox into incorrectly issuing a certificate for a trusted website. Perspectives can also detect this attack and will warn you if things look suspicious.
   
   The same is true for HTTPS sites with certificates that contain mismatched domain names (e.g., www.gmail.com uses a certificate for mail.google.com) or certificates that are expired.

   The primary description for Perspective also states:
   

   A client can automatically make a secure connection to one of several publicly available “network notary servers” located around the world. These servers tell the client:
   

   
   
   1. What key does the server see for host.domain.com right now?
   
   
   2. What keys has the server seen in the past for host.domain.com?
   
   

   
   The replies from the network notaries can go a long way toward either providing the user with confidence that the key it received is valid, or that a real threat of a “man in the middle” attack exists.

   The end result is that instead of having applications issue bland warnings, which users often ignore, the application can either skip the warning if notary data indicates that the key is valid, or give a very stern warning in the rare cases when an attack appears to be in progress.

   
   This extension does pretty much exactly what I wished Firefox would have done with the new policy from the beginning.

   Link to the project: HERE

   
   

Mark Kahn found out the hard way that even “small” sites will press charges when he hacked into Six Flags’ computer systems. He used a bad form on Six Flags’ job site to submit lots of bogus job applications containing threatening messages. While his stunt did not result in the loss of data, it did annoy some people enough to press charges. What I want to know now, is how well amusement parks’ externally facing websites are separated from the really important computer systems – those that belong to the rides/roller coasters.

I’m speculating here, because I ride coasters a lot, and the newer systems are controlled by general purpose computer systems – I’ve seen the Millennium Force at Cedar Point blue screen, and it was built in 1999/2000. I don’t know if these systems are networked at all, but I could see a business use for it: letting people know what rides were having problems, or just generally monitoring the health of each ride. These computer systems (like many at hospitals) control life or death literally, not just storing someone’s personal data. It’s a lot like the pacemakers that are bluetooth controlled. Do we really want to network these devices?

There are arguments on both sides of the fence, and I can see both sides – it’s easier to monitor and make changes (without having to go through surgery again), as well as “but someone could get killed”. Both sides make great cases (someone could die during surgery too), but the networked (whether bluetooth, wi-fi, RF, etc) devices also present the accidental hazard. What if I want to just play around with the bluetooth protocol and start sending garbage to a device I own (say my cell phone), and someone with a new pacemaker just happens to be sitting across the way at the coffee shop?

To network or not network is probably going to be an eternal question, and the answers are going to be different each time we ask that question. It all depends on what risks we’re willing to accept, and what ones we’re not.

In 2007 a handful of companies (including Google, Microsoft, and Yahoo) decided to draft a set of guidelines influencing the behavior of online businesses when it comes to the subject of policies and regulations dealing with human rights. It was to be a kind of unofficial voluntary code of conduct initiative thing.

According to this letter(pdf) from Yahoo to Senators Durbin and Coburn:

Principles on Freedom of Expression and Privacy [...] provide direction and guidance to the ICT industry and its stakeholders in protecting and advancing the enjoyment of freedom of expression and privacy globally. The Principles describe key commitments in the following areas: Freedom of Expression; Privacy; Responsible Company Decision Making; Multi-Stakeholder Collaboration; Governance, Accountability & Transparency

Along with censorship and freedom of speech, the idea was also to provide general requirements for privacy. The idea also calls for a way to determine if a company is compliant with the code and a way to hold companies accountable if they violate it.

This is important because it shows that some of the most relevant internet-based companies are taking the rights of their users seriously. So seriously, in fact, that they are willing to sponsor a set of guidelines that help other companies protect THEIR user’s rights as well. If more companies get on board, this could be a step in the right direction in helping to strengthen the trust between service provider and user.

We’re constantly looking over, analysing, and adhering to narrowly defined security standards in the IS field. These standards are focused on large companies, yet what is there for the little guy?

Websites slap on labels like “Hacker Safe”, which we don’t trust and there are countless blogs vulnerable to a number of security holes, gaps, and simple poor configuration.

What we need is an open-source set of general security recommendations and guidelines for a host of applications – encryption, blogs, and even social networks. The formula for these guidelines to work, be useful, and adopted are,

• Keep Them General - Don’t include specific instructions on how to configure a setting.


• Have Input From Independent Security Experts – The people that work, teach, and have “intangible” experience working in information security.


• A Ranking System - What something protects against, how effectively it does it, and how difficult is it to configure.

Such a set of open source standards, would do wonders for not only the people using them, but the companies that stand behind them. Especially smaller companies who can respond quickly, speak more freely with the public, and have a more varied palate of work vs. a large corporation.

Why not have a set of well-scrutinized general security guidelines that could be adopted by schools, independent consultants, or Web developers?

If you used to use nessus for vulnerability scanning, but stopped when Tenable released 3.0 under a non-GPL license, you’re in luck. OpenVAS is a fork of nessus 2.0 and uses .nasl files. However, the vulnerability test feeds (NVTs) seem to be lacking the same breadth as those released by Tenable. However, many .nasl files are open and released by third-parties, so you could add them to your scanner.

Nessus is one of the better vulnerability scanners I’ve used for raw data. It doesn’t do any of the fancy dashboard or report generating that some of the others do, so it tends to get a bad rap. However, if you just need a scanner that finds potential vulnerabilities, Nessus gets the job done and well.

I have yet to play with OpenVAS, but I think it’ll be on my weekend list of things to play with.

Your company creates a custom web application and deploys it live. I bet it went through some serious security testing, and even the development process had security in mind from the design stage right (it should have). So if all this effort is put into a custom web application, why isn’t the same being done for your company’s blog?

Blogs are nothing more than web applications. And unless you created your own blog engine from scratch, you are using some third party solution (Wordpress or TypePad). This means you’re trusting the software is free of any vulnerabilities and has been developed with secure coding techniques as well. It’s one thing to insist your developers use secure coding techniques but it’s a way different scenario when you’re dealing with third-party, Internet facing applications like blogs.

If you’re going to be using third party web applications that you cannot guarantee are secure (and you can’t) then you ought to be taking advantage of a web application firewall (WAF). A web application firewall can protect third-party applications just as easily as it can for custom developed applications, and in many cases it is actually a lot easier.

In a lot of companies blogs are the web face for the company (at least one could hope). It’s important to realize that thereare risks here, especially if it’s pulling the the most hits and getting the most attention. So stay protected – use a WAF!

One of our clients unintentionally DoSed themselves this weekend by switching registrars. In what turns out to be an honest mistake on someone’s part, the new registrar set the company’s DNS servers to the registrar’s (pretty standard action), but they didn’t copy the old DNS information from the previous registrar. Effectively denying service to the organization’s mail server (no DNS entry and no MX record), and some websites that generate revenue.

I would suspect that this is a common situation for smaller companies. They decide that they’re not happy with their current registrar for whatever reason, and switch. Unfortunately, not understanding how computers find each other and buying into the “complete hosting solution” packages offered by many registrars. In an effort to prevent other small companies from suffering the same fate, I present DNS, whois, and hosting for dummies.

Read the rest of this entry »

Authoring web sites was a lot easier in the 90’s…write some static HTML, maybe some JavaScript, and you were done.  Need to update the site?  Just edit the HTML pages and upload.

In the past decade or so, web applications have made a lot of progress with interactivity and dynamic content.  Services hosted outside of the application container, such as third party web services and databases,  can provide a boatload of flexibility when designing and implementing a web site.  But, these services rarely, if ever, allow anonymous interaction…so we need to go back to our old friend, the password.

Passwords are usually stored in a configuration file along with a web application.  The configuration files are generally not made accessible with an application URL, but often connection information is stored unencrypted, which means vulnerability to security bugs that can trick the web app into displaying the configuration files.  Local access would also compromise the password, but local access almost always means that nothing is safe.

I’m in the process of authoring a new .NET app, and I’m feeling okay about the capability to encrypt sections of the web.config file (including service passwords).  This seems to be able to hide data from prying eyes using keys managed by the local security authority.  However, I haven’t yet figured out how to manage this in a deployment scenario.  Encrypting the section inherently makes it difficult to update the configuration – this now has to be done through code, because the security provider has to be invoked to decrypt and re-encrypt the configuration sections.  If the same authentication provider is used to authenticate administrators to perform these updates, then what if there is a problem with that authentication provider, and the administrators get locked out from fixing the configuration?

From a security standpoint, I have to make this work (and be usable)...I just haven’t yet figured out how.  If anyone in my legion of loyal readers has any tips, I’d be glad to hear them.

IBM’s X-Force R&D has sent out a report( pdf ) detailing computer security statistics collected over the first six months of 2008.

Among the results of this report, we find the following (compared to last year’s figures):

• Decreased time between disclosure and public exploit


• Further shift from OS and multimedia exploits to web browser exploits


• Further shift from browser core to browser plugins

What this tells us is that attackers are keeping a steady eye on the disclosure process itself, quickly adapting the details into POC code. It also shows that attackers are recognizing and taking advantage of the browser as an attack vector—a trend that has been steadily increasing over the past few years.

Another interesting trend that caught my eye was the most commonly used web browser plugin exploits… most attacks exploited vulnerabilities that were between 1 and 2 years old. On one hand, I would say that an improvement has been made—no longer are people getting exploited by 4 or 5 year old bugs. But at the same time, we have a long way to go before people constantly address the security issues of software that is regularly exposed to the dangers of web browsing.

The rest of the report ( pdf ) is a very solid read—they cover everything from spam, to phishing, and even the relatively fresh vulnerability frontier of virtualization.

Many people have been praising Mozilla’s Firefox 3 ever since pre-beta. I myself can easily throw myself onto that band wagon. But there is one feature that has been causing a little commotion, and I again can easily agree with the commotion.

Firefox 3 (FF3) limits usable encrypted (SSL) web sites to those that have an approved digital certificate from an authorized vendor of Mozilla’s choosing. Making it so you have to pay to be recognized. What’s the big deal?

When you visit an encrypted site in FF3, and that site uses a self-signed, or simply unapproved certificate, FF3 doesn’t immediately show the page. Instead you are greeted with what, at first glance, would seem to be an error page.

In order to move beyond this page, and actually continue to the site as intended you need to process through 4 clicks to add that site as an “exception”.

The use of a certificate is for SSL – which has two main purposes – allow connections to be encrypted so they can’t be snooped, and it allows sites to be authenticated so they can’t be impersonated. Advocates to Mozilla’s policy seem to only focus on the later stating that a self-signed certificate has no value for authenticating a web site. The real concern is that snooping is much more of a easily attainable threat then impersonation. So it is much more valuable to have a self-signed certificate than nothing at all. But doing so put’s yourself at a inconvenience for FF3 users.

This to me sounds like it is blatantly going against the notions of Net Neutrality. Something that has been fought to keep open for ages. Something like this completely discriminates against those not willing to purchase a “approved” certificate.