BOMTOTAL.com - Check your Bill of Materials

Bomtotal.com is an initiative created by Codenomicon to provide visibility into the bill of materials of an application. By uploading an executable file to bomtotal.com, you will be provided with a list of components inside your executable. This will also show you not just the third party components but also the versions associated with the components. 

How to use it? 

Simply go to www.bomtotal.com and upload any binary file to the site

Once uploaded, you will be shown the version of the application, the third party components used and the versions associated with it.

Why do you need the BOM?

In early December 2014, representatives from the US introduced H.R. 5793, the "Cyber Supply Chain Management and Transparency Act of 2014." The legislation will ensure all contractors of software, firmware or products to the federal government provide the procuring agency with a bill of materials of all third party and open source components used, and demonstrate that those component versions have no known vulnerabilities.

Source: http://royce.house.gov/news/documentsingle.aspx?DocumentID=397589

Which means, that the the "Cyber Supply Chain Management and Transparency Act of 2014" requires any Hardware/Software/Firmware sold to any agency must come with the Bill of Materials and vendors must prove that their HW/SW/FW must not use known vulnerable components or at least a less vulnerable version.

The Act. Source: https://www.govtrack.us/congress/bills/113/hr5793/text

Wait a minute! BOM and Vulnerable components? 

By default, bomtotal.com do not provide the information whether or not the version of the components used are vulnerable. However, while Codenomicon's Appcheck is solely designed for this (and much much more visibility/reports/formats/interface), we can find out whether or not the components are vulnerable based on the version information manually. 

Taking example of the Citrix application that we have uploaded to Bomtotal.com, we can see that there are 2 components used. One is an OpenSSL with the version 0.9.8. 

Knowing the version, visit www.cvedetails.com and search for the version of the component

Select the appropriate link

And tadaaaa, you can see all the vulnerabilities associated to the component.

How this helps Organizations?

Having visibility to the BOM is one thing, knowing the vulnerabilities associated with the components is another. As stakeholders of the organization, one can have the transparency of the software composition during initial stages of procurement of software. Also, this will provide managers to understand the risks involved of an executable even before installing it to the corporate environment thereby making calculated decisions based on the risks involved. 

Advantages for Bomtotal.com

It is designed as its name, to provide the Bill of Materials of an application. Nothing more than that. Codenomicon's Appcheck does provide the BOM and more with automatically providing all the versions as well as the vulnerabilities associated with them, visibility of licenses used in these components, remediation via instant simulation, report generation in multiple formats and many many more. While the manual way can be done, it is definitely time consuming if one were to upload GBs of data size and contain hundreds to thousands of third party components. Surely, automation definitely helps alot in this form of binary analysis through software composition analysis via Codenomicon's AppCheck.

Curious about the power of AppCheck? Check out the link to find more information about it.

http://www.codenomicon.com/products/appcheck/

S3VLC – SCADA Software Security Verification Life Cycle

Taking a different approach on securing application

Introduction

Heartbleed, Shellshock and Poodle. These are some of the highly talked vulnerabilities for the year 2014. We live in an Internet era where they can never be a day without vulnerabilities not being found or an organization not being compromised. Things seem to get worse when such vulnerabilities are used as a form of weapon geared towards critical infrastructure. As defined by Wikipedia; critical infrastructures are assets that are essential to the functioning of the country's economy and society [1]. If an attack towards our critical infrastructure were to happen and worse, succeed, then it will definitely impact the country, from the savings in our banks, transportation on the roads to the distributing of gas, water and electric to our everyday needs.

This blog intends to share the problems with majority of the critical organizations systems, the reports in the news, the challenges faced towards software developers and how by introducing a process called S3VLC can help protect critical organizations.

Attacks on Critical Infrastructure

On November 18th 2011, reports state that a group of foreign hackers were targeting U.S water plants. It was said to be the first known cyber-attack that damaged the water and electricity distribution systems [2]. On June 30th

2014, Symantec uncovered a malware campaign from a group called Dragonfly which compromised more than a thousand power plant systems[3]. On April 4th 2012, according to DHS, the America's water and energy utilities face daily cyber espionage and DOS attacks against its industrial control systems [4].

