[Case Study] Comprehensive Security Reviews in a Fast-Paced Financial Environment

Background
ACME, a leading financial sector company with multiple lines of business, has implemented a stringent security review program that mandates each application or implementation undergo a thorough security evaluation before being approved for production or go-live. This program is not just a compliance requirement but a critical measure to ensure the security and integrity of the firm’s diverse financial services, which cater to a vast and varied clientele. By maintaining this high standard, ACME continues to uphold its reputation as a secure and reliable financial institution.

Challenge
ACME operates in an extremely fast-paced development environment characterized by various development models, including custom-developed applications, third-party platforms for in-house apps, vendor applications with Single Sign-On (SSO) implementations, and frequent sprint releases. Each development type brings unique security challenges that require a tailored approach to testing, ensuring that all potential risks are addressed. Moreover, the complexity of coordinating between separate teams, managing pre-requisites, and ensuring the integrity of data across multiple departments further complicates the security review process. The need for seamless communication, precise planning, and the alignment of multiple stakeholders adds layers of difficulty in ensuring that security assessments are both comprehensive and timely.

Solution
To address these multifaceted challenges, ACME partnered with Blueinfy, entrusting them with the complete management of the security testing process from start to finish:

Pre-Requisites Sharing and Access Verification:
Blueinfy begins each engagement by ensuring that all necessary pre-requisites are thoroughly shared, and access to relevant systems is meticulously verified before any testing commences. This careful preparation is crucial for setting up a test environment that accurately mirrors the production environment, thereby ensuring that security assessments are realistic and reliable. By verifying access and prerequisites early, Blueinfy minimizes the risk of encountering delays or oversights during testing.

Scheduling Demos to Understand Applications/Implementations:
Before diving into the technical aspects of testing, Blueinfy schedules detailed demonstrations with ACME’s internal teams to gain a deep understanding of each application or implementation. These sessions are designed to uncover any unique functionalities, workflows, or potential vulnerabilities that might not be immediately apparent. This proactive approach ensures that the subsequent security testing is not just a box-checking exercise but a thorough examination tailored to the specific nuances of the application, increasing the likelihood of identifying any subtle or context-specific risks.

Scoping/Test Scenario Preparation:
Based on the understanding gained from these demos, Blueinfy meticulously narrows down the scope of the penetration test according to the nature of the changes being implemented. Whether it’s a full-blown penetration test, a limited scope assessment for specific enhancements, a client-side mobile application, API penetration test, or SSO implementation, the scope is carefully defined to match the specific needs of the project. This targeted approach not only ensures that the testing is highly relevant but also enables faster report delivery and more efficient budget utilization, aligning with ACME’s need for both speed and precision in their fast-paced environment.Thorough Penetration Testing:

Blueinfy’s penetration testing is both comprehensive and rigorous, combining the precision of automated tools with the nuanced insights of manual testing. The manual aspect of testing is particularly crucial, as it allows for the creation of custom-designed test cases that are directly aligned with the specific architecture and implementation details of each application. This dual approach ensures that both traditional vulnerabilities, such as SQL injection or XSS, and implementation-specific risks, are thoroughly vetted. The extensive nature of these tests ensures that no stone is left unturned in the pursuit of securing ACME’s applications.

Detailed Reporting:
Upon completing the security assessments, Blueinfy provides ACME with highly detailed reports, with zero false positives or false negatives that adhere to the firm’s stringent formatting and content requirements. These reports go beyond mere identification of vulnerabilities; they offer a comprehensive analysis that includes risk assessments, potential impact evaluations, and actionable recommendations for remediation. By delivering these insights in a clear and organized manner, Blueinfy empowers ACME’s teams to take swift and effective action, thereby reinforcing the firm’s overall security posture.

GRC Platform Integration:
To ensure that all findings are properly tracked and managed, Blueinfy seamlessly integrates the results of their security assessments into ACME’s Governance, Risk, and Compliance (GRC) platform. This integration allows for the efficient tracking of issues, timely closure of vulnerabilities, and streamlined approval processes. By embedding the findings directly into the GRC system, Blueinfy helps ACME maintain a cohesive and organized approach to risk management, ensuring that all security-related activities are thoroughly documented and easily accessible for future reference.

