[Case Study] Implementing Comprehensive Application Security Program for ACME – Pharma Company

Background
ACME is a global pharmaceutical company overseeing more than 30,000 domains. The company operates a diverse portfolio, including critical applications related to vaccine sales and lower-priority platforms like cafeteria surveys. The new CISO faced a significant challenge: determining how to best allocate resources for application security amid a lack of compliance requirements, no existing pen-testing program, and a general absence of strategic focus. Additionally, ACME had limited knowledge about its technology stack and faced issues with SSL certificate configurations.

Challenges

1. Resource Allocation Dilemma
The CISO needed to decide whether to invest more in securing high-value applications like those related to vaccine sales or lower-priority ones like cafeteria surveys, which might not pose immediate risks but could still impact the brand.
2. Lack of Structured Security Program
ACME lacked a strategic approach to application security, resulting in reactive rather than proactive measures. Without regulatory compliance driving security practices, there was no structured pen-testing or regular scanning in place.
3. Knowledge Gaps and Technology Issues
The company had limited understanding of the technology stack used across its domains.  Even an inconsistent SSL certificate configurations across domains posed potential security risks.
4. Inadequate Scanning Practices
Scans were performed on-demand by the application team without a comprehensive strategy, leading to incomplete vulnerability management.

Solution
Blueinfy was enlisted to create and implement a detailed multiyear application security program to address ACME's multifaceted challenges.

Phase 1: Comprehensive Domain Profiling and Risk Assessment

1. Domain Profiling through Data Collection and Public Data Analysis
Blueinfy conducted an in-depth profiling of all 30,000+ domains (which was collected as part of DNS dumps and proprietary methodologies which gathers information from public domains). This involved collecting 60 different data points, including information about the technology stack and SSL certificate status.

2. Asset Base Reduction
Identification of expired or non-essential domains allowed ACME to streamline its application asset base, focusing on domains that required attention.

3. Risk Assessment

• Blueinfy worked closely with ACME to assign risk levels to each domain (High, Medium, Low) based on predefined criteria such as handling PII, PHI, login functionalities, and e-commerce.
• A new policy was developed, mandating regular scans and pen-testing based on the risk rating of each domain, ensuring that high-risk domains received prioritized attention.

4. Vulnerability Discovery

• The profiling identified domains hosting viruses due to sub-domain takeover vulnerabilities.
• Numerous SSL certificate-related vulnerabilities were discovered, including expired certificates and misconfigurations.
• Numerous domains were discovered where admin interface were accessible with default credentials.

Phase 2: Implementation of DAST Scanner and Pen-Testing

1. DAST Scanner Evaluation and Implementation

• Blueinfy assessed various DAST (Dynamic Application Security Testing) scanners to find the best fit for ACME’s needs.
• The chosen DAST scanner was implemented, with Blueinfy assisting in configuring and fine-tuning scan profiles to enhance accuracy and effectiveness.
• Detailed evaluations were conducted to eliminate false positives and ensure actionable results.

2. Pen-Testing

• Comprehensive pen-testing was performed on all high-risk domains identified during Phase 1. This included manual and automated testing to have comprehensive security review to uncover complex vulnerabilities and actionable report with zero false positives.

Results
1. Enhanced Security Posture
The structured approach led to significant improvements in the security of ACME’s application assets, with critical vulnerabilities being addressed and mitigated.
2. Strategic Resource Allocation
ACME was able to make informed decisions about where to allocate resources, ensuring that high-value applications received the necessary protection while reducing the focus on lower-priority domains.
3. Improved Security Measures
The implementation of a DAST scanner and pen-testing processes established a more robust security framework, leading to better management of vulnerabilities and improved overall security.
4. Operational Efficiency
The reduction of domains and optimized scanning practices led to more efficient operations and a more manageable security environment.

Conclusion
By partnering with Blueinfy, ACME successfully addressed its application security challenges with a well-structured phase wise plan. The comprehensive profiling and risk assessment in Phase 1 provided a clear understanding of the security landscape, while the implementation of a DAST scanner and pen-testing in Phase 2 enhanced the company's security posture. The approach not only optimized resource allocation but also established a strategic focus on application security, positioning ACME to better protect its diverse range of domains and applications.

Article by Hemil Shah

[Case Study] Enhancing DAST Security Scans for ACME News Company

Background
ACME, a prominent news-based company, operates hundreds of websites accessible over the internet. These sites, primarily content-focused, share a uniform technology stack. The company's admin applications, however, remain inaccessible from the internet. Given the minimal input and largely static nature of these websites, traditional penetration testing seemed unnecessary. However, the potential brand damage from a compromised site was a significant concern.

Challenge
ACME sought to ensure the security of its numerous websites through automated Dynamic Application Security Testing (DAST) scans on a monthly basis. The challenge lay in the sheer volume of links across these sites, coupled with their minimal functionality, which resulted in prolonged scanning durations. Each scan took days to complete, delaying the identification of potential vulnerabilities.

Solution
Blueinfy, leveraging its extensive experience in DAST scanners and a deep understanding of ACME's specific technology, developed an innovative approach to optimize the scanning process. Instead of a traditional, exhaustive scan of every link, Blueinfy devised a methodology where each unique functionality was tested only once. This streamlined approach significantly reduced the scanning time while maintaining accuracy of the results.

Furthermore, Blueinfy tailored the DAST scanner to align with ACME's specific technology stack, ensuring the scans were relevant and focused on the most critical vulnerabilities. To facilitate seamless integration into ACME's GRC platform, the scan results were converted into a specific CSV format, enabling easy import and efficient use of the data.

Outcome
With Blueinfy's tailored approach, ACME successfully implemented a more efficient and effective security scanning process. The new methodology allowed for timely and accurate scans, enabling ACME to promptly address vulnerabilities and protect its brand. The customization of the DAST scanner and the provision of results in CSV format ensured that the data was not only actionable but also easily integrated into ACME's existing systems.

Blueinfy's expertise in configuring DAST scanners to align with ACME's technology stack proved invaluable, offering a solution that was both time-efficient and highly accurate. This partnership underscored the importance of leveraging specialized knowledge to overcome unique challenges in cybersecurity.

Article by Hemil Shah

Deep Lambda Inspection by age-old LD_PRELOAD Trickery

Lambda function uses AWS Fargate as an underlying platform and it is being leveraged by Firecracker. Firecracker is a Micro-VM, which is used to run lambda functions. As shown in the below figure, it runs in a guest OS and inherits the environment before executing the lambda code. At this time, one can leverage age-old preload trick.

Leveraging LD_PRELOAD:

Lambda function runs under a Linux based environment and it is possible to leverage preloading mechanism as shown in the above figure. If we look at “LD_PRELOAD” usage in the man page –

“A list of additional, user-specified, ELF shared objects to be loaded before all others.  The items of the list can be separated by spaces or colons, and there is no support for escaping either separator.  This can be used to selectively override functions in other shared objects.”

Hence, LD_PRELOAD is an environmental variable that contains paths to shared libraries and objects; which the loader will load before any other shared library including the C runtime library. This is the way preloading would work within lambda function as well.

It allows us to load and override various functions, which are important, and we would like to review these functions from a security perspective. For example:

1.    Underlying OS calls – we can load/override all remote command execution calls, made by lambda function. Hence, when the lambda function makes these calls, we can monitor them to discover vulnerabilities.

2.    Underlying file operations – we can load/override all file operations and monitor them at runtime. We can see if function is making any calls which are vulnerable or the file path it is using. This would aid in identifying path traversal and other file system related vulnerabilities.

3.    Underlying network operations – we can load/override networking functions and observe how lambda function is making calls to external entities. By monitoring third party outgoing calls, vulnerabilities like SSRF or any other network related abuses can be identified.

Let’s look at a simple implementation to observe networking calls. Through the below snippet, we are injecting code to capture socket, connect and send calls in the shared object. We dump the content into “/tmp/lammon.txt” file and can retrieve this content via function or write it to CloudWatch logs.

// Overriding socket call…
int socket(int domain, int type, int protocol)
{
    int (*new_socket)(int domain, int type, int protocol);
    new_socket = dlsym(RTLD_NEXT, "socket");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "socket function called Process %d:%d:%d:%d\n",
getpid(), domain, type, protocol);
    fclose(logfile);
    return new_socket(domain, type, protocol);  

}

// Overriding connect call…
int connect(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
    int (*new_connect) (int sockfd, const struct sockaddr *addr,
socklen_t addrlen);
    new_connect = dlsym(RTLD_NEXT, "connect");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "connect function called Process %d:%d:%d:%s\n",
getpid(), sockfd, (int)addr->sa_family, addr->sa_data);
    fclose(logfile);
    return new_connect(sockfd, addr, addrlen);
}

//Capturing send call…
ssize_t send(int sockfd, const void *buf, size_t len, int flags)
{
    ssize_t (*new_send)(int sockfd, const void *buf, size_t len, int flags);
    new_send = dlsym(RTLD_NEXT, "send");
    FILE *logfile = fopen("/tmp/lammon.txt", "a+");
    fprintf(logfile, "send function called Process %d:%d:%s\n",
getpid(), sockfd, (buf == NULL ? " " : (char *)buf));
    fclose(logfile);
    return new_send(sockfd, buf, len, flags);      
}

We compile the code and build a shared object. Now, we can put this into lambda layers so it can be used into any lambda functions in a shared way as shown below: -




 Now, let’s add to the lambda function as shown below: -

 

Once it is set, all functions will be intercepted by our code and actual outgoing sniffing can be seen as shown in the below figure: -





As shown above, we were able to sniff or see actual calls being made to other hosts by lambda function.

Integrating into assessment methodology:

This type of object can help in assessing lambda functions for vulnerabilities. We can load the shared object, which can gather critical information while lambda function, is invoked. It is getting logged into file or CloudWatch logs. We can invoke functions with different payloads and monitor the behaviour. It allows us to identify various sets of vulnerabilities. It ends up being a similar approach to IAST along with DAST by leveraging this simple trick.

Can it help in protection?

Yes, one can build shared object in such a way that when anything objectionable is found at runtime then it can stop execution of that call.

Conclusion:

“LD_PRELOAD” trick seems interesting for lambda function assessment. One can leverage it by adding a small code and loading it before the start of execution. It can intercept all calls and log important information. This information can help in validating and identifying vulnerabilities like – remote command execution, SSRF, third party calls, path traversal, information leakage and other architecture layer issues. This approach can be expanded to defend a lambda function as well. One can disallow all remote execution calls, block out going traffic, disallow file system access etc. We would like to focus more into vulnerability detection while performing pen-testing or automated scanning. This module can be integrated to any other methodology by common logs with timestamps.

Article by Amish Shah & Shreeraj Shah