Problems in Software Security

These cyber-attacks are not surprising especially when vulnerabilities are constantly found on these critical infrastructure systems. On October 18th 2013, researchers in the US found over 25 security vulnerabilities in SCADA systems [5]. On September 18th 2014, 3 security holes were found in the commonly used SCADA software from Schneider Electric [6].  And through these vulnerabilities, according to Darlene Storm, a security blogger for Computerworld, hackers took advantage of these holes to take full control of critical infrastructure [7].

"On average over 70% of IT Security budget is spent on Infrastructure, yet over 75% of attacks happen at the Application level." - Rob Labbe (Microsoft SDLC for IT)

SDLC

SDLC or Software Development Life Cycle is a process for planning, creating, testing and deploying an information system. In SDLC, security has never been part of the process thus making the application stable but insecure.  Recent article from The Register states that 80% of application developers suck at securing client's data [8]. This is not a surprise since majority of application developers are good at that - developing applications and nothing else hence security is never part of the process. The introduction of adding security as part of the SDLC process is slowly being adopted by application developers and software making companies however due to constraints in time, tools and budget, little of the security portion are deployed in the process [9].

Secure Source Code Review

One of the earliest starting point for a SSDLC is the introduction of secure source code review. Using manual or automatic approach and analysis tools, code reviewers analyse source code in order to help find security flaws. This stage allow reviewers to find issues such as buffer overflows, SQL injection flaws and cross site scripting. All these can be tackled before final compilation.

Challenges

There are a number of challenges in this stage. One is time constraint and by taking a manual approach, it is extremely difficult to look through the thousands or even million lines of codes. And if an automatic approach is adopted using tools, then chances of false positives are high and many potential vulnerabilities such as authentication problems, access control issues are hard to get flagged.

Transparency of SSDLC

Some of the biggest challenges to clients when purchasing the SCADA software is the inability to know the contents of the software and has no transparency to whether proper SSDLC process being adopted during its development. To add to this woes, many critical organizations using SCADA application have little or no security team in place to ensure the ‘cleanliness’ of the software and have little or no expertise to test the reliability of security of the software. 

Without proper security verification check, engineers and operators risk themselves by installing the software in their production environment, thus allowing potential known and unknown vulnerabilities lurking in their environment waiting to be exposed or exploited.

Another challenge is that clients usually are not provided with the source code of the application from their vendors due to many reasons and one of them is the potential leakage of their source code to competitors or online.

Current Vendor to Client Cycle

 

Fig 1: Vendor-Client cycle

S3VLC

S3VLC or SCADA Software Security Verification Life Cycle is a process that would allow organizations to test and check the security of their applications, adopting the art of binary analysis and fuzzing. This framework allow organizations not to rely or depend on the software vendors and instead taking ownership of the software and ensuring its security before deploying to their environment.

Binary Analysis

Binary analysis is the process of analysing the binary code to search for compliance issues and vulnerabilities in 3rd party libraries. The idea behind this assessment is to think what could a hacker possibly do or find out about the compiled executable. Unlike code review, binary analysis do not rely on assumptions but instead it will detect on the actual libraries and components in the binary and check the version of the libraries and with these versions known and detected, give references to vulnerability databases such as CVEs or NVDs and see if any components are vulnerable. This process allows client to have the transparency in the BOM (Bill of Materials) to the software and gives the ability for the clients to manage any vulnerabilities found and understand its potential risks if such software are deployed.

Fig 2: List of Third Party Components and the Vulnerabilities associated with it

Fuzzing

Fuzzing is a technique used by introducing malformed or random data to an application and see the output of it that may reveal potential security issues. In 2006, according to an article from The Register, security researcher HD Moore managed to find a number of bugs in the Internet Explorer browser using the fuzzing technique [10]. In a presentation by John Neystadt, a Microsoft employee states that 'over 70% of security vulnerabilities Microsoft patched in 2006 were found by fuzzing [11]. Thus, as fuzzing becomes increasingly important as a way to find potential bugs and zero days, Microsoft security guru, Michael Howard stated back in 2007 to adopt fuzzing as part of the software creation process [12]. And when Microsoft starts to adopt fuzzing as part of its process, in 2010, the company found over 1800 Office bugs [13]. This shows that by incorporating fuzzing technique as part of a security life cycle framework, is beneficial to the software owner and users.