Management Reporting:
In addition to the technical reports, Blueinfy also provides ACME’s leadership with comprehensive management reports. These documents synthesize the outcomes of the security assessments, highlighting the unique findings identified in applications, key risk areas and offering strategic insights into the firm’s overall security posture. By presenting this high-level overview, Blueinfy enables ACME’s decision-makers to understand the broader implications of the security assessments, facilitating informed decision-making and strategic planning.

Outcome
Through its partnership with Blueinfy, ACME has achieved and maintained an exceptional security track record. After production, there have been virtually no vulnerabilities identified in annual penetration tests, production URL scans, or any other third-party assessments performed by ACME’s clients. This impeccable performance underscores the effectiveness of Blueinfy’s thorough and detailed approach to security testing. As a result, ACME continues to build and maintain trust with its clients, knowing that its applications are not only innovative but also secure, thereby reinforcing its position as a leader in the financial industry.

Article by Hemil Shah

[Case Study] Enhancing Security in a Large Manufacturing Company's Applications

Background
A large manufacturing company, managing a wide array of applications critical to its operations, engaged a US-based ACME company having a DAST scanner to conduct a security assessment. ACME utilized it’s proprietary automated scanner to identify vulnerabilities across the company’s applications. However, during the assessment, ACME realized that while their scanners were effective in detecting standard vulnerabilities, they had limitations in identifying more complex issues, such as logical abuses and authorization bypasses—risks that could severely compromise the security of the company’s applications.

Challenge
The primary challenge was the inability of automated scanners to detect critical vulnerabilities related to business logic and authorization controls. These types of vulnerabilities require a deep understanding of the application’s functionality and how users interact with it, which often falls outside the capabilities of an automated scanner. The manufacturing company needed a more thorough approach to ensure that these high-risk issues were addressed and that their applications were secure.

Solution
Recognizing the limitations of their automated scanner, ACME sought the expertise of Blueinfy, a specialized security firm with extensive experience in uncovering complex vulnerabilities. Blueinfy proposed a targeted, time-bound manual penetration testing approach focused specifically on identifying authorization bypasses and logical abuses. Blueinfy’s team of skilled security professionals conducted in-depth manual testing of the manufacturing company’s applications. This method allowed them to simulate real-world attacks, exploring the applications' business logic, user roles, and access controls in a way that automated scanner could not.

Combining manual penetration testing with automated scans offered a balanced and comprehensive approach to security assessments specially in a scenario of large application assets. Here are some key benefits of this engagement to manufacturing company - 

1. Coverage and Depth
Scanner quickly scanned and identified common vulnerabilities across large systems, covering a wide range of issues efficiently. Scanners are great for routine checks and can handle repetitive tasks without getting tired. Manual testing explored vulnerabilities that automated scanner might miss, particularly those that require contextual understanding or nuanced analysis, such as business logic flaws, complex access control issues, and custom applications.
2. Efficiency and Thoroughness
Scanner helped in accelerating the process by identifying obvious vulnerabilities, which can then be reviewed and validated by manual testers. This saved time compared to manual testing alone. Manual Testing ensured that the identified vulnerabilities are accurately validated and assessed, reducing false positives and ensuring that the results are actionable.
3. Cost-Effectiveness
Scanner reduced the overall cost of initial assessments by handling the bulk of routine checks. Manual Testing focused on high-value areas where human insight is crucial, optimizing the cost associated with expert time.
4. Adaptability
Scanner were configured and run at regular intervals, providing ongoing assessments and alerts for newly discovered vulnerabilities. Manual Testing adapted to the specific context of the application and its environment, adjusting tactics based on findings and changing threat landscapes.
5. Comprehensive Reporting
Scanner generated detailed reports with identified vulnerabilities, often with recommendations for remediation. Manual Testing provided in-depth analysis and contextual information that enhances the automated reports, offering insights into the impact and potential exploitability of vulnerabilities.
6. Continuous Improvement
Scanner continuously updated to detect new vulnerabilities and threats as they emerge. Manual Testing allowed for human intuition and understanding of emerging threats, contributing to a more nuanced security posture.

Outcome
The manual penetration testing approach recommended by Blueinfy proved to be highly effective. Blueinfy team identified critical authorization bypasses or logical abuses in more than 98% of the applications tested. The combination of manual testing, with its focus on high-risk areas, and the automated scanning provided a comprehensive assessment that uncovered a significant number of vulnerabilities that could have otherwise gone undetected.

