Database and ERP Security and Best Practice Management

FrontRange Solutions Launches Discovery 9 to Improve the …

Perfect Solution: A shop of Computer Hardware & Software Solution …

Trends in Mobile Payments Are Frightening

You can follow John on  here

Posted by John Kindervag

New IIA Thought Leadership Reports Provide Guidance on Fraud and SEC Proxy Disclosure Rules

Litchfield DBMS_JVM_EXP_PERMS 0-day on Oracle

At last week’s BlackHat D.C., David Litchfield revealed 0-day vulnerabilities in Aurora, the Java implementation built into Oracle.

Vulnerabilities in the following packages:

• DBMS_JAVA
• DBMS_JAVA_TEST
• DBMS_JVM_EXP_PERMS
  

allow an attacker to escalate their privileges to sysdba and take complete control of the database. It was successfully demonstrated how a low privileged user can grant themselves sysdba privileges, access on every file on the Oracle host server and execute those files, including a shell. It was also shown how to load binary code into the Oracle process and execute it. Finally a way to bypass Oracle Label Security was demonstrated.

There is currently no fix available from Oracle, however Oracle’s access control features allow for a workaround. By default EXECUTE is granted to PUBLIC for the above mentioned packages.

In order to protect against these current threats, database administrators should revoke execution privileges on these packages from PUBLIC and any other user that does not require them. The AppDetective and DbProtect ‘Object privilege granted to PUBLIC’ Oracle Vulnerability Assessment checks can be used to help find and remediate these privileges.

Application Security has also made available for download a custom policy and check to specifically find these privileges and learn if your Oracle databases are vulnerable. With Application Security, Inc.’s User Rights Review (URR) platform, customers will also be able to determine which users can exploit the vulnerability as well as an explanation of how to fix the vulnerability.

Team SHATTER also suggests adhering to the following general security considerations to minimize the risk of new attacks like this:

• Always stay up-to-date on the latest security patches
• Minimize the attack surface by only installing and enabling functionality that is required for the business task
• Remove all unused default components, accounts and databases
• Assign only minimal privileges required
• Assign privileges through roles, not directly to users

Related links:
SHATTER Security Bulletin

Video: Do you want Microsoft Software Assurance?

Do you want or need Microsoft’s Software Assurance? A couple of basics of why or why not, and how an external party can help. Less than 15 seconds of a very unpainful “sell”, but some basic and very useful information about when Software Assurance is needed.

Increasing Online Insurance Self-Service Adoption

The State Of The PMO

SharePoint 2010: Search Improved, But Think Twice About FAST Search Upgrade

London 2012: Athletes And New Services Will Push Boundaries, Not The Underlying Technologies

Web Application Firewall: 2010 And Beyond

B2B Tech Field Marketers Must Adapt To Remain Relevant

TV Advertising Budgets Are Under Siege

Securing Java In Oracle and DBMS_JVM_EXP_PERMS

IT World: IT maintanance

Oracle Breaks Regular Patch Cycle Because of Zero-Day Bug

A Lazy Pen Tester’s Guide to Testing Flash Applications

Yesterday, I received a post in the Pen-Test mailing list requesting for tips/resources on penetration testing of flash applications. While there are some tools and white papers available, I could not find many authoritative resources which wraps the entire spectrum of flash security testing of RIA applications. So here is an endeavor to detail out the steps of testing. I will keep this post only to outline the essential steps or points. Please feel free to recommend additional inclusion of tools and techniques. The idea is to come up with a comprehensive paper which can be used by pen-testers to test flash based Rich Internet Applications (RIA).

A short unnecessary introduction on Flash RIA

Adobe Flash (formerly Macromedia Flash) is a multimedia platform originally acquired by Macromedia and currently developed and distributed by Adobe Systems. Since its introduction in 1996, Flash has become a popular method for adding animation and interactivity to web pages. Flash is commonly used to create animation, advertisements, and various web page Flash components, to integrate video into web pages, and more recently, to develop rich Internet applications. Source: en.wikipedia.org/wiki/Adobe_Flash

Conventionally, RIA developed with Adobe Flash technology consists of a frontend application compiled as an SWF/AIR object to be executed by the Flash Plugin inside the User’s Browser or the AIR Platform installed on the User’s System. This interactive application provides a user Interface to the end-user and in turn communicates with a backend server for its business logic over protocols like HTTP/AMF, HTTP/SOAP, HTTP/REST etc.

The security angle..

Similar to any widely used web application and software, a RIA can also be a victim of most common and dangerous security Issues. For example, since most Flash based RIAs are backed by an application for its business logic which in turn uses a database, a Flash based RIA might also be vulnerable to common application vulnerabilities like SQL Injection if user input is not sanitized properly. Quite logical huh?. Attackers can also utilize Flash to execute mass exploitation, for example backdoors or malware entirely written in Flash/ActionScript or BOFs against player/plugin or browser.

It is quite general to deduce that security flaws may also be present in the core environment (which includes the OS and web browsers) that can be exploited regardless of the applications (including Flash Player) running in that environment. A recent paper from Adobe suggests that the approach of Adobe is to implement robust security within its own products while “doing no harm” to the rest of the environment (in other words, to introduce no exposures to the rest of the environment, nor allow any avenues for additional exploitation of any existing platform security weaknesses). This provides a consistently high level of security for what Flash applications can do (as managed within Flash Player), regardless of the platform. Because Adobe products are also designed to be backwards-compatible when possible, some environments may be more vulnerable to weaknesses in the browser or operating system, or have weaker cryptography capabilities. Ultimately, users are responsible for their choices of platforms and maintenance of appropriate operational environments.

Vulnerabilities in flash RIA can be broadly classified under two categories: client side vulnerabilities and server side vulnerabilities. Let’s review each one of these very quickly:

Client Side Vulnerabilities:

Amongst the various vulnerabilities that might affect a Flash Application on the client side, some of the most common ones are:

Flash parameter Injection: It might be possible for an attacker can inject global Flash parameters when the movie is embedded in a parent HTML page. These injected parameters can grant the attacker full control over the page DOM, as well as control over other objects within the Flash movie. There is nice detailed paper by the IBM Rational guys on this vulnerability. You can download it here.

Cross Domain Privilege Escalation: Cross Domain inter-mixing of content and data is done based on access policy defined in crossdomain.xml of the serving domain for the SWF object. If the access policy is too open, then under certain circumstances, it might be possible for an attacker to supersede the original SWF object with his own malicious version or access the DOM of the hosting domain.

Cross Site Scripting: Depending on access policy, a Flash SWF can access its host DOM for various functional use cases. A Flash SWF can in turn modify the DOM of its host and if it does so based on un-sanitized user input, it might be possible to perform a conventional XSS attack on the host DOM.

Cross Site Flashing: Cross Site Flash (XSF) occurs when an SWF objects loads another SWF Object. This attack could result in XSS or in the modification of the GUI in order to fool a user to insert credentials on a fake flash form. XSF could be used in the presence of Flash HTML Injection or external SWF files when loadMovie methods are used. OWASP has a testing guide for XSF. Although not comprehensive, still it is a very good point to start. Read it here.

Server Side Vulnerabilities

Flash Applications seldom makes remote calls to a backend server for various operations like looking up accounts, retrieving additional data and graphics, and performing complex business operations. However, the ability to call remote methods also increases the attack surface exposed by these applications. Flash Applications built with Adobe Flex SDK usually use AMF Objects exchanged over HTTP Protocol as a method of communication. AMF Remoting calls are essentially RPC like calls where the Flash Application is calling a given method defined on the server on a specific AMF Endpoint. An attacker can intercept and tamper the AMF data to compromise the server.

In most of the cases the application server responsible for providing Business Logic to a Flash RIA frontend is a standard web application and can be affected by the very same vulnerabilities as any other web application like as described by the WASC Threat Classification Project.

Testing Flash Applications: Objectives and Approach

A Flash Security Testing exercise for a Flash Based RIA is conducted with the following objectives:

• Identify the application entry points and test for possible vulnerabilities in the SWF Object itself.
• Identify the remote server with which the application might communicate for its business logic requirements.
• Identify the protocol with which the SWF Object is communicating with its back-end server. In most of the cases, the protocol will either be SOAP/REST or AMF.
• Identify and enumerate all the functionalities exposed by the back-end application.
• Penetration Testing of the individual functionalities exposed by the back-end application for standard application security vulnerabilities.

Client Side Testing

Client side primarily relates to static analysis of the flash application. The idea of static analysis of a Flash SWF Object is to decompile the SWF file and attempt to do a white box testing approach by looking into the source code of the Flash SWF File. Basic approach to test client side vulnerabilities is :

1. Decompile SWF files into source code (ActionScript) and statically analyzes it to identify security issues such as information disclosure (hard coded).
2. Audit third party applications without requiring access to the source code.
3. Common vulnerabilities includes hard coded login credentials, internal IP disclosure, etc.
4. Apart from analyzing the SWF file, it is also important to analyze the code responsible for generating the HTML file that embeds the SWF object. Under certain circumstances in might be possible to manipulate the FlashVars variable through which SWF inputs can be influenced.

There are however automated tools like HP SWFScan available to do this job upto a certain degree.

Server Side Testing

The best straightforward way to do a server side testing for flash based RIA applications are as follows:

1. Extract Gateway

• Load the flash e.g http://foo.com/bar.swf in a browser with service capture/burp proxy/charlesproxy running .
• Decompile the SWF using swfdump and grep the gateway patterns. Also get a list of all the urls in SWFdump.

2. Enumerate service/methods

• Try amfphp.DiscoveryService on all gateways using Pinta.
• Use Pinta for AMF calling even if the services and methods are manually entered and hence can be helpful in testing remote methods.
• If it fails try extracting them using regex from SWFDump using the following regular expression.
  Services:

  –"\"([a-zA-Z0-9_]*)\"“ with filter as “service” (conventional)

  –"destination id=\"([\\w\\d]*)\"“

3. Make AMF calls

• Use Pinta to call remote methods using different test parameters.
• Single quote (SQL injection), neighbor parameters (Direct Object Reference).

Testing the backend application once the exposed functionalities are enumerated should be more or less conventional to standard web application security testing methodology just that a different protocol (AMF serialized calls in this case) is used for interacting with the server and invoking the functionalities.

Checklist of Vulnerabilities to be tested

• Cross Site Scripting
• Malicious Data Injection
• Insufficient Authorization Restrictions
• Secure Transmission
• SWF Information Leak
• Minimum Stage Size for Anti-ClickJacking
• SWF Control Permission
• Untrusted SWF in Same Domain
• Clickjacking
• Privilege Seperation
• Cross Domain Policy Audit
• Uninitialized Variable Scanning
• Remote Method Enumeration
• Business Logic Testing

This is a brief guide to testing flash applications. Comments are welcome to make it better and more comprehensive. At the end, we intend to publish a freely available whitepaper to pen testers for testing flash based RIA. Additional sections included in the paper will also carry due credits as received in the comments section below.

Online Shopping Sites May Be Sharing Your Credit Card Data

The Attorney General of New York is investigating a large group of online retailers to see if they have been sharing your credit card data with third parties without your knowledge or permission. In a press release, the AG's Office details the scheme, including the fact that you may unknowingly be giving someone other than the retailer you are shopping with your credit card number:

"Information about joining the membership program and its ramifications, including the fact that the consumer is agreeing to transfer his or her credit or debit card account information, is buried in fine print and cluttered text."

My gut tells me that this violates the spirit, if not the letter, of the PCI Data Security Standard.  According to the PCI DSS:

"Additionally, merchants and service providers must manage and monitor the PCI DSS compliance of all associated third parties with access to cardholder data."

It is probably safe to assume that the business agreement around the data sharing identified by the New York AG's office did not include language surrounding PCI compliance.

An MSNBC story on the investigation puts it this way:

"Here’s where things really get smarmy. Even though you did not give that second company any account information, they will bill the credit or debit card number you used to make the original purchase. You didn’t have to provide your account number because the “trusted” retailer gave it to them for a cut of the action."

My guess is that this is being done outside of the security and PCI folks at these companies. In fact, this type of usage of credit card information is one of the biggest areas of push back our clients get internally.  We often hear complaints from security teams that they are having difficulty enforcing PCI and other security initiatives because marketing and business intelligence management claim that they "need" credit card numbers to run their businesses. Really bad idea. No one "NEEDS" credit card numbers for anything except completing a transaction. They may "USE" credit card numbers for other business purposes, but they do this at the risk of their entire organization. True credit card security will only happen when there is a fundamental mindshift in organization so that they understand that credit card numbers (or any other personal or private information for that matter) is not theirs to use in any way they want, especially for marketing purposes.

Expect to see other states get involved. Nothing will shut this practice down faster than legal departments being forced to respond to a whole bunch of subpoenas.

Posted by John Kindervag

Meta tags – UK Business Forums

My trip to China

Just a few pics from my visit to China.  If you think it’s cold here, try walking around for 5 minutes on The Great Wall.

Using Digital Channels To Create Breakthrough Multichannel Experiences

Banking CIOs: Keep Your Eye On The Ball

Trends 2010: North American Retail Banking eBusiness And Channel Strategy

Mapping The Customer Journey

Leveraging Customer Satisfaction, Loyalty, And Perception To Drive B2B Tech Success

Web 2.0 Pivot Attacks

---

WhiteHat Security is a leading provider of website security services.

---

Security Alert For CVE-2010-0073 Released

Hi, this is Eric Maurice again.

Oracle just released a Security Alert with a fix for the vulnerability CVE-2010-0073, which affects Oracle WebLogic Node Manager. This vulnerability was recently publicly disclosed and the organization that discovered this vulnerability did not attempt to contact Oracle prior to releasing detailed technical information about it.

A successful exploitation of this vulnerability may result in a full compromise of the targeted server on Windows. On other platforms (Unix, Linux, etc.), the attacker may gain access to the targeted server with the same privileges as the WebLogic server processes. This kind of vulnerability further highlights the need to use "least privilege" as much as possible on operating systems for running sensitive processes and applications. Additionally, note that many organizations have firewall policies preventing connection to the Node Manager administrative port by external users, thus preventing the exploitation of the vulnerability by anonymous Internet users.

Oracle strongly recommends that WebLogic customers apply this fix as soon as possible, and review their network access policies to possibly further restrict TCP/IP access to the WebLogic Node Manager to very few trusted staff.

For more information:
- Oracle's security vulnerability fixing policies (including Oracle's policies when working with external security researchers) are available on http://www.oracle.com/technology/deploy/security/securityfixlifecycle.html
- The Critical Patch Updates and Security Alerts page is located on http://www.oracle.com/technology/deploy/security/alerts.htm
- Information on how to subscribe to Oracle security notifications are posted on: http://www.oracle.com/technology/deploy/security/securityemail.html

Turkey, Germany, York, Holland and the Oak Table book

I was away most of last week to teach my class How to perform a security audit of an Oracle database in Istanbul, Turkey including the travel out and back. It was a good class, very well attended and some....[Read More]

Posted by Pete On 02/02/10 At 06:37 PM

The Oracle listener password algorithm

There has been a thread on my forum for a couple of years discussing the Oracle listener password algorithm. The thread is titled " Key and algo for encrypting the listener password ". This thread discussed the issue of being....[Read More]

Posted by Pete On 01/02/10 At 07:39 PM

Two new Oracle root kits

Dennis has made two great posts about Oracle rootkits on his blog. The first is about creating a backdoor into the Oracle binaries and logon process/function by replacing the C library function kziaia() so that if the user presented is....[Read More]

Posted by Pete On 20/01/10 At 02:06 PM