AppSecUSA 2015

There exists a lot of web security scanners and many are doing a descent good job. Yet there are times and genuine reasons when you wished you had your own scanning infrastructure. You perhaps wished how great it would be if you could build your own in 40 minutes. That you had more control. That you can add your custom requirements. Or may be using an existing one was not an option, from cost, scale, speed or code reuse perspective.

In this talk we will demonstrate:
1. how to build a robust web security scanner that answers many questions you might have.
2. how to scale it up as an infrastructure,
3. how to integrate it into your own continuous delivery pipeline.

We will also discuss the difference in the nature of this project as compared to related works such as Mozilla Minion and Netflix Monterey.

DevOps puts an intense focus on automation – taking humans out of the loop whenever possible to allow frequent, incremental updates to production systems. However, thorough application testing often has multiple components – much of this can be automated, but manual testing is also required. This is inconvenient and not “DevOps-y,” but is unfortunately an unavoidable requirement in the real world. In addition, managing these multiple sources of application vulnerability intelligence often requires manual interaction – to clear false positives, de-duplicate repeated results, and make decisions about triage and remediation.

Axway has rolled out an application security program that incorporates automated static and dynamic testing, attack surface analysis, component analysis, as well as inputs from 3rd parties including manual penetration testing, automated and manual dynamic testing, automated and manual static testing, and test results from vendors providing test data on their products. Automation has allowed Axway to increase the frequency of web application testing, thus reducing the cycle time in the application vulnerability “OODA loop.” Moving beyond the identification of vulnerabilities, Axway has deployed ThreadFix to automatically aggregate the results of the automated testing and de-duplicate findings. 3rd party penetration testers are also finding vulnerabilities and reporting them in reasonably structured CSV files requiring Axway to convert this manual test data and incorporate it into the aggregated vulnerability model in ThreadFix. Centralizing this pipeline allows for metric tracking – both for the application security program as a whole as well as on a per-vulnerability-source basis. This automation and consolidation now covers 50% of Axway’s application vulnerability review process - with plans to extend further.

This presentation walks through Axway’s construction of their application security-testing pipeline and the decisions they were forced to make along the way to best maximize the use of automation while accommodating the reality of manual testing requirements. It then looks at how this testing regimen and the associated automation have allowed them to impact deployment practices as well as collect metrics on their assurance program. Finally, it looks at lessons learned along the way – the good and the bad – and identifies targeted next steps Axway plans to take to increase the depth and frequency of application security testing while dealing with the deployment realities placed on them to remain agile and responsive to business requirements.

Organizations are increasingly incorporating open source software into their applications. Leveraging existing software to provide generic functionality results in reduced development costs as well as faster time to market.

However, along with these benefits, this freely available software also comes with an inherent problem – security vulnerabilities. While the advantages of using open source software are obvious, the negative impact on security brought on by their use is insidious.

While organizations spend enormous effort in securing their applications, most of this effort goes toward securing the part of the application that was developed in-house. A relatively small percentage of effort goes toward evaluating vulnerabilities in open source software, if they are considered at all. This makes open source libraries the weakest link in the security chain of an application.

We will present the current status of vulnerabilities in commonly used third party libraries and their impact on your application. We will then discuss an approach to holistically secure your application: a combination of securing in-house code and managing the security risk of third party libraries that are used.

Mom had a good reason for you to eat your vegetables; same thing goes with Application Security. It’s the good solid meat and potatoes (and broccoli) that help our programs grow up big and strong. The latest software development practices are out pacing traditional application security programs. Agile and DevOps are increasing the speed and frequency of development and deployments. Traditional application security is either slowing the process down or being bypassed; neither path is good for business. Security must be integrated into the process so that it is not an afterthought that inhibits the release of new features and fixes, but rather an expectation set up front.

Does your organization have unlimited resources? Of course not, you need to know where (and how) to spend the limited resources that are available to you. If you have an unknown number of applications with unknown levels of risk; how do you know which ones you should spend your limited time and resources on (and to what level of effort)? This critical understanding of the security stature of an application is not possible without a solid secure development program.

You hear the terms "proactive application security” or “earlier in the SDLC” often where someone is talking about how they managed to get pen testing or code review earlier in the testing cycle. This is an all too common pitfall in Secure Development and is often bypassed when seen as an impediment to delivery. There is a lot of time and money spent on the post-code activities: code review, functional testing, vulnerability assessments, and penetration testing. These are crucial activities for validating the current state of the application; but they are simply too late and too slow by themselves.

If you security team is only searching for vulnerabilities, they are not looking at the big picture; and they are doing your developers a disservice. Your developers are being held to security requirements that were not part of the original application design. Before you get to a security assessment, you need a line of sight from the potential threats to the application, through the resulting security requirements, the design/architecture, and how the design incorporated security controls at the right levels to help mitigate those identified threats.