As a result, the manufacturing company was able to address these vulnerabilities, significantly enhancing the security of their application assets. The collaboration between Blueinfy and ACME not only improved the manufacturing company’s overall security posture but also demonstrated the value of integrating manual and automated testing methods. By partnering with Blueinfy, ACME ensured that even the most complex and subtle vulnerabilities were identified and mitigated, safeguarding operations and reducing the risk of potential security breaches of the client applications.

In essence, using both manual and automated penetration testing approaches leverages the strengths of each, leading to a more robust and effective security assessment.

Article by Hemil Shah

[Case study] Agile Product Company Balances Rapid Release Cycles with Security

Background
A product company utilizing agile methodology was grappling with the challenge of ensuring robust security while managing frequent sprint release cycles. The company managed their sprint stories as part of a ticketing system. The company’s commitment to both speed and security led them to engage Blueinfy to ensure security without compromising deployment timelines. The goal was to integrate security seamlessly into their agile development process.

Challenge
The company’s agile development model involved rapid, iterative releases, which posed a challenge for maintaining comprehensive security assessments. The primary need was to align security testing with their fast-paced development cycle without impeding the release schedule. 

Solution
Blueinfy developed a strategic security approach tailored to the company’s agile workflow, leveraging agile penetration testing principles:

Initial Comprehensive Penetration Test
To establish a security baseline and identify pre-existing vulnerabilities before the agile release cycles commenced, Blueinfy conducted an in-depth penetration test to assess the application’s security posture comprehensively. This initial assessment provided a detailed report outlining vulnerabilities, their potential impacts, and remediation recommendations.

Ongoing Agile Penetration Testing
 To continuously assess the security implications of changes in each agile release cycle. The company shared an export from their ticketing system in excel format with Blueinfy, detailing use cases, changes, and user stories associated with each release. Blueinfy team, having complete knowledge of the application and security knowledge, identified the changes which can potentially have a security impact. Blueinfy team performed targeted penetration tests focused on the specific changes highlighted. This approach, aligned with agile testing practices, allowed for rapid assessments of security impacts without disrupting the development cycle. Blueinfy integrated into the company’s agile workflow, providing quick feedback on vulnerabilities introduced by new changes. This iterative process ensured that security assessments were aligned with the pace of development.

Enhanced Reporting and Management Tracking
To enable effective tracking and management of security performance, Blueinfy delivered detailed reports on vulnerabilities, trends, and the status of issues, which were updated regularly to reflect the latest changes. A security dashboard was developed, offering management a clear, real-time view of the application’s security status, including trends and actionable insights. As an example, following graph was provided: -
 

The iterative nature of testing allowed for continuous improvement and adaptation of security practices in response to evolving threats and development changes.
Benefits

• Security assessments were integrated into the agile development process, allowing for rapid and efficient identification of vulnerabilities without slowing down release cycles.
• Detailed and timely reports enabled management to track security performance, prioritize remediation efforts, and make informed decisions.
• The targeted approach ensured that each release was evaluated for security impacts in the context of recent changes, aligning with agile principles and enhancing overall security posture.
• Blueinfy’s agile penetration testing approach fostered close collaboration between security experts and development teams, facilitating a proactive and adaptive security strategy.

Key Differences

Conclusion
By leveraging Blueinfy’s agile penetration testing expertise, the company successfully balanced the need for rapid release cycles with robust security measures. This approach not only streamlined their security assessments but also ensured that security remained a key focus throughout their agile development process, enhancing both speed and security in their product releases.

Article by Hemil Shah

[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

Working of Lambda Layers and Runtime

Amazon came up with many innovative and interesting announcements about new technologies and services provided by them during the recent AWS "re:Invent" event. One of the widely discussed topic in the event was "serverless". With the increasing usage of AWS lambda, it is imperative to understand anything that impacts the lambda architecture in any way. The below two announcements were quite important for security professionals as they directly deal with serverless changes and its implications.

Firecracker - Firecracker is Amazon’s micro VM, which runs lambda functions, and it will be open source. Hence, anybody can play around and understand it's working. For more details: - https://aws.amazon.com/blogs/aws/firecracker-lightweight-virtualization-for-serverless-computing/

Lambda Layers and Runtime APIs - Lambda functions allow a holding place in terms of layers. One can deploy set of layers and can execute these layers with Runtime APIs or leverage packages deployed in these layers. For more details: - https://aws.amazon.com/about-aws/whats-new/2018/11/aws-lambda-now-supports-custom-runtimes-and-layers/

In this post, we are going to explore Layers and Runtime APIs.

AWS was supporting a set of runtime environment predefined within lambda functions. With the introduction of Layers and Runtime APIs, that it no longer a limitation. It now supports and allows to load one's own runtime binaries and leverage it across the lambda eco-system. Thus, now support has been added for Ruby, C++, and Rust etc. making it a Bring Your Own Runtime kind of scenario.

Their tutorial (https://docs.aws.amazon.com/lambda/latest/dg/runtimes-walkthrough.html) explains how to configure and invoke one's own runtime through layering and APIs. We are going to modify the scripts mentioned in this tutorial and deploy our runtime through the management console for better understanding.

First, we need to make our own bootstrap to start the activity of lambda functions within shell.  This is the shell script which one can run and initiate any environment and binaries within it. It supports runtime APIs so one can fetch the "event" and pass it to lambda handler.

Here is the sample bootstrap script: -

--bootstrap—

#!/bin/sh

set -euo pipefail

# Initialization - load function handler
echo $_HANDLER >> /tmp/dump
env >> /tmp/dump
source $LAMBDA_TASK_ROOT/"$(echo $_HANDLER | cut -d. -f1).sh"

# Processing
while true
do
  HEADERS="$(mktemp)"
  # Get an event
 
  EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")
  cat $HEADERS >> /tmp/dump
  echo $EVENT_DATA >> /tmp/dump
  REQUEST_ID=$(grep -Fi Lambda-Runtime-Aws-Request-Id "$HEADERS" | tr -d '[:space:]' | cut -d: -f2)
  echo $REQUEST_ID >> /tmp/dump
  # Execute the handler function from the script
  RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")

  # Send the response
  curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE"
done

Let’s look at few important lines: -

1.    We are using /tmp/dump to put interesting values to it so we can read them through the function and pass it back as response as well.
2.    "EVENT_DATA=$(curl -sS -LD "$HEADERS" -X GET "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/next")" – this line will fetch "event" through runtime from underlying localhost (127.0.0.1).
3.    "RESPONSE=$($(echo "$_HANDLER" | cut -d. -f2) "$EVENT_DATA")" – once we have "event" with us we can invoke our own local function and fetch the response. It is like calling another script or you can pass it to any other runtime binaries.
4.    Finally, "curl -X POST "http://${AWS_LAMBDA_RUNTIME_API}/2018-06-01/runtime/invocation/$REQUEST_ID/response"  -d "$RESPONSE" – we send response back to the client through runtime API.

We just have to make sure these files are "chmod 755" as shown below: -




We can zip the file to "bootstrap.zip" and create a new layer for lambda.

 

We can upload the zip file and create a runtime layer as below: -



Now, we have runtime-shell layer read. We can utilize this layer/runtime and build many lambda functions using simple shell scripts. Let’s make a function here called "runlambda": -

 

We select "custom runtime" as our environment. Next, let’s load the layer which we want to use: -



As shown in the above screenshot, we pass on ARN to the layer and then it is ready: -



Next, let’s load simple echo function as below (function.sh). We are doing simple cat to the entire dump we collected in the bootstrap along with the event.

--function.sh--

function handler () {
  EVENT_DATA=$1
  echo "$EVENT_DATA" 1>&2;
  cat /tmp/dump
  RESPONSE="Echoing request: '$EVENT_DATA'"
  echo $RESPONSE
}

Next, we can load this function as zip to the lambda function as shown below: -


All set! We can invoke the function as below: -

 

We can also invoke the function through our script (scanLambda.py) as below: -

 

We are getting a dump of all the variables available in the bootstrap layer: -

 

Above, we have cURL calls made to APIs.



Finally, we have echo coming back from the function itself.

Conclusion:

Lambda Layers and Runtime APIs enable the use of binaries or shell scripts as well as our choice of programming languages. Moreover, one can centrally manage common components across multiple functions enabling better code reuse. This implementation will have its own set of security concerns as well – thus making it necessary to understand the customized layers and runtime APIs before evaluating the function from a security standpoint.

Article by Amish Shah & Shreeraj Shah