Back from the latest OWASP Belgium Chapter meeting… Two speakers were scheduled tonight: Colin Watson presented the OWASP AppSensor project then Andreas Falkenberg talked about modern attacks against web services like Twitter. A last-minute guest joined us: Josh Corman who spoke about “rugged software“.
What’s new at OWASP? First OWASP European Foundation is now live! The list of ongoing projects keeps growing. At the moment, 155 projects split in three categories: Protection, detection and life-cycle.
Amongst this huge list, one of them is called AppSensor. It can be briefly described as follows:
“The AppSensor project defines a conceptual framework and methodology that offers prescriptive guidance to implement intrusion detection and automated response into an existing application. Current efforts are underway to create the AppSensor tool which can be utilized by any existing application interested in adding detection and response capabilities.“
Colin, a leader of this project, explained the foundation of AppSensor: patterns for logging, architecture and signaling. Today, attackers are not script kiddies anymore but motivated hackers. They spend a lot of time to find vulnerabilities and try to exploit them. AppSensor can protect you against those attacks. Two important questions to ask yourself:
- Is your application under attack?
- Have an unknown vulnerability been exploited today?
Your answer will probably be “I don’t know“. Colin gave three test cases:
- Stepping trough a process in the wrong order (ex: http://url/step4 then http://url/step2)
- Requesting an unauthorized resource identifier (ex: http://url?id=1004 then http://url?id=1008)
- Payment transfer exceed limit (ex: http://url?amount=10000000)
Typically, web infrastructures are protected by four conventional defenses:
- TLS / SSL
- Firewalls
- Deep Packets Inspection
- Web Application Firewalls
The problem? Most of them won’t block the test cases! Classic WAF’s rely on generic protection (based on patterns) but do not follow the application requirements. So, how to perform a proper attack detection? It must be:
- Integrated – understand the application
- Effective
- Scalable
We need active defenses based on:
- Event Detection
- Event Analyze
- Event Determination
- Response selection
- Response execution.
The detection point can be achieved at several points like data input, access control, requests, authentication, file input/output, user trend, system trend, reputation, encoding, command injection, etc.
How to implement AppSensor into your applications?
- What are the new project requirements
- Retrofitting existing apps
- Preliminary requirements
- Logging
- Risk assessment
- Secure coding (nothing new!)
- Monitoring & tuning
Note that proper logging is mandatory! Using a correct signaling method (Colin mentioned CEF & CEE but other can be used). AppSensor proposes 50 different detection points and more than a dozen of response actions like session reset, user or IP blacklist, speed reduction etc. Colin showed a demo, the dashboard looks impressive. But, by talking with some developers, the same question always came back: How to integrate AppSensor in an efficient way into your applications?
After a short break, Andreas presented a new type of attacks. Web Services (“WS“) are more and more used everywhere today to manage applications, devices. Examples of users? Amazon, BMW (for communications with suppliers), military organizations (NATO, DoD). All of them are nice targets!
Andreas started his presentation with a definition of Web Services and the underlying technologies. Web Services are “an array of technologies and standards to implement remote procedure calls (RPC’s)“. Below, we found the following technologies:
- WSDL files (they define what operations are offered and how to reach them)
- SOAP protocol (used to send WS messages in XML over HTTP(S))
What are the security features of SOAP?
- XML encryption of an arbitrary part of a message
- XML signature of an arbitrary part of a message
The way of SOAP requests are processed is important to understand to conduct attacks. What kind of attacks are they vulnerable?
- All classical web applications attacks (XSS, SQL in, …)
- But lot of new specific attacks like “Signature Wrapping Attack“
Andreas gave a first example of a basic SOAP request without security features enabled. The example was a message sent to a e-commerce portal with a shipping address. He showed how it is easy to change the delivery address. The second example was based on a messages containing a signed body (the signature is based on a regular PKI). Again, easy to move the signed body to an alternative place in the XML and create a new one with the fake data. This showed a major problem with the signature of XML files: it does not specify where the signed data are located! To conduct an attack, prerequisites are just a valid signed SOAP messages which can be easily found by sniffing some traffic, reading logfiles, contacting evil employees or just be reading forums!
The next example explained an Advanced Sign Wrapping Attack against a nice service: Twitter. The social network is hosted by a major cloud provided. This is not Twitter which is vulnerable but the cloud provider itself: The Twitter backend is available via Web Services messages. In this case, SOAP messages contained an expiration time stamp. Hélas, this information can also be hidden and the messages became forever valid. The vulnerability is based on the malformed XML message which contained more than one body. How is this possible? Just due to performance reasons! The XML schema validation is simply not performed. Here is another example of vulnerability.
What countermeasures are available to protect against this type of attacks?
- Strict server side security policy
- XML schema validation
- Use “see what is signed” approach
- Apply “XML signature best practice” by W3C
How to detect if your infrastructure is vulnerable? If it is not designed to resist against this attack, you are! For more information about Web Services attacks, have a look at ws-attacks.org.
Finally, last minute a last minute speaker joined us. Josh Corman presented some slides and good ideas about “rugged software”. The first message was: We are doing it wrong! Can we compare software to a building? A building is made of concrete and steel and we can rely on it. What about software? We can’t rely on them even if they are fully part of our daily life. We need to implement security but business people hate it: it’s very expensive and prevent them to do what they want.
Here is a small survival guide:
- Defensible infrastructure
- Operational discipline
- Situational awareness
- Countermeasures
This was a “turbo” talk but lot of interesting ideas. Feel free to visit ruggedsoftware.org for more info.
