Penetration Testing

Our customers have the challenging task of securing increasingly complex IT environments to deliver reliable services for the organisation and their customers. The threat to critical systems is ever increasing and the high probability of a security weakness being exploited needs constant vigilance to ensure that risks are contained at acceptable level for the business. Penetration testing plays an important role in this process.

The penetration testing process helps our customers discover vulnerabilities that could result from poor or improper architecture or design, both known and unknown software flaws, and operational weaknesses in process or technical countermeasures. Testing is performed with an attacker’s mindset and employs the same techniques and approaches threat actors use to gain control of restricted functionality and steal confidential data.

The greater the complexity of application features and functionality, the greater the risk.

Our customers are often early adopters of new and emerging technologies, they are continuously innovating technology to drive new business opportunities through applications. Changing architectures toward containerization and micro services together with evolving development processes like lean and agile leads to faster development times and continuous release cycles that bring their own security challenges. We understand software development and know how to work as an integrated member of your development teams to secure critical applications that are driving your business.

BLACK, WHITE, OR GREY BOX ?

Black-box testing is performed without any information about the target system or any user credentials. Black-box testing provides a real-world assessment of the strengths and weaknesses of an organisations security posture and its resilience to an attack upon its external facing applications and publicly exposed services.

White-box testing is performed with full access to source code and documentation. White-box testing can be performed as an integral part of the development process or as a deep dive review of a critical application once it has been developed.

Grey-box testing is performed with user credentials provided and limited information on functionality and architecture of the target system. Grey-box testing is the most frequently used security testing approach in the industry and provides a balance between black and white box testing.

PENETRATION TESTING LIFE CYCLE

1. Preparation

Preparation involves ensuring the information required is ready for testing before the engagement starts. During this phase we will ask for credentials, MFA tokens, systems architecture diagrams and API documentation such as Swagger output or postman collections.

2. Mapping the attack surface

3. Test Case Completion

4. Business Logic Testing

5. Reporting

6. Retesting

ALIGNED TO REGULATORY STANDARDS

We use dynamically generated Test Cases (or "Abuse Cases") to ensure a consistent and thorough approach to how we conduct penetration testing.

Test cases are generated for each application during a profiling stage whereby the technology, design and regulatory regulatory requirements are used to generate test-cases that fit the requirements. This approach ensures efficiency and a tailored approach to applications in highly regulated industries such as Banking and Finance or medical.

We support industry technical standards such as the OWASP Mobile Security Testing Guide and the OWASP Top 10. Test cases also follow regulatory requirements such as the Technology Risk Management Guidelines from MAS Singapore and the Singapore Personal Data Protection Act of 2012 (PDPA).

Collectively our test cases represent decades of Penetration Testing experience and provides the Vantage Point Team with a knowledge base of technical advice and regulatory considerations.

WEB APPLICATIONS

Web applications continue to be a prime target for malicious attack that can cause significant impact on the confidentiality of sensitive data and the availability of critical business functionality. Security design flaws in authentication and user authorization, poorly implemented encryption for the protection of sensitive data and coding bugs like injection flaws are all attack vectors that leave applications vulnerable to exploitation.

70% of all data breaches are through attacks on an organisations web applications.

Vantage Point understand where the weaknesses and vulnerabilities are and how they can be exploited. Our testing approach is fully aligned with internationally accepted best practices including the OWASP Application Security Verification Standard and the OWASP Top 10. In the past we have witnessed security trends occurring due to the introduction of new technologies and development styles. These trends have shaped our own testing approach and allowed us to create language and framework specific test cases to identify vulnerabilities in technologies such as Java Struts and Spring, Microsoft .NET, Ruby, and Python, these test-cases are built upon years of hands on experience and includes more than 300 technology specific test cases.

Included Test Cases

Injection Flaws

SQL Injection.
Command Injection.
LDAP Injection.
XPath Injection.
XML Injection.

Broken Session and Authentication

Session not invalidated during logout.
Session token available to remote parties.
Insecure login forms.
Insecure cookie configuration.
Default or insecure credentials.

Sensitive Data Exposure

Banking details such as credit card numbers and account numbers.
Health-related data.
Exposure of PII details such as Identity Card, Passport Number, Date of Birth, Full Name.
Other details such as usernames and associated passwords.

XML External Entities (XEE)

User supplied data is allowed within the document type declaration (DTD).
The XML processor is configured to resolve external entities within the DTD.

Insecure Access Controls

Unenforced or missing access controls.
Horizontal or vertical privilege escalation object refrences.
Unprotected Administrative controls.

Security Misconfigurations

Debugging enabled.
Incorrect folder permissions.
Using default accounts or passwords.
Setup/Configuration pages enabled.

Cross-Site Scripting (XSS)

Reflected XSS.
Stored XSS.
DOM XSS.

Insecure Deserialization

Object and data structure related attacks during deserialization.
Data tampering attacks to change existing data structures.

Using Components with Known Vulnerabilities

Identifying known vulnerabilities in 3^rd party plugins, libraries and components.

Insufficient Logging and Monitoring

Ensure login, access control failures, and server-side input validation failures are logged with sufficient user context.
Ensure high-value transactions have an audit trail with integrity controls.

MOBILE APPLICATIONS

“Mobile is becoming not only the new digital hub, but also the bridge to the physical world. That’s why mobile will affect more than just your digital operations — it will transform your entire business.” - Thomas Husson, Principal Analyst at Forrester Research

The growth of “Mobile First” technology has made Mobile security one of the most in-demand services for penetration testing and Vantage Point have a broad range of experience working across many different mobile frameworks such as Kotlin, Kony, Flutter, ReactNative, NodeJS, Swift and natively developed applications.

Mobile application developers frequently assume that mobile applications are more secure than their web counterparts and cannot be easily intercepted or manipulated by threat actors. This assumption is dangerous and incorrect and the same vulnerabilities impacting web applications can impact Mobile applications - such as business logic vulnerabilities, injection vulnerabilities and the disclosure of confidential information.

Our mobile security testing methodology is aligned to the OWASP Mobile Security Testing Guide (MSTG) and the Mobile Application Security Verification Standard (MASVS). These technical guidelines cover a range of Android and iOS specific security test case which provide a strong baseline against commonly found vulnerabilities in Mobile applications and can be tailored to specific industries.

Included Test Cases:

Authentication and Session Management

Verifying Appropriate Authentication.
Password Best Practices.
Session Timeout.
User Logout functionality.
Two-Factor Authentication.
Testing OAuth 2.0 Flows.

Network Communications

Verifying Encryption exists on the Network.
Configuration of Network Communications.
Custom Certificate Stores and Certificate pinning.
Weaknesses in third party libraries.

Cryptography

Use of Insecure Cryptographic Algorithms.
Cryptographic Configuration Issues.
Random number generation.
Cryptographic key management.

Testing Code Quality

Injection Flaws.
Application Permissions.
Cross-Site Scripting Flaws.
Memory Corruption Bugs.
Correct Use of WebViews.

Local Authentication

Testing Authentication Requirements.
Testing Biometric Authentication.
Testing Stateless (token-based) authentication.
Testing Session timeout.

Data Storage

Testing Local Storage for Sensitive Data.
Identifying storage of Sensitive data in logs.
Sensitive Data is Sent to Third Parties.
Testing Backups for Sensitive Data.
Testing the Device-Access-Security Policy.
Finding sensitive data in the keyboard cache.

Resiliency Against Reverse-Engineering

Testing Root Detection.
Testing Anti-Debugging Detection
Testing File Integrity Checks.
Testing Emulator Detection
Testing Runtime Integrity Checks.

Platform Interactions

Testing App Permissions.
Testing Custom URL Schemes.
JavaScript Execution in WebViews.
WebView Protocol Handlers.
Java Objects Exposed Through WebViews.

Code Quality and Build Settings

Testing for Debugging Code.
Identifying debugging symbols
Validating production App signing.
Weaknesses in Third Party Libraries.
Testing Exception Handling.
Memory Corruption Bugs.
All free security features enabled.

CLOUD INFRASTRUCTURE

As organizations move away from an on-premise architecture and into the cloud, they often overlook the newly created attack surface which is unique to cloud environments and equally as critical. Although cloud infrastructure can provide significant cost savings through consolidation it also increases the security and risk impact as often multiple businesses critical assets are kept in the same cloud service.

Reviewing the security of cloud infrastructure involves a detailed configuration review of the services that are provided by the cloud hosting provider such as credential management, file storage and cloud database servers and reviewing how business critical applications consume and integrate with these services.

Cloud security reviews requires read-only access being provided to the cloud Administrative portal which is used to conduct a granular configuration review of the services utilised. Our methodology includes test-cases for AWS, Azure, and Google Cloud and covers the most used aspects of cloud infrastructure.

Included Test Cases:

Intergration and Consumption of Cloud Services

Granular access controls for application service accounts.
Cloud file storage access controls.
Minimizing exposure of cloud hosted API Endpoints.
Correct use of API Tokens.
Preventing abuse of Cloud Services.
Encryption or tokenization of sensitive data.

Azure

Use of Federated Single Sign-On.
Multi-Factor Authentication enforcement.
Restricting access to management interface.
Defining guest tenant domains.
Enable advanced threat protection for all storage accounts.
Business-critical data in immutable blobs.
Limit shared access signature (SAS) tokens to HTTPS connections only.
Use Azure Active Directory (Azure AD) to authorize access to blob data.
Keep in mind the principal of least privilege when assigning permissions.
Regenerate your account keys periodically.
Allow trusted Microsoft services to access the storage account.
Use VNet service tags.
Limit network access to specific networks.

Amazon

Turn on MFA for the root account.
Minimize or completely avoid using the root account.
Ensure S3 buckets don’t allow public write.
Ensure S3 buckets containing sensitive data don’t have public read permissions.
Encrypt Elastic Block Store (EBS) database.
Encrypt inbound and outbound S3 traffic.
Disallow unrequired ingress or egress traffic.
Implement Server access logging.
Implmenet Object-level logging.

Google Cloud

2-Step Verification for admin accounts.
Enroll a spare security key.
Prevent password reuse.
Create a Whitelist of trusted apps.
Limit external calendar sharing.
Chrome OS and Chrome Browser policy.
Warn the users when chatting outside their domain.
Disable “Do not require sender authentication” setting for spam policies.
Disable automatic forwarding of incoming mail.
Enforce mobile password requirements.
Disable access to offline docs.

AUTOMATIC TELLER MACHINES

When threat actors are intent on exploiting vulnerabilities in financial institutions, ATM systems can serve as primary access points. While ‘smash and grab’ attacks on ATMs are nothing new, in the rapidly evolving world of cyber-crime cash machines are now a focus for threat actors aiming to steal physical currency.

Money is the main driving force behind 90% of all cyberattacks and unsecure ATMs present a soft target for criminals.

ATM assessments are a mixture of host-based security review, physical security, network assessment, and deployment review of vendor specific technology stacks. We have worked with Automated Teller Machines, Cash Deposit Machines and next-generation Video Teller Machines throughout Asia and are familiar with securing the vendor technology stacks from DieBold, Wincor NixDorf and Hyosung. Our methodology contains but is not limited to the following test-cases.

Host Based Assessment

Test BIOS configuration.
Test the Default BIOS password.
Test Protection against USB devices
Test all keyboard shortcuts are disabled.
Verify the patch level of the OS.
Validate the privilege level of the ATM user.
Test privilege escalation methods.
Secure transaction logs.
Check if antivirus is enabled.
Check Windows audit controls.
Check Windows Software Restriction Policies and Group Policies.
Test SRPv2 implementation.
Test NTFS File system permissions on services and core OS binaries.
Check Windows 10 UAC configuration.
Validate Power Shell security settings.
Identify any DLL hijacking instances
Identify Insecure COM object controls.
Ensure default maintenance mode PIN is changed.

Network Assessment

Discover all open ports on the ATM.
Test if the ATM can communicate with other hosts.
Ensure communication are encrypted.
Validate the ability to perform Man-in-the-middle attacks

Physical Access Assessment

Testing all ATM input devices.
Testing the Ethernet point is secured.
Testing the electric-power point is secured.
Test Mirror and pin shield to identify and prevent shoulder surfing.
Test the card reader against card skimming.
Test the keypad against keypad tampering.
Test the lock protection again unauthorized access to banknotes or bills.
Test the ATM must be grouted on the floor to secure against robbery.
Disabling unused network and electric ports.

Vendor Application Assessment

Test the ATM application is not vulnerable to injection attacks.
Test the application is not storing any sensitive information.
Test the application is using a secure channel.
Check for hidden application windows running in the background.
Test hidden modal dialog within vendor administrative services.

MICROSERVICES AND API's

A microservice is an architectural design that separates portions of a usually monolithic application into small, self-contained API services. One drawback of microservices is that they can be more vulnerable to security threats. This is because adopting a microservices-based approach often involves exposing a lot more of your system’s functionality directly to the network, which in turn means it is in closer reach of threat actors.

We have worked to secure API collections ranging from ten’s to more than thousand’s, across a wide range of technologies and frameworks such as:

Flask, Django, Neo4J and Spring.
Cloud based technologies such as AWS Lambda and Azure functions.
In message API encryption and signing.
Legacy SOAP/XML RPC technologies.

Our methodology and approach for API security testing is tailored to the technology in use and aligned to the OWASP API Security guide lines.

Test Cases Included:

API1:2019 Broken Object Level Authorization

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface Level Access Control issue. Object level authorization checks should be considered in every function that accesses a data source using an input from the user.
API2:2019 Broken User Authentication

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other user’s identities temporarily or permanently. Compromising system’s ability to identify the client/user, compromises API security overall.
API3:2019 Excessive Data Exposure

Looking forward to generic implementations, developers tend to expose all object properties without considering their individual sensitivity, relying on clients to perform the data filtering before displaying it to the user.
API4:2019 Lack of Resources & Rate Limiting

Quite often, APIs do not impose any restrictions on the size or number of resources that can be requested by the client/user. Not only can this impact the API server performance, leading to Denial of Service (DoS), but also leaves the door open to authentication flaws such as brute force.
API5:2019 Broken Function Level Authorization

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions, tend to lead to authorization flaws. By exploiting these issues, attackers gain access to other users’ resources and/or administrative functions.

API6:2019 Mass Assignment

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on a whitelist, usually lead to Mass Assignment. Either guessing objects properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.
API7:2019 Security Misconfiguration

Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.
API8:2019 Injection

Injection flaws, such as SQL, NoSQL, Command Injection, etc., occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s malicious data can trick the interpreter into executing unintended commands or accessing data without proper authorization.
API9:2019 Improper Assets Management

APIs tend to expose more endpoints than traditional web applications, making proper and updated documentation highly important. Proper hosts and deployed API versions inventory also play an important role to mitigate issues such as deprecated API versions and exposed debug endpoints.
API10:2019 Insufficient Logging & Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems, maintain persistence, pivot to more systems to tamper with, extract, or destroy data. Most breach studies demonstrate the time to detect a breach is over 200 days, typically detected by external parties rather than internal processes or monitoring.