tag:blogger.com,1999:blog-23815583878004001322019-03-13T01:20:59.651-07:00Blueinfy's blogshreerajnoreply@blogger.comBlogger112125tag:blogger.com,1999:blog-2381558387800400132.post-66121914744842711872019-02-12T03:17:00.000-08:002019-02-12T03:17:15.921-08:00Deep 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 shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-79434955943225206602018-12-06T03:59:00.000-08:002018-12-07T01:45:16.906-08:00Working 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 shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-15167177605132320412018-11-27T22:04:00.000-08:002018-11-27T22:04:23.720-08:00Lambda Post Exploitation – Devil in the Permission
In the last blog post, we covered an exploit scenario where an attacker could get access to all the resources which were part of the AWS account once a vulnerability was identified in a lambda function. A weak implementation of permission controls led to the above mentioned exploit scenario. We concluded the following: -“The permission controls implemented for lambda functions may not seem shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-69484103642459757992018-10-30T22:17:00.000-07:002018-10-30T23:38:52.449-07:00Blind Lambda Event Injections without Outbound Connections (Part 3) – Extracting AWS Building Blocks
Lambda functions, integrated with various AWS components according to the design of serverless applications, can be a medium of various exploit scenarios if vulnerable. As discussed in the previous blog posts, a vulnerability in a lambda function (with or without outbound connections) can be identified through various methods. In this blog post, we will discuss the exploit scenarios which come shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-16598913586009286742018-10-24T22:45:00.000-07:002018-10-24T22:45:50.800-07:00Blind Lambda Event Injections without Outbound Connections (Part 2)
In the previous blog post (here), we covered a simple technique to both discover and exploit serverless/lambda functions at blind spots without outbound connections in place. We concluded the following at the end of the article: - “It is imperative to identify injection points and fix the vulnerabilities at the source rather than relying on deploying ‘post exploitation’ solutions like blocking shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-51006483570815345282018-10-16T02:03:00.000-07:002018-10-16T02:12:25.096-07:00Blind Lambda Event Injections without Outbound Connections
Serverless functions, like AWS Lambda, have similar injection opportunities as in traditional applications, API's and other components. It is usually difficult to identify blind spots and exploit this kind of vulnerabilities, though there are various tools and methods available to identify these blind spots. The most common methods to identify these issues are timing attacks and logical shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-22611320304262163102018-10-09T23:10:00.000-07:002018-10-09T23:20:45.237-07:00Runtime Lambda Protection (Part 3) – "Self-Inspection"
Serverless functions, like AWS Lambda, are uniquely placed and transient in nature. These functions need a non-standard approach for both pentesting as well as defense. In the past blogs, we have covered the following two aspects for protecting lambda functions using the 'protectLambda' utility of the 'lambdaScanner' toolkit (can be downloaded from here).
1. Runtime Lambda Protection – "shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-42158970000695274422018-09-21T22:26:00.001-07:002018-09-21T22:27:22.374-07:00Runtime Lambda Protection (Part 2) – Monitoring, Analytics and Alerts (Real-Time)
In the last blog, we discussed about how traditional defense solutions are not sufficient for protection of lambda functions and how 'protectlambda', a small utility from the 'lambdaScanner' toolkit, can be used to guard incoming as well as outgoing stream through a set of predefined rules. Please refer to http://blog.blueinfy.com/2018/09/runtime-lambda-protection-self-defense.html (here) for shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-80656280902740313222018-09-11T23:17:00.000-07:002018-09-18T04:25:17.492-07:00Runtime Lambda Protection – "Self Defense" from Inside
Brief:
Serverless functions, like AWS Lambda, are transient, temporary and do not have traditional defenses like WAF/IPS/IDS/RASP. Moreover, these functions are not always invoked through API gateway over HTTP(S), where one can provide defenses like WAF to filter for malicious payloads. Lambda functions consume “events” coming from various sources like S3, DynamoDB, SQS etc. (as shown in the shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-84926193545542111892018-09-07T02:48:00.000-07:002018-09-07T02:48:15.217-07:00Leveraging tunnelLambda with pentesting tools for serverless function testing
One of the challenges for lambda function testing is to incorporating and integrating traditional effective tools like netcat, burp proxy or sqlmap. These tools runs on HTTP(S) pipes while lambda function's events can be coming from any where without HTTP pipe. Hence, one can leverage tool like tunnelLambda while performing pentesting. It is part of our scanLambda toolkit (Here - http://shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-59748870100459126832018-09-04T02:01:00.000-07:002018-09-04T02:01:45.277-07:00lambdaScanner - Scan and Secure serverless lambda functions
'lambdaScanner' is a toolkit which has a combination of scripts for
performing penetration testing of lambda functions. The scripts
available in the toolkit help assessing the lambda functions from a
security standpoint. It helps the tester to discover vulnerabilities in
deployment as well as code. It aids in checking vulnerabilities like
improper permissions, SQL injections, command shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-47478523366430091882018-08-24T03:04:00.000-07:002018-08-24T03:15:06.444-07:00Lambda Event Assessment and Pentesting – Invoke, Trace and Dissect (Part 3)
In the last two blog posts, we covered an approach of pentesting lambda functions, using DAST and SAST methodologies, by footprinting, enumerating, scanning and tracing lambda functions to discover and verify security vulnerabilities. In this blog post, we will leverage instrumentation/IAST (Interactive Application Security Testing) approach to analyse and test lambda functions. This approach shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-70970520672806886512018-08-20T00:02:00.000-07:002018-08-24T03:00:55.872-07:00Lambda Event Assessment and Pentesting – Invoke, Trace and Dissect (Part 2)
In the last blog post, we talked about the basic methodology for lambda testing where we covered enumeration, profiling and invocation. We can do a quick fuzzing of the lambda function by passing a set of payloads. Lambda functions can be used to build micro services, which get incorporated into the web applications as part of the architecture. These functions can be called in both synchronous shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-1747330324045277882018-08-07T02:46:00.002-07:002018-08-07T02:47:34.256-07:00Lambda Event Assessment and Pentesting – Invoke, Trace and Dissect (Part 1)
Lambda functions are at the core of applications. These functions are invoked, through various events, from various sources like browser, mobile devices or via API calls etc. The events through which the lambda functions are invoked have a pre-defined format for event payloads. The payloads sent via events are eventually consumed by the user-defined code (functions). An attacker, with a shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-13417861260272396322018-07-24T04:06:00.000-07:002018-07-24T07:47:55.919-07:00Enumerating Lambda functions for Pentesting
Lambda functions can be directly pentested as discussed in the last post. We would like to take it to the next level by illustrating the methodology to automate pentesting. It is interesting to leverage scripting to automate reviewing Lambda functions from security standpoint. We can use SDK and libraries available in various languages. In this post, we are using python with boto3. More detail shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-19985824781545551472018-07-16T00:08:00.000-07:002018-07-16T00:08:09.985-07:00Fuzzing Serverless Lambda functions directly
Serverless application (FaaS - Function as a Service) development and use of microservices model are emerging in next generation applications and architecture. It is becoming easier to maintain and cost effective in the days of DevOps era. It is imperative to do a quick testing of these functions from security standpoint and look for common vulnerabilities like injections. Amazon provides Lambdashreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-15191939540938850622018-07-05T02:21:00.000-07:002018-07-05T02:21:36.490-07:00JSON Parameter Pollution
HTTP parameter pollution attack is known to the industry for quite some time now. In HTTP parameter pollution attack, an attacker plays with order of HTTP parameters going to web/application server as part of querystring and/or POST parameter. Attacker tries to confuse HTTP parsers and leverages vulnerable code. Further details on HTTP parameter pollution (HPP) can be found at OWASP - https://shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-8803762561736415792018-01-23T02:02:00.002-08:002018-01-23T02:04:52.540-08:00Securing APIs – Defence Controls for Developers
APIs have emerged as a solid backbone of applications in this modern world of mashups where applications are using one back-end with multiple front-ends. REST based APIs running over HTTP with JSON or XML are becoming preferred choices for developers. However, API end points are also becoming points of attack for attackers. Hence, developers need to implement proper security controls across APIsshreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-62153789908870947762017-12-22T21:19:00.002-08:002017-12-22T21:19:32.391-08:00Server Side Request Forgery (SSRF) Attack and Defence
Server Side Request Forgery (SSRF) is an interesting vulnerability, which can have potential impact on internal infrastructure residing behind firewall. In this case, HTTP server running over ports like 80/443 becomes an entry point for an attacker to enter into internal network over as legitimate HTTP/HTTPS tunnel.To understand this vulnerability in detail, let’s assume we have a vulnerable shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-32436200462164083942017-12-13T03:57:00.000-08:002017-12-13T03:57:03.611-08:00XXE Attack – A4 of OWASP Top 10
XML External Entities (XXE) issue is added to newly listed OWASP Top 10 vulnerabilities list. In current world, number of applications is using XML streams or Web Services (SOAP) for back-end processing. Hence, browser or client can make this simple XML call over HTTP POST and fetch XML response from the server as shown in the figure -
Once XML stream hits to the application server, it needs shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-59331671508499232692017-12-04T22:08:00.001-08:002017-12-04T22:24:40.248-08:00Insecure Deserialization Attacks – OWASP A8 2017
HTML5 and Web 2.0 applications are using modern architecture and modelling for web programming. It has opened up relatively different ways of attacking and exploiting. One of the issues, which are easy to detect and exploit by manual analysis, is called insecure deserialization. This is not new attack category but OWASP Top 10 came up with this vulnerability into their current list and started shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-1727146224366515512017-11-27T01:50:00.001-08:002017-11-27T02:15:07.047-08:00New OWASP Top 10 (2017) - What is NEW and final state?
Here is the view on top 10 from OWASP
Resource on OWASP - Get it from HERE
Injections are still on the top. It makes sense since lot of attack vectors are leveraging poor validation controls. It leads to injections like SQLi, Command injections etc, and are still very common across applications.
Broken authentication is still a very common issue, it is very easy to discover by human shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-67709900850765612752017-11-07T00:54:00.005-08:002017-11-07T00:54:56.289-08:00HTML5 Drag and Drop abuse with ClickJacking
We came across interesting observation/article over herehttps://medium.com/@arbazhussain/weaponizing-clickjacking-attack-with-click-content-jacking-ab50cb6a37ed
It is possible to Hijack content by click jacking by loading two frames coming from the same domains. If domain is the same then it is possible to drag and drop API to function between two frames. Hence, it is possible to force victim shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-88578598829746056062017-09-08T22:30:00.002-07:002017-09-08T22:31:24.944-07:00(Advisory) Patch your Apache Struts
Researchers discovered a critical and easily exploitable vulnerability in Apache Struts framework recently. Exploitation can lead to remote command execution and complete control of the machine via web server. Web Server running on port 80/443 is not blocked by firewall and can be exploited at ease.
Here is the original note from research group -
https://lgtm.com/blog/shreerajnoreply@blogger.comtag:blogger.com,1999:blog-2381558387800400132.post-74156739775076363822017-07-19T04:20:00.001-07:002017-07-19T23:55:12.956-07:00Blind and Asynchronous injections, techniques and exploitations
Web applications and APIs are vulnerable to set of injections like SQL, command, SMTP etc. Some of these injections are easy to detect since their behavior are synchronous and visible. Synchronous and visible implies, you send simple HTTP request with payload and you get HTTP response back which has clear indication of success. Hence, request-response are synchronous and outcome of vulnerabilityshreerajnoreply@blogger.com