Here are ten Lift answers for the OWASP Top 10 vulnerabilities by David Pollak on Liftweb, Thu, 22 Oct 2009:

1. Lift is resistant to XSS attacks. By default pages are composed in
   XML rather than Strings. It takes the developer extra work to insert XSS
   strings into output rather than having to make sure each String is properly
   escaped before being cat’ed to the output.
2. Lift is resistant to SQL Injection attacks because mapper and JPA do
   not compose Strings into SQL statements, but rather bind well typed
   parameters into prepared statements. So, if you go the normal path, you get
   SQL injection resistance. If you want to manually craft a String to send as
   a query, in mapper you have to “sign” the string with the time, date and a
   certification that you’ve reviewed the String for SQL Injection problems.
3. Lift never shells out. You can’t cause a file to be executed from a
   Lift app unless your app manually uses Java’s Runtime.execute() call.
4. By default, Lift creates opaque GUIDs to refer to components on the
   server side (whether that’s a function to execute when a form field is
   submitted, what to do on an Ajax call, etc.) By default, it’s easier to use
   this callback mechanism than advertise a primary key or other sensitive
   piece of information. Lift also has the KeyObfuscator which will create a
   session-specific mapping of primary keys to opaque ids. Using
   KeyObfuscator, you can send JSON objects to the client with stable primary
   keys that are obfuscated and not usable outside the current session.
5. By default Lift’s form fields contain GUIDs that are cryptographically
   impossible to predict. It’s not possible to do CSRF because one does not
   know the name of form fields (they are not stable)
6. Lift has different production vs. development mode error messages.
   There’s little information that leaks about underlying configurations, even
   exceptions, in production mode.
7. Lift uses the container’s session management (usually JSESSIONID) for
   session management. As far as I know, Jetty, Tomcat, Glassfish are secure
   in terms of the way they deal with sessions. Of course, anything that’s not
   over SSL is vulnerable to a cookie stealing attack.
8. Crypto key storage is a container-level issue. See #7
9. See #7
10. Lift’s sitemap is the best and most secure integration of UI and
    page-level access. You can look at the sitemap to determine the access
    control rules for a given page (it’s declarative) and it’s enforced long
    before your page gets accessed.

Liftweb also maintains a “Seven Things” site with six answers to the OWASP Top 10

• A1: Injection – Lift’s Mapper and Record do proper escaping of query strings before they are sent to the backing store.
• A2: XSS – Lift keeps the rendered page as a DOM until very late in the page rendering cycle. This allows Lift to automatically HTML escape Strings before they are sent to the browser.
• A3: Session Management – Lift uses the J/EE container’s session management, allows for generation of new sessions on login, and keeps passwords hashed at all times with per-row salt.
• A4: Direct Object References – Lift forms do not expose direct object references, but instead keep the object references server-side and issues a session-specific token that refers to the objects.
• A5: CSRF – Lift uses session-specific bindings between HTML elements and the server-side behaviors associated with those elements. The bindings cannot be predicted so it’s not possible to issue Cross Site requests that invoke session-specific bindings.
• A8: URL Access – Lift includes SiteMap which provides declarative rules for access to URLs in the application. SiteMap will deny access to URLs unless the criteria is met for accessing the specific URL.

Secumania posted on February 4th a a privilege escalation flaw in Metasploit 3.5.1

By placing a DLL file in the %systemdrive%\framework\postgresql\bin it is possible to get it loaded by a program (postgres.exe) that is executed by the frameworkPostgreSQL´s service executable (pg_ctl.exe), every time the service starts, with NT AUTHORITY\SYSTEM user privileges, being able to run arbitrary code in the local system. Notice the service startup is set to automatic by default.

I know, I know, you’re probably thinking “who runs this on Windows?” Metasploit has fixed the problem, perhaps ironically, by following the Microsoft Windows Application Specification (e.g. Requirement 4.4: Run in a secure Windows environment from January 21, 2000) a little more diligently in their Feb 9th release of 3.5.2. OMG that’s nearly 432,000 seconds in 0-day time since disclosure!

The new installers fix this issue through two changes: first, we’ve moved the default installation to %ProgramFiles%, which does not normally allow non-admin write access; second, we explicitly remove any inherited permissions for the “Users” and “Authenticated Users” groups. For users who prefer not to re-install Metasploit, you can use the following commands to fix the problem:

Vista and newer:

icacls c:\framework /inheritance:d /t
icacls c:\framework /remove *S-1-5-32-545 /t
icacls c:\framework /remove *S-1-5-11 /t

For systems older than Vista, you will need the xcacls.vbs tool available from Microsoft.

xcacls.vbs c:\framework /E /R SID#S-1-5-32-545 /T

Note that the “Authenticated Users” group doesn’t exist before Vista, so you only need to remove “Users”.

This issue is mitigated by the fact that it only affects multi-user Windows installations with low-privileged accounts, a scenario we believe to be a small percentage of our users.

Cue the evil cackle/laugh. Is that meant to be a hint? A liability disclaimer? Metasploit knows full well that those who choose to run Windows installations always run with high-privileges. Srsly now.

Metasploit must monitor download data for Windows version of the program, so maybe they could qualify their statement with something like “a small percentage of our tens of thousands/hundreds of…Windows users”. Even better would be if they could say “Dear HBGary, your installation of Metasploit…”. Kidding. Everyone knows HBGary used home-grown pentest tools as part of their custom CMS.

A Canadian airline called Air Transat gave a British passenger’s name to the American government, which resulted in him being barred from flying to England.

Canadian Civil Liberties Association is expressing concerns about why Canadian airlines were willing to give passenger information to the U.S. when they are not legally obligated to do so. A bill going into third reading in Ottawa is calling for airlines to be exempt from Canada’s privacy laws, which will enable the companies to send the information to counter-terrorism officials in the U.S. and other countries. “Bill C42 hasn’t yet passed, but it seems aircraft carriers may be acting as if Bill C42 is already law,” the group said.

He went to the media for help. Lucky for him the British embassy stepped in and he was cleared of suspicion — allowed by the US to fly from Toronto to a destination in England. The Edmonton Journal says if he had made the appeal on his own to the US he could have been left stranded in their bureaucracy for months despite being on Canadian soil.

Michal Zalewski gives a biting commentary

…the purported details of the attack on HBGary – a horribly vulnerable, obscure CMS; unpatched internal systems; careless password reuse across corporate systems and Twitter or LinkedIn; and trivial susceptibility to e-mail phishing – are a truly fascinating detail. These tidbits seem to imply either extreme cynicism of their staff… or an ubelievable level of cluelessness. And from a broader perspective, both of these options are pretty scary.

Oh, the ironic part? Despite all the lofty rhetoric, looks like in the end, they have been undone by just a bunch of bored kids.

At least China is still off the hook…for now.

Couldn’t help but notice the breach report simplicity: a simple SQL query produced the password hashes and then an easy brute-force produced the passwords. The passwords were the same on many different sites.

The exact URL used to break into hbgaryfederal.com was

http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27.

[…]

[T]he hbgaryfederal.com CMS used MD5. What’s worse is that it used MD5 badly: there was no iterative hashing and no salting.

[…]

[And they] used passwords that were very simple; each was just six lower case letters and two numbers.

Yeah, oops on several counts.

Maybe, just maybe, this will help the PCI Council change their position on MD5. It would be great to get some pressure again to fix the ten-year old security flaws. Compliance regulations are one of the most effective ways to move that dial.

Updated to add: Colbert on HBGary — it was a government subversive plot to undermine journalists and proves they can’t get anything right: