Stan's Blog - Security

Update now available for the ASP.NET security flaw

Stanislas Biron — Wed, 29 Sep 2010 15:41:59 GMT

This morning Microsoft released a security update that addresses the ASP.NET Security Vulnerability that I’ve blogged about this past week.

From Scott Guthrie’s blog post we learn that the update should not require any code or configuration change to your existing ASP.NET applications. Also, if you apply the update to a live web-server, there will be some period of time when the web-server will be offline (although an OS reboot should not be required). You’ll want to schedule and coordinate your updates appropriately.

If you want to apply the update right now, you can go to the microsoft download center and download it. The update will also be released in the next scheduled Windows Update and Windows Server Update.

Other posts

19 great tips to enhance your SQL Server security

Intro to LDAP injection

The LoginProperty function in SQL Server 2005

Google Translator Hacked

SQL Injection joke

In The News: AES Encryption Flaw Makes ASP.NET Sites Vulnerable To Attacks

Stanislas Biron — Wed, 15 Sep 2010 13:35:36 GMT

Seen on Visual Studio Magazine

Two security researchers, Thai Duong and Juliano Rizzo, have discovered a bug in the default encryption mechanism used to protect the cookies normally used to implement Forms Authentication in ASP.NET. Using their tool (the Padding Oracle Exploit Tool or POET), they can repeatedly modify an ASP.NET Forms Authentication cookie encrypted using AES and, by examining the errors returned, determine the Machine Key used to encrypt the cookie. The process is claimed to be 100 percent reliable and takes between 30 and 50 minutes for any site.

Once the Machine Key is determined, attackers can create bogus forms authentication cookies. If site designers have chosen the option to embed role information in the security cookie, then attackers could arbitrarily assign themselves to administrator roles. This exposure also affects other membership provider features, spoofing protection on the ViewState, and encrypted information that might be stored in cookies or otherwise be made available at the client.

While the exposure is both wide and immediate, the fix is simple. The hack exploits a bug in .NET's implementation of AES encryption. The solution is to switch to one of the other encryption mechanisms -- to 3DES, for instance. Since encryption for the membership and roles providers is handled by ASP.NET, no modification of existing code should be required for Forms Authentication.

The encryption method can be set in the web.config file for a site, in IIS 7 for a Web server, or in the config file for .NET on a server in %SYSTEMROOT%\Microsoft.NET\Framework\version\CONFIG\. On 64-bit systems, it must also be set in %SYSTEMROOT%\Microsoft.NET\Framework64\version\CONFIG\. A typical entry would look like this:

    <machineKey validationKey="AutoGenerate,IsolateApps"         
                           validation="3DES"                           
                           decryptionKey="AutoGenerate,IsolateApps"
                           decryption="3DES" />

On a Web farm, this setting will have to be made on all the servers in the farm.

These settings are also used to prevent spoofing (ViewState data is encoded but not encrypted), so making this change will also switch the ViewState to using 3DES. Developers who are using AES in their code to encrypt information made available at the client should consider modifying their code to use a different encryption mechanism.

Other Posts:

Google instant makes searching for God harder

Tabnabbing: A New Kind Of Phishing Attack

Big news in security: 1024-bit RSA encryption cracked!

Tips to enhance your SQL Server security

What is LDAP injection?

Tabnabbing: A New Kind Of Phishing Attack

Stanislas Biron — Tue, 06 Jul 2010 13:40:27 GMT

This is an interesting new attack, I just saw a live demo of it here: Tabnabbing: A New Type of Phishing Attack. All you need to do is let the page load, then browse to another tab for more than 5 seconds and you’ll see the favicon change to Gmail and the page will load a Gmail image.

And apparently the use of this attack is on the rise in the wild according to Panda Labs. It’s a pretty interesting phishing attack and although it’s unable to change the URL in the address bar I believe a lot of people rely on visual cues and may not notice the URL doesn’t match the page content.

The use of Tabnapping, the recently-identified phishing technique, is on the rise, says Panda Labs.

Tabnabbing exploits tabbed browser system in modern web browsers such as Firefox and Internet Explorer, making users believe they are viewing a familiar web page such as Gmail, Hotmail or Facebook. Cybercriminals can then steal the logins and passwords when users enter them on the these hoax pages.

According to Panda’s latest Quarterly Report on IT Threats, the technique is likely to be employed by more and more cybercriminals and users should close all tabs they are not actively using.

I think this could be quite effective, especially for the less technical crowd on Facebook and using services like Hotmail and Gmail. It could even extend into targeted localized attacks on online banking systems.

Apparently all browsers are susceptible to this including Chrome, Firefox, Internet Explorer and Opera (on Windows XP anyway). More details in a PC Advisor article here.

Perhaps this is something that can be addressed in Firefox as the person who developed this technique is the Creative Lead for Firefox – Aza Raskin.

Other Posts:

Big news in security: 1024-bit RSA encryption cracked!

Google Translator Hacked

Tips to enhance your SQL Server security

How to: Use Active Directory to authenticate users in C#

Big news in security: 1024-bit RSA encryption cracked!

Stanislas Biron — Wed, 10 Mar 2010 14:32:52 GMT

First off: no, it’s not a joke! April 1^st is in three weeks.

Since 1977, RSA public-key encryption has protected privacy and verified authenticity when using computers, gadgets and web browsers around the globe. Only the most brutish of brute force efforts (and 1,500 years of processing time) could manage to bypass its 768-bit variety.

Now, three eggheads (or Wolverines, as it were) at the University of Michigan claim they can break it simply by tweaking a device's power supply. By fluctuating the voltage to the CPU such that it generated a single hardware error per clock cycle, they found that they could cause the server to flip single bits of the private key at a time, allowing them to slowly piece together the password. With a small cluster of 81 Pentium 4 chips and 104 hours of processing time, they were able to successfully hack 1024-bit encryption in OpenSSL on a SPARC-based system, without damaging the computer. That's why they're presenting a paper at the Design, Automation and Test conference this week in Europe, and that's why -- until RSA hopefully fixes the flaw -- you should keep a very close eye on your server room's power supply.

From the article on techworld:

RSA authentication is susceptible, they say, to changes in the voltage supply to a private key holder. The researchers – Andrea Pellegrini, Valeria Bertacco and Todd Austin - outline their findings in a paper titled “Fault-based attack of RSA authentication” to be presented 10 March at the Design, Automation and Test in Europe conference.

Quite scary…

Other posts:

US Investigators Pinpoint Author Of Google Attack Code

Google Translator Hacked

What is LDAP injection?

Tips to enhance your SQL Server security

Password aren't a good defense?

In the news: US Investigators Pinpoint Author Of Google Attack Code

Stanislas Biron — Tue, 23 Feb 2010 15:33:37 GMT

The big news over the past few months were the Aurora attacks and how they seemed to originate from China, last month Microsoft took the unusual step and released an Out-Of-Band patch for the IE6 0-Day vulnerability used in the attacks.

It was always thought the exploit originated from China due to parts of the code only being discovered on Chinese language sites, the latest news is that the actual origin of the code has been discovered by US investigators.

US investigators have pinpointed the author of a key piece of code used in the alleged cyber attacks on Google and at least 33 other companies last year, according to a new report.

Citing a researcher working for the US government, The Financial Times reports that a Chinese freelance security consultant in his 30s wrote the code that exploited a hole in Microsoft’s Internet Explorer browser. The report also says that Chinese authorities had “special access” to this consultant’s work and that he posted at least a portion of the code to a hacking forum.

According to The Financial Times report, the unnamed security consultant who wrote the exploit code is not a full-time government worker and did not launch the attacks himself. In fact, the FT says, he “would prefer not to be used in such offensive efforts.”

The reports says that when he posted the code to the hacking forum, he described it as something he was “working on.”

With a January blog post, Google announced that attacks originating from China had pilfered unspecified intellectual property from the company, and Microsoft later said the attack had exploited a hole in its Internet Explorer 6 browser. According to security researchers, at least 33 other companies were targeted by similar attacks.

Put simply, this means that the “consultant” who created the code posted a proof of concept for this exploit on a hacking forum. Then someone took this proof of concept, turned it into a working exploit and attacked 33 US based companies.

It will be interesting to watch how this story will unfold after this and if it’s going to increase the tension between the US and China governments. The whole cyberwar has been going on for quite a while now with both sides trying to secretly steal information from each other.

So far the author of the code has not been named and his real identity or purpose is still a little vague.

Source: The Register

Other posts:

Google Will Pay 500$ Bounty For Each Chrome Browser Bugs You Find

Google Translator Hacked

Password aren't a good defense?

In the news: Google negotiating cooperation with the NSA

Some tips to enhance your SQL Server security

How To: Create an Outlook 2003 addin using VSTO SE and Visual Studio 2005

In the news: Google negotiating cooperation with the NSA

Stanislas Biron — Fri, 05 Feb 2010 15:30:04 GMT

In January, Google went public with news that some of its systems had been hacked, along with those of a number of US-based companies. The attacks had targeted both accounts maintained by political activists and commercial code, and Google pointed the finger straight at China, vowing to change its entire approach to business in that country. But a report now suggests that the company is also looking to beef up its internal defenses to prevent a repeat of the attacks.

The Washington Post is reporting that Google has started negotiations with the US National Security Agency about a collaborative effort to analyze the attack and figure out how best to prevent a recurrence. The Post is citing confidential sources, as the deal isn't final and, even if it were, it's unlikely that Google would seek to publicize it.

For starters, both organizations have already been the target of many complaints by privacy advocates, the NSA for its domestic surveillance efforts, Google for its data retention policies. The combination of the two would clearly make the advocates far more uneasy, and might help them make their case with the wider public. Meanwhile, as the report notes, private companies have often been loath to share information about their proprietary systems with the government for a variety of reasons.

That may explain why the negotiations have been going slowly, as the NSA would clearly need access to and understanding of Google's infrastructure in order to fully evaluate the attacks and future risks. And that's precisely the sort of proprietary information that Google is presumably reluctant to provide anyone with—even a highly secretive organization like the NSA.

Other posts:

Google Willing To Pay 500$ Bounty For Each Chrome Browser Bugs You Find

Google Translator Hacked

BusinessWeek hit by SQL Injection attack

Password aren't a good defense?

Google Willing To Pay 500$ Bounty For Each Chrome Browser Bugs You Find

Stanislas Biron — Mon, 01 Feb 2010 15:22:17 GMT

This is a pretty interesting development from Google and also seems to be coming much more common now, companies openly offering payments for bugs/vulnerabilities discovered in their software. They already used that strategy to find bugs last year with their Native Client Security hacking contest. This time they offer $500 for most vulnerabilities, $1,337 for 'particularly clever' flaws. You can see the blog post on the Chromium blog here.

It’s a chance for the white-hat guys to earn a few bucks, but honestly I don’t think it’s going to change anything. Especially not when we’re talking $500 per vulnerability because a serious browser 0-day exploit that can allow execution of malware will go for 100 times that much on the black market. Even for the particularly severe or clever bugs worth $1,337, that’s still peanuts compared to what they can sell the exploit for on the black market.

I hope it helps though and gives some legitimate security researches a little more incentive to focus on Chrome, the bad guys won’t pay much attention though as Chrome is still a relatively small player in the browser world.

From the article at Network World

“We are hoping that … this program will encourage new individuals to participate in Chromium security,” said Evans. “The more people involved in scrutinizing Chromium’s code and behavior, the more secure our millions of users will be.”

“Internet Explorer, Safari, Firefox…those browsers have been out there for a long time,” said Pedram Amini, manager of the security research team at 3com’s Austin, Tex.-based TippingPoint, which operates Zero Day Initiative (ZDI), one of the two best-known bug-bounty programs. “But Chrome, and now Chrome OS, need researchers. Google needs people to put eyes on the target.”

Google’s new bounty program isn’t the first from a software vendor looking for help rooting out vulnerabilities in its own code, but it’s the largest company to step forward, Amini said. Microsoft , for example, has traditionally dismissed any calls that it pay for vulnerabilities. “This will be beneficial to Google,” Amini added. “There are actually very few vendors who play in the bounty market, but Google doing it is definitely interesting.”

I don’t realistically expect any groundbreaking bugs to come out of this initiative, but I think a few people might bust out their browser fuzzing tools and see what they can find.

Worth a bit of effort if you can find 10 decent bugs in a couple of hours and net yourself $5000usd.

You can see the on the chromium project severity guidelines page the different severity ranking for bugs.

Other posts:

Google Translator Hacked

Some tips to enhance your SQL Server security

What is LDAP injection?

Some tips to enhance your SQL Server security

How to generate random numbers within a T-SQL query

Some tips to enhance your SQL Server security

Stanislas Biron — Mon, 14 Dec 2009 18:12:56 GMT

Physical security:

Ensure the physical security of each SQL Server, preventing any unauthorized users to physically accessing your servers.

Network:

Ensure that your SQL Servers are behind a firewall and are not exposed directly to the Internet
Avoid creating network shares on any SQL Server.
Only install required network libraries and network protocols on your SQL Server instances.

Configuration:

Only give SQL Server service accounts the minimum rights and permissions needed to run the service. In most cases, local administrator rights are not required, and domain administrator rights are never needed. SQL Server setup will automatically confgure service accounts with the necessary permissions for them to run correctly, you don’t have to do anything.
Run each separate SQL Server service under a different Windows domain account.
Use strong passwords for all SQL Server login accounts.
Turn on login auditing so you can see who has succeeded, and failed, to login.
Remove sample databases from all production SQL Server instances.
Add operating system and SQL Server service packs and hot fixes soon after they are released and tested, as they often include security enhancements.

Users and permissions management:

Assign the SA account a very obscure password, and never use it to log onto SQL Server. Use a Windows Authentication account to access SQL Server as a sysadmin instead.
When possible, use Windows Authentication logins instead of SQL Server logins.
Remove user login IDs who no longer need access to SQL Server.
Remove the guest user account from each user database.
Never grant permission to the xp_cmdshell to non-sysadmins.
Don’t use the SA account, or login IDs who are members of the Sysadmin group, as accounts used to access SQL Server from applications.
Give users the least amount of permissions they need to perform their job.
Use Windows Global Groups, or SQL Server Roles to manage groups of users that need similar permissions.
Don’t grant permissions to the public database role.

Other posts:

What is LDAP injection?

The T-SQL LoginProperty function in SQL Server 2005

How to: Use Active Directory to authenticate users

How to put log4net configs outside of the application configuration file

What is LDAP injection?

Stanislas Biron — Mon, 23 Nov 2009 20:31:41 GMT

LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.

The key to exploiting injection techniques with LDAP is to manipulate the filters used to search in the directory services. Using these techniques, an attacker may obtain direct access to the database underlying an LDAP tree, and thereby to important corporate information. This can be even more critical because the security of many applications and services relies on single sign-on environments based on LDAP directories.

Example

In a page with a user search form, the following code is responsible to catch input value and generate a LDAP query that will be used in LDAP database.

 <input type="text" size=20 name="userName">Insert the username</input>

The LDAP query is narrowed down for performance and the underlying code for this function might be the following:

 String ldapSearchQuery = "(cn=" + userName + ")";
 System.out.println(ldapSearchQuery);

If the variable userName is not validated, it could be possible accomplish LDAP injection, as follows:

If a user puts “*” on box search, the system may return all the usernames on the LDAP base
If a user puts “jonys) (| (password = * ) )”, it will generate the code bellow revealing jonys’ password ( cn = jonys ) ( | (password = * ) )

How to protect against these attacks?

INPUT VALIDATION. This will never be said enough: input validation is the best way to protect against most injection-type attacks. Whitelist validation is always your best bet. The idea is that you should check that the data is one of a set of tightly constrained known good values. For example, for the username field above, the input should accept only alphanumeric characters.

Other posts:

The T-SQL LoginProperty function in SQL Server 2005

BusinessWeek hit by SQL Injection attack

How to: Use Active Directory to authenticate users

How to set NTFS permissions using C# 2005

Google Native Client Security - Hacking Contest - You could win $8,192 USD!

Stanislas Biron — Wed, 11 Mar 2009 13:57:37 GMT

What is Native Client?

Native Client is an open-source research technology for running x86 native code in web applications, with the goal of maintaining the browser neutrality, OS portability, and safety that people expect from web apps.

About the contest

Do you think it is impossible to safely run untrusted x86 code on the web? Do you want a chance to impress a panel of some of the top security experts in the world? Then submit an exploit to the Native Client Security Contest and you could also win cash prizes, not to mention bragging rights.

What is the contest

This is a contest with the goal to test the security of Native Client.

To participate, you will need to:

Register yourself (or your team)
Download our latest build
Join the NaCl discussion group
Report the exploits you find to our team

When

You can register for the contest on Wednesday, February 25th 2009. The contest will end on Tuesday, May 5th 2009 at 11:59:59 Pacific time. Sign up early to start reporting exploits as soon as possible.

What’s in it for you

Participating in the contest means that you will engage with early stage research technology. In addition, your work will be reviewed by a panel of security experts from some of the world’s most renowned universities, chaired by Edward Felten of Princeton University. Finally, by submitting high impact bug(s), you will also have the chance to compete to win one of our five cash prizes, as well as the recognition of your peers.

Eligible participants that are ranked in the top 5 positions of the competition by Judges will receive the following awards in U.S. Dollars based on their rank:

1st prize: $8,192.00
2nd prize: $4,096.00
3rd prize: $2,048.00
4th prize: $1,024.00
5th prize: $1,024.00

Winning Entries will be announced on or about December 7th.

Details at:

http://code.google.com/contests/nativeclient-security/

The T-SQL LoginProperty function in SQL Server 2005

Stanislas Biron — Tue, 02 Dec 2008 15:40:46 GMT

Did you change the “sa” password recently? As a DBA, you should be aware that there is a great security risk linked to the sa account. You should always use strongs password for this account and change the password frequently.

You can easily check when the “sa” password was last changed in SQL Server 2005 by executing the following T-SQL code:

SELECT LOGINPROPERTY ('sa', 'PasswordLastSetTime')>

The LOGINPROPERTY function gives you lots of information on the logins properties and password policy information for these logins.

Another thing you can do with this function is to look for security attacks. For example if you want to look for brute-force or dictionnary attack on the “sa” account, you can use the following query:

SELECT LOGINPROPERTY ('sa', 'BadPasswordCount')

This will return the number of failed consecutive attempts to login since the last successful login. So if this value goes over a certain value, you can easily see that something might be wrong.

Here is the complete list of properties you can query for using the LoginProperty function:

BadPasswordCount
Returns the number of consecutive attempts to log in with an incorrect password.

BadPasswordTime
Returns the time of the last attempt to log in with an incorrect password.

DaysUntilExpiration
Returns the number of days until the password expires.

DefaultDatabase
Returns the SQL Server login default database as stored in metadata or master if no database is specified. Returns NULL for non-SQL Server provisioned users; for example, Windows authenticated users.

DefaultLanguage
Returns the login default language as stored in metadata. Returns NULL for non-SQL Server provisioned users, for example, Windows authenticated users.

HistoryLength
Returns the length of time the login has been tracked using the password-policy enforcement mechanism.

IsExpired
Returns information that will indicate whether the login has expired.

IsLocked
Returns information that will indicate whether the login is locked.

IsMustChange
Returns information that will indicate whether the login must change its password the next time it connects.

LockoutTime
Returns the date when the SQL Server login was locked out because it had exceeded the permitted number of failed login attempts.

PasswordHash
Returns the hash of the password.

PasswordLastSetTime
Returns the date when the current password was set.

Other posts:

Differences between temporary tables and tables variables

How to insert a file in an image column in SQL Server 2005

How to add a row number in an SQL Query

BusinessWeek hit by SQL Injection attack

Stanislas Biron — Fri, 28 Nov 2008 17:51:21 GMT

It’s stunning to see how many website are still vulnerable to SQL Injection attacks. Many SQL Injection worms are circulating right now and are dropping malicious code in thousands of databases. Even major sites are vulnerable to this type of attack. BusinessWeek, the world-class magazine, was a victim of this kind of attack last September.

From the article at Net-Security:

Folks from Sophos have discovered that the website of BusinessWeek, the world famous weekly magazine, has been attacked by hackers in an attempt to infect its readership with malware.

Hundreds of webpages in a section of BusinessWeek’s website which offers information about where MBA students might find future employers have been affected. According to Sophos, hackers used an SQL injection attack - where a vulnerability is exploited in order to insert malicious code into the site's underlying database - to pepper pages with code that tries to download malware from a Russian web server.

At the time of writing, the code injected into BusinessWeek’s website points to a Russian website that is currently down and not delivering further malicious code. However, it could be revived at any time, infecting hundreds of MBA students looking for high-earning jobs. Sophos informed BusinessWeek of the infection last week, although at the time of writing the hackers' scripts are still present and active on their site.

This goes to show you that, if you are the developer of an internet facing website (or an intranet for that matter), you need to commit yourself to enhance it’s security against these kind of threats. Everyone should adopt secure coding practices as there is no site that will be spared. More and more we will see automated SQL Injection attacks using crawlers, worms and bots and.