The document discusses detecting "certified pre-owned" software, or software containing backdoors. It describes how static analysis of software binaries can detect various types of application backdoors, including special credentials, unintended network activity, and deliberate information leakage. The document focuses on detecting indicators that software is trying to hide its behavior, such as rootkit behavior and anti-debugging techniques, through static analysis of the software code. Rules can be developed for static analyzers to inspect software for these types of backdoor behaviors and indicators.
A FRAMEWORK FOR ANALYSIS AND COMPARISON OF DYNAMIC MALWARE ANALYSIS TOOLSIJNSA Journal
Malware writers have employed various obfuscation and polymorphism techniques to thwart static analysis
approaches and bypassing antivirus tools. Dynamic analysis techniques, however, have essentially
overcome these deceits by observing the actual behaviour of the code execution. In this regard, various
methods, techniques and tools have been proposed. However, because of the diverse concepts and
strategies used in the implementation of these methods and tools, security researchers and malware
analysts find it difficult to select the required optimum tool to investigate the behaviour of a malware and to
contain the associated risk for their study. Focusing on two dynamic analysis techniques: Function Call
monitoring and Information Flow Tracking, this paper presents a comparison framework for dynamic
malware analysis tools. The framework will assist the researchers and analysts to recognize the tool’s
implementation strategy, analysis approach, system-wide analysis support and its overall handling of
binaries, helping them to select a suitable and effective one for their study and analysis.
Agisa towards automatic generation of infection signaturesUltraUploader
This document describes AGIS, a system for automatically generating infection signatures to detect compromised systems. AGIS monitors the runtime behavior of suspicious code to detect infections based on security policy violations. It then uses dynamic and static analysis to identify the characteristic behaviors of the malware in terms of system/API calls. Important instructions related to the infection's malicious behavior are extracted from executables to generate signatures that can be used by scanners to detect the infection. AGIS was implemented on Windows and evaluated against real malware samples, demonstrating its ability to detect new infections and generate high-quality signatures.
TriggerScope: Towards Detecting Logic Bombs in Android ApplicationsPietro De Nicolao
Presentation of paper "TriggerScope: Towards Detecting Logic Bombs in Android Applications" for the course of Advanced Topics in Computer Security of prof. Stefano Zanero.
Source and further information: https://github.com/pietrodn/triggerscope
SOURCE CODE ANALYSIS TO REMOVE SECURITY VULNERABILITIES IN JAVA SOCKET PROGR...IJNSA Journal
This paper presents the source code analysis of a file reader server socket program (connection-oriented
sockets) developed in Java, to illustrate the identification, impact analysis and solutions to remove five
important software security vulnerabilities, which if left unattended could severely impact the server
running the software and also the network hosting the server. The five vulnerabilities we study in this
paper are: (1) Resource Injection, (2) Path Manipulation, (3) System Information Leak, (4) Denial of
Service and (5) Unreleased Resource vulnerabilities. We analyze the reason why each of these
vulnerabilities occur in the file reader server socket program, discuss the impact of leaving them
unattended in the program, and propose solutions to remove each of these vulnerabilities from the
program. We also analyze any potential performance tradeoffs (such as increase in code size and loss of
features) that could arise while incorporating the proposed solutions on the server program. The
proposed solutions are very generic in nature, and can be suitably modified to correct any such
vulnerabilities in software developed in any other programming language. We use the Fortify Source
Code Analyzer to conduct the source code analysis of the file reader server program, implemented on a
Windows XP virtual machine with the standard J2SE v.7 development kit
Snippets, Scans and Snap Decisions: How Component Identification Methods Impa...Sonatype
1) Component identification methods like source code scanning, CPE name matching, and simple binary matching can result in inaccurate component identification with false positives and negatives.
2) Advanced Binary Fingerprinting, a patent-pending technique from Sonatype, can precisely identify components and versions even if modified, eliminating false results and enabling efficient risk analysis.
3) Sonatype pioneered component-based development and maintains the Central Repository, giving it unique expertise in component identification and supply chain management.
Finding Zero-Days Before The Attackers: A Fortune 500 Red Team Case StudyDevOps.com
Graph databases offer security teams a new and more efficient way to find zero day vulnerabilities. As software development increases its reliance on open source libraries and release cycles get faster and faster application security is becoming more and more difficult. AppSec still has the same charter -- to find vulnerabilities in dev, before they reach prod, but now with more complexity and less time. Graphing source code, and traversing it to identify technical and business logic vulnerabilities, gives AppSec teams a much needed leg up identify zero days and stay ahead of attackers.
As numerous famous examples demonstrate, open source libraries are a common attack vector. Hence, AppSec teams must secure 3rd party dependencies just as vigorously as custom code. While much of the emphasis for securing open source libraries (OSS) has been on identifying and eliminating known CVEs, because OSS is widely used, zero-day vulnerabilities are often more likely to be found in popular OSS than custom code.
This webinar will cover the following:
An introduction to the emerging graph landscape and why it matters for AppSec
How a Fortune 500 company is using graphs to find zero days
Technical demo of finding technical and business logic vulnerabilities in source code
DevSecOps: Securing Applications with DevOpsWouter de Kort
DevOps is all about delivering new features as fast as possible. But what if this means that you're also shipping security issues faster than ever? Security practices must speed up to keep pace with DevOps. This session shows you how you can increase your deployment frequency while still making sure that you ship secure applications. You'll learn best practices and principles for securing your application in a cloud world. You’ll also learn about tooling such as Whitesource and Azure Security Center. In the end, you’ll have a good idea of how to integrate security checks into DevOps and deliver more secure applications.
A FRAMEWORK FOR ANALYSIS AND COMPARISON OF DYNAMIC MALWARE ANALYSIS TOOLSIJNSA Journal
Malware writers have employed various obfuscation and polymorphism techniques to thwart static analysis
approaches and bypassing antivirus tools. Dynamic analysis techniques, however, have essentially
overcome these deceits by observing the actual behaviour of the code execution. In this regard, various
methods, techniques and tools have been proposed. However, because of the diverse concepts and
strategies used in the implementation of these methods and tools, security researchers and malware
analysts find it difficult to select the required optimum tool to investigate the behaviour of a malware and to
contain the associated risk for their study. Focusing on two dynamic analysis techniques: Function Call
monitoring and Information Flow Tracking, this paper presents a comparison framework for dynamic
malware analysis tools. The framework will assist the researchers and analysts to recognize the tool’s
implementation strategy, analysis approach, system-wide analysis support and its overall handling of
binaries, helping them to select a suitable and effective one for their study and analysis.
Agisa towards automatic generation of infection signaturesUltraUploader
This document describes AGIS, a system for automatically generating infection signatures to detect compromised systems. AGIS monitors the runtime behavior of suspicious code to detect infections based on security policy violations. It then uses dynamic and static analysis to identify the characteristic behaviors of the malware in terms of system/API calls. Important instructions related to the infection's malicious behavior are extracted from executables to generate signatures that can be used by scanners to detect the infection. AGIS was implemented on Windows and evaluated against real malware samples, demonstrating its ability to detect new infections and generate high-quality signatures.
TriggerScope: Towards Detecting Logic Bombs in Android ApplicationsPietro De Nicolao
Presentation of paper "TriggerScope: Towards Detecting Logic Bombs in Android Applications" for the course of Advanced Topics in Computer Security of prof. Stefano Zanero.
Source and further information: https://github.com/pietrodn/triggerscope
SOURCE CODE ANALYSIS TO REMOVE SECURITY VULNERABILITIES IN JAVA SOCKET PROGR...IJNSA Journal
This paper presents the source code analysis of a file reader server socket program (connection-oriented
sockets) developed in Java, to illustrate the identification, impact analysis and solutions to remove five
important software security vulnerabilities, which if left unattended could severely impact the server
running the software and also the network hosting the server. The five vulnerabilities we study in this
paper are: (1) Resource Injection, (2) Path Manipulation, (3) System Information Leak, (4) Denial of
Service and (5) Unreleased Resource vulnerabilities. We analyze the reason why each of these
vulnerabilities occur in the file reader server socket program, discuss the impact of leaving them
unattended in the program, and propose solutions to remove each of these vulnerabilities from the
program. We also analyze any potential performance tradeoffs (such as increase in code size and loss of
features) that could arise while incorporating the proposed solutions on the server program. The
proposed solutions are very generic in nature, and can be suitably modified to correct any such
vulnerabilities in software developed in any other programming language. We use the Fortify Source
Code Analyzer to conduct the source code analysis of the file reader server program, implemented on a
Windows XP virtual machine with the standard J2SE v.7 development kit
Snippets, Scans and Snap Decisions: How Component Identification Methods Impa...Sonatype
1) Component identification methods like source code scanning, CPE name matching, and simple binary matching can result in inaccurate component identification with false positives and negatives.
2) Advanced Binary Fingerprinting, a patent-pending technique from Sonatype, can precisely identify components and versions even if modified, eliminating false results and enabling efficient risk analysis.
3) Sonatype pioneered component-based development and maintains the Central Repository, giving it unique expertise in component identification and supply chain management.
Finding Zero-Days Before The Attackers: A Fortune 500 Red Team Case StudyDevOps.com
Graph databases offer security teams a new and more efficient way to find zero day vulnerabilities. As software development increases its reliance on open source libraries and release cycles get faster and faster application security is becoming more and more difficult. AppSec still has the same charter -- to find vulnerabilities in dev, before they reach prod, but now with more complexity and less time. Graphing source code, and traversing it to identify technical and business logic vulnerabilities, gives AppSec teams a much needed leg up identify zero days and stay ahead of attackers.
As numerous famous examples demonstrate, open source libraries are a common attack vector. Hence, AppSec teams must secure 3rd party dependencies just as vigorously as custom code. While much of the emphasis for securing open source libraries (OSS) has been on identifying and eliminating known CVEs, because OSS is widely used, zero-day vulnerabilities are often more likely to be found in popular OSS than custom code.
This webinar will cover the following:
An introduction to the emerging graph landscape and why it matters for AppSec
How a Fortune 500 company is using graphs to find zero days
Technical demo of finding technical and business logic vulnerabilities in source code
DevSecOps: Securing Applications with DevOpsWouter de Kort
DevOps is all about delivering new features as fast as possible. But what if this means that you're also shipping security issues faster than ever? Security practices must speed up to keep pace with DevOps. This session shows you how you can increase your deployment frequency while still making sure that you ship secure applications. You'll learn best practices and principles for securing your application in a cloud world. You’ll also learn about tooling such as Whitesource and Azure Security Center. In the end, you’ll have a good idea of how to integrate security checks into DevOps and deliver more secure applications.
COVERT is a tool that analyzes Android applications in a compositional manner to detect security vulnerabilities that occur due to the interaction of apps. It extracts models of individual apps and the Android framework and uses the Alloy analyzer to check the models for vulnerabilities. An evaluation on over 500 real-world apps found that COVERT can effectively detect inter-app vulnerabilities in minutes and does not require source code. It was implemented with desktop, mobile, and web-based front-ends to facilitate end-user analysis of apps.
Tools & Techniques for Addressing Component Vulnerabilities for PCI ComplianceSonatype
Recent revisions to the Payment Card Industry (PCI) guidelines now require organizations to address potential vulnerabilities caused by use of open source components in their applications.
1. FlowDroid is a static taint analysis system that precisely tracks sensitive data flows in Android apps. It models lifecycles, callbacks, and asynchronous execution to handle Android complexity.
2. An evaluation on 39 benchmark apps found FlowDroid had higher precision and recall than commercial tools. It also detected all leaks in a vulnerable app with no false positives/negatives.
3. FlowDroid analyzes app bytecode, configurations, and models execution to detect data leaks from sources like contacts to sinks like advertising. Its context, field, object and flow sensitivities improve precision over prior work.
PHP is one of the most commonly used languages to develop web sites because of i
ts simplicity, easy to
learn and it can be easily embedded with any of the databases. A web developer with his basic knowledge
developing an application without practising secure guidelines, improper validation of user inputs leads to
various source code
v
ulnerabilities. Logical flaws while designing, implementing and hosting the web
application causes work flow deviation attacks.
In this paper, we are analyzing the complete behaviour of a
web application through static and dynamic analysis methodologies
Lawyers and Licenses in Open Source-based Development: How to Protect Your So...Sonatype
You can build better software faster with Open Source Software (OSS) components, but you must ensure that your organization meets component-licensing terms. Violating the terms of an open source license is copyright or intellectual property infringement and can lead to legal and financial penalties. This white paper explains why certain types of open source licenses create legal risk and describes win-win methods for avoiding risk that give lawyers the confidence they need while giving developers the speed they need.
IRJET- Penetration Testing using Metasploit Framework: An Ethical ApproachIRJET Journal
This document discusses penetration testing using the Metasploit framework. It begins with an introduction to penetration testing and why it is important for ensuring system and network security. It then describes the phases of penetration testing: information gathering, vulnerability analysis, vulnerability exploitation, post exploitation, and report generation. Finally, it discusses using tools in the Metasploit framework like exploits and payloads to conduct penetration testing according to these phases and ethical approaches. The goal is to identify vulnerabilities before attackers can exploit them.
This document describes a web vulnerability scanner and reporting tool developed by researchers. The tool scans websites for various vulnerabilities like SQL injection, cross-site scripting, and file inclusion vulnerabilities. It performs scans both without login and with login credentials provided by the website owner. The without login scan checks if the site is reachable and identifies vulnerabilities, while the with login scan allows for deeper scanning. The tool uses machine learning, DOM, and aggregation algorithms. It produces a report with the number and types of vulnerabilities found, and URLs of affected pages. The researchers validated the tool and believe it can help developers identify and address security issues on their websites.
The document describes Swascan's cloud cyber security and GDPR compliance platform. The platform includes services like web app scanning, network scanning, and code review that identify vulnerabilities. It also provides compliance assessments and generates reports. The platform allows for both cloud-based and on-premise deployment. Swascan's competence center offers additional cybersecurity services including testing, threat management, and incident response.
Introduction to Web Application Penetration TestingNetsparker
These slides give an introduction to all the different things and stages that make a complete web application penetration test. It starts from the very basics, including how to define a Scope of Engagement.
These slides are part of the course Introduction to Web Application Security and Penetration Testing with Netsparker, which can be found here: https://www.netsparker.com/blog/web-security/introduction-web-application-penetration-testing/
The document discusses integrating security testing into the typical iterative development lifecycle through automated software tests at various stages, including unit tests, integration tests, and acceptance tests. It provides examples of using JUnit for unit testing and tools like Cactus, Selenium, and WATIR for integration and acceptance testing to validate valid/invalid inputs and test for vulnerabilities like SQL injection and cross-site scripting.
DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroidMahmoud Hammad
Android is widely used for the development and deployment of autonomous and smart systems, including software targeted for IoT and mobile devices. Security of such systems is an increasingly important concern.
Android relies on a permission model to secure the system's resources and apps. In Android, since the permissions are granted at the granularity of apps, and all components in an app inherit those permissions, an app's components are over-privileged, i.e., components are granted more privileges than they actually need. Systematic violation of least-privilege principle in Android is the root cause of many security vulnerabilities. To mitigate this issue, we have developed DELDroid, an automated system for determination of least privilege architecture in Android and its enforcement at runtime. A key contribution of DELDroid is the ability to limit the privileges granted to apps without modifying them. DELDroid utilizes static analysis techniques to extract the exact privileges each component needs. A Multiple-Domain Matrix representation of the system's architecture is then used to automatically analyze the security posture of the system and derive its least-privilege architecture. Our experiments on hundreds of real-world apps corroborate DELDroid's ability in effectively establishing the least-privilege architecture and its benefits in alleviating the security threats.
Software Birthmark Based Theft/Similarity Comparisons of JavaScript ProgramsSwati Patel
A birthmark is a set of characteristic possessed by a program that uniquely recognizes a program. Birthmark of the software is based on Heap Graph. It is generated by using Google Chrome Developer Tools when the program is in execution. Software’s behavioural structure is demonstrated in the heap graph. It describes how the objects are related to each other to deliver the desired functionality of the website. Our aim is to develop and evaluate a system that can find theft/similarity between websites by using Agglomerative Clustering and Improved Frequent Subgraph Mining. To identify if a website is using the original program’s code or its module, birthmark of the original program is explored in the suspected program’s heap graph.
The Log4Shell Vulnerability – explained: how to stay secureKaspersky
On December 9th, researchers uncovered a zero-day critical vulnerability in the Apache Log4j library used by millions of Java applications. CVE-2021-44228 or “Log4Shell” is a RCE vulnerability that allows attackers to execute arbitrary code and potentially take full control over an infected system. The vulnerability has been ranked a 10/10 on the CVSSv3 severity scale.
While the Apache Foundation has already released a patch for this CVE, it can take weeks or months for vendors to update their software, and there are already widespread scans being conducted by malicious attackers to exploit Log4Shell.
What should companies or organizations do?
Join Marco Preuss, Head of Europe’s Global Research and Analysis (GReAT) team, Marc Rivero and Dan Demeter, Senior Security Researchers with GReAT, for an in-depth discussion on Log4Shell and a live Q&A session.
To see the full webinar, please visit: https://securelist.com/webinars/log4shell-vulnerability-how-to-stay-secure/?utm_source=Slideshare&utm_medium=partner&utm_campaign=gl_jespo_je0066&utm_content=link&utm_term=gl_Slideshare_organic_s966w1tou5a0snh
The OWASP Top Ten is the de-facto web application security standard because it reflects the evolving threat landscape, providing organizations a framework to manage and mitigate application security risk.
This presentation examines the critical newcomers and pesky incumbents from both an offensive and defensive perspective. Our experts share their insight on how to harden Web applications and align your program towards OWASP compliance.
Secure Software Development with 3rd Party Dependenciesthariyarox
This document discusses securing software development with third party dependencies. It defines third party libraries and dependencies and explains how to identify direct and transitive dependencies of a project. It introduces tools like NVD, CVE, CVSS, and OWASP Dependency Check for finding vulnerabilities in dependencies. It emphasizes the need to regularly check dependencies for vulnerabilities and provides approaches for upgrading vulnerable dependencies, handling false positives and negatives, and integrating vulnerability management into the SDLC.
This is the slides of the presentation done in "WSO2 Jaffna: Integrating Security Into Software Development Life Cycle" http://www.meetup.com/wso2srilanka/events/233915649/
The document discusses the science behind runtime application self-protection (RASP) and interactive application security testing (IAST). It describes how RASP works by instrumenting application code to perform dynamic taint analysis, tracking tainted data from inputs and checking for policy violations at sinks like database queries. IAST similarly instruments code but also correlates runtime behavior with attacks to confirm vulnerabilities. The document outlines challenges with taint analysis like under-tainting causing false negatives or over-tainting causing false positives. Both RASP and IAST add overhead, and IAST also has limitations of traditional dynamic application security testing.
Hidden Speed Bumps on the Road to "Continuous"Sonatype
As a companion piece for our '2015 State of the Software Supply Chain Report' this ebook explores the hidden complexities in modern software development by drawing analogies to a traditional supply chain. This is a real eye-opener for anyone who cares about development speed, efficiency and quality.
Security testing involves testing software to identify security flaws and vulnerabilities. It is done at various stages of development, including unit testing by developers, integrated system testing of the full application, and functional acceptance testing by quality assurance testers. Security testing techniques include static analysis, dynamic testing, and fuzzing invalid or random inputs to expose unexpected behaviors and potential vulnerabilities. Thorough security testing requires checking for issues like SQL injection, unauthorized access, disclosure of sensitive data, and verifying proper access controls, authentication, encryption, and input validation. Various tools can assist with security testing.
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...Sonatype
In 2013, the Open Web Application Security Project (OWASP) was updated to include “A9: using components with known vulnerabilities.” This paper explains this new threat with practical ideas for reducing risk from open source components which now comprise 80% of an average application.
Static Detection of Application BackdoorsTyler Shields
The document discusses detecting application backdoors through static analysis of executable code. It defines application backdoors as versions of legitimate software modified to bypass security under certain conditions. The summary discusses three main types of application backdoors that can be detected through static analysis:
1) Special credentials - Detecting hardcoded or computed credentials not from the authentication store.
2) Unintended network activity - Finding network activity not intended in the software design.
3) Deliberate information leakage - Identifying code that leaks sensitive information.
Static analysis rules can inspect for these patterns and other malicious indicators like embedded shell commands, time bombs, and rootkit-like behavior. Well-known backdoor mechanisms can be ob
This document provides a checklist of secure coding practices for software developers. It covers topics such as input validation, output encoding, authentication, session management, access control, cryptography, error handling, data protection, and general coding practices. Implementing the practices in this checklist can help mitigate common software vulnerabilities and security issues. The document recommends defining security roles and responsibilities, providing training, and following a secure software development lifecycle model.
COVERT is a tool that analyzes Android applications in a compositional manner to detect security vulnerabilities that occur due to the interaction of apps. It extracts models of individual apps and the Android framework and uses the Alloy analyzer to check the models for vulnerabilities. An evaluation on over 500 real-world apps found that COVERT can effectively detect inter-app vulnerabilities in minutes and does not require source code. It was implemented with desktop, mobile, and web-based front-ends to facilitate end-user analysis of apps.
Tools & Techniques for Addressing Component Vulnerabilities for PCI ComplianceSonatype
Recent revisions to the Payment Card Industry (PCI) guidelines now require organizations to address potential vulnerabilities caused by use of open source components in their applications.
1. FlowDroid is a static taint analysis system that precisely tracks sensitive data flows in Android apps. It models lifecycles, callbacks, and asynchronous execution to handle Android complexity.
2. An evaluation on 39 benchmark apps found FlowDroid had higher precision and recall than commercial tools. It also detected all leaks in a vulnerable app with no false positives/negatives.
3. FlowDroid analyzes app bytecode, configurations, and models execution to detect data leaks from sources like contacts to sinks like advertising. Its context, field, object and flow sensitivities improve precision over prior work.
PHP is one of the most commonly used languages to develop web sites because of i
ts simplicity, easy to
learn and it can be easily embedded with any of the databases. A web developer with his basic knowledge
developing an application without practising secure guidelines, improper validation of user inputs leads to
various source code
v
ulnerabilities. Logical flaws while designing, implementing and hosting the web
application causes work flow deviation attacks.
In this paper, we are analyzing the complete behaviour of a
web application through static and dynamic analysis methodologies
Lawyers and Licenses in Open Source-based Development: How to Protect Your So...Sonatype
You can build better software faster with Open Source Software (OSS) components, but you must ensure that your organization meets component-licensing terms. Violating the terms of an open source license is copyright or intellectual property infringement and can lead to legal and financial penalties. This white paper explains why certain types of open source licenses create legal risk and describes win-win methods for avoiding risk that give lawyers the confidence they need while giving developers the speed they need.
IRJET- Penetration Testing using Metasploit Framework: An Ethical ApproachIRJET Journal
This document discusses penetration testing using the Metasploit framework. It begins with an introduction to penetration testing and why it is important for ensuring system and network security. It then describes the phases of penetration testing: information gathering, vulnerability analysis, vulnerability exploitation, post exploitation, and report generation. Finally, it discusses using tools in the Metasploit framework like exploits and payloads to conduct penetration testing according to these phases and ethical approaches. The goal is to identify vulnerabilities before attackers can exploit them.
This document describes a web vulnerability scanner and reporting tool developed by researchers. The tool scans websites for various vulnerabilities like SQL injection, cross-site scripting, and file inclusion vulnerabilities. It performs scans both without login and with login credentials provided by the website owner. The without login scan checks if the site is reachable and identifies vulnerabilities, while the with login scan allows for deeper scanning. The tool uses machine learning, DOM, and aggregation algorithms. It produces a report with the number and types of vulnerabilities found, and URLs of affected pages. The researchers validated the tool and believe it can help developers identify and address security issues on their websites.
The document describes Swascan's cloud cyber security and GDPR compliance platform. The platform includes services like web app scanning, network scanning, and code review that identify vulnerabilities. It also provides compliance assessments and generates reports. The platform allows for both cloud-based and on-premise deployment. Swascan's competence center offers additional cybersecurity services including testing, threat management, and incident response.
Introduction to Web Application Penetration TestingNetsparker
These slides give an introduction to all the different things and stages that make a complete web application penetration test. It starts from the very basics, including how to define a Scope of Engagement.
These slides are part of the course Introduction to Web Application Security and Penetration Testing with Netsparker, which can be found here: https://www.netsparker.com/blog/web-security/introduction-web-application-penetration-testing/
The document discusses integrating security testing into the typical iterative development lifecycle through automated software tests at various stages, including unit tests, integration tests, and acceptance tests. It provides examples of using JUnit for unit testing and tools like Cactus, Selenium, and WATIR for integration and acceptance testing to validate valid/invalid inputs and test for vulnerabilities like SQL injection and cross-site scripting.
DELDroid: Determination & Enforcement of Least Privilege Architecture in AnDroidMahmoud Hammad
Android is widely used for the development and deployment of autonomous and smart systems, including software targeted for IoT and mobile devices. Security of such systems is an increasingly important concern.
Android relies on a permission model to secure the system's resources and apps. In Android, since the permissions are granted at the granularity of apps, and all components in an app inherit those permissions, an app's components are over-privileged, i.e., components are granted more privileges than they actually need. Systematic violation of least-privilege principle in Android is the root cause of many security vulnerabilities. To mitigate this issue, we have developed DELDroid, an automated system for determination of least privilege architecture in Android and its enforcement at runtime. A key contribution of DELDroid is the ability to limit the privileges granted to apps without modifying them. DELDroid utilizes static analysis techniques to extract the exact privileges each component needs. A Multiple-Domain Matrix representation of the system's architecture is then used to automatically analyze the security posture of the system and derive its least-privilege architecture. Our experiments on hundreds of real-world apps corroborate DELDroid's ability in effectively establishing the least-privilege architecture and its benefits in alleviating the security threats.
Software Birthmark Based Theft/Similarity Comparisons of JavaScript ProgramsSwati Patel
A birthmark is a set of characteristic possessed by a program that uniquely recognizes a program. Birthmark of the software is based on Heap Graph. It is generated by using Google Chrome Developer Tools when the program is in execution. Software’s behavioural structure is demonstrated in the heap graph. It describes how the objects are related to each other to deliver the desired functionality of the website. Our aim is to develop and evaluate a system that can find theft/similarity between websites by using Agglomerative Clustering and Improved Frequent Subgraph Mining. To identify if a website is using the original program’s code or its module, birthmark of the original program is explored in the suspected program’s heap graph.
The Log4Shell Vulnerability – explained: how to stay secureKaspersky
On December 9th, researchers uncovered a zero-day critical vulnerability in the Apache Log4j library used by millions of Java applications. CVE-2021-44228 or “Log4Shell” is a RCE vulnerability that allows attackers to execute arbitrary code and potentially take full control over an infected system. The vulnerability has been ranked a 10/10 on the CVSSv3 severity scale.
While the Apache Foundation has already released a patch for this CVE, it can take weeks or months for vendors to update their software, and there are already widespread scans being conducted by malicious attackers to exploit Log4Shell.
What should companies or organizations do?
Join Marco Preuss, Head of Europe’s Global Research and Analysis (GReAT) team, Marc Rivero and Dan Demeter, Senior Security Researchers with GReAT, for an in-depth discussion on Log4Shell and a live Q&A session.
To see the full webinar, please visit: https://securelist.com/webinars/log4shell-vulnerability-how-to-stay-secure/?utm_source=Slideshare&utm_medium=partner&utm_campaign=gl_jespo_je0066&utm_content=link&utm_term=gl_Slideshare_organic_s966w1tou5a0snh
The OWASP Top Ten is the de-facto web application security standard because it reflects the evolving threat landscape, providing organizations a framework to manage and mitigate application security risk.
This presentation examines the critical newcomers and pesky incumbents from both an offensive and defensive perspective. Our experts share their insight on how to harden Web applications and align your program towards OWASP compliance.
Secure Software Development with 3rd Party Dependenciesthariyarox
This document discusses securing software development with third party dependencies. It defines third party libraries and dependencies and explains how to identify direct and transitive dependencies of a project. It introduces tools like NVD, CVE, CVSS, and OWASP Dependency Check for finding vulnerabilities in dependencies. It emphasizes the need to regularly check dependencies for vulnerabilities and provides approaches for upgrading vulnerable dependencies, handling false positives and negatives, and integrating vulnerability management into the SDLC.
This is the slides of the presentation done in "WSO2 Jaffna: Integrating Security Into Software Development Life Cycle" http://www.meetup.com/wso2srilanka/events/233915649/
The document discusses the science behind runtime application self-protection (RASP) and interactive application security testing (IAST). It describes how RASP works by instrumenting application code to perform dynamic taint analysis, tracking tainted data from inputs and checking for policy violations at sinks like database queries. IAST similarly instruments code but also correlates runtime behavior with attacks to confirm vulnerabilities. The document outlines challenges with taint analysis like under-tainting causing false negatives or over-tainting causing false positives. Both RASP and IAST add overhead, and IAST also has limitations of traditional dynamic application security testing.
Hidden Speed Bumps on the Road to "Continuous"Sonatype
As a companion piece for our '2015 State of the Software Supply Chain Report' this ebook explores the hidden complexities in modern software development by drawing analogies to a traditional supply chain. This is a real eye-opener for anyone who cares about development speed, efficiency and quality.
Security testing involves testing software to identify security flaws and vulnerabilities. It is done at various stages of development, including unit testing by developers, integrated system testing of the full application, and functional acceptance testing by quality assurance testers. Security testing techniques include static analysis, dynamic testing, and fuzzing invalid or random inputs to expose unexpected behaviors and potential vulnerabilities. Thorough security testing requires checking for issues like SQL injection, unauthorized access, disclosure of sensitive data, and verifying proper access controls, authentication, encryption, and input validation. Various tools can assist with security testing.
Understanding & Addressing OWASP’s Newest Top Ten Threat: Using Components wi...Sonatype
In 2013, the Open Web Application Security Project (OWASP) was updated to include “A9: using components with known vulnerabilities.” This paper explains this new threat with practical ideas for reducing risk from open source components which now comprise 80% of an average application.
Static Detection of Application BackdoorsTyler Shields
The document discusses detecting application backdoors through static analysis of executable code. It defines application backdoors as versions of legitimate software modified to bypass security under certain conditions. The summary discusses three main types of application backdoors that can be detected through static analysis:
1) Special credentials - Detecting hardcoded or computed credentials not from the authentication store.
2) Unintended network activity - Finding network activity not intended in the software design.
3) Deliberate information leakage - Identifying code that leaks sensitive information.
Static analysis rules can inspect for these patterns and other malicious indicators like embedded shell commands, time bombs, and rootkit-like behavior. Well-known backdoor mechanisms can be ob
This document provides a checklist of secure coding practices for software developers. It covers topics such as input validation, output encoding, authentication, session management, access control, cryptography, error handling, data protection, and general coding practices. Implementing the practices in this checklist can help mitigate common software vulnerabilities and security issues. The document recommends defining security roles and responsibilities, providing training, and following a secure software development lifecycle model.
Application Security Guide for Beginners Checkmarx
The document provides an overview of application security concepts and terms for beginners. It defines key terms like the software development lifecycle (SDLC) and secure SDLC, which incorporates security best practices into each stage of development. It also describes common application security testing methods like static application security testing (SAST) and dynamic application security testing (DAST). Finally, it outlines some common application security threats like SQL injection, cross-site scripting, and cross-site request forgery and their potential impacts.
Using Analyzers to Resolve Security Problemskiansahafi
in this presentation i took a project and used an analyzer(e.g. SonarQube) to detect the security issues with it and reported a the result and after resolving most of those problems i used the same analyzer to get another report and in the process showed how to use such analyzers to detect security issues in the web applications
This document discusses the importance of mobile application security and penetration testing. It describes penetration testing as discovering vulnerabilities before attackers through vulnerability detection, comprehensive penetration attempts, and analysis/reporting. The document outlines static and dynamic analysis methods used for Android application security assessments. These include code review, function hooking, runtime debugging, and analyzing data at rest and in transit. It promotes understanding how applications work through reverse engineering, decompilation, and deobfuscation. The methodology uses tools like MARA, MobSF, Xposed, Frida, and BurpSuite.
This white paper includes all the basic things about Rootkit, how they work, their types, detection methods, their uses, the concept of payload, and rootkit removal.
Detection of vulnerabilities in programs with the help of code analyzersPVS-Studio
Static code analysis tools can help detect vulnerabilities by analyzing source code without executing the program. This document describes 16 such tools, including BOON for buffer overflows, CQual for format string vulnerabilities, MOPS for checking rule compliance, and ITS4, RATS, PScan, and Flawfinder for buffer overflows and format strings. While useful, static tools have limitations and cannot guarantee to find all vulnerabilities. Manual review is still needed to verify results.
International Journal of Engineering and Science Invention (IJESI) is an international journal intended for professionals and researchers in all fields of computer science and electronics. IJESI publishes research articles and reviews within the whole field Engineering Science and Technology, new teaching methods, assessment, validation and the impact of new technologies and it will continue to provide information on the latest trends and developments in this ever-expanding subject. The publications of papers are selected through double peer reviewed to ensure originality, relevance, and readability. The articles published in our journal can be accessed online.
Keyloggers are a invasive software often used to harvest secret information. One of the main reasons for
this fast growth is the possibility for unprivileged programs running in the user space to secretly steal and record all the
keystrokes typed by the users on a system. The ability to run in unprivileged mode makes possible their implementation
and distribution. but, at the same time, allows one to understand and imitate their behavior in detail.
This document outlines a proposed vulnerability assessment tool called Falcon. It discusses how vulnerability scanning can help organizations identify and remedy security vulnerabilities before hackers can exploit them. The tool would conduct thorough scans to find any gaps in a system's defenses. The document provides details on the tool's aims, introduction to cybersecurity and vulnerability scanning, proposed technical stack including Next JS, MongoDB, and Python, data flow diagrams, and the team working on the project.
The document discusses vulnerability scanning and OpenVAS. Vulnerability scanning involves using a scanner to identify security weaknesses. OpenVAS is an open source vulnerability scanning framework that consists of several services and tools for vulnerability scanning and management. At the center is the OpenVAS scanner which executes Network Vulnerability Tests (NVTs) from an NVT database that is regularly updated. The OpenVAS Manager receives tasks from the administrator and keeps a history of past scans.
If you want to make your career in ethical hacking, Bytecode Security offers the best malware analysis course online offline with job placement assistance. Read more: https://www.bytec0de.com/malware-analysis-course-training-certification/
This document describes Lastline's Deep Content Inspection technology for malware analysis. It provides full visibility into CPU instructions and memory that legacy sandboxes lack. This allows it to detect and bypass sophisticated evasion techniques used by advanced malware. In contrast, legacy sandboxes have limited visibility through OS APIs and common hypervisor approaches, and rely on signatures that malware can evade.
10 Tips to Keep Your Software a Step Ahead of the HackersCheckmarx
Checkmarx provides software security solutions to help organizations introduce security into their software development lifecycle. Their product allows developers and auditors to easily scan code for security vulnerabilities in major coding languages. The document provides 10 tips for keeping software secure, such as performing threat modeling, scrutinizing open source components and frameworks, treating security as part of the development process, and using whitelist input validation. To learn more about Checkmarx's products and services, contact their team.
Often the overall security of a software application is impacted due to loopholes in the operating systems, networks, system configuration, third-party services, or endpoints. The QA professionals perform penetration testing to identify the loopholes that make the software vulnerable to targeted security attacks by gaining access to the application’s features and data.
Source Code Audit in Application Development.pptxGROWEXX LTD
This document discusses the importance of conducting code audits to ensure software application compliance. It defines a code audit as a thorough examination of an application's source code to identify vulnerabilities, errors, or deviations from standards. The document then outlines the key steps in a code audit process, including defining compliance requirements, reviewing the codebase, checking authentication, assessing data handling, and documenting findings. Regular code audits can help identify and address potential compliance issues to protect applications and data.
The document discusses the 20 SANS Critical Security Controls, which provide guidelines for securing systems and networks. It summarizes several of the key controls, including maintaining an inventory of authorized and unauthorized devices and software, securely configuring hardware and software, continuous vulnerability assessment and remediation, and malware defenses. Implementing the controls involves using tools like DHCP logging, whitelisting applications, patch management, and network access control to monitor systems and remediate vulnerabilities. Following the SANS guidelines helps businesses effectively secure their networks and systems from evolving cyber threats.
This document provides an agenda for a presentation on comprehensive web application attacks. The presenter, Ahmed Sherif, has over 5 years of experience in penetration testing and web application security. The agenda includes an overview of security in corporations and web technologies, the OWASP security testing methodology, common web attacks like XSS and SQL injection, and a demo of these attacks. The goal is to educate attendees on how to identify and address vulnerabilities in web applications.
Similar to Blackhat Europe 2009 - Detecting Certified Pre Owned Software (20)
The New Mobile Landscape - OWASP IrelandTyler Shields
The document discusses threats to mobile devices and potential solutions. It outlines the mobile threat landscape including types of mobile malware, vulnerabilities, and statistics on infected platforms. It then examines players in the mobile ecosystem like MDM vendors, mobile anti-virus, application markets, and developers. Potential fixes are explored at the enterprise, consumer, vendor, and developer levels through capabilities mapping, malware detection, vulnerability analysis, and secure coding practices. The road ahead is seen through continued collaboration between these players and communities.
This document provides an overview and summary of mobile application risks. It begins with defining the mobile threat landscape, including statistics on the prevalence of Android malware. It then discusses the various types of mobile malware threats and behaviors. The document outlines vulnerabilities in mobile applications and ecosystems. It proposes approaches for securing the mobile environment, including static and dynamic behavioral analysis, malware detection, and vulnerability analysis. Finally, it discusses strategic control points for security and some enterprise solutions for mitigating risks of bring your own device policies.
This document summarizes key points about mobile application privacy based on an analysis of over 53,000 applications:
1) Many applications request unnecessary permissions like location tracking and SMS access without proper disclosure to users.
2) Code reuse through third party libraries introduces privacy risks as the libraries' data practices are often unknown.
3) Developers should securely store sensitive data, encrypt data in transit, analyze all reused code for flaws, and avoid hardcoded secrets to better protect user privacy.
This document discusses the rise of mobile, social, and cloud computing as a "new computing paradigm" that requires a new approach to security. It notes that traditional security methods like firewalls and relying on application permissions are no longer effective due to the decentralized and interconnected nature of modern applications and data. The document provides statistics on mobile application permissions and third-party libraries that indicate many apps are overprivileged and reuse code of unknown integrity. It argues that securing data as it flows between devices, networks, and services is now critical and that the only real defense is to secure all code through practices like secure development and verification.
Social Media Basics: Security Loopholes with Twitter & Other Social MediaTyler Shields
The document appears to be a syllabus for a course on social media security basics. It includes sections on definition of terms, risks, common attacks, and what can be done to protect yourself. Some common social media attacks mentioned are malware distribution, command and control of malware, compromise of sensitive data, social media worms like KoobFace that spread through messages/posts, targeted attacks, password/account hacking, and spam. The syllabus suggests users should avoid random links, use strong unique passwords, and not trust unsolicited messages. Vendors and enterprises are encouraged to implement better security practices while more research should be done on social media threats.
Shmoocon 2010 - The Monkey Steals the BerriesTyler Shields
The document outlines the technical details of mobile spyware targeting Blackberry devices. It describes common spyware programs, how they are installed, their behaviors like logging calls, texts and location, and how they exfiltrate data. It also reviews the technical methods used, like accessing APIs to dump contacts and record audio. Blackberry security mechanisms like code signing and policies are discussed, but many default policies allow broad permissions.
Survey of Rootkit Technologies and Their Impact on Digital ForensicsTyler Shields
This document discusses the history and evolution of rootkit technologies and their impact on digital forensics. It begins with defining rootkits as code used by attackers to surreptitiously execute and control systems while remaining undetected. The document then covers: (1) the origins and evolution of rootkits from modifying system binaries in the 1980s to more advanced techniques today, (2) the five classes of rootkits - application, library, kernel, firmware, and virtualized, and (3) how rootkits aim to hide themselves and impede forensic investigation, posing challenges for incident response.
Source Boston 2009 - Anti-Debugging A Developers ViewpointTyler Shields
The document discusses anti-debugging techniques, defining terms like debugging, anti-debugging, and dumping. It covers why anti-debugging is useful, references past work, and categorizes anti-debugging methods into classes like API based detection, process/thread blocking, hardware/register based detection, exception based detection, modified code based detection, and timing based detection. The goal is to make reversing applications more difficult by implementing multiple layers of defense.
Source Boston 2010 - The Monkey Steals the Berries Part DeuxTyler Shields
The document discusses mobile spyware, providing background information and case studies of existing spyware programs like FlexiSpy and Mobile Spy. It notes the increasing popularity of smartphones and mobile applications as a driver for more mobile spyware. Key points covered include motivation for attackers, installation methods, effects and behaviors of spyware, and challenges around detection.
Software Developers Forum 2010 - The Monkey Steals the BerriesTyler Shields
Malicious mobile applications can steal private user data, make unauthorized phone calls or SMS messages, and install additional malware. They may access location data, camera, contacts, and other sensitive resources without permission. Users are often unaware an app is malicious as attackers design apps to appear legitimate.
Raleigh ISSA 2010 - The Monkey Steals the BerriesTyler Shields
The document discusses mobile spyware, including case studies of FlexiSpy spyware which allows remote monitoring of SMS, calls, emails, and location on smartphones. It also provides statistics on mobile operating system and application market shares. The presenter's background in security research and consulting is provided.
The document discusses various techniques for anti-debugging, which aims to hinder reverse engineering or debugging of software. It describes six major categories of anti-debugging techniques: API-based, exception-based, direct process/thread detection, modified code detection, hardware/register-based detection, and timing-based detection. The document provides code examples for API-based techniques including IsDebuggerPresent(), CheckRemoteDebuggerPresent(), OutputDebugString(), and FindWindow() calls. The goal is to educate developers on implementing anti-debugging in their software.
Praetorian Veracode Webinar - Mobile PrivacyTyler Shields
The document discusses mobile application security risks and recommendations. It summarizes the OWASP Mobile Top 10 security risks, describes how static analysis can reveal vulnerabilities without executing code, and analyzes results from analyzing over 53,000 Android applications. Key findings include the high percentage of applications requesting permissions for location, contacts, and SMS/calling functions. Many applications shared third-party libraries for advertising and analytics. The document recommends users carefully review an app's permissions and author before installing and to use security monitoring applications.
Owasp Ireland - The State of Software SecurityTyler Shields
This document summarizes the key findings from an analysis of application security data by Veracode. Some of the main findings include:
1) Most software applications were found to be insecure, with over 50% receiving high or critical risk ratings.
2) Third-party software applications and components make up a significant percentage of enterprise infrastructure and applications, but were found to have the lowest security quality.
3) Open source projects had faster remediation times and fewer vulnerabilities than commercial or outsourced software.
The document discusses these and other findings around languages used, differences between industries, and the need for multiple testing techniques to adequately assess application security.
The document discusses risk and defines it as the possibility of loss or injury. It then discusses crowd sourcing security testing and outlines some of the current inadequate solutions such as expensive security consultants, tools that don't scale, and developers who prioritize functionality over security. The document then summarizes the results of analyzing over 53,000 Android applications, finding most request GPS and contact permissions and lists the top third party libraries used. It concludes by proposing a whitelisting approach to security testing using static analysis and an unbiased third party.
Dirty Little Secret - Mobile Applications Invading Your PrivacyTyler Shields
The document discusses privacy risks associated with mobile applications. It notes that applications can access personal data and device sensors through vulnerabilities or malicious code at the application, OS, hardware and network layers. It also discusses how the complexity of developing mobile applications across multiple teams and outsourcing parts of the development process makes it difficult to ensure application security. Finally, it provides an example case study of how static analysis was used to investigate privacy issues with the Pandora Radio mobile application.
IT Hot Topics - Mobile Security Threats at Every LayerTyler Shields
The document defines the term "risk" as the possibility of loss or injury. It then discusses various challenges with relying on internal teams, crowd sourcing, software vendors, developers, and processes alone to adequately manage security risks. The document proposes conducting static analysis of applications to create a whitelist of approved software that could then be enforced through mobile device policy as a potential solution to improve on current inadequate approaches.
IT Hot Topics 2010 - The Coming Wave of Smartphone AttacksTyler Shields
The document discusses the growing threat of smartphone attacks through mobile spyware, analyzing case studies of existing spyware programs like FlexiSpy and Mobile Spy that can track locations, read messages and calls, and more without the user's knowledge. It also outlines the security mechanisms of BlackBerry devices and how spyware can be installed, along with its potential effects and technical details, and ways to detect spyware and areas for future work.
iSec Forum NYC - Smartphone Backdoors an Analysis of Mobile SpywareTyler Shields
This document discusses smartphone backdoors and mobile device spyware. It begins by defining mobile spyware and how it is often inserted by those with access to source code or distribution binaries. It then covers the motivations of attackers in using mobile spyware such as retrieving private data from targets and maintaining access. The majority of the document analyzes the growing use of smartphones and mobile platforms as targets for spyware, using statistics on unit sales and application availability across platforms. It concludes by examining several case studies of existing mobile spyware programs and incidents.
How to Get CNIC Information System with Paksim Ga.pptxdanishmna97
Pakdata Cf is a groundbreaking system designed to streamline and facilitate access to CNIC information. This innovative platform leverages advanced technology to provide users with efficient and secure access to their CNIC details.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
Dr. Sean Tan, Head of Data Science, Changi Airport Group
Discover how Changi Airport Group (CAG) leverages graph technologies and generative AI to revolutionize their search capabilities. This session delves into the unique search needs of CAG’s diverse passengers and customers, showcasing how graph data structures enhance the accuracy and relevance of AI-generated search results, mitigating the risk of “hallucinations” and improving the overall customer journey.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
Let's Integrate MuleSoft RPA, COMPOSER, APM with AWS IDP along with Slackshyamraj55
Discover the seamless integration of RPA (Robotic Process Automation), COMPOSER, and APM with AWS IDP enhanced with Slack notifications. Explore how these technologies converge to streamline workflows, optimize performance, and ensure secure access, all while leveraging the power of AWS IDP and real-time communication via Slack notifications.
TrustArc Webinar - 2024 Global Privacy SurveyTrustArc
How does your privacy program stack up against your peers? What challenges are privacy teams tackling and prioritizing in 2024?
In the fifth annual Global Privacy Benchmarks Survey, we asked over 1,800 global privacy professionals and business executives to share their perspectives on the current state of privacy inside and outside of their organizations. This year’s report focused on emerging areas of importance for privacy and compliance professionals, including considerations and implications of Artificial Intelligence (AI) technologies, building brand trust, and different approaches for achieving higher privacy competence scores.
See how organizational priorities and strategic approaches to data security and privacy are evolving around the globe.
This webinar will review:
- The top 10 privacy insights from the fifth annual Global Privacy Benchmarks Survey
- The top challenges for privacy leaders, practitioners, and organizations in 2024
- Key themes to consider in developing and maintaining your privacy program
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Driving Business Innovation: Latest Generative AI Advancements & Success StorySafe Software
Are you ready to revolutionize how you handle data? Join us for a webinar where we’ll bring you up to speed with the latest advancements in Generative AI technology and discover how leveraging FME with tools from giants like Google Gemini, Amazon, and Microsoft OpenAI can supercharge your workflow efficiency.
During the hour, we’ll take you through:
Guest Speaker Segment with Hannah Barrington: Dive into the world of dynamic real estate marketing with Hannah, the Marketing Manager at Workspace Group. Hear firsthand how their team generates engaging descriptions for thousands of office units by integrating diverse data sources—from PDF floorplans to web pages—using FME transformers, like OpenAIVisionConnector and AnthropicVisionConnector. This use case will show you how GenAI can streamline content creation for marketing across the board.
Ollama Use Case: Learn how Scenario Specialist Dmitri Bagh has utilized Ollama within FME to input data, create custom models, and enhance security protocols. This segment will include demos to illustrate the full capabilities of FME in AI-driven processes.
Custom AI Models: Discover how to leverage FME to build personalized AI models using your data. Whether it’s populating a model with local data for added security or integrating public AI tools, find out how FME facilitates a versatile and secure approach to AI.
We’ll wrap up with a live Q&A session where you can engage with our experts on your specific use cases, and learn more about optimizing your data workflows with AI.
This webinar is ideal for professionals seeking to harness the power of AI within their data management systems while ensuring high levels of customization and security. Whether you're a novice or an expert, gain actionable insights and strategies to elevate your data processes. Join us to see how FME and AI can revolutionize how you work with data!
UiPath Test Automation using UiPath Test Suite series, part 5DianaGray10
Welcome to UiPath Test Automation using UiPath Test Suite series part 5. In this session, we will cover CI/CD with devops.
Topics covered:
CI/CD with in UiPath
End-to-end overview of CI/CD pipeline with Azure devops
Speaker:
Lyndsey Byblow, Test Suite Sales Engineer @ UiPath, Inc.
GraphSummit Singapore | The Art of the Possible with Graph - Q2 2024Neo4j
Neha Bajwa, Vice President of Product Marketing, Neo4j
Join us as we explore breakthrough innovations enabled by interconnected data and AI. Discover firsthand how organizations use relationships in data to uncover contextual insights and solve our most pressing challenges – from optimizing supply chains, detecting fraud, and improving customer experiences to accelerating drug discoveries.
GraphSummit Singapore | The Future of Agility: Supercharging Digital Transfor...Neo4j
Leonard Jayamohan, Partner & Generative AI Lead, Deloitte
This keynote will reveal how Deloitte leverages Neo4j’s graph power for groundbreaking digital twin solutions, achieving a staggering 100x performance boost. Discover the essential role knowledge graphs play in successful generative AI implementations. Plus, get an exclusive look at an innovative Neo4j + Generative AI solution Deloitte is developing in-house.
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
Maruthi Prithivirajan, Head of ASEAN & IN Solution Architecture, Neo4j
Get an inside look at the latest Neo4j innovations that enable relationship-driven intelligence at scale. Learn more about the newest cloud integrations and product enhancements that make Neo4j an essential choice for developers building apps with interconnected data and generative AI.
Programming Foundation Models with DSPy - Meetup SlidesZilliz
Prompting language models is hard, while programming language models is easy. In this talk, I will discuss the state-of-the-art framework DSPy for programming foundation models with its powerful optimizers and runtime constraint system.
Programming Foundation Models with DSPy - Meetup Slides
Blackhat Europe 2009 - Detecting Certified Pre Owned Software
1. Detecting “Certified Pre-owned” Software
Tyler Shields, Veracode
Chris Wysopal, Veracode
March 25, 2009
Introduction
Backdoors in software, whether maliciously inserted or carelessly introduced, are a risk
that should be detected prior to the affected software or system being deployed. We
call software and devices that come with malicious functionality built in, “Certified Pre-
Owned”.
Modern static analysis methods can detect many classes of common vulnerabilities.
Static analyzers do this by building a semantic model of the software which typically
includes control flow and data flow graphs. This model is then scanned for patterns
that typically lead to vulnerabilities such as buffer overflows. Static analysis methods
can also be targeted at detecting code that offers backdoor functionality to an attacker
who knows of its existence. Binary static analysis has the powerful capability of being
able to use static analysis techniques when source code is not available, which is the
typical case when a consumer is concerned about detecting a backdoor in a product
they have purchased.
Special credentials, hidden commands, and unintended information leakage are a few
of the types of application backdoors that have been discovered in commercial and
open source software. Rules can be created for a static analyzer to inspect for these
patterns. Rules can also be created that inspect for evidence that someone is hiding
functionality in software by looking for rootkit behavior and anti-debugging
functionality. If the analyzer finds these “anti-reverse engineering” patterns, further
inspection should be performed to determine what the software is hiding.
Technical Summary
Backdoors are a method of bypassing authentication or other security controls in order
to access a computer system or the data contained on that system. Backdoors can
exist at a number of different levels including the system level, in a cryptographic
algorithm, or within application code. We have concentrated on application backdoors
which are embedded within the code of a legitimate application. We define application
backdoors as versions of legitimate software modified to bypass security mechanisms
under certain conditions. These legitimate programs are meant to be installed and
running on a system with the full knowledge and approval of the system operator.
2. Application backdoors can result in the compromise of the data and transactions
performed by an application. They can also result in system compromise.
Application backdoors are often inserted in the code by someone who has legitimate
access to the code. Other times the source code or binary to an application is modified
by someone who has compromised the system where the source code is maintained or
the binary is distributed. Another method of inserting an application backdoor is to
subvert the compiler, linker, or other components in the development tool chain used
to create the application binary from the source code. Ken Thompson famously
performed this feat with his C compiler for UNIX. He modified it to insert a backdoor
into the UNIX login program whenever is compiled login.c.
Application backdoors are best detected by inspecting the source code or statically
inspecting the binary. It is impossible to detect most types of application backdoors
dynamically because they use secret data or functionality that cannot be adequately
tested for using only dynamic methods .
Application backdoor analysis is imperfect. It is impossible to determine the intent of
all application logic. Well known backdoor mechanisms can be heavily obfuscated and
novel mechanisms can certainly be employed. Another angle of detection is to look for
signs that the malicious actor is trying to hide their tracks with rootkit behavior, anti-
debugging and/or code and data obfuscation techniques.
In the past, backdoors in source code have been detected quickly while backdoors in
binaries often hide from detection for years. A survey of the last 15 years of discovered
backdoors bears this out. One famous backdoor that was in a program only available
in binary form was the “special credential” backdoor in Borland Interbase. A famous
open source backdoor was a modification attempted on the Linux kernel code. The
Linux kernel “uid=0” backdoor attempt was quickly discovered but the Borland
Interbase backdoor lasted for many years until the software was open sourced. In
general, backdoors in open source software tend to be discovered quickly while
backdoors in binaries can last for years.
For compiled software, a subverted development tool chain or compromised
distribution site requires binary analysis for backdoor detection since the backdoor
only exists after compilation or linking. In addition, modern development practices
often dictate the usage of frameworks and libraries where only binary code is available.
When backdoor reviews are performed at the source code level there are still
significant portions of the resultant software that are not getting reviewed. For these
reasons we have chosen to implement our static detection techniques on binary
executables.
By researching backdoors that have been discovered, it is possible to create rules for a
static analyzer to inspect for backdoor behavior. One such example is a “special
credential” back door. This is when the software has a special username, password,
3. password hash, or key that is embedded within the software. If an attacker knows that
special credential they can authenticate to the software no matter what the contents of
the authentication store. A static analyzer can inspect the cryptographic functions
that are used by the authentication routine and the data flow graph that connects to
these function calls. A special credential can be detected by looking for static or
computed values that do not come from the authentication store yet allow
authentication.
There are several categories of application backdoors which can be detected using
automated static analysis:
• Special credentials
• Unintended network activity
• Deliberate information leakage
Other constructions in the code that indicate that a backdoor or other malicious code
may be present can also be detected statically. These include:
• Embedded Shell Commands
• Time Bombs
• Rootkit-like Behavior
• Code or Data Anomalies
• Self-modifying Code
• Anti-debugging
Looking for Backdoor Indicators
In this paper we will concentrate on looking for indicators that the software is trying to
hide its behavior from dynamic run time detection.
Two categories of backdoor indicators that are designed to evade detection by run
time analysis are rootkit behavior and anti-debugging. Rootkit behavior modifies the
functionality of the operating system the software is running on so that
instrumentation and system administration tools cannot detect the existence of a
backdoor. An example of rootkit behavior is a backdoor that opens up a network port
listening for incoming connections and also modifies the operating system functions
that enumerate all listening network ports. Anti-debugging is an approach that makes
runtime inspection of the running code more difficult. If the software containing the
backdoor can stop a debugger from single stepping through the code or inspecting
4. internal data structures it makes it difficult to determine if the software has unwanted
backdoor functionality at execution time.
One of the solutions to this challenge we propose is to look directly for the code that
implements the anti-debugging or rootkit behavior using static analysis.
Rootkit Behavior
The following section details common techniques that rootkits use to hide their
behavior from the instrumentation a reverse engineer or system administrator might
use. These techniques include: DLL injection, IAT hooking, and Inline function
hooking. A scan rule can be created for each of the following coding patterns such
that a static analyzer can search for the pattern in the code.
Windows DLL Injection
DLL Injection can be used for many legitimate purposes; however its usage is a red flag
that should cause the application metadata to be analyzed. If the scanned application
is intended to inject DLLs into external processes then there is a chance these are false
positive returns; however if the scanned application should not be executing DLL
injection of any manner, positive hits on these scan tests are highly likely to be
indicative of a userland rootkit or subversive function.
Via the Registry
Injecting a DLL into a target process can be achieved via modification of a registry
entry. A static analysis engine needs to flag any registry modifications to the following
key:
HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWindows
AppInit_DLLs = *
This key will load a DLL into all processes as they are created. An attacker would use
this to hook function calls in injected processes. This requires a reboot to affect all
processes; however as soon as the key is modified, all future processes will be
impacted.
Modification of this registry key can be accomplished via calls to RegCreateKey,
RegCreateKeyEx, RegLoadKey, and RegOpenKey followed by RegSetValueEx. Static
engine detection should detect modification to the specific registry keys using any of
the above stated functions.
Using Windows Hooks
It is also possible to inject a DLL via windows hook calls. The call SetWindowsHookEx
will hook a target process and load a DLL of our choosing into the target process. This
DLL could then hook the IAT or execute inline hooking as desired.
5. HHOOK SetWindowsHookEx
{
int idHook,
HOOKPROC lpfn,
HINSTANCE hMod,
DWORD dwThreadId
};
For example:
myDllHandle = Rootkit DLL
SetWindowsHookEx(WH_KEYBOARD, myKeyBrdFuncAd, myDllHandle, 0)
Rootkit DLL has the myKeyBrdFuncAd defined and written.
Using Remote Threads
It is possible to inject a DLL into a target process by creating and using remote
threads. First we programmatically find the process ID of the target process by using
the OpenProcess call. We then allocate some memory in the target process for our
thread via VirtualAllocEx and then write our DLL name into the target process memory
space. Finally we create a remote thread by calling the CreateRemoteThread with the
PID and memory location of our injected DLL name and a reference to the LoadLibraryA
function.
PID = OpenProcess(DWORD dwDesiredAccess, BOOL bInheritHandle, DWORD
dwProcessId);
// This is used to find the PID of our target process
ADDRESS = GetProcAddress(GetModuleHandle(TEXT( "Kernel32")), "LoadLibraryA");
// This is used to find the address of LoadLibraryA in our current process. We assume
that
// the base is the same in our target thus keeping the function location the same.
BASEAD = VirtualAllocEx(PID, NULL, len_of_our_dll_name_string, MEM_COMMIT |
MEM_RESERVE, PAGE_READWRITE)
// The above allocates some memory in our target process
WriteProcessMemory(PID, BASEAD, Pointer to BUF containing "c:pathtoourdll", size,
NULL)
CreateRemoteThread(PID, NULL, 0, ADDRESS, BASEAD, 0, NULL)
DLL injection simply injects the DLL, it does not actually execute the IAT or inline hook.
An example DLL that we could use with the injection techniques outlined in this section
is below.
6. Thread Suspend and Hijack
It is also possible to inject a DLL by directly modifying the thread execution of a
process and injecting data of our choosing. To execute this injection the attacker first
must pick a process and walk the threads of the process by using calls to
CreateToolhelp32Snapshot, Thread32First, and Thread32Next. Once the target thread
has been determined, the attacker suspends the handle that was acquired by executing
a call to SuspendThread.
After the target thread has been suspended, a call to VirtualAllocEx followed by
WriteProcessMemory occurs. Using these two calls we write a small section of assembly
code to our allocated memory within the suspended target thread. This assembly code
executes the LoadLibraryA function and looks like the following:
pushfd; push EFLAGS
pushad; push general purpose registers
push &<dll_path>; push the address of the DLL path string we have already injected
call LoadLibraryA; call the LoadLIbraryA function.
popad; pop the general purpose registers
popfd; pop EFLAGS
jmp Original_Eip; resume execuation at the original EIP value
The dll_path value is dependent upon the return results of VirtualAllocEx and where
the data is written to memory. The same is true for the original EIP value. These two
values should be programmatically determined when the injection is being made.
Triggering our injected payload occurs by direct modification of the EIP register of the
remote thread to point to the address of our injected code. Next a call to
SetThreadContext makes the change to the EIP permanent. Finally we tell the system to
resume the thread via ResumeThread.
Sample DLL for IAT/Inline Injection
BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID
lpReserved)
{
if (ul_reason_for_call == DLL_PROCESS_ATTACH)
{
// EXECUTE THE IAT OR INLINE HOOK HERE
}
return TRUE:
}
__declspec (dllexport) LRESULT myKeyBrdFuncAd (int code, WPARAM wParam, LPARAM
lParam)
7. {
return CallNextHookEx(g_hhook, code, wParam, lParam)
}
Windows Userland Rootkits
Windows userland based rootkits target the hooking and modification of processes in
ring three. By not having a requirement to go to a lower operating level, such as ring
one, these are the simplest forms of rootkit technologies that can be implemented.
Static detection of userland process modifications target specific sequences of calls
that are indicative of the existence of a hooking utility or rootkit. Each method below
outlines the API calls that should be identified and flagged on when using a static
analysis engine for the detection of these types of activities.
IAT Hooking
IAT hooking is the modification of the Import Address Table for a binary that has been
loaded into memory. This is typically done by injecting a DLL into the running process
and executing the IAT modification code in the context of the target process. The code
first locates the IAT table within the loaded image by using the following reference:
(IMAGE_DOS_HEADER->e_lfanew)->OptionalHeader-
>DataDirectory[IMAGE_DIRECTORY_ENTRY_IMPORT]
// This is using the image base as a starting reference point and the other values as
offsets.
Once the reference to the IAT is discovered, code is used to walk the IAT table entries
until the entry that matches the function we would like to patch is discovered. At this
point we execute the following code to unlock the memory protections of the segment
of memory we will be modifying, overwrite the target function pointer, and then revert
the memory protections that were originally in place.
/* Unlock read only memory protection */
VirtualProtect((LPVOID)(&pIteratingIAT-
>u1.Function),sizeof(DWORD),PAGE_EXECUTE_READWRITE,&dwProtect);
/* OVERWRITE API address! :) */
(DWORD*)pIteratingIAT->u1.Function = (DWORD*)pApiNew;
/* Restore previous memory protection */
VirtualProtect((LPVOID)(&pIteratingIAT-
>u1.Function),sizeof(DWORD),dwNewProtect,&dwProtect);
To detect IAT hooking we should identify any reference to the IAT structure noted
above that is followed by memory unprotect, write, and re-protect code. Alternate
code to unprotect and re-protect memory is demonstrated within the SSDT hooking
portion of this document. This is interchangeable with the above VirtualProtect, write,
8. VirtualProtect method above. Static analysis should check for both moethods in all
places where one is used.
Inline Function Hooking (Runtime Patching)
Runtime patching is the modification of the function to be called directly in memory. By
runtime patching an exported library call, the execution of that call can be subverted
and arbitrary code of our choosing executed in its place. Runtime patching modifies
the first bytes of the destination function, typically with a jmp instruction, while saving
the original bytes for later use. The first bytes of the target function are modified to
jmp to a function of our choosing within our injected DLL. Upon completion of the
rerouted function, we call the saved bytes and execute a jmp back to the subverted
function plus the appropriate offset of our injected bytes.
The most direct method of detection for this type of rootkit activity is to check for the
existence of a function that is declared (naked), meaning no epilog and prolog will
exist around the function, which ends in a jmp statement. Standard functions will have
epilog and prolog data surrounding the function within the disassembly; however to be
able to properly insert our function we would have to end the function without a prolog
and on a jmp statement such that the function would properly return to the original
hijacked function call.
__declspec(naked) my_function_detour_ntdeviceiocontrolfile()
{
__asm
{
//exec missing instructions
push ebp
mov ebp, esp
push 0x01
push dword prt [ebp+0x2c]
// do anything we want here
// end on a jmp statement to jump back to the original
// functionality. The address is stamped in later by the rootkit
_emit 0xEA
_emit 0xAA
_emit 0xAA
_emit 0xAA
_emit 0xAA
_emit 0x08
_emit 0x00
}
}
As a point of interest, it should be noted that this is the same method that the
Microsoft Detours API package utilizes when creating its inline hooks. This type of
detection should work against the MS Detours API by default.
9. Anti-Debugging
Anti-debugging is the implementation of one or more techniques within computer
code that hinders attempts at reverse engineering or debugging a target binary. These
techniques are used by commercial executable protectors, packers, and malicious
software, to prevent or slow-down the process of reverse-engineering. Out static
analysis engine has implemented scans for generic and targeted anti-debugging and
anti-tracing techniques as outlined below.
API
The most straightforward method of anti-debugging uses operating system provided
API functions to determine the existence or operation of a debugger. Some of the API
calls are documented features provided by the operating system itself, while others are
unpublished functions that can be linked at runtime from various system DLL files.
Occasionally it is difficult to align a particular anti-debugging technique with only one
class so some overlap between classes may exist.
IsDebuggerPresent Windows API
The IsDebuggerPresent API call checks to see if a debugger is attached to the running
process. This is a Windows specific API call that checks the process environment block
(PEB) for the PEB!BeingDebugged flag and returns its value.
if (IsDebuggerPresent()) {
MessageBox(NULL, L"Debugger Detected Via IsDebuggerPresent", L"Debugger
Detected", MB_OK);
}
CheckRemoteDebuggerPresent Windows API
The CheckRemoteDebuggerPresent API call takes two parameters. The first parameter
is a handle to the target process while the second parameter is a return value
indicating if the target process is currently running under a debugger. The word
“remote” within CheckRemoteDebuggerPresent does not require that the target process
be running on a separate system. The API call uses a call to ntdll!
NtQueryInformationProcess with ProcessInformationClass set to ProcessDebugPort.
CheckRemoteDebuggerPresent(GetCurrentProcess(), &pbIsPresent);
if (pbIsPresent) {
MessageBox(NULL, L"Debugger Detected Via CheckRemoteDebuggerPresent",
L"Debugger Detected", MB_OK);
}
OutputDebugString on Win2K and WinXP
The function OutputDebugString operates differently based on the presence of a
debugger. The return error message can be analyzed to determine if a debugger is
10. present. If a debugger is attached, OutputDebugString does not modify the
GetLastError message.
DWORD AnythingButTwo = 666;
SetLastError(AnythingButTwo);
OutputDebugString(L"foobar");
if (GetLastError() == AnythingButTwo) {
MessageBox(NULL, L"Debugger Detected Via OutputDebugString", L"Debugger
Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected",
MB_OK);
}
FindWindow
OllyDbg by default has a window class of "OLLYDBG". This can be detected using a
function call to FindWindow with a first parameter of "OLLYDBG". WinDbg can be
detected with an identical method instead searching for the string WinDbgFrameClass.
HANDLE ollyHandle = NULL;
ollyHandle = FindWindow(L"OLLYDBG", 0);
if (ollyHandle == NULL) {
MessageBox(NULL, L"OllyDbg Not Detected", L"Not Detected", MB_OK);
} else {
MessageBox(NULL, L"Ollydbg Detected Via OllyDbg FindWindow()", L"OllyDbg
Detected", MB_OK);
}
OllyDbg OpenProcess HideDebugger Detection
The "Hide Debugger" plugin for OllyDbg modifies the OpenProcess function at offset
0x06. The plugin places a far jump (0xEA) in that location in an attempt to hook
OpenProcess calls. This can be detected programmatically and acted upon.
hMod = GetModuleHandle(L"kernel32.dll");
procAdd = (void*) GetProcAddress(hMod, "OpenProcess");
ptr = (byte *)procAdd;
ptr = ptr + 0x06; // Offset to the byte modified by HideDebugger Plugin
if (*ptr == 0xea) {
MessageBox(NULL, L"Debugger Detected Via 0xEA Olly Hide Debugger Check",
L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
11. Debugger Registry Key Detection
This is a very basic check to determine if there is a debugger installed on the system.
This does not determine if the debugger is currently running. This technique can be
used to assist other anti-debugging methods by adding an additional data point to
previously existing heuristics.
if (RegOpenKeyEx(HKEY_LOCAL_MACHINE, L"SOFTWAREMicrosoftWindows NT
CurrentVersionAeDebug", 0, KEY_QUERY_VALUE, &hKey)==0) {
RegQueryValueEx(hKey, L"Debugger", 0, NULL, (LPBYTE)&lpData, &BufferSize);
}
if (RegOpenKeyEx(HKEY_CLASSES_ROOT, L"exefileshellOpen with Olly&Dbg
command", 0, KEY_QUERY_VALUE, &hKey)==0) {
RegQueryValueEx(hKey, NULL, 0, NULL, (LPBYTE)&lpData, &BufferSize);
}
if (RegOpenKeyEx(HKEY_CLASSES_ROOT, L"dllfileshellOpen with Olly&Dbg
command", 0, KEY_QUERY_VALUE, &hKey)==0) {
RegQueryValueEx(hKey, NULL, 0, NULL, (LPBYTE)&lpData, &BufferSize);
}
NtQueryInformationProcess ProcessDebugPort Detection
The NtQueryInformationProcess function is located within ntdll.dll. A call to this
function using a handle to our currently running process and a
ProcessInformationClass value of ProcessDebugPort (7) will return the debugging port
that is available. If the returned value is zero, no debugging port is available and the
process is not being debugged. If a value if returned via this function, the process is
currently being debugged.
hmod = LoadLibrary(L"ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");
status = (_NtQueryInformationProcess) (-1, 7, &retVal, 4, NULL);
printf("Status Code: %08X - DebugPort: %08X", status, retVal);
if (retVal != 0) {
MessageBox(NULL, L"Debugger Detected Via NtQueryInformationProcess
ProcessDebugPort", L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected",
MB_OK);
}
OllyDbg Filename Format String
OllyDbg contains a flaw where it crashes if the name of the file that is being opened
contains a value of %s. Putting a %s in our filename will stop Ollydbg from functioning.
12. Thus we can create a file with a “%s” string in the name and within our code we check
that our name has not changed. If it has changed we can safely assume that someone
is trying to debug our file with OllyDbg.
GetModuleFileName(0, (LPWCH) &pathname, 512);
printf("Filename: %ls", pathname);
filename = wcsrchr(pathname, L'');
if (wcsncmp(filename, L"%s%s.exe", 9) == 0) {
MessageBox(NULL, L"No Debugger Detected - Original Name Found", L"No
Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"Debugger Detected - File Name Modification Occured",
L"Debugger Detected", MB_OK);
}
OllyDbg IsDebuggerPresent Detection
Many anti-anti-debugging plugins for OllyDbg (and other debuggers) will hook the
IsDebuggerPresent function call so that they can always return a value indicating false.
This effectively bypasses generic IsDebuggerPresent antidebugging techniques. An
attack against this hooking method is to set the PEB!BeingDebugged byte to an
arbitrary value and then call IsDebuggerPresent. If the request does not return your
arbitrary value, you know that something has hooked that function call and returned a
modified response.
status = (_NtQueryInformationProcess) (hnd, ProcessBasicInformation, &pPIB,
sizeof(PROCESS_BASIC_INFORMATION), &bytesWritten);
if (status == 0) {
pPIB.PebBaseAddress->BeingDebugged = 0x90;
}
OllyDbg OpenProcess String Detection
OllyDbg has a static string at offset 0x004B064B that contains the value 0x594C4C4F.
It's possible to enumerate all processes and walk them looking for this static string at
this offset in all processes. If the string is present we know we have a running OllyDbg
process on the system.
if (ReadProcessMemory(hProcess, 0x4B064B, &value, (SIZE_T) 4, &read)) {
...
if (value == 0x594C4C4F) {
...
13. NtSetInformationThread Debugger Detaching
By calling NtSetInformationThread with a ThreadInformationClass of 0x11 it is possible
to detach our current thread from any attached debugger.
lib = LoadLibrary(L"ntdll.dll");
_NtSetInformationThread = GetProcAddress(lib, "NtSetInformationThread");
(_NtSetInformationThread) (GetCurrentThread(), 0x11, 0, 0);
kernel32!CloseHandle Debugger Detection
The CloseHandle call generates a STATUS_INVALID_HANDLE exception if passed an
invalid handle value. This exception will be trapped by the debugger and can be used
by a program to determine if it is running inside of a debugger.
__try {
CloseHandle(0x12345678);
}
__except (EXCEPTION_EXECUTE_HANDLER) {
flag = 1;
MessageBox(NULL, L"Debugger Detected via kernel32!CloseHandle", L"Debugger
Detected", MB_OK);
}
if (flag == 0) MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
Self-Debugging
A process can determine if it is being debugged by attempting to debug itself. This is
done by creating a child process which then attempts to debug its parent. If the child is
not able to attach to the parent as a debugger, it is a strong indicator that our process
is being run under a debugger.
pid = GetCurrentProcessId();
_itow_s((int)pid, (wchar_t*)&pid_str, 8, 10);
wcsncat_s((wchar_t*)&szCmdline, 64, (wchar_t*)pid_str, 4);
success = CreateProcess(path, szCmdline, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);
...
success = DebugActiveProcess(pid);
if (success == 0) {
printf("Error Code: %dn", GetLastError());
MessageBox(NULL, L"Debugger Detected - Unable to Attach", L"Debugger
Detected", MB_OK);
}
if (success == 1) MessageBox(NULL, L"No Debugger Detected", L"No Debugger",
MB_OK);
14. ProcessDebugFlags
A call to NtQueryInformationProcess with a second parameter of 31
(ProcessDebugFlags Enum) will return a DWORD indicating if the target process is
being debugged. This request returns the inverse of the flag and thus if a 0 is
returned, our process is being debugged.
hmod = LoadLibrary(L"ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");
status = (_NtQueryInformationProcess) (-1, 31, &debugFlag, 4, NULL); // 31 is the
enum for ProcessDebugFlags
ProcessDebugObjectHandle
Just like the DebugProcessFlags method, a call to NtQueryInformationProcess with a
second parameter of 0x1e will return a handle to the DebugObject if and only if the
target process is being debugged. We can use this to determine the debugging status
of a target process and act accordingly.
OllyDbg OutputDebugString Format String Vulnerability
OllyDbg has a format string vulnerability in the handling of OutputDebugString values.
It's possible to crash OllyDbg by executing OutputDebugString(TEXT("%s%s%s%s%s%s%s
%s%s%s%s").
__try {
OutputDebugString(TEXT("%s%s%s%s%s%s%s%s%s%s%s"), TEXT("%s%s%s%s%s%s%s
%s%s%s%s"), TEXT("%s%s%s%s%s%s%s%s%s%s%s"), TEXT("%s%s%s%s%s%s%s%s%s%s%s") );
}
__except (EXCEPTION_EXECUTE_HANDLER) {
printf("Handled Exceptionn");
}
return;
Exception
Many times a debugger will handle exceptions on behalf of a piece of code and then
not properly hand the exception back to the process for internal handling. This
exception handling discrepancy can be detected and acted upon. By triggering
exceptions that are caught by debuggers our process can determine if its internal
exception handler was triggered thus revealing the presence of an attached debugger.
INT 2D Debugger Detection
The debugging interface is accessed by "INT 2d". To convey the service request to the
kernel debugger, the trap handler for "INT 2d" constructs an EXCEPTION_RECORD
structure with an exception code of STATUS_BREAKPOINT. This exception is ultimately
handed to the kernel debugger. We can use this same interrupt call from ring 3 to
15. trigger an exception. If the application exception occurs, we are not running under a
debugger; however if the exception triggers we can be sure that a debugger is present.
Additionally, INT 2D can be used as obfuscation of code when being run in a debugger.
Depending on the particular debugger in use, it may or may not execute the
instruction directly following the INT 2D call.
OllyDbg - run until next breakpoint (if we have any)
Visual Studio - skips one instruction then breaks
WinDbg - stop after INT 2d (always even if we 'Go')
__try {
__asm {
int 2dh;
}
}
__except (EXCEPTION_EXECUTE_HANDLER) {
flag = 1;
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
if (flag != 1) MessageBox(NULL, L"Debugger Detected via int2d", L"Debugger Detected",
MB_OK);
To detect this type of construct a static analysis engine would have toflag on any inline
asm call to INT 2d. Inline asm calls to INT 2d are generally not used in standard coding
practices and should have a relatively low rate of false positive identification.
INT3 Exception Detection
If a process that is not running in a debugger triggers an INT 3, an exception will be
thrown. However, if the process is running under a debugger, the debugger will
capture the INT 3 call and the exception will never occur. Using this discrepancy it is
possible to detect if a process is running inside of a debugger.
int flag = 0;
__try {
__asm {
int 3;
}
}
__except (EXCEPTION_EXECUTE_HANDLER) {
flag = 1;
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
if (flag == 0) MessageBox(NULL, L"Debugger Detected Via Int3", L"Debugger Detected",
MB_OK);
16. Single Step Detection
If the Trap Flag is set within the thread context, the SEH will be called prior to the
instruction occurring. By enabling the Trap Flag we can detect the presence of the SEH
being fired to accurately determine if the process is running under a debugger.
//Set the trap flag
__try {
__asm {
PUSHFD; //Saves the flag registers
OR BYTE PTR[ESP+1], 1; // Sets the Trap Flag in EFlags
POPFD; //Restore the flag registers
NOP; // NOP
}
}
OllyDbg Memory Breakpoint Detection
OllyDBG interprets PAGE_GUARD as a Memory break-point. Thus if we execute a
PAGE_GUARDED page a code exception will occur. If the debugger is present it will trap
this as a break point and continue executing code after it. If there is no debugger
present we will catch the exception in code and handle it appropriately via the SEH.
memRegion = VirtualAlloc(NULL, 0x10000, MEM_COMMIT, PAGE_READWRITE);
RtlFillMemory(memRegion, 0x10, 0xC3);
success = VirtualProtect(memRegion, 0x10, PAGE_EXECUTE_READ | PAGE_GUARD,
&oldProt);
myproc = (FARPROC) memRegion;
success = 1;
__try {
myproc();
}
__except (EXCEPTION_EXECUTE_HANDLER) {
success = 0;
MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected",
MB_OK);
}
Ctrl-C Vectored Exception Handling
When a console program is being debugged, a Ctrl-C command will throw an
exception that can be trapped by a vectored exception handler. If the program is not
being debugged, no exception is thrown and only a signal handler will be called. We
can detect this by registering both a signal handler for Ctrl-C as well as a vectored
exception handler. If the exception handler is triggered we are running under a
17. debugger otherwise we are not. This does not work against OllyDbg. Visual Studio
debugger is susceptible.
AddVectoredExceptionHandler(1, (PVECTORED_EXCEPTION_HANDLER)exhandler);
SetConsoleCtrlHandler((PHANDLER_ROUTINE)sighandler, TRUE);
success = GenerateConsoleCtrlEvent(CTRL_C_EVENT, 0);
ICE Breakpoint 0xF1
An undocumented opcode within the Intel chipset is the 0xF1 or ICE Breakpoint. This
opcode causes a breakpoint to occur that triggers a SINGLE_STEP exception. If this
opcode is run while under a debugger, the debugger will trap the exception and not
pass it on to the exception handler. If the exception handler receives the opcode
directly we are not running in a debugger.
__try {
__asm {
__emit 0xF1; // ICE BREAKPOINT
}
}
__except (EXCEPTION_EXECUTE_HANDLER) {
flag = 1;
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
if (flag == 0) MessageBox(NULL, L"Debugger Detected via ICE Breakpoint", L"Debugger
Detected", MB_OK);
Prefix Handling
In place inline asm instruction prefixes may be skipped when single stepping with a
debugger. If we emit a REP instruction followed by a breakpoint instruction the single
stepping debugger will skip the breakpoint instruction. This can be trapped and
handled with a SEH.
__try {
__asm {
__emit 0xF3; // 0xF3 0x64 is PREFIX REP:
__emit 0x64;
__emit 0xF1; // Break that gets skipped if single stepping
}
}
__except (EXCEPTION_EXECUTE_HANDLER) {
flag = 1;
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
Using the CMPXCHG8B with the LOCK Prefix
The LOCK prefix, when used with CMPXCHG8B is considered an invalid lock and will
cause a debugger to catch an invalid instruction exception. This call will cease
18. debugging; however an Unhandled Exception Handler will be able to gracefully
continue code execution when executed outside of a debugger.
SetUnhandledExceptionFilter((LPTOP_LEVEL_EXCEPTION_FILTER) error);
__asm {
__emit 0xf0;
__emit 0xf0;
__emit 0xc7;
__emit 0xc8;
}
Process and Thread Blocks
Some of the API based anti-debugging methods outlined above have equivalent
techniques that can be executed by directly accessing the process and thread block
data. The process and thread block data holds information pertinent to the execution
of the particular process or thread that is used by the operating system.
IsDebuggerPresent Direct PEB Access
A flag is kept within the process environment block (PEB) for the currently running
process that indicates if the process is running under a debugger. This can be detected
by looking at the PEB for our process and analyzing the DebuggerPresent element of
the structure.
hmod = LoadLibrary(L"Ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");
hnd = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId());
status = (_NtQueryInformationProcess) (hnd, ProcessBasicInformation, &pPIB,
sizeof(PROCESS_BASIC_INFORMATION), &bytesWritten);
if (status == 0 ) {
if (pPIB.PebBaseAddress->BeingDebugged == 1) {
MessageBox(NULL, L"Debugger Detected Using PEB!IsDebugged",
L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected",
MB_OK);
}
}
NtGlobalFlag Debugger Detection
The PEB structure holds flags at offset 0x68 that contains information regarding the
start status of the process. When a process is started under a debugger, the flags
FLG_HEAP_ENABLE_TAIL_CHECK (0x10), FLG_HEAP_ENABLE_FREE_CHECK(0x20), and
FLG_HEAP_VALIDATE_PARAMETERS(0x40) are set for the process, and we can use this
19. to our advantage to identify if our process is being debugged. It is possible to detect
the value located at offset 0x68 in the PEB and act accordingly.
hmod = LoadLibrary(L"Ntdll.dll");
_NtQueryInformationProcess = GetProcAddress(hmod, "NtQueryInformationProcess");
hnd = OpenProcess(PROCESS_QUERY_INFORMATION, FALSE, GetCurrentProcessId());
status = (_NtQueryInformationProcess) (hnd, ProcessBasicInformation, &pPIB,
sizeof(PROCESS_BASIC_INFORMATION), &bytesWritten);
value = (pPIB.PebBaseAddress);
value = value+0x68;
printf("FLAG DWORD: %08Xn", *value);
if (*value == 0x70) {
MessageBox(NULL, L"Debugger Detected Using PEB!NTGlobalFlag", L"Debugger
Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger Detected",
MB_OK);
}
return;
PEB ProcessHeap Flag Debugger Detection
When a process is started under a debugger, the heap headers are created differently
than when it is run without a debugger present. As the above PEB analysis method
indicates, there are specific flags set that manipulate how ntdll.dll creates heaps.
Looking at a heap header at offset 0x10 will indicate if the heap has been created while
in a debugger or not. If the heap was created under a debugger, the offset at 0x10 will
be a nonzero value.
base = (char *)pPIB.PebBaseAddress;
procHeap = base+0x18;
procHeap = *procHeap;
heapFlag = (char*) procHeap+0x10;
last = (DWORD*) heapFlag;
Vista TEB system dll pointer
When a process is created without being under a debugger in Vista, the main thread
environment block (TEB) (at offset 0xBFC) contains a pointer to a Unicode string
referencing a system DLL. The string directly follows the pointer at 0xC00. If the
process is debugged, the Unicode string equals "HookSwitchHookEnabledEvent".
wchar_t *hookStr = _TEXT("HookSwitchHookEnabledEvent");
TIB = getTib();
// Function to gather a TEB pointer (Can use API or inline asm)
strPtr = TIB+0xBFC; // Offset into the target structure
20. delta = (int)(*strPtr) - (int)strPtr; // Ensure that string directly follows pointer
if (delta == 0x04) {
if (wcscmp(*strPtr, hookStr)==0) { // Compare to our known bad string
MessageBox(NULL, L"Debugger Detected Via Vista TEB System DLL PTR",
L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
LDR_MODULE
When a process is created from within a debugger, the heap allocation routines append
a hex DWORD of 0xEEFEEEFE to the end of the memory space. This can be detected by
looking at the LDR_MODULE section pointer to by the PEB as it is allocated using the
heap when a process is started.
__try {
while (*ldr_module != 0xEEFEEEFE) {
printf("Value at pointer: %08Xn", *ldr_module);
walk = walk +0x01;
ldr_module = walk;
}
}
Size Based Anti Dumping
When a PE executable file is loaded into memory, the header of the process (PE Header)
contains a value indicating the size of the image in memory. Dumping programs such
as LordPE and ProcDump use this information to determine the length of the process in
memory when attempting to dump the image. Since this information is not used by the
binary itself to execute, it is possible to fool dumping applications into the thinking the
image is larger or smaller than it is. The result is that the dumping application may
crash or dump an otherwise inoperable binary to disk from memory.
PIMAGE_DOS_HEADER image_addr;
PIMAGE_DOS_HEADER dosHeader;
PIMAGE_NT_HEADERS pNTHeader;
...
pNTHeader->OptionalHeader.SizeOfImage = sizeOfImage + 0x3000;
Registers
CPU hardware registers contain information that can aid debugging processes. These
hardware breakpoints rely upon registers internal to the CPU to hold address and
trigger data and to respond when certain addresses are discovered on the bus.
21. Hardware Breakpoint Detection
There are two different types of breakpoints, software and hardware breakpoints. When
a hardware breakpoint is set the CPU debug registers are used to hold the specific
breakpoint information. DR0-DR3 holds the address that is used to break the program
execution while DR7 holds context information about the breakpoints in DR0-DR3. We
can access these debug registers via the GetThreadContext() function and determine if
hardware breakpoints have been set and act accordingly.
hnd = GetCurrentThread();
status = GetThreadContext(hnd, &ctx);
if ((ctx.Dr0 != 0x00) || (ctx.Dr1 != 0x00) || (ctx.Dr2 != 0x00) || (ctx.Dr3 != 0x00) ||
(ctx.Dr6 != 0x00) || (ctx.Dr7 != 0x00))
{
MessageBox(NULL, L"Debugger Detected Via DRx Modification/Hardware
Breakpoint", L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
VMware Detection
Multiple techniques exist to detect if our process is running within an instance of
VMware. These techniques are based on the fact that some processor specific registers
can be accessed from user mode and will return the value that the host system is
storing in those registers. Due to this fact, the virtual machine must emulate those
registers and will return values that are different than the standard values stored by
the host operating system. IDT and GDT values were originally used to detect the
presence of a virtual machine but due to the advent of multiple processors they
became less accurate. However, checks against the LDT register are impervious to
multiple processor differences. As such it is possible to reference this register from
code and accurately determine if we are running under an instance of VMware. If the
return value for the first and second bytes is not equal to zero we can be certain that
we are within a virtual machine.
__asm {
sldt ldt_info;
}
if ((ldt_info[0] != 0x00) && (ldt_info[1] != 0x00)) ldt_flag = 1;
Timing
Timing based anti-debugging methods are primarily used to detect single stepping
through a process. By surrounding sensitive code blocks with time states, or
alternatively conducting two time checks in succession, it is possible to determine the
22. execution latency between lines of code. If the time is too large when compared
against a reasonable threshold we know that single stepping is occurring.
RDTSC Instruction Debugger Latency Detection
It is possible to detect a single stepping debugging effort by calculating the delta
between two rdtsc calls. If the resultant delta value is greater than 0xFF (arbitrary
threshold), then the program is being single stepped.
i = __rdtsc();
j = __rdtsc();
if (j-i < 0xff) {
MessageBox(NULL, L"No Debugger Detected", L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"Debugger Detected Via RDTSC", L"Debugger Detected",
MB_OK);
}
Kernel-Mode Timer NtQueryPerformanceCounter
Similar to the rdtsc technique, QueryPerformanceCounter can be used to determine if a
debugger is connected to our process and single stepping. Simply call the
QueryPerformanceCounter twice and determine the delta. If the delta is above a
reasonable threshold (0xFF in our case) we are single stepping.
QueryPerformanceCounter(&li);
QueryPerformanceCounter(&li2);
if ((li2.QuadPart-li.QuadPart) > 0xFF) {
MessageBox(NULL, L"Debugger Detected via QueryPerformanceCounter",
L"Debugger Detected", MB_OK);
} else {
MessageBox(NULL, L"No Debugger Detected", L"No Debugger", MB_OK);
}
GetTickCount Timer
This is the same method as the other timing related anti-debugging techniques. This
technique uses GetTickCount functions to determine an execution timing delta. If the
delta is too large we can assume that our process is being single stepped manually.
The primary difference between this and other timing related techniques is that the
threshold must be set much lower as this is a lower precision timer than the others in
use.
timeGetTime Timer
Identical to other timer methods using timeGetTime function to determine execution
deltas.
23. Conclusion
The list of techniques a programmer can use to hide from runtime analysis continues
to grow as new methods are found over time. Like most areas of security research this
is a classic cat and mouse game. rootkit techniques are a fertile ground of research
and new operating systems and virtual machines give additional debugging
opportunities that the anti-reverse engineer will want to thwart. The list is long and
growing. However, when a new technique is discovered it is relatively easy to add a
scan or check for the pattern with a rules based static analyzer. Binary static analysis
is up to the task of looking for the tell tale signs that a program is trying to hide its
behavior from a reverse engineer which is often a tip off that something unwanted is
hidden in the software.
24. References
1. Reflections on trusting trust. Commun. ACM 27, 8 (Aug. 1984), 761-763. DOI=
http://doi.acm.org/10.1145/358198.358210, Thompson, K. 1984.
2. http://www.veracode.com/images/stories/static-detection-of-
backdoors-1.0.pdf, Chris Wysopal and Chris Eng, August 2007
3. http://www.offensivecomputing.net/files/active/0/vm.pdf, Danny Quist and Val
Smith
4. http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx, Josh
Jackson, 11/9/2008
5. http://www.securityfocus.com/infocus/1893, Nicolas Falliere, 9/12/2007
6. http://ieeexplore.ieee.org/Xplore/login.jsp?url=/
iel5/8013/4218538/04218560.pdf?temp=x, Michael N. Gagnon et al., Jun-07
7. http://pferrie.tripod.com/papers/unpackers.pdf
, Peter Ferrie, May-08
8. http://pferrie.tripod.com/papers/unpackers.ppt, Peter Ferrie, May-08
9. http://www.openrce.org/reference_library/anti_reversing, Mixed, Unknown
10.http://pferrie.tripod.com/papers/attacks2.pdf, Peter Ferrie, Oct-08
11.http://www.codebreakers-journal.com/downloads/cbj/2005/
CBJ_2_1_2005_Brulez_Anti_Reverse_Engineering_Uncovered.pdf, Nicolas Brulez,
3/7/2005
12.http://www.piotrbania.com/all/articles/antid.txt, Piotr Bania, Unknown
13.http://securitylabs.websense.com/content/Assets/
apwg_crimeware_antireverse.pdf, Nicolas Brulez, 2006
14.http://vx.netlux.org/lib/vlj03.html, Lord Julus, 1998
15.http://handlers.sans.org/tliston/ThwartingVMDetection_Liston_Skoudis.pdf,
Tom Liston and Ed Skoudis, 2006
16.http://nagareshwar.securityxploded.com/2007/12/16/new-antidebugging-
timer-techniques/, Nagareshwar Talekar, 12/16/2007
17.http://www.piotrbania.com/all/articles/playing_with_rdtsc.txt, Piotr Bania,
Unknown