Hear about what’s worked and not worked for different organizations in both the public and private sectors over several years of building secure development programs. There will be a focus on understanding the key components of a successful Secure Development Program, along with the critical differences when integrating with development life-cycles like Waterfall and Agile, and DevOps. See how secure development can feed your Risk Management Framework and other key initiatives and learn how a Secure Development Program may even justify its own existence.

SecureMe – Droid is an Android security application that notifies the user of publicly known vulnerabilities found in the installed version of applications on the user’s device. The application has been built on a client-server model so that user’s device has to perform least CPU operations and the network traffic is also limited.

The current version of SecureMe – Droid uses only NVD CVE XML database to find vulnerabilities and security weaknesses in apps using its application name, package name and version number.

SecureMe – Droid has an easy to use interface which allows user to configure the scanning options, check installed applications for vulnerabilities along with other application behavior actions.

Android broadcast action "android.intent.action.PACKAGE_ADDED” is released when a new Android application package is installed and "android.intent.action.PACKAGE_REPLACED" is released when an existing Android application package is either upgraded or replaced. Do not that these broadcast actions are automatically generated and released by Android itself when a new Android app is installed/ upgraded/replaced.
SecureMe – Droid passively listens for these two broadcast actions to identify when a new application has been installed or an existing application is upgraded or replaced.

Settings allow to tweak the app notifications and search depth according to user's choice. The app allows the user to choose from Intense (2010-2014) to Low (only 2014) CVE database to search for vulnerabilities and weaknesses. Default search depth is Medium (2012-2014).

User can check single, multiple or all apps for vulnerabilities using an easy to use user-interface.

The Scheduled Scan feature allows the user to configure a scheduled scan of installed apps using SecureMe – Droid. At present scheduler can run weekly/monthly/yearly.

To avoid exploitation due to excessive Android permission, SecureMe – Droid requires only two permissions to run on an Android:
1. Internet Access (android.permission.INTERNET)
2. Run at startup (android.permission.RECEIVE_BOOT_COMPLETED


SecureMe – Droid does not access or transmit any sensitive user information and respects privacy at all times. The data that accessed from user's device are:
The only information which gets accessed and transmitted are listed below:
1. Application Name
2. Application Package Name
3. Application Version Number
4. Application Version Name
5. SecureMe – Droid Search Depth setting (1-5 only)
6. SecureMe – Droid Vulnerability Details settings (1 or 0)

OWASP is the largest application security non-profit organization in the world. We have over 200 chapters in over 100 countries around the world. Join us to find out current events from the OWASP Global Board of Directors and the OWASP Executive Director. 

Submit your questions here:
http://goo.gl/forms/rKnluv9PSi

Bots, also commonly referred to as scrapers or spiders, are omnipresent on the Internet. Studies show that bot activity represents a great percentage of the overall traffic on the Internet. Bots are built for different purposes from simple health check to ensure the site is up to site spidering for the purpose of indexing the content or collecting specific information en mass. Not all bots are bad:
- The ones operated by search engines, audience analytics, SEO companies, web site performance monitoring services or partners drive users to the site, are vital to its success and the business it supports. But like with any automated activity, sometimes with the best of intentions, bot activity can have a negative load impact on the web site infrastructure.
- Other bot activity, sometimes more difficult to detect, can have more questionable benefits, hurt the image of company that owns the targeted site or even have some impact on the company's revenue in the case of content theft or competitive scraping.

The amount of bot activity seen on a given web site is generally proportional to the value of the content hosted on the site. The value of the content is defined by the dollar amount that can be gained by exploiting the data collected.

Bots are usually part of botnets and come in all shapes and sizes. Some are very simplistic scripts that run on a single machine and can only support a single task. Others are highly distributed and have the same abilities as a web browser and support a wide variety of tasks.

In order to efficiently detect as much bot activity as possible, it is essential to implement many different techniques to match the different types of bots. In this talk, we’ll discuss different detection methods including evaluating the HTTP header signature, testing the ability of a client and evaluating the client behavior.

Detecting bots is however half of the trouble. Because a bot has a certain header signature or behavior doesn’t mean it has bad intentions and would have a negative impact on the business. Clearly identifying and categorizing the bots is key, this talk will provide some guidelines on how to identify and categorize bots.

Once detected and categorized, bots that are considered good for the business should be allowed access to the content. However, the one that do not appear to bring any benefits should be handled appropriately. Denying the traffic has the immediate effect of sending a signal to the bot operator, telling him that the activity was detected. Although such action may provide immediate relief, the bot operator may adapt, redeploy and resume its activity undetected. To conclude the session, we’ll go over some guidelines on how best to respond to “bad bot” activity.

We created a “Game of Hacks” – a viral Web app marketed as a tool to train developers on secure coding – with the intention of building a honeypot. During a 6-month timeframe, we witnessed each attack that came at this game, secured the app against it and studied how attackers adapted to the mitigation measures. The lessons learnt can be applied to any Web app introduced into the organization.

-----

How do hackers adjust, in real-time, to various strengthening measures of Web apps? We set to answer this question through an interactive Web app honeypot. For the honeypot, we created a viral Web-based gaming application. However, the lessons learnt could be applied to any Web application.

Aptly called “The Game of Hacks”, our gaming app was marketed as a tool to train developers to write secure code. The app presented users a piece of vulnerable code and a set of multiple choice questions from which the user had to choose the correct vulnerability – in the minimal amount of time. Storing a central database, the app kept a scoreboard of all players, displaying the top winners. Additionally, the app was built on crowd-sourcing capabilities where users could contribute their own piece of code and questions.

Our “Game of Hacks” quickly became a popular game, boasting more than 200K users within 2 weeks. Consequently, it also garnered the desired hackers’ attention. We were set to analyze, planning a continued 6-month analysis.

With the list of vulnerabilities in hand (and some that we added as we adapted to the threat landscape), we witnessed each attack that came at this game. Against each attack, we secured the app and studied the attackers’ next move. One by one, we crossed off the different attacks and had a live look at the way that attackers adapted to our mitigation measures.

We start this session with a brief introduction to “Game of Hacks” and the included vulnerabilities. We then proceed to simulate the actual honeypot activity in an interactive session similar to the actual cat-and-mouse game that we witnessed: for each vulnerability, we show how it was exploited, the corresponding security measure and how it was bypassed.

We examine vulnerabilities/ attacks such as: A) Business logic attacks. Here, hackers tweaked the timer so that their scores – based on parameters such as time and accuracy - became unsurpassable. B) DDoS attacks through site scraping where an external database was built to correctly respond to each question automatically. C) Comment spam enabled through the crowd-sourcing of questions.

