VCookie - The Virtual Forge Blog

Security in times of the crisis

2009-02-17T13:41:00.000-08:00

In times of a world-wide crisis, people reconsider their IT investments. What’s a must-have? What can be postponed? What can be dropped? From a security perspective we say, that security continues to be a must have. Damage occurs whenever people neglected security. And the trend for criminal actions doesn’t go down due to a recession. On the contrary, your competitors take a strong line on your assets. Industrial espionage is a bigger threat than ever. Even internal people will try to take whatever they can in order to foster their advantage in market. Therefore, we recommend: investing in security is a must-have – especially in times of a crisis.

Also IBM States: Custom Developed Applications Pose Great Risk

2009-02-06T13:43:00.000-08:00

IBM published its yearly X-Force report. The study verifies a fact that we often see in our security projects: Security defects in custom applications are not on the radar and represent great risk for companies.

"[...] Again, this figure does not take into account custom developed Web applications that may not have had any vulnerability testing and may never see a public vulnerability disclosure to notify the developer of a Web site about vulnerability issues and potential exploitation."

Virtual Forge recommends reading the entire report.

Of course, we also recommend testing custom developed applications regularly and systematically.

Testing for Security Vulnerabilities - What are the Standards?

2009-02-02T13:45:00.000-08:00

In our projects we are often asked for standard lists of vulnerabilities. The rationale be-hind this question is to ensure that security tests follow industry best-practice. If you don't do this, liability discussions might follow.

For quite some time there are top lists of vulnerabilities that must be avoided in applications. Some focus only on Web applications (OWASP Top 10) and others are industry-specific (e.g. security standard of Payment Credit Card Industry (PCI) or FDA Part 11). The "TOP 25 Most Dangerous Programming Errors" compiled by CVE/SANS is one of the most comprehensive lists today. Review such lists carefully and ensure that well-known issues are addressed in your development projects. You should also ensure that your security tester of choice is aware of such benchmarks.

A final thought - focusing solely on these lists is not sufficient. It's important to extend such a list for dedicated environments like SAP applications. They have some very special properties and specific security demands that are not addressed by generic top lists of vulnerabilities.

SAP GUI Vulnerable?

2009-01-08T13:47:00.000-08:00

Every once in a while we see public alerts about insecure SAP software. A recent example is a security alert that describes a vulnerability of SAP GUI. We like to highlight that SAP provides a dedicated list of recent security notes: We recommend to monitor this list carefully and implement appropriate countermeasures in a timely manner.

SAP TechEd Berlin in Retrospect

2008-10-17T13:35:00.000-07:00

The Codeprofiler Team had a great time at SAP TechEd in Berlin. Announcing "The 1st security scanner for ABAP" we had many interesting discussions with developers and managers.

Managers like the idea of having transparency about security at the code level by clicking a button. The built-in "traffic light" reporting of Virtual Forge CodeProfiler perfectly fits into existing reporting paradigms.

On the other hand, developers like the level of detail provided by the Code Cockpit: CodeProfiler shows the affected lines of code and provides technical details and guidance on fixing the issues.

That way, CodeProfiler users

a) Know if there are issues and how many
b) Can prioritize which issues to address first
c) Get a clear picture how to get the security of their ABAP programs right.

We also had a developer from a code supplier at our booth. She asked "What’s now with my backdoors in the ABAP code?" – Sad news for her: CodeProfiler will identify such issues quickly and will help companies to enforce their security requirements in every outsourced development project.

Mastering SAP Technologies 2008

2008-07-23T04:12:00.000-07:00

Seems like Doug, owner of Eventful Management, was fed up with Melbourne's rainy winter weather. Anyway, this year's Mastering SAP Technologies moved from Melbourne (where it took place in 2007) to the Gold Coast. Winter at Gold Coast is really more like a nice summer day in Germany. Blue sky, 25° Celsius, and hundreds of kilometers of beautiful beaches.

So people were in a good mood and the SDN networking meeting went very nice with Thomas Jung leading the discussions. One of the hot topics in the meeting was the future of the Business Server Pages (BSP) development at SAP. Even though WebDynpro is the successor of BSP, Thomas presented a view new things he developed in BSP.

BSP indeed is a nice way to develop Web applications with SAP technology. However, when it comes to security, a BSP developer has to actively do certain things to secure the Web application. The developer has to do input validation and output encoding manually. If the developer does not perform those measures at any place, the Web application may be vulnerable.

I got some feedback to my comments on BSP security during the SDN networking meeting. Some suggested to include real ABAP coding examples during my talk, which I did. Here is the source code of a very simple example of a BSP Web page:


<%@page language="abap"%>
 <html>
  <body>
    <% data: x type string.
     x = request->get_form_field( 'x' ).
    %>
    <a href="<%=x%>">Next</a>
  </body>
 </html>"

As the Web page prints user input directly into an HTML page without any Input validation and output encoding, the Web page contains a Cross Site Scripting (XSS) security vulnerability. Actually, I found this code online as an example for BSP coding.

To mitigate this security threat, you need to filter the user input by passing it to the ABAP function cl_http_utility=>escape_url. This is the only way to fix the XSS vulnerability without breaking the functionality of the code.

As the above coding renders user input into a hyperlink, the page also has a Cross Site Request Forgery (XSRF) vulnerability, which allows attackers to trick victims into making arbitrary (potentially malicious) requests to other Web pages. But that's a different story.

So are those SAP vulnerabilities? No, they aren't. BSP works similarly to Java Server Pages (JSP), or PHP. Both technologies suffer from the same quirks. If you want to stick to BSP, you have to do a lot of security homework to keep up with the hackers. Note, that by using WebDynpros, you have a lot less to worry about, but you still have to worry. ... but that's a different story.

Hygiene of Web Applications

2008-05-06T06:13:00.000-07:00

Back in 1847, a physician called Ignaz Semmelweis was working in a Hospital in Vienna, Austria. During this time, 5-30 percent of the female patients in this hospital got infected with puerperal fever which is often fatal.

Semmelweis was performing a study where he compared physicians who washed their hands regularly with others that didn't. He made a ground-braking discovery: Women treated by the hand-washing physicians had only a 1-2 percent chance of getting infected with puerperal fever, whereas other patients still had a 5-30 percent chance. Semmelweis' experiment showed that increasing hygienic standards in hospitals can safe many lifes.

What is really interesting in this study is that most of the physicians ignored, rejected, or ridiculed Semmelweis for this conclusion. They simply could not believe that a simple thing such as hand washing could have such an enormous effect on patient's health. It took many years for the medical profession to realize that Semmelweis was right with his views that are taken for granted in today's hospitals. Today's physicians are taught during study that hygiene is a crucial part of their
profession.

I was wondering when such an learning effect takes place in IT. Currently, there is only a limited number of universities teaching IT Security and even fewer that teach secure application design and secure programming. As a result, university graduates will continue to produce insecure application designs as well as insecure coding. Some of them are lucky enough to get training in secure application development, others will learn it the hard way that secure development matters. Same as the physicians 160 years ago, today's developers answer to good advices such as input validation, output encoding, and security design that they don't have time for these things.

Maybe, at some day, we'll have mandatory IT security classes in university and people will shake their heads when they hear that in the old days most of the web applications on the Internet were vulnerable to security bugs.

Secure Software Applications - Today: Input Validation

2008-04-04T07:44:00.000-07:00

Security assessments usually result in a lot of customer questioning and answering. It is just more efficient to just ask the right questions to the customer than looking up the information in documents or reading large amounts of source code. We have a set of questions that we usually ask a customer at the start of any security assessment.

One question is about input validation, which is one of the cornerstones of security application design and implementation. As an example, a credit card number solely consists of a fixed amount of digits in the range from zero to nine. There is really no reason for a software application to continue processing unless the user filled the credit card form field with the proper amount of digits. Other characters than digits must not be allowed. Performing strict input validation will greatly enhance the security of the software application.

In reverse, not performing strict input validation is a good indicator that the application has software bugs. This is why we ask customers where and how they perform input validation in their software applications. Not performing input validation is common, but one answer of a customer brought it straight to the point:

"The user is responsible for valid input. Are there any risks with that?"

Back in 2004, the risk related with that made in to the top of the OWASP Top 10, a hit list of the most exploited security vulnerabilities. So the answer is "Yes! There is a risk." Missing input validation does not directly result in exploitable security vulnerabilities. However, the most critical security issues such as Cross Site Scripting, Buffer Overflows, and SQL-Injection may result out of it.

Take an analogy:
If a bank employee said: "We neither have a vault, nor do we close our doors in the night. It's the people's responsibility to not steal the money.", would you entrust your money to this bank?

Key take-aways:
Security risks don't emerge solely through coding errors. Performing input validation is a requirement and should be integrated into the application's architecture.

Article: The Need for Measuring Software Security

2008-03-17T08:07:00.000-07:00

Given the complex nature of modern software solutions, software testing is a crucial process step in the development cycle. Best practices in software testing are (more or less) standardized and supported with a variety of different tools. As a result, we see complex applications that can be used efficiently without failing too often. Furthermore, an experienced software tester is able to measure the quality of a software application and compare the results to other software applications.

Unfortunately, in our security assessments we often find reliable software applications that contain critical security vulnerabilities. In this article, Dr. Markus Schumacher and Sebastian Schinzel from Virtual Forge show an example of why security testing is that different from traditional software testing. Furthermore, the article shows Virtual Forge's approach to measuring the security of business software applications.

The article appeared in the first issue of Testing Experience, a new magazine that targets for professional software testers.

Vulnerabilities in Web Applications remain No.1

2008-02-20T07:01:00.000-08:00

The annual Update to the SANS Top 20 list was published recently. This list compiles the top 20 security vulnerabilities in computer software per year. Web Applications stay at the pole position of the most common security vulnerabilities according to the SANS Institute (SysAdmin, Networking and Security).

The problem with Web Applications is that they have to be accessible from anywhere in the Internet. You cannot just secure Web Applications by telling a Firewall to filter out the bad guys because it is impossible to distinguish a normal user and a skilled attacker – you will inevitably fail.

The Web Applications itself must be air-tight when it comes to security. Unfortunately, preventing security vulnerabilities such as Cross Site Scripting (XSS) is not as easy as it sounds. In our security assessments, we regularly find XSS vulnerabilities amongst others in the target applications. And we find them within minutes after we get our hands on the customer's test system. Fixing XSS vulnerabilities is difficult as there seem to be many ways to mitigate the vulnerabilities for a developer layman. Unfortunately, only few of these ways fix XSS vulnerabilities once and for all. Others only prevent the proof-of-concept attacks that we communicate to the developers. This approach has the effect that slight modifications of the attack circumvent the alleged fix of the vulnerability. Our proof-of-concept attack does not work any more, but the vulnerability persists.

The key take away for you:
Certainly the most effective and efficient way to secure software applications is to bring in security experts right from start. This enables you to build your application on a secure foundation. Remember that you cannot test in security…

How OWASP changed the security rules overnight

2008-02-20T06:47:00.000-08:00

Companies become increasingly aware of business risks related to application vulnerabilities. However, application security is a very difficult field. As a result, most companies have little or no expertise with it. Unfortunately, if you have little or no expertise with any given topic, it's difficult to define a sufficient set of test cases. As a result, companies tend to use "Top X" vulnerability lists of platforms like OWASP, WASC, The SANS Institute and others. One advantage of this approach is that those lists appear to be best practice as they are publicly made available by independent organisations that are dedicated to this area. And they are a best practice, since those vulnerabilities are so common they are the absolute minimum requirement for testing. Unfortunately, hackers don't care which attacks are listed and which are not.

Therefore, if companies focus too much or only on publicly approved top issues, they run inevitable into trouble, because they will miss risks that are slightly below the radar. You might now argue if companies violate their due diligence by only focusing on the most widespread risks. But in any way, ignoring certain supposedly lower priority attacks does certainly not make applications sufficiently safe. In turn, this invites hackers to focus on those "lower priority" attacks.

Focusing on top vulnerabilities only has another adverse effect. What if the security organisation suddenly changes the attacks on the list you chose as a benchmark? OWASP did this in May 2007 by putting Cross Site Request Forgery (XSRF) on their Top Ten vulnerability list. All your past assessments and security guidelines become more or less invalid over night and your applications have to be re-tested for the most current list of top vulnerabilities. This is a reactive process and definitely not a best practice.

But how should companies address such a seemingly moving target?

In our experience, it's better to have security testers to prioritize testing activities by risks rather than by vulnerabilities. What matters to business, is that one supplier should not be able to see the prices of another (that is a business risk). If he gains this information through forceful browsing or command injection attacks is of little relevance. The risk is that confidential information is disclosed and not any specific method of attack. Therefore, companies should rely on a more general practice, both for external testing and for internal security guidelines. For external testing, they should define "risk cases" rather than test cases and focus their tests on them. No matter what and how attacks are ranked at any given time, the risks to the company usually remain the same. Testing according to a risk profile assures the security of your assets in a sustainable way.

For development guidelines, companies should focus on root causes rather than specific instances of attacks. Understanding root causes helps identifying attack variations and countering attack patterns in other contexts.

The key take away for you:
Of course, companies are well advised to make sure all attacks listed in the top ranks are covered by their risk mitigation approach. However, focusing solely on these is not enough!

In one of the next issues, we will talk about how to apply a risk profile driven approach for security testing.

Q: How much development budget should be spent for security? A: 2%

2007-09-27T04:36:00.000-07:00

Yesterday at the Software Quality Conference in Zurich, we gave a keynote about Measuring Security and discussed this very interesting topic from different points of view (attacker view, suit view, geek view, etc.). It was great to see that the Quality community has a very natural attitude to security and that many quality assurance concepts can be applied for measuring security aspects, too.

At the end of the talk, we were asked how much of the development budget should be spent for security. After a short pause for thinking, the answer was "2%". An interesting discussion followed. How many people have planned more, exactly or less (including 0) than 2%. Another category was a few people that simply did not know the security budget.

The beauty of defining such a budget for security lies in 2 (maybe more) things. First, you make people think whether they considered security in the development lifecycle at all. Second, you can gather some experience, see whether (in this case) 2% are enough and adjust the value according to your needs.

We'd be interested in your thoughts and your experiences regarding the big question "how much security is enough?".

SAP gets Hacker attention - Buffer Overflow Vulnerabilities

2007-07-25T00:22:00.000-07:00

On July 6th, NGSSoftware released a set of security vulnerability advisories regarding several SAP enterprise software packages.

The same group stated earlier that it keeps 175 so-called 0-day vulnerabilities in enterprise applications of various vendors (Oracle, IBM, HP, Microsoft, Openbase, Real, Sybase, Ingres, Veritas, CA and Sun) under its pillow and they add more every week. Such 0-day vulnerabilities are flaws in software applications that are not yet fixed by the vendor, thus leaving the customers vulnerable to attacks until the vendor releases a patch.

Note that 0-day vulnerabilities are actively exploited by cybercriminals for one year until they become publicly known. This fact was found by Immunity, a company that buys newly found security vulnerabilities from their founders and sells fixes to Immunities customers.

There is even a fast growing market for security vulnerabilities. Recently we have seen a bidding platform, similar to Ebay, where people can sell and buy unreleased 0-day vulnerabilities for software applications.

Conclusion: it seems that complex business application frameworks as for example provided by IBM, Oracle, SAP and Software AG get more attention of security researchers as well as hackers. Professional attackers are out there that buy know-how about vulnerabilities. As business owner you should be prepared to take meaningful measures in advance.

Get in touch if you want to know more about how to protect your business applications.

How SAP adresses Cross Site Scripting

2007-05-01T08:15:00.000-07:00

The Internet Crime Complaint Center has found that computer crimes caused a loss of almost 200 million US$ in 2006. Responsible vendors like SAP offer powerful technologies such as WebDynpro to protect your customized SAP installation against possible attacks. However, the key to success is that you as a SAP customer have to use SAP's security solutions and use them correctly. If you fail here, this might expose sensitive data of your SAP system to criminals that could severely harm your business.

The April-May-June issue of SAP Insider features an article of SAP's security expert Patrick Hildenbrand. Patrick gives a brief overview on some of the topics covered in our training, namely how to face the widespread Cross Site Scripting attacks (85% of all attacks against systems that use Web-based protocols are Cross Site Scripting attacks).

The Answer to the RFC (In)Security Hype: use SNC

2007-04-09T01:09:00.000-07:00

Several people are analyzing SAP security. Particularly, Remote Function Calls (RFC) has been examined more extensively. In March 2007, a security analysis of the RFC implementation was presented at the Blackhat conference. It was labeled Attacking the Giants: Exploiting SAP Internals.

You could value this as another indication that SAP is getting more and more attention of security researchers and hackers. The analysis is extensive and shows several ways how RFC can be exploited (all security issues have been fixed by SAP before the paper was published).

So what? It has been known for years, that RFC isn't a security protocol. Actually, the authors also ackknowledge that in the accompanying paper; the most important sentence is that SAP customers should use Secure Network Communication (SNC), SAP's answer for securing RFC connections. This is analogous to HTTP which is usually protected by SSL.

There are many ways to get information about SAP Security and we strongly recommend to follow SAP's security recommendations. Learn more about SNC in the SAP NetWeaver Security Guide. General information about SAP Security can also be found in the SAP Developer Network (here) or in SAP's Security Forum.

Conclusion: the short answer to the RFC (In)Security hype is: use SNC!