An example of how easy it is to perform a Denial of Service attack via fuzzing technique:

Fig 3: Illustration on how an application is fuzzed

Fig 4: Application crashed due to unable to understand packets received

The S3VLC Framework

Fig 5: S3VLC in action

The Future of Software Security through Transparency

Last year, Dec 4th, U.S. representatives introduced "Cyber Supply Chain Management and Transparency Act of 2014." The legislation will ensure all contractors of software, firmware or products to the federal government provide the procuring agency with a bill of materials of all third party and open source components used, and demonstrate that those component versions have no known vulnerabilities. [17]

Fig 6: The Bill at glance

This act enforces vendors providing firmware, software and hardware to the U.S. government to provide the BOM (Bill of Materials) of the F/S/H and to demonstrate that components used are not vulnerable and software must be created for patching as well. 

Conclusion

The main idea for this framework is to allow organizations to properly validate and evaluate the software using the art of binary analysis and fuzzing technique. As consumers are not given with the source code as well as the transparency to know whether or not vendors adopt proper SSDLC approach in creating the software, S3VLC framework allow organizations to find both known and unknown vulnerabilities in the software they purchased/evaluate thus allowing them to work closely with the vendors to improve and minimize the potential risks involved based on the results found. 

Final Words

There can never be a silver bullet when it comes to protecting the infrastructure. We have evolved to a generation where having an Antivirus and firewall is just a small piece of a bigger puzzle that needs to be filled. The list to secure an environment is exhaustive, ranging from SSDLC, OS hardening, network security perimeter for both internal and external, audit and compliance, following best practices when it comes to network design to the implementation of event logging and network monitoring. As the famous phrase 'Security is a Journey, Not a Destination', there can never be a one solution that solves everything. As security professionals, it is our duty to educate the masses about the importance of security and the consequences of ignorance. And as an end user, it is our duty to understand that security is a shared responsibility and that we all have a role to play in it.

References

[1] http://en.wikipedia.org/wiki/Critical_infrastructure

[2] http://www.washingtonpost.com/blogs/checkpoint-washington/post/foreign-hackers-broke-into-illinois-water-plant-control-system-industry-expert-says/2011/11/18/gIQAgmTZYN_blog.html

[3] http://www.symantec.com/connect/blogs/dragonfly-western-energy-companies-under-sabotage-threat

[4] http://www.networkworld.com/article/2188264/malware-cybercrime/dhs--america-s-water-and-power-utilities-under-daily-cyber-attack.html

[5] http://www.computerweekly.com/news/2240207488/US-researchers-find-25-security-vulnerabilities-in-SCADA-systems

[6] http://www.securityweek.com/vulnerabilities-found-schneider-electric-scada-product-line

[7] http://www.computerworld.com/article/2475789/cybercrime-hacking/hackers-exploit-scada-holes-to-take-full-control-of-critical-infrastructure.html

[8] http://www.theregister.co.uk/2014/09/23/app_devs_suck_at_security_says_trainer/

[9] www.coverity.com/library/pdf/the-software-security-risk-report.pdf

[10] http://www.theregister.co.uk/2006/04/13/data_fuzzing/

[11] http://www.mccabe.com/pdf/McCabeIQ-FuzzTesting.pdf

[12] http://www.zdnet.com/blog/security/microsoft-security-guru-get-fuzzing/258

[13] http://www.computerworld.com/article/2516563/security0/microsoft-runs-fuzzing-botnet--finds-1-800-office-bugs.html

[14] http://www.informationweek.com/hacking-contest-reveals-solaris-vulnerability/d/d-id/1010480?

[15] http://www.technewsworld.com/story/75768.html

[16] http://www.zdnet.com/blog/security/stuxnet-attackers-used-4-windows-zero-day-exploit

[17] http://royce.house.gov/news/documentsingle.aspx?DocumentID=397589

Disclaimer

The above post is solely based on my personal research and in no way represent the views and opinions of Codenomicon.

Dissecting Third Party Application Policy & Process – Finding the Missing Link

Abstract

"On average over 70% of IT Security budget is spent on Infrastructure, yet over 75% of attacks happen at the Application level." - Rob Labbe (Microsoft SDLC for IT)

POODLE, HeartBleed and ShellShock. If there’s something to be learned from these vulnerabilities is that they came from the applications side of things rather than network. As the above quote states, organizations spend bulk of the budget in securing the infrastructure yet majority of the attacks happen at the application level. Top organizations follow best practices and comply to standards such as ISO 27*, NIST and many other frameworks yet recent news have shown that despite all that, organizations keep falling victims to hackers. Are we doing enough to protect our systems? What have we done to ensure that our applications residing in our systems now are not filled with holes waiting to be exploited? How well do we ensure that our installed applications, be it in-house or third party software are soundly checked before deployment? Do organizations have the proper process when it comes to installation of third party software? This paper will explore at two of the big organizations on how their policies and processes play a part when it comes to third party applications into corporate systems and what could possibly be the missing link that could potentially stop the change of a secure corporate system to a gateway of heaven for hackers.

Background

"As a house is only as strong as its foundation, it's no wonder cyber attacks are on the rise with reports showing 71 percent of software contains components with critical vulnerabilities," – Rep Royce (http://royce.house.gov/)

In my experience as a security consultant and an ethical hacker, my primary role was to perform vulnerability assessment and penetration testing to clients ranging from servers, web applications, network and even workstations. Some organizations were repeated customers and that allowed me to observe on the changes and remediation made towards the vulnerabilities found via previous assessments reports. Most of the vulnerabilities found during my experience were those assessments done on workstations. It was quite surprising and at the same time shocking to see the kinds of vulnerabilities found on these workstations. Much of these vulnerabilities found were mainly from third party applications such as torrent clients, FTP clients and servers, databases and many more. These observations made me wonder on how these users were allowed to install such applications and whether or not proper processes exist to monitor, verify and validate these applications before being given the permit to install on corporate systems.

The Interview

To find out about how third party applications are being installed on the machines, 2 personnel were being interviewed from two different organizations. One is from a global bank and another from a government agency. Two basic questions were asked: 1) Are end users allowed to install 3^rd party applications? 2) What is the process involved for this? Below are the case studies.

Case Study 1 – A Bank’s Security Manager

Me: “So I understand that 3^rd party applications can be installed on end users machine. Is that true”

BSM: “Depending on the type of users. Usually they are not allowed to install, however, some users, if they need to install will have to request for it.”

Me: “Walk me through this process.”

BSM: “Well, we have a form that user needs to fill in and it will be submitted to the relevant department for clearance and approval. Once approved, a member of the IT team will install it for the user.”

Me: “Are the users allowed to install themselves?”

BSM: “No. Because they have limited privileges and only an IT personnel have the proper rights to install it for them.”

Me: “So who will provide the binary for the installation? The user or the IT team?”

BSM: “The user”

Me: “Are there any security checks involved before the installation?”

BSM: “At most, we will scan it against the AV scanner and ensure its not infected.”

The Process in Graphic

Case Study 2 – A Government CIO

Me: “So I understand that 3^rd party applications can be installed on end users machine. Is that true”

GCIO: “Depending on the type of users. Usually they are not allowed to install, however, some users, if they need to install will have to request for it”.

Me: “Walk me through this process.”

GCIO: “The user will have to log a ticket with the helpdesk using a remedy system. The user will have to write down the reason for this request and why is it necessary to be installed in the machine. This will then be approved by their department’s manager to confirm if such request is necessary. Once approved, the request will then be submitted to another level of management. The application will be downloaded by the relevant IT team and installation and proper packaging is involved before installation. Once its packaged, it will then be committed into the SCCM and will be pushed to the users requested. The installation will commence without the need for user to have system privileges”.

Me: “Are there any security checks involved before the packaging”

GCIO: “Yes. Our packaging team in the development lab is equipped with endpoint protection systems and it is a standard to have new application be scanned by the AV/AS before packaging.”

The Process in Graphic

Findings

As we can see from the above 2 case studies, in both situations, proper privileges are enforced and users has the possibility to install third party applications if approved. In terms of security, in both cases, there were only relying on scanning the applications for infections or malware. There was no process or effort to check for vulnerabilities in the applications at all.

Potential Issues and Impact

Based on the two case studies, we can see that there are no proper checks to ensure that the applications are not vulnerable before deploying or installing them onto the user’s machines. As Anti Virus or Anti Malware products do not detect vulnerable libraries used in these applications, these installed applications can be a gateway to hacker’s heaven. If we look at previous hacking related events, the systems that were compromised were not the servers but were started from the end users machines before pivoting to another and eventually compromising the entire network.

Challenges in Vulnerability Scanners

In most, if not all policies and standards require a section that concentrates on the need for organizations to perform vulnerability assessments which include vulnerability scanning of a network or a system. According to Qualys, (https://community.qualys.com/docs/DOC-1068) a typical vulnerability scanning processes in the following manner:

1) Check if the remote host is alive

2) Detecting if the host is behind a firewall

3) Scans for TCP/UDP ports

4)  Scans and Detects for Operating System

5) Discover services through the TCP/UDP ports

6) Checks version of the services and detects if it is a known vulnerability

While vulnerability scannings detect vulnerabilities and are practiced in most organizations, we need to understand that most of these scanners are able to detect for known vulnerabilities based on the version of the services detected. These scanners, however, do not detect for vulnerable libraries/components inside an application/binary.

Binary Analysis via Codenomicon’s Appcheck

AppCheck brings total visibility to the digital assets that organizations of all sizes regularly use to build and expand their digital infrastructure. Leaving no stone unturned and no component unchecked, AppCheck performs a patent-pending, non-destructive static binary analysis on your digital assets to provide a comprehensive and up-to-date bill of materials (BOM). With AppCheck, you gain unprecedented situational awareness and visibility to the risk posture an organization.

The following image is an example of a popular firewall system manager of a vendor whose firmware was publicly available and downloaded. Upon uploading the binary to AppCheck, we can see the number of 3^rd party components being used in this application and how many components are vulnerable.

AppCheck’s dashboard showing the components, vulnerabilities and component licenses.

AppCheck listing the list of 3^rd party components and the number of vulnerabilities associated to each component.

AppCheck listing the libraries using the vulnerable component as well as the CVE number and CVSS score for the vulnerabilities associated with the vulnerable component.

Compromise despite Compliance

Past reports have clearly shown that even companies from the fortune 500, despite its maturity and compliance to standards and/or following best practices were compromised affecting its customers, its brand and its reputation and costs. With so many analyses on how these hacks were done, from the exploitation of vulnerable application, the holes in the network to cyber espionage caused from disgruntled employees to political causes. If there is one thing that we can learn is that there are more things that need to be done when it comes to cyber security.

Solution

As shown, performing just vulnerability scanning as part of the assessment or management is insufficient. Organizations need to relook at its policies and processes to ensure that proper security checks are done both in the form of checking for malware and vulnerabilities in the form of binary extraction and analysis. As organizations do not have the source codes for these 3^rd party applications, analyzing from that angle will be almost impossible, however it has been shown that analyzing in its binary form is possible, extracting the package and reviewing the libraries used giving organizations the capability to identify the vulnerabilities in its libraries thereby allowing them to understand the risks involved before installing on to their systems.

Enhancing Desktop Application Software Policy

With the current policies only look for malwares and scanning against existing Anti Virus applications before installing on corporate machines, security managers must understand that this is not enough as much of applications that are being infiltrated are not through malware but through vulnerable components inside the application that are not malicious at all. AppCheck allow organizations to have the transparency of the inside of the binary, ability to view the components and understanding the risks involved before deploying or installing them to corporate machines.

The Process in Graphic

Conclusion

With thousands of applications being developed and uploaded online every day, it is time for organizations to relook at its current vulnerability management policies and processes. Just like the history of weaponry, with every evolvement of defense, so do to the evolvement of attacks. Traditional security of securing from the perimeter is no longer enough. If there’s one thing we can learn about the Trojan Horse of Troy is that the perimeter defense will eventually be breached and if there’s no proper strategy to handle and manage what’s inside the walls, then we, unfortunately will lose the war.