Dec. 31st 1999, 23:59:59 GMT
The famous Y2k issue. We made it… (so far )

Jan. 10th, 2010, 10:10:00 GMT
“Binary Armageddon Day”. The binary representation, 1010011010 translates to ‘666′. Also, the date only includes 1s and 0s (other then the ‘2′ in the year). (thx Gadi. Also see Gadi’s facebook group about this issue ). If you are on facebook, you can find the group here: http://www.facebook.com/pages/Binary-Armageddon-Day

Dec. 21, 2012
end of Mayan calendar. Just listed here because everybody is talking about it. Should not affect software (other then the fact that the world will end that day).

Feb. 7th 2036, 6:28:16 GMT
The last date that can be expressed using “ntp”. ntp is a protocol used to synchronize clocks on the internet. The ntp date starts on Jan 1st 1900 and is expressed in 64 bits. The first 32 bits are used to indicate the number of seconds since Jan 1st 1900, the remaining bits are used as fractional seconds.

Jan. 19th 2038, 03:14:07 GMT
The end of the Unix epoch. Unix uses a 32 it signed number to express time. ‘0′ is January 1st 1970. The last date that can be expressed using unix time is Jan 19th 2038. After that… who knows? This can already be a problem. Imagine you are a bank and handing out 30 year mortgages?

Dec. 31st 9999, 23:59:59 GMT
The end of 4 digit years. Well, we got a while until that will happen.

Got any other dates of note? Let us know!

But why should you bother?

First of all, Google webmaster tools will provide you with more insight into how Google indexes your page. The section I am looking at first is “crawl errors”. It will tell you if any pages were not found, or if pages timed out. You can also check how robots.txt limited the crawl.

The “HTML Suggestions” section will tell you about search related errors in your HTML code. For example, inefficient use of META tags.

A common question we get at the Internet Storm Center is how to remove a URL from Google’s index. Webmaster tools will again help with that. The feature is a little bit hidden, but if you select “Site Configuration” and “Crawler Access”, you will see the “Remove URL” feature. This is probably the fastest way to remove a URL from Google.

Finally, the “Labs” section: One feature Google is currently experimenting with is malware detection. If Google found malware on your site, it will tell you about it. Sure, this is not the ideal way to find out about malware on your site. But better late then never.

I think Google’s webmaster tool is a “must have” for everybody running a website. While not strictly a security tool, it does help with security (and of course search engine optimization).

Johannes Ullrich and I got a little curious about the adoption of X-FRAME-OPTIONS header in the major sites. We went and got the list of top sites according to Alexa and see if the top sites actually use X-FRAME-OPTIONS header. We expected the results to be low, but when we looked at the results from visiting all these sites, we were a slight bit surprised. Of the TOP 10,000 sites from the Alexa’s list, only 4 sites have the header specified. That number obviously is very low.

Not having the X-FRAME-OPTIONS header does not mean these site are not protected from clickjacking, maybe they are using some type of Javascript framebusting, we haven’t looked at how many have framebusting deployed yet. It is widely believe that the Javascript only defense is not as good as the attacker could disable Javascript in the frame by setting SECURITY=RESTRICTED on the IFrame to disable the Javascript defense.

As a side note, I am doing my personal part on promoting the X-FRAME-OPTION. In the next major update of my SANS DEV422 course (soon to be 522), there will be emphasis on various defenses against Clickjacking that a site owner can leverage.

The person I had the IM discussion with was Daniel Miessler. He responded in his own blog, and sent me the excerpt below as a response. Thanks for the offline and online comments to far. Certainly an interesting topic to discus!

My view is much different than Johannes’s. I feel the test type he’s describing is a detailed vulnerability assessment–not a penetration test. I think the key difference is opacity. He says that he doesn’t believe in black box testing, and that’s fine; I too agree that white box testing is far more effective.

But I think very concept of white box vs. black box is, by default, a discussion about vulnerability assessment and not penetration testing because penetration testing implies black box. In other words, you can have a white box or black box vulnerability assessment, but you can only have a black box pentest.

This is because the analog to the pentest (in my opinion) is the elite military unit commissioned to test a military base’s security. See Tiger Team. Many readers may remember Richard Marcinko, from SEAL Team 6 who used to break in and kidnap Admirals and hijack nuclear subs. This is a pentest in my view–you are given a single goal by the client: “get as far as you can”, or “see what you can get out of my database” or “try and modify my payroll records”.

The mission of the pentest team is to achieve the goal that has been given–not to find all (or even many) vulnerabilities in the target’s defenses. Any vulnerability assessment that takes place against the target will be solely for the purpose of finding a way in–nothing more. And if they get in on the first try, and accomplish the goal, then the report will indicate as much.

The report will state how they got in, what the customer should do to shore things up from that vector, and perhaps mention a few other things in passing. But it won’t be a comprehensive review of the customer’s security posture. That would be a separate engagement–a *vulnerability assessment* engagement.

Main Points

So here are my main propositions:

• A vulnerability assessment focuses on breadth: the goal is to identify as many issues as possible. This is why white box VAs are generally a superior option if the testing team is skilled enough to provide one.
• A penetration test focuses on depth, not breadth: the focus is on achieving a pre-determined goal that could only be possible if security were to fail, and not to find vulnerabilities. Vulnerabilities are used in a pentest, but they aren’t the focus. The focus is achieving the pre-determined goal.
• Vulnerability Assessments are (or should be) requisitioned by those who already know they have many issues and simply need help identifying and prioritizing them. The more issues identified the better, so naturally a white box approach should be embraced when possible.
• Penetration Tests should only be commissioned as a final stage of a security program, by those who believe their security program is mature, functioning well, and wish to test it against an adversary. It is, by nature, black box because the goal is to simulate a real-world attacker.

My complete post on the topic can be found here.

I think it is a matter of pentesting philosophy. I see myself primarily as a coder. A pentest is for me part of my software testing regimen. Like my other tests, code coverage is of utmost importance. I don’t consider my application working until it has been fully and thoroughly tested. A pentest is just another, very special, test I subject my code to. As a result, I am not a big fan of “black box” testing, or “early dawn raids” as I call them. They may find a problem, but the tester will typically waste a lot of time finding and exploiting vulnerabilities, which may have been trivial to exploit with a bit of source code, or after talking to the developer. I rather have the pentester spend their precious time on going after yet another possible vulnerability.

I do understand that a pentest does not find all bugs, but the aim should be to do just that. I strongly believe that a pentester should be held to the same standards as a developer. Would you accept software that works once? Code that only has one bug fixed? Just because it is hard, doesn’t mean that we shouldn’t attempt it. In many ways, this is what I enjoy about being a developer: Hard problems.

Is it possible to come close to the goal? I think it is. All of this is based on a good framework and to apply this framework thoroughly. You do your recognicance, and don’t stop at the first web application you find, unless the scope of the project limits you. Next, you map out the web application, and try to find not just all URLs or “pages”, but all features. A feature you miss in the mapping phase will be a feature you miss in your test. Next, you discover vulnerabilities. And finally, you try to exploit them. Once you manage to exploit a vulnerability, you are likely to find more content and your process starts all over again.

Sounds boring and tedious? Yes it is! If you don’t know how to script. I say this a lot: If you don’t script, you will soon be replaced by a script. If you want to distinguish yourself as a pentester, you will have to understand your tools well enough to extend them and build upon them.

We are now ready to share some collected data with the community. Our intention is to share the data and findings with the community in the same manner as the original DShield project.

The high level stats of the Webhoneypot can be found at
http://isc.sans.org/weblogs/

Various reports can be found at
http://isc.sans.org/weblogs/reports.html

A limited search interface can be found at
http://isc.sans.org/weblogs/filter.html

These report pages and especially the search interface is in beta currently. We intend to refine these as the project matures. We appreciate any feedback on these reports and search capabilities.

Feel free to analyze the data as you wish, if you spot anything interesting, please write to us. Thanks and happy log reading.

1 – “SQL Overflow”

If a value you insert into a column is too large, it is truncated silently. This can lead to security issues if you don’t validate that the submitted string is of the right length.

2 – “Trailing White Space Ambiguity”

Trailing white spaces are removed by MySQL silently. For example, these two queries retrieve the same result:

select role from user where username='Admin';
select role from user where username='Admin   ';   (note the space at the end).

3 – Unbalanced comments

Older versions of MySQL allow /* to be used unbalanced. For example,

select now() /* test

will work. Newer versions of MySQL require balanced comments (unbalanced was always “illegal” according to the documentation

4 – php ‘rand()’ function returns bad results

If the argument exceeds the maximum integer, you will get not-so random numbers back. This one depends a bit on the version of PHP you are using. But you will not get an error. Instead, you will get negative numbers, or numbers that are not random (e.g. only last couple of digits change).

5 – MySQL “–” comments require a white space

In order to use “–” as a comment, it has to be followed by a whitespace.

select now() –test  will fail
select now() — test will work

You don’t have to use a space. A tab will work just fine and evades some filters.

Got some to add? Use the comments

Session fixation isn’t really that much of a problem as long as you stick with a few simple principles. Remember we called this blog “App Sec Streetfighter“? Its about simple and reproducible techniques that work while under attack. So lets keep it simple:

1. Use only cookies to transport the session token. This considerably raises the bar on session fixation. The attacker now has to set a cookie which isn’t easy at all.
2. Change the session ID whenever the users state changes (logged in vs. logged out).
3. Change the session ID every so often. (every X pageviews, every X minutes).

In order to change the session id, PHP offers a simple comand, session_regenerate_id, just add it to your header and you will get a new session ID on every page. If that works for you: great!. If it causes performance issues, then add some logic to limit the life time of sessions or add the session_regenerate_id whenever the user logs in and out.

One important caveat for session_regenerate_id: It uses one parameter. Set it to “true“. The default is “false“, which will leave the old session intact.

Now to the part everybody appears to be waiting for: Why not /tmp ?

/tmp is a convinient location for session data. Every Unix system I have seen has a /tmp directory that is globally readable and writable. But this is just the problem for session data. The file name itself gives away the session ID. A listing of all session files will give an attacker a list of all valid sessions. In most dedicated web server scenarios, the risk of leaking /tmp file names is low. But the defense is simple enough to “just do it” ™ :

• Create a directory which will only hold session data (let’s call it /tmp/phpsessions).
• This directory should NOT be owned by the apache user, but by root and the apache user’s group.
• Set permissions to 770. Sadly, 760 is not possible. Theoretically, it should work. PHP (the web server) doesn’t really need to be able to get a list of valid sessions. But sessions will fail if you set the permissions to 760.

I typically prefer to keep my sessions in a database, less for security reasons but more for scalability. Memcached sessions is an other great way to get sessions to scale.

My initial reaction to his article was ‘that’s a crazy idea’ – but after some reflection, I really felt like it was a good mental exercise to actually consider what he was saying. If I hadn’t known who Nielsen was, I probably would have dismissed his suggestion outright. Sometimes it is a good exercise to go back and review why we do the things we do – especially as it relates to information security controls. Nielsen questions the real security benefit of password masking – something I haven’t given a second thought to…well, ever.

“Typically, masking passwords doesn’t even increase security, but it does cost you business due to login failures.”

Nielsen’s probably right: It might be costing you business. The question is, how much business? Security shouldn’t be the be-all, end-all goal. It’s there to serve the organization first and foremost. Viewing the cost of security controls with respect to the function it’s protecting is the correct perspective. Enter risk analysis – risk analysis is an important process that helps determine if the cost of having (or not having) a security control mitigates threats, while not adversely affecting the business (too much). It’s about reducing risk to an acceptable level, not about 100% security. It’s a balancing act. Why not target 100% security? Well, if an organization attempted to implement absolute security, it’d go out of business – it’s just too expensive. For example, it doesn’t make sense to spend a million dollars on security solutions that will protect a web site that only earns a few thousands dollars a month.

Again, Nielsen pretty much has it right- except for the ‘true loss of security’ statement:

“The more uncertain users feel about typing passwords, the more likely they are to (a) employ overly simple passwords and/or (b) copy-paste passwords from a file on their computer. Both behaviors lead to a true loss of security.”

Next Nielsen gives a nod to the importance of security and provides an option for masks that takes security into consideration:

“Yes, users are sometimes truly at risk of having bystanders spy on their passwords, such as when they’re using an Internet cafe. It’s therefore worth offering them a checkbox to have their passwords masked; for high-risk applications, such as bank accounts, you might even check this box by default. In cases where there’s a tension between security and usability, sometimes security should win.”

Though I would go further than Nielsen: Users, unless forced, won’t use a complex password even if there is no mask, unless complexity is enforced. If complexity is enforced, a non-masked textbox would certainly help the user meet complexity requirements more easily – which is probably what Nielsen means. Likewise, when presented with an option for masked password or not masked – users typically chose convenience over security so in most cases I would want to default the option to show the mask.

Using simple passwords or ‘copy-paste passwords’ is not NECESSARILY a ‘true loss of security’, but the devil’s in the details.

The loss of security for ‘copy-paste password’ scenarios (which assumes users are storing passwords locally in a file of some sort) assumes a local computer or local network compromise. If so, he’s correct – the gig is up, but that’s not necessarily a true loss of security…well, it IS for the ONE compromised user (or network of users) – but not for all the users of that web site. The main reason we insist on password complexity is increase the keyspace of a password which helps stop brute force and dictionary attacks that originate from attackers “out there” who don’t require access to the user’s computer to begin with. The attacker attempts to find a collision with a password for a known account through a dictionary attack and if they have more time, a brute force attack. Additionally, Password Manager Software (KeePass or Password Safe) will encrypt password stores locally and even associate them automatically with the appropriate web site. Though I suspect the use of password management tools is the exception, not the rule.

As for users choosing too simple of a password: If the site allows users to pick an insecure password, that’s already a failure of the site. But it’s possible to have both a simple password as well as a secure password. Contrary to common belief, good passwords don’t necessarily have to contain symbols, digits, upper and lower case characters.  The reason these complexity requirements were introduced was to protect against brute force attacks as well as dictionary attacks on shorter passwords. Humans have a natural propensity to use simple dictionary words that are easy to remember – such as names, meaningful numbers/dates, pet names, etc., as passwords – hackers take advantage of this seemingly reasonable behavior and use it to their advantage. By adding complexity – that is, the symbols, digits, upper/lower characters – this makes the dictionary attacks more expensive (time consuming) to the attacker since each time we increase the length and the number of possible combinations, this increases the keyspace of the password. So if instead of increasing the combinations, instead increase the password length and use a simple phrase or sentence as the password. These long passwords with less complexity are called a passphrase. Dictionary attacks are useless against passphrases since they are not made up of a dictionary words. By increasing the keyspace by requiring a minimum of 30 normal alpha characters (including spaces and maybe an optional period or comma) we’ve also made it very expensive (time consuming) to brute force. So my passphrase could be “my name is jason and this is my password.” – this is 40+ characters and no more difficult to remember than a dictionary word – but it’s not found in any dictionary so it will stop dictionary attacks and it has a very large keyspace so it will slow down brute force attacks considerably, making them impractical.

A true loss of security? It doesn’t have to be – at least not for the organization. However, I can already hear Nielsen groaning on the usability of typing 40+ characters blindly into a masked password box. This is where two-factor authentication can solve the problem of passwords and passphrases completely – which can really improve usability.

Nielsen’s observation about typing in passwords on mobile devices makes the most sense to me. It is more difficult to shoulder surf someone on a mobile device. It’s also much more difficult to type a password with complexity requirements correctly on a mobile device unless you’re a profession texter. There’s probably not as much risk here by unmasking, so we could probably forgo the mask on mobile devices.   It’s trivial to detect mobile devices, so simple choosing to use a non-masked text box in these situations would be okay for most situations.

But before we go running to dump the masked password box, there’s a few questions we must ask – what are the unintended side-effects of this change? Are there good workarounds to these issues? How much education do developers need to implement this? Remember, we’ve known about and had solutions to SQL Injection for over 10 years now, yet there’s still a constant barrage of developers who still don’t know how to protect against this properly – this is an education problem.

Here’s my initial pass of issues I see by displaying (not masking) passwords to end users:

1. Accidental observation - in the enterprise there are many opportunities where someone else will be at your computer and may accidentally see your password. A great example of this is when using older command line programs that required the password as an argument. I’ve on occasion seen others’ passwords and others have seen mine.
2. Autocomplete Web Forms – Modern web browsers now remember and prefill text boxes with previously used input. This is a usability feature at the expense of privacy/security. This means the password is stored not only  in the OS somewhere for retrieval later, but will pop-up anytime a user starts typing in the textbox. This has the most serious implications on public systems. Developers, if aware of the issue, can prevent this data from being stored by setting the autocomplete attribute to off in the form. This is a developer educational issue.
3. Compliance – I don’t want to get into all the details here, but bad password management practices can cause compliance issues. Lack of compliance can affect business. Not masking passwords may be in violation of certain security requirements for the organization.
4. Nuanced Issues - there are potentially a variety of issues for every masked password box implementation – for instance, in .NET for Windows Applications, there’s a way to encrypt passwords in memory (using the System.Security.SecureString object). Displaying the characters in the textbox first may completely defeat the security provided by this control.
5. What else? - Are there other issues here?

Certainly a usability guy isn’t going to or need to understand all the ins and outs of security, just as I won’t understand the broad range of usability issues.  We should be cautious when recommending broad sweeping changes that affect security. Additionally, us security folks should not resist usability improvements that affect security just because we’ve always done things another way – we should have a good solid business reasons why we do things the way we do. We need to make sure changes can continue to protect our customers/users. Changes to security functionality can often cause unintended side-effects that can put us at risk.  Not that there isn’t a good solution – to me, the most IDEAL solution to improve usability would be to dump passwords as the authentication mechanism all together – there are some partial solutions to this problem, but Identification is a difficult problem to solve – we’re definitely not there yet.  Personally, I look forward to the day where authentication, passwords, and password management all become a thing of the past, but that’s a completely different conversation.

In most cases, database encryption does not prevent the hacker from accessing the backend database via an application compromisse. The reasoning is very simple. If the web application needs to be able to access the data for normal operation and hackers are able to compromise the application, the hackers can essentially access the same data by controlling the applicaton (attacker owns the application). Encryption does not prevent a hacker to access the backend database if the hacker can control the application.

Some may argue that if the database encryption is per user based, then one user’s compromise does not lead to compromise of another user’s data. That is very valid but that usually requires authentication of the user to some backend pieces (or the database itself). Maybe authentication alone is sufficient for the security requirement? The database can provide access control based on user’s identity so one user’s compromise does not lead to access to other user’s data.

You might think I am an anti-encryption person. The fact is – I am not. Encryption totally has its place for web application security reasons. Asymmetric encryption usage to protect data that is “one way” in nature is a good example. As a retail store trying to store the user’s credit card details for recurring monthly payment, the data should be encrypted with asymmetric encryption so that the Web frontend can never read the data back but another party with another related key can. Also, there are numerous other scenario where encryption should be used, such as backup, protecting against rogue DB administrators and against physical theft of database machine.

I often recommend a threat risk assessment before deciding on the database encryption solution. That would allow you to quickly understand the threats that affect the web application and also  possible countermeasures that can help protect against the threat. Due to the cost of deploying and maintaining database encryption, I am seeing very limited deployment of database encryption, most folks tend to turn to other alternatives for risk mitigation.

Encryption is a useful defensive technology that can help protect the web application but it is not a silver bullet, blindly deploying it may not address any threats that you are trying to mitigate. The managers and auditors tend to request these technologies to be deployed to defend against web application compromise after seeing another competitor getting compromised thru web application security flaws (eg. SQL injection). Encryption is likely not the best choice of defensive technology given the scenario.