We finalize the session with a summary of the methodologies we took to strengthen our gaming honeypot and share with attendees our insights. It is our hopes that attendees learn from these measures and apply them to any Web app being introduced in the enterprise.

In two years, over twenty thousand Cisco employees and contractors worldwide invested hours over and above their assigned duties to improve their knowledge of application security. Why would they take action voluntarily? What made them care about security? The answer is we made application security awareness personal, professionally valuable, and fun.

In today’s chaotic environment, every company desires a more secure product or solution, and their customers demand it. To achieve this, every person involved in the product life cycle must be security aware. The challenge is teaching people in a way that sticks. This is how Cisco did it: how employees and contractors learned to love and own Cisco’s security story; and built security into our organizational DNA and our products and solutions.

The Cisco Application Security Awareness Program raises technical security awareness at all levels of the organization through the creative, fun, and humorous use of video. The content ranges from introductory to advanced learning, using belts to measure student achievement and provide recognition. As students progress, they migrate from knowledge acquisition using video into doing things to improve the security of their products. A system of tracking and recognizing achievement-based activities gets people fired up to make security improvements in their products. Sprinkled throughout the talk are examples of the videos and interfaces that draw users into this world. The audience will experience the Cisco Security Awareness Program and visually understand the abstract concepts described.

Approaching crescendo, it is time to address the elephant in the room: “So What”. What is the true impact to Cisco? Through the metrics and feedback collected, a case will be made that this program has had a huge positive impact for Cisco.

The grand finale is the “top ten secrets of success”. This is a discussion of the actions taken to achieve success, broken down into four categories: content, recognition, system, and marketing.

Content is the lessons learned about video and how to master it for success. Recognition is how to reward participants and lead them to want to grow as security people. System is how to set up for success. Marketing is the intentional causes for the viral nature of the program.

This advice applies to real life; this is how we did it, now how can you learn from us and apply this in your own organization.

Most penetration testers know the headaches of testing mobile applications. Challenges like certificate pinning and wondering what files are being written to the device while the app is in use. Since Android is open source, you create your own custom OS that takes the guess work out of your assessment.

By doing this, you can monitor HTTP/HTTPS traffic, SQL Lite queries, file access and more. Since this is part of the OS, you can intercept web traffic before it is encrypted. And this works for all apps. No need to hook, inject or rebuild each app you test. This saves you time and helps you deliver accurate test results.

Outline of Presentation:
- Describe challenges with testing mobile applications and what is it we are solving
- Overview of the Android operating system - Identify key Android source code files for modification - Demonstrate the Android build process for the new modifications
- Demonstrate a custom Android OS showing data being intercepted and monitored from a remote application (this will be done using the Android Emulator and a PC) Takeaways: