Executive Summary
The problem of vulnerable software was identified by the US Department of Homeland Security as the root origin for 90% of cyber attacks1. vRx, a new product in the field of application security, aims to protect software without having its source code, install a patch or have the application’s vendor involved.
Once a software is installed in a given business, the responsibility for the product security is transferred from the vendor to the organization. As of today, there is no way to protect software unless you patch it. Vicarius’s vision is to change that equation.
vRx is the first platform in the world to predict and protect against yet-to-be-discovered risks originating in software.
The system integration process has three main steps:
Predict – A discovery process takes place on any digital asset of the organization. Using the ‘Capability Driven Security Engine’, software structure is being automatically built to understand its ecosystem. At the same time, the application binaries are reverse-engineered to associate code portions with capabilities such as Network, Encryption, Media, etc. to imply the chances of this binary area to get exploited in the future.
Prioritize - The gathered data from the prediction phase is mixed with known vulnerability (CVE) data and asset context (application usage over time, asset-specific network configurations, user privileges, etc.) to understand the most critical risks which require immediate attention.
Protect - By understanding the most critical risks of the business security operations and each software structure, the ‘Dynamic Policy Engine’ propagates security measures to protect from:
Application components abuseÂ
Abuse of legit software executables
Introduction
There is nothing new about the recurring tries to tackle the issue of vulnerable software.
Vendor-side solutions try to ‘catch’ a software breach before it gets released to the client. Others run black-box checks using databases of previously known attacks. Traditional application scanners inform IT teams about patches after they’ve been exploited and become publicly available. 2
The vulnerable software concern stays a top priority for security teams around the world.
The current process of detecting breaches on the client (not the vendor) side hasn’t changed dramatically apart from prioritization solutions. Their primary focus was on operational security rather than providing immediate mitigation. Some of the prioritization solutions lack the asset contexts as a priority criterion because of their network scanning approach.3Â
As the market evolved, organizations understood that once you install software, you also share the security liabilities of the product alongside the vendor. No one cares if a breach occurred because of a flaw in a third-party application or because of infrastructure misconfigurations. The organization still holds responsibility4.
The increasing usage of third-party applications raises a crucial need for a comprehensive solution that will provide complete visibility of what software is doing and how a customer can take action to strengthen his or her security level5. Defined by Gartner as the next-generation of the application security market, this new world of products, Application Monitoring & Protection, intends to provide new security measures to protect software without changing its source code or installing patches.
This paper will explore the Vicarius way of solving this challenge – from visualizing yet-to-be-discovered threats, taking actions to mitigate them efficiently, and providing out-of-the-box anti-exploitation protection for third-party software binary code. Â
What's Software?
As a preview of the platform overview, let’s try to understand the basic structure of software.
StructureÂ
Once you install an application, you get two main things that are related to its execution: Executables and Libraries.
Operating systems are built in the same way. Its libraries usually contain functionality which is being used by multiple applications and consumers.
LibraryÂ
The functionality inside each library is externalized for the operating system to redirect relevant system calls. Any business logic of the application should be located inside shared libraries for the application software developers to avoid identical code lines in the same project. Those kinds of files are usually of DLL or OCX type in Windows6 and SO or A7 in *NIX based hosts.Â
Executable
The logical flow of an application is required to have an orchestrator to turn the functionality located inside the libraries into a real functioning software.Â
The executable can use two kinds of libraries: operating system and application. If it wishes to build functionality that is specific to the program internals—for instance, registration or authentication for a given service—it will probably use an interface located inside a library that was ‘shipped’ with the software. A more general capability, such as a webcam or keyboard usage, is found in operating system libraries.
Interaction
We can sum up that the software is using the underlying operating system and its libraries to function in an appropriate manner.
Figure #1, Software Interaction
Main Ways of Attack
We came to understand that there are three main ways to abuse software executables and libraries.
Abuse the Executable
Code-related breaches such as Cryptographic Issues8, Logging of Excessive Data9, Insufficiently Protected Credentials10, etc. enable attackers to initiate exploits from within the application. Such attacks usually intend to extract sensitive information (e.g., SQL Injection11) or activate functionality hidden inside the software (e.g., Stack-based Buffer Overflow12 attacks) without the vendor or client’s awareness.
Figure #2, Executable Abuse
Impersonate as the Executable
Operating systems contain built-in features to ‘jump’ between processes in the runtime environment. While there is a proper use of these capabilities, attackers often use it to disguise themselves as legit consumers. Functionalities such as ‘OpenProcess’ located in Kernel32.dll13 is one of the ways to achieve that. Popular attack frameworks, such as mimikatz14, metasploit15, PowerSploit16, etc., are extensively using that capability.
Figure #3, Executable Impersonation
Directly Abuse the LibraryÂ
The operating system's course of action includes system call redirections for built-in and third-party modules (e.g. ‘LoadLibray’19 function in Windows). For that process to function, any code module has to declare what functionality it contains (e.g., Export Table17) so the operating system is aware of system calls it should receive. Just like any legit application, an adversary can initiate system calls to modules it wishes to exploit. An endless number of attacks fall under the category of API Abuse18 to take advantage of the unrestricted access to module files.
Figure #4, Library Abuse
Vulnerability Prediction
To properly enforce restriction mechanisms over functionality access to shared code modules, we need to understand that the biggest challenge is to have the most lightweight and non-intrusive solution possible.
Tracking every system call by any executable on the operating system level will create a significant degradation on the user experience and can potentially cause a high rate of false-positive alerts (or system crashes in cases of access prevention over detection).
Our system wishes to understand which functionalities inside module binary files can interest attackers in their current or future exploitations. Under this goal, we need to make a distinction between two scenarios:Â Â
The application creates a system call to one of its library functionalities.
The application makes a system call to an operating system library functionality.
To create an efficient way for system call restrictions, we need to preemptively predict which functionalities - binary code areas – are currently and will be exploited by hackers.
Risky Functionalities Within the Application
By reverse engineering the library binary files, we associate functionalities with capabilities that attackers often use.
We can look at each function inside a module as a chain of sub calls. The system performs the analysis process on the server with no impact on the user experience.
Figure #5, Static Analysis of Software Library
The trees are matched with pre-made patterns to indicate if a given function is associated with some capability, for example:
A function called PK11_CheckUserPassword located in a library called nss3.dll20 which is part of Mozilla Firefox. The function contains both ‘User’ and ‘Password’ phrases and can be associated with ‘User Interaction’ and ‘Password Interaction’ capabilities. Those capabilities are exploited by hackers to steal user credentials from the browser.Â
A given function has a 3rd level call to a function containing the word ‘HTTP’ and a 4th level call to a function containing the word ‘AES’. The original function is associated with ‘Encryption’ and ‘Network’ capabilities, respectively. Interestingly, the platform identifies that the combination of a 3rd level call to encryption capability combined with a 4th level call to network capability relates to ransomware type attacks.
Figure #6, Capabilities and Attack Surface Association as Seen on Vicarius’ vRx Platform
Application Usage of Sensitive Operating System Libraries
As described in the previous section, we can highlight sensitive areas in libraries’ binary code using server-side static code analysis. The platform is running these processes on third-party and operating system libraries.
While a sensitive code portion in a third-party software can instantly imply a future exploit, the situation with operating system libraries is much more complicated. Operating system features that contain sensitive functionality are an essential and built-in feature of legitimate applications that run on top of it.
To understand a regular flow of a given software, we need to perform two steps:
Associate operating system-related library binary code with risky capabilities (e.g., Risky Functionalities Within the Application).
Randomly track a given application executable to see which risky capabilities of the operating system it accesses.
Figure #7, Dynamic Analysis of Software Executable
This Dynamic Evaluation process intends to draw a map of which operating system capabilities a software executable touches.
Two important things to highlight here regarding minimizing user experience overhead are:
The ‘watched’ functions inside the operating system libraries are only the ones that are highlighted as risky in the static analysis process.
A process is being tracked only on machines that our system found it is highly active on as we need to get a general idea of what the software is usually doing.
Bottom Line
The purpose of those two steps is to give us an idea of:
How risky is a given software based on its bundled libraries?
How can this software do harm in the event it’s being abused by an adversary through its legit features it’s using in the operating system?
How will it be exploited in the future? And in that case, we have two options.
Abuse of its libraries
Forcing the software to do something terrible and exploit operating system features.Â
At the end of this process, the system indicates the risk level of the software based on those parameters to understand the cost of ownership and level of threat to the company. This method presents a new and innovative way to understand ‘where the next vulnerability is going to come from'.
Figure #8, Products Overview as Seen on Vicarius’ vRx Platform
Asset-based Prioritization
From working closely with our customers, we could see that organizations have an enormous number of applications, software services, and devices. As a direct consequence, their well-known vulnerabilities21, predicted vulnerabilities and network configurations grow exponentially and create a ‘tunnel view’, which leads them to miss the most critical risks.
As vRx runs on any of the organization assets, it has a significantly better overview of how an asset can be compromised based on its specific configurations and the software it runs.
Our prioritization engine is based on a proprietary map-reduce platform. The system has two components – data collecting commands and map-reduce python-based scripts.
Map Reduce Engine
An analysis process should run on the output of the raw information for the system to generate insightful action items from a significant amount of raw data.
In vRx, this process is done using fully customized python-based scripts which have access to all the data in the system.
Let’s take two examples of user story scenarios:
Use Case #1Â
An organization has 2000 endpoints with vulnerable Flash Player24, but they have internal-only network access. A web server (e.g., Web-Server-1) has one vulnerability in Apache Struts25, the server has an external internet access, and Apache Tomcat26 processes are never idle.
Use Case #2
Vicarius’s vRx identified a scripting-related attack surface in a new kind of browser (e.g., Firedos) your users (including the CEO laptop, e.g., CEO-LAPTOP) started to use; the browser requires admin privileges to run.
Rules which will allow us to identify essential risks:
Use Case #1
Highlight all assets which have:Â
Public internet accessÂ
Network related vulnerability in an installed software
Highlight all software which:
Has highly active processes
Exposed open attack surface
OR
Has well-known weaknesses
Use Case #2
Highlight all software which:
Runs with admin privileges
Has scripting-related attack surfaceÂ
OR
Has script-related well-known vulnerabilities
As mentioned earlier, users can edit, add and remove any rule in the system. As part of our integration, we auto-populate scripts that we built.
For a more technical overview of how you can build a rule, please visit our blog.
Action Items
The result of the map-reduce phase is a three-way landscape overview of:
General Insights – Entire organization insights
Which assets and software should I focus on?
Use Case #1
One vulnerable software with network-related weakness found on one internet-facing asset.
One highly active and vulnerable software found on one asset.
Use Case #2
One vulnerable software with script-related weakness found on 2000 high-privileged assets.
Figure #11, General Insights Overview as Seen on Vicarius’ vRx Platform
Assets Insights – Asset-specific insights
What assets should I focus on?
Use Case #1
Web-Server-1 is internet-facing and has one vulnerable software with network-related weakness installed.
Web-Server-1 has one highly active and vulnerable software installed.
Use Case #2
CEO-LAPTOP runs with high-privileges and has one vulnerable software with script-related weakness installed.
Figure #12, Asset Insights Overview as Seen on Vicarius’ vRx Platform
Products Insight – Software-relevant insights
What software should I focus on?
Use Case #1
Apache Struts has network-related weakness and is installed on one network-facing asset.
Apache Tomcat is highly active, vulnerable, and runs on one asset
Use Case #2
Firedos has script-related weakness and runs on 2000 high-privileged assets.
Figure #13, General Insights Overview as Seen on Vicarius’ vRx Platform
The rotation between the landscapes intends to make the system admin work much more efficiently as he can gain ‘quick wins’ to reduce his organization’s risk level – for example:
Update one software on one server.
Instantly protect Firedos with vRx on all relevant assets.
If an insight won’t ‘jump’ to an administrator's eyes in the first view, it will probably appear as he plays around in other landscapes to spare the job he used to do manually.
Software Protection
As of today, the options security teams have to protect software are:
Keep track of security patches
Contact the software’s vendorÂ
Limit software to specific environments or asset configurations
What we understood is that organizations are still vulnerable even if they will perform all of the above.
The process of software vulnerability mitigation has many steps. First, the software’s vendor should be informed about a new optional vulnerability by the community or professional security researchers. Then, after a validation process on his side, he approves it as a real breach. By then, the vulnerability details are already publicly available and can serve hackers in their future attacks. If the vendor decides to release a security patch, he will allocate development teams to fix it. However, that’s not always the case as the call is on the vendor side.Â
As a massive number of security patches are released every month, organizations around the world are struggling to propagate those updates in their networks, leaving their digital assets exposed to security threats.
The Vicarius way of protecting software is to look at applications and operating systems as two sources of ‘targets’. We know that there will be an attack, but if we can map out the functionalities of the modules that exist on a given computer, the malicious code will be sterilized and useless.
vRx characterizes software it analyzes in three ways:Â
What are the legitimate application executables?
Which sensitive operating system capabilities does the software use over time?
Which software code portions are likely to get exploited?
Figure #14, Risky Targets Software Mapping
Executable Out-of-Boundary Limitation
To tackle attacks which originated from security breaches inside software executable precompiled code (e.g., Abuse the Executable), vRx first maps out sensitive capabilities in the operating system and then outlines what capabilities each software executable uses.
While the system won’t be able to tell the attack type, or which code area is responsible for the flaw, it will block the software as it tries to access capabilities that are not part of its original map.
Figure #15, Legit Software Operating System Capabilities Restriction
Restriction of operating system sensitive capabilities is being performed over legit applications in case someone made it do things it usually doesn’t.
This feature is currently experimental.
Executable Isolation
An executable attached to a protected application is allowed to access its core capabilities and the operating system features that are detected during the mapping process. A common scenario of attack may involve an adversary trying to disguise himself as one of the legit application executables and act on its behalf. This document is also describing this technique (e.g., Impersonate as the Executable).Â
To prevent processes from hiding themselves as a legit executable, vRx has an isolation mechanism to check executable integrity.
Figure #16, Blockage of Impersonation-Based Attack
The impersonation capability in the operating system can be used for legit purposes, such as debugging. For that reason, vRx doesn’t block every kind of impersonation attempt and allows any executable to use that capability.
Figure #17, Impersonation Attempt as Seen on Vicarius’ vRx Platform
The only case in which the agent will initiate a blockage is once a protected software executable is the target of the impersonation attempt. That way our system ensures low user experience overhead and low false-positive rates.
The only case in which the agent will initiate a blockage is once a protected software executable is the target of the impersonation attempt. That way our system ensures low user experience overhead and low false-positive rates.
Libraries Protection
As we outlined previously, software comes with built-in libraries that usually contain sensitive capabilities.
The process of identifying dangerous code areas (e.g., Risky Functionalities Within the Application) is similar to what attackers do during their reconnaissance attack phase (e.g., Directly Abuse the Library).
The main difference between vRx’s analysis process and the attacker’s is that the attacker needs to understand both the input and output of that feature to exploit a functionality.Â
Figure #18, Software Capability Abuse Restriction
The system puts a gate above the attacker's desired target unrelated to its input or output.Â
Figure #19, Software Capability Abuse Attempt as Seen on Vicarius’ vRx Platform
To decrease runtime activity, token-based integrity checks are being done in specific library loading points and not on every function system call.
Summary
This document outlines Vicarius's approach to next-generation application security.Â
The number of use cases our clients find the system relevant to is endless:Â
Checking software risks before organization-wide installation
Custom software protection
Generating continuous compliance reports
Analyzing organizational risk over time
Protecting server and desktop applications
And many more.
If you wish to see a live demo or ask one of our team members any questions, feel free to contact me:
Name: Michael Assraf
Position: CEO
Email: michael@vicarius.ioÂ
Phone: +1 605-593-5454
Office: 2 Kiach St, Jerusalem, Israel
References
‘Is poor software development the biggest cyber threat?’, Steve Morgan, Link
‘What do SAST, DAST, IAST, and RASP mean to developers?’, Sherif Koussa, LinkÂ
‘Market Guide for Vulnerability Assessment’, Oliver Rochford & Prateek Bhajanka, LinkÂ
‘Hype Cycle for Application Security, 2017’, Ayal Tirosh, LinkÂ
‘Using third-party vendors? Keep a close eye on them’, Michelle Drolsset, LinkÂ
‘What is a DLL?’, Microsoft Official Support, Link
‘Shared Libraries: Understanding Dynamic Loading’, Amir Rachum, LinkÂ
‘CWE CATEGORY: Cryptographic Issues’, MITRE Official Website, Link
‘CWE-779: Logging of Excessive Data’, MITRE Official Website, Link
‘CWE-522: Insufficiently Protected Credentials’, MITRE Official Website, Link
‘CAPEC-66: SQL Injection’, MITRE Official Website, Link
‘CWE-121: Stack-based Buffer Overflow’, MITRE Official Website, Link
‘OpenProcess function’, Microsoft Official Support, Link
‘rapid7/metasploit-framework’, GitHub, Link
‘PowerShellMafia/PowerSploit’, GitHub, Link
‘Peering Inside the PE: A Tour of the Win32 Portable Executable File Format’, Microsoft Official Support, LinkÂ
‘CWE CATEGORY: 7PK - API Abuse’, MITRE Official Website, Link
‘LoadLibrary function’, Microsoft Official Support, Link
‘Network Security Services’, MDN web docs moz://a, Link
‘Common Vulnerabilities and Exposures’, MITRE Official Website, Link
‘Understanding How MapReduce is Used in Data Science’, DataScienceGraduatePrograms, Link
‘GNU Bash’, GNU Official Website, Link
‘Adobe Flash Player’, Adobe Official Website, Link
‘Apache Struts’, Apache Software Foundation, Link
‘Apache Tomcat’, Apache Software Foundation, Link
‘Vicarius Blog’, Vicarius LTD, Link