In today's digital world, one cannot afford to be unprotected. It does not matter if you are a multi-national enterprise or a home user, there is someone out there who will want to use your PC to collect sensitive data or to infiltrate into your network.
We use computers for everything – from banking and investing to shopping and communicating with others through email or chat programs. Although you may not consider your communications "top secret," you probably do not want strangers reading your email, using your computer to attack other systems, sending forged email from your computer, or examining personal information stored on your computer (such as financial statements).
Most of our information security devices use malware “signatures” to identify different types of malware and thus protect our assets. These signatures can be in the form of firmware for our switches and routers, configuration and patches for IPS/IDS, firewalls and other servers, and virus/malware signatures for our anti-virus servers. We, as computer users, need to update these signatures on a daily basis in order to stay protected.
But, is it enough?
Is it Enough?
Apparently not.
According to CERT, 8,064 vulnerabilities were detected in 2006 alone.
But that is not all. The amount of time it takes for a virus to be distributed varies, though typically the fiercer attacks also spread more rapidly: 'Low Intensity' attacks take approximately 7 hours to 2 days; 'Significant' attacks take 1 hour to 1 day; and 'Medium' to 'Massive' attacks were swiftly distributed in 3 to 5 hours.
This means that vendors will have to update their firmware and release patches on a daily basis, while we will have to dedicate most of our time to patching our devices and servers.
But even that may not be enough. In some organizations there is a very strict patch release control which can take more that a week, and in some organizations, the Information Technology (IT) is so large, that it is not a task for one man. You may need to hire additional personnel for this one task.
Failure to comply will expose the organization to various threats. Furthermore, there is a chance that you might be attacked before a patch will be applied.
What is the Alternative?
The alternative, as I see it, is to do what the financial sector (banks) did and still does to client's on-line transactions.
Most of the banks today have fraud detection systems. And if they don't – they should. These systems analyse client's behaviour patterns over a period of time and then detect any digression in behaviour. After that, they may pop-up an authentication box or block the transaction, depending on vendor and configuration.
Why not take this approach into the IT world?
Instead of analysing client behaviour, we will analyse the normal behaviour of our software and then monitor it for any abnormal activity. For example, Microsoft Word will never try to rename a word.exe or try to manipulate .DLL files. In general, programs do not try to rename themselves.
We can take two different approaches. One, we will analyse “good” programs and allow them to function according to the patterns of their behaviour. The other approach can be analysis of “bad” software and thus block every software that behaves the same.
Why is it Good?
This alternative approach gives us the ability to react to any abnormal behaviour in our IT infrastructure and react fast, be it a registry key change or TCP packages manipulation. We will not have to deal with situations where we already lost the information and now we have to close the gap. With good and appropriate behaviour analysis, the gaps simply won't be there.
Since behaviour of malware does not change often, we won't have to spend the whole day patching our servers or disconnecting them to handle a virus outbreak.
For an attack to be successful, each attacker will have to come up with totally different intrusion scenarios, and I don't mean buffer overflow through a different DLL file.
Published under Comsec Consulting UK
Friday, February 16, 2007
Monday, February 12, 2007
AJAX - The Evil Within
What is Ajax?
Ajax shorthand for Asynchronous JavaScript and XML and it is a web development technique for creating interactive web applications. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
Standards presentation using XHTML and CSS
Dynamic display and interaction using the Document Object Model (DOM)
Data interchange and manipulation using XML and XSLT
Asynchronous data retrieval using XMLHttpRequest
JavaScript that binds everything together
The main reason for Ajax is reduce bandwidth usage and increase interactivity and user experience. By using the XmlHttpRequest object to request and return data without a re-load, a programmer by-passes this requirement and makes the loosely coupled web page behave much like a tightly coupled application.
The “Traditional” Web Applications
In “Traditional” web applications, the default architecture was considered as back-end servers to store and manipulate the data while front end (HTML web page) was mostly used to style and display the information.
A lot of information security best practices were written to support the growing demand on business to go on-line. Users started to be aware of security implication and the on-line behaviour like, don't press the “Submit” button twice, "Wait a bit longer, it's just processing," or "Don't press the 'back' button after you've submitted the form.
But you can throw that basic knowledge out of the window now that AJAX is here.
“Ajax” Web Applications
The data is still resides in the back-end data servers, but Ajax extends program across both the client device and the server. Instead of seeing blank browser window and an hourglass icon, Ajax don't “steal” user's interaction with the application.
Every user action that normally would generate an HTTP request to the server. Now, any response to a user action that doesn’t require a trip back to the server, such as simple data validation, editing data in memory, and even some navigation, the Ajax engine handles on its own. If the engine needs something from the server in order to respond, the engine makes those requests asynchronously, usually using XML.
Threats in Ajax
As we seen before, Ajax extends programs across both the client device and the server, creating far more opportunities for hackers to deliver malware onto sites.
Multiple Transmissions
If before, when user fill the form, the information was submitted only once to the server, an Ajax-enabled form, which automatically relays the data from each field as data is entered, will launch multiple transmissions that virus writers can latch into.
Screen Capturing Attacks
Before Ajax, the user were been able to control (with more or less granularity) the information which website was able to get access to. The user was able to review the information couple of times before hitting the “Submit” button. Now, So-called screen-scraping attacks and Web session hijacking attempts, both of which also seek to steal users' data, could also be performed more easily by taking advantage of Ajax. With AJAX, a user's actions can be constantly and meticulously monitored. Because it can be done, it will be done, and that will lead to a headache bigger than just wasted bandwidth, gigabytes of useless information, and slower page load times.
Cross Site Scripting
Ajax introduce a lot more JavaScript code into the web pages. Before, most of the business logic was hidden safely on our servers and the client was presented with mostly processed data and very few lines of script. Now, Ajax moves fair amount of business logic to front-end which allow bigger “surface” to attack.
DoS (Denial of Service)
Though this problem is not new, Ajax approach may increase this vulnerability. Just imagine the following scenario: Web server is serving 1000 users to lookup ten digits serial number. Poorly implemented Ajax web page will do a look up for every digit user type. This will increase the load server needs to handle tenfold.
Source Code Hiding
Since Ajax allow to perform any action in the background, it also allow malicious web page to change the JavaScript code on right button click. In other words, it's possible to add or modify JavaScript functions and code in the background even after a page load!
So even if you inspect the page source for code that might be sending keystrokes or mouse movements back to the Web server, you can't be certain that the code you see is the only code that's executing.
Intellectual Property
Commercial application vendors regard their source code as their intellectual property, and are likely to want to obfuscate client side code to protect it. AJAX implementations introduce a large amount of client side code so we are likely see a lot of commercial applications implement JavaScript obfuscation. This may be an understandable approach from a legal perspective, but it breaks apart when the intention is to obfuscate security controls.
Even average developer with malicious intentions and with enough time could reverse-engineer, and get “insider view” on security control of such applications.
Eavesdropping
Eavesdropping is one of the simplest and the oldest techniques for data theft: an unauthorized party listens to conversations between systems and collects their data. Eavesdropping could be done simply to get access to data like credit card account information, or it could be used to hijack identity credentials and start an authentication attack as described above.
Data Integrity and Replay Attacks
Eavesdropping enables both data integrity attacks and replay attacks. Using data obtained by eavesdropping with slight modifications (recall that XML is a text-based, human-readable format) before sending it on its way is known as a data integrity attack. The most basic version is a simple message forgery.
Replay attacks occur when a hacker uses stolen messages and continually replays that same valid (maybe we validate the schema) message at potentially high rates. Obviously that type of attack could have serious repercussions like server overload.
Knowledge and Best Practices
This might be the biggest problem of Ajax today, lack of knowledge base and best practices. For the last 1o years, a lot of security experts and developers gathered huge knowledge base, expertise and best practises of how to secure and migrate risks in standard web application. Nothing of this kind exist for Ajax. Ajax applications have a huge attack surface, much larger than traditional applications, and the buzz around Ajax is creating immense security implications, as the available knowledge bases and types of resources available for developers are poor.
Inexperienced developers fail to properly protect their work and attackers learn to use the benefits of Ajax to their advantage. His (inexperienced Ajax programmer) use of widely available Ajax code in their own programs without proper understanding, a common practice, will create even more problems.
XML Security
Since the other end point of Ajax is Web Service with understand XML, all security threats exits in XML are relevant with usage of Ajax. The XML threats are:
How to protect your application
Actually, there is nothing new. We still need to validate the input received from he users, perform output encoding and improper access control. AJAX in itself does not introduce these vulnerabilities – poorly web applications have been susceptible to these problems long before AJAX.
Spajax
Sprajax (sometimes called as “Atlas” ajax security scanner , since it can only detect the “Atlas” framework and the SOAP web services used by the “Atlas” framework) is the first web security scanner developed specifically to scan AJAX web applications for security vulnerabilities.
XML Firewall
XML firewalls are different breed of application firewall. It can examine SOAP headers and XML tags, and based on what they find, distinguish legitimate from unauthorized content.
In addition, XML firewalls can look into the body of the message itself and examine it down to the tag level. It can tell if a message is an authorized one, or coming from an authorized recipient. Also, they can understand metadata about the Web service's service requester as well as metadata about the Web service operation itself. They can gather information about the service requester, such as understanding what role the requester plays in the current Web service request, for example. XML firewalls can also provide authentication, decryption, and real-time monitoring and reporting.
Same Old, Same Old
Maybe Ajax is new in town, but it is just a combined usage of existing technologies.
Number of tips to secure your application:
The future
Despite security threats mentioned above, the business' drive to attract more clients by improving their websites and web applications will create a increasing usage of Ajax. Customers love dynamic and interactive website, everything that Ajax represents, so there is a lot of demand. But the problem is, most of Ajax developers know nothing about security.
As I see it, the threat of improper usage of Ajax won't stop companies for massive adoption of technology which can give them advantage over their competitors. It will take a number of attacks on popular web site and large business before they will realise the security impact on their business.
Ajax in itself is not “evil”. When it was created it had only best intentions in mind, but as all technologies can be used by malicious users, so do Ajax can be a deadly threat to security of your organization if those threats are not mapped, analysed and migrated.
Published under Comsec Consulting UK
Ajax shorthand for Asynchronous JavaScript and XML and it is a web development technique for creating interactive web applications. Ajax isn’t a technology. It’s really several technologies, each flourishing in its own right, coming together in powerful new ways. Ajax incorporates:
Standards presentation using XHTML and CSS
Dynamic display and interaction using the Document Object Model (DOM)
Data interchange and manipulation using XML and XSLT
Asynchronous data retrieval using XMLHttpRequest
JavaScript that binds everything together
The main reason for Ajax is reduce bandwidth usage and increase interactivity and user experience. By using the XmlHttpRequest object to request and return data without a re-load, a programmer by-passes this requirement and makes the loosely coupled web page behave much like a tightly coupled application.
The “Traditional” Web Applications
In “Traditional” web applications, the default architecture was considered as back-end servers to store and manipulate the data while front end (HTML web page) was mostly used to style and display the information.
A lot of information security best practices were written to support the growing demand on business to go on-line. Users started to be aware of security implication and the on-line behaviour like, don't press the “Submit” button twice, "Wait a bit longer, it's just processing," or "Don't press the 'back' button after you've submitted the form.
But you can throw that basic knowledge out of the window now that AJAX is here.
“Ajax” Web Applications
The data is still resides in the back-end data servers, but Ajax extends program across both the client device and the server. Instead of seeing blank browser window and an hourglass icon, Ajax don't “steal” user's interaction with the application.
Every user action that normally would generate an HTTP request to the server. Now, any response to a user action that doesn’t require a trip back to the server, such as simple data validation, editing data in memory, and even some navigation, the Ajax engine handles on its own. If the engine needs something from the server in order to respond, the engine makes those requests asynchronously, usually using XML.
Threats in Ajax
As we seen before, Ajax extends programs across both the client device and the server, creating far more opportunities for hackers to deliver malware onto sites.
Multiple Transmissions
If before, when user fill the form, the information was submitted only once to the server, an Ajax-enabled form, which automatically relays the data from each field as data is entered, will launch multiple transmissions that virus writers can latch into.
Screen Capturing Attacks
Before Ajax, the user were been able to control (with more or less granularity) the information which website was able to get access to. The user was able to review the information couple of times before hitting the “Submit” button. Now, So-called screen-scraping attacks and Web session hijacking attempts, both of which also seek to steal users' data, could also be performed more easily by taking advantage of Ajax. With AJAX, a user's actions can be constantly and meticulously monitored. Because it can be done, it will be done, and that will lead to a headache bigger than just wasted bandwidth, gigabytes of useless information, and slower page load times.
Cross Site Scripting
Ajax introduce a lot more JavaScript code into the web pages. Before, most of the business logic was hidden safely on our servers and the client was presented with mostly processed data and very few lines of script. Now, Ajax moves fair amount of business logic to front-end which allow bigger “surface” to attack.
DoS (Denial of Service)
Though this problem is not new, Ajax approach may increase this vulnerability. Just imagine the following scenario: Web server is serving 1000 users to lookup ten digits serial number. Poorly implemented Ajax web page will do a look up for every digit user type. This will increase the load server needs to handle tenfold.
Source Code Hiding
Since Ajax allow to perform any action in the background, it also allow malicious web page to change the JavaScript code on right button click. In other words, it's possible to add or modify JavaScript functions and code in the background even after a page load!
So even if you inspect the page source for code that might be sending keystrokes or mouse movements back to the Web server, you can't be certain that the code you see is the only code that's executing.
Intellectual Property
Commercial application vendors regard their source code as their intellectual property, and are likely to want to obfuscate client side code to protect it. AJAX implementations introduce a large amount of client side code so we are likely see a lot of commercial applications implement JavaScript obfuscation. This may be an understandable approach from a legal perspective, but it breaks apart when the intention is to obfuscate security controls.
Even average developer with malicious intentions and with enough time could reverse-engineer, and get “insider view” on security control of such applications.
Eavesdropping
Eavesdropping is one of the simplest and the oldest techniques for data theft: an unauthorized party listens to conversations between systems and collects their data. Eavesdropping could be done simply to get access to data like credit card account information, or it could be used to hijack identity credentials and start an authentication attack as described above.
Data Integrity and Replay Attacks
Eavesdropping enables both data integrity attacks and replay attacks. Using data obtained by eavesdropping with slight modifications (recall that XML is a text-based, human-readable format) before sending it on its way is known as a data integrity attack. The most basic version is a simple message forgery.
Replay attacks occur when a hacker uses stolen messages and continually replays that same valid (maybe we validate the schema) message at potentially high rates. Obviously that type of attack could have serious repercussions like server overload.
Knowledge and Best Practices
This might be the biggest problem of Ajax today, lack of knowledge base and best practices. For the last 1o years, a lot of security experts and developers gathered huge knowledge base, expertise and best practises of how to secure and migrate risks in standard web application. Nothing of this kind exist for Ajax. Ajax applications have a huge attack surface, much larger than traditional applications, and the buzz around Ajax is creating immense security implications, as the available knowledge bases and types of resources available for developers are poor.
Inexperienced developers fail to properly protect their work and attackers learn to use the benefits of Ajax to their advantage. His (inexperienced Ajax programmer) use of widely available Ajax code in their own programs without proper understanding, a common practice, will create even more problems.
XML Security
Since the other end point of Ajax is Web Service with understand XML, all security threats exits in XML are relevant with usage of Ajax. The XML threats are:
- Schema Poisoning - Manipulating the XML Schema to alter processing information.
- XML Parameter Tampering - Injection of malicious scripts or content into request parameters.
- WSDL Scanning - Scanning the WSDL interface can reveal sensitive information about invocation patterns, underlying technology implementations and associated vulnerabilities.
- Oversized Payload - Sending oversized messages to create an XDoS attack.
- Recursive Payload - Sending mass amounts of nested data to create an XDoS attack against the XML parser.
- SQL Injection - SQL Injection allows commands to be executed directly against the database for unauthorized disclosure and modification of data.
- External Entity Attack - An attack on an application that parses XML input from un-trusted sources.
- Malicious Code Injection - Scripts embedded within a SOAP message can be delivered directly to applications and databases; traditional binary executables and viruses attached to SOAP payloads.
How to protect your application
Actually, there is nothing new. We still need to validate the input received from he users, perform output encoding and improper access control. AJAX in itself does not introduce these vulnerabilities – poorly web applications have been susceptible to these problems long before AJAX.
Spajax
Sprajax (sometimes called as “Atlas” ajax security scanner , since it can only detect the “Atlas” framework and the SOAP web services used by the “Atlas” framework) is the first web security scanner developed specifically to scan AJAX web applications for security vulnerabilities.
XML Firewall
XML firewalls are different breed of application firewall. It can examine SOAP headers and XML tags, and based on what they find, distinguish legitimate from unauthorized content.
In addition, XML firewalls can look into the body of the message itself and examine it down to the tag level. It can tell if a message is an authorized one, or coming from an authorized recipient. Also, they can understand metadata about the Web service's service requester as well as metadata about the Web service operation itself. They can gather information about the service requester, such as understanding what role the requester plays in the current Web service request, for example. XML firewalls can also provide authentication, decryption, and real-time monitoring and reporting.
Same Old, Same Old
Maybe Ajax is new in town, but it is just a combined usage of existing technologies.
Number of tips to secure your application:
- Secure architecture – Design your application to be secure. Start secure and stay secure by including security as a component in each stage of the software development life cycle.
- Trusted software libraries - From encryption to session management, it’s best to use components that are trusted, reliable, tried and thoroughly tested. No need to reinvent the wheel and repeat the mistakes of others.
- Validate user's input - Web applications must NEVER trust the client (web browser).
- Secure principles - Every component of the website should be configured with separation of duties, least privilege, unused features disabled, short session lifetime and error message suppressed.
- Threat Management – Continuous vulnerability assessments are the best way to prevent attackers from accessing corporate and customer data. By perform periodic penetration tests, gap analysis and threat migration plan it is possible to stay ahead of the malicious users and protect our assets.
The future
Despite security threats mentioned above, the business' drive to attract more clients by improving their websites and web applications will create a increasing usage of Ajax. Customers love dynamic and interactive website, everything that Ajax represents, so there is a lot of demand. But the problem is, most of Ajax developers know nothing about security.
As I see it, the threat of improper usage of Ajax won't stop companies for massive adoption of technology which can give them advantage over their competitors. It will take a number of attacks on popular web site and large business before they will realise the security impact on their business.
Ajax in itself is not “evil”. When it was created it had only best intentions in mind, but as all technologies can be used by malicious users, so do Ajax can be a deadly threat to security of your organization if those threats are not mapped, analysed and migrated.
Published under Comsec Consulting UK
Subscribe to:
Posts (Atom)