Kailash Bohara

Container Security Hardening Guide and its Importance

2026-07-21T00:00:00+00:00

Why Container Security Matters

Containers share a kernel. Unlike virtual machines, they are not hard boundaries they are namespaced processes with optional control group limits and Linux security modules layered on top. When we treat containers like as “VMs,” and think it inherit controls like VMs such as internal traffic is trusted, root inside the container is harmless this does not satisfies in Kubernetes.

In a monolithic application architecture, compromise might mean one server. But in Kubernetes:

One privileged pod can read host filesystems, access cloud metadata APIs, or pivot to the node IAM role.
One poisoned image in CI can deploy to every environment that trusts the pipeline.
One missing NetworkPolicy can leave the entire cluster open to internal reconnaissance between microservices.

Compliance and Customer Trust

Regulators and auditors expect evidence that production workloads are built from verified artifacts, run with least privilege, encrypt sensitive data, and leave an audit trail when configurations change. Frameworks such as SOC 2, ISO 27001, HIPAA, and PCI DSS all map to concrete Kubernetes practices: signed images and SBOMs for supply chain integrity, RBAC and secret management for access control, NetworkPolicies for segmentation, and centralized logging for monitoring and incident response. Below are basic controls that auditors might ask evidence for:

Signature verification logs at deploy time
SBOM + vulnerability scan reports per release
Least-privilege RBAC and secret handling
Use of non-root user and no privileged pods
Kubernetes audit logs for who changed cluster resources and when
Scan report that align with CIS Benchmarks and Pod Security Standards

Cost of Getting It Wrong

Missing Controls	Typical Impact
Root + privileged pod	Node compromise, cluster takeover
`:latest` tag in production	Uncontrolled rollbacks, unknown CVE exposure
Secrets in ConfigMaps	Credential theft, data exfiltration
No network segmentation	Lateral movement after initial foothold
Weak CI/CD identity	Supply chain compromise at scale

Defense in Depth: How the Control Domains Fit Together

The security controls below are not separate items to pick and choose from. They work together like layers of one system.

flowchart TB
    subgraph Layer1["Layer 1: Supply Chain & Deployment"]
        A1[Signed Images]
        A2[SBOM Validation]
        A3[GitOps + Approvals]
        A4[Separate Build/Deploy Identity]
    end

    subgraph Layer2["Layer 2: Cluster & Infrastructure"]
        B1[API Server Hardening]
        B2[etcd Encryption]
        B3[Node Hardening]
        B4[Admission Controllers]
    end

    subgraph Layer3["Layer 3: Workload Configuration"]
        C1[Non-Root / PSS Restricted]
        C2[Resource Limits & QoS]
        C3[Network Policies]
        C4[Service Mesh mTLS]
    end

    subgraph Layer4["Layer 4: Runtime & Detection"]
        D1[Image Scanning]
        D2[Runtime Anomaly Detection]
        D3[Falco Alerts]
        D4[Audit Logging]
    end

    Layer1 --> Layer2 --> Layer3 --> Layer4

    style Layer1 fill:#e8f4fd
    style Layer2 fill:#d4edda
    style Layer3 fill:#fff3cd
    style Layer4 fill:#f8d7da

Secure Reference Architecture

The following diagram illustrates a production-grade secure container platform.

flowchart LR
    Git[Git Repository] --> CI[CI Pipeline<br/>Build · Scan · Sign · SBOM]
    CI --> Reg[(Private Registry)]
    Reg --> CD[GitOps Deploy<br/>+ Prod Approval]
    CD --> K8s[(Kubernetes Cluster)]
    K8s --> Policy[Policy Layer<br/>Admission · PSS · Network]
    K8s --> Observe[Observability<br/>Logs · Metrics · Runtime]
    K8s --> Identity[Identity<br/>Secrets · Service Accounts]
    style CI fill:#e8f4fd
    style CD fill:#d4edda
    style K8s fill:#fff3cd

Internal cluster traffic is not automatically secure. We should implement Network Policies and service mesh mTLS for identity-aware communication.

flowchart TB
    subgraph Ingress["Ingress Layer"]
        WAF[WAF / API Gateway]
        TLS[TLS Termination]
    end

    subgraph NS_Frontend["Namespace: frontend"]
        FE[Frontend Pods]
    end

    subgraph NS_API["Namespace: api"]
        API[API Pods]
    end

    subgraph NS_Data["Namespace: data"]
        DB[(Database Pods)]
    end

    subgraph Egress["Egress Control"]
        EGW[Egress Gateway / Firewall]
        Ext[External APIs]
    end

    Internet((Internet)) --> WAF --> TLS --> FE
    FE -->|"NetworkPolicy: allow 443"| API
    API -->|"NetworkPolicy: allow 5432"| DB
    API -->|"Restricted egress"| EGW --> Ext

    FE -.->|"mTLS via Service Mesh"| API
    API -.->|"mTLS via Service Mesh"| DB

    style NS_Frontend fill:#e8f4fd
    style NS_API fill:#d4edda
    style NS_Data fill:#fff3cd

Why Golden Images Matter

A golden image is a pre-approved, minimal base image that every team should builds instead of pulling random public images. Think of it as the standard front door every application must use—same locks, same thickness, same inspection before anyone moves in.

Why security teams care:

Smaller attack surface : A slim base image contains fewer packages, which means fewer known vulnerabilities to patch and fewer places for attackers to hide tools.
Consistent hardening : Non-root user, dropped capabilities, and security patches are applied once in the golden image, not reimplemented (or forgotten) by every development team.
Faster, reliable scanning : When all apps share a known base, vulnerability scans are repeatable. You scan the golden image and every app built on top of it inherits that baseline.
Audit and compliance : Auditors can review one approved image pipeline instead of hundreds of one-off Dockerfiles. You can show exactly what is allowed to run in production.
Supply chain control : Only blessed images from your private registry get deployed. Unknown or tampered public images never reach the cluster.

Implementation Roadmap

Prioritize controls by risk reduction vs effort. The phased approach below mirrors what most security engineering teams deploy successfully.

flowchart TB
    subgraph P1["Phase 1 — Foundation (Weeks 1–4)"]
        direction TB
        P1A[Non-root users and resource limits]
        P1B[Private registry with pinned tags]
        P1C[RBAC review and service accounts]
        P1D[Centralized logging]
    end

    subgraph P2["Phase 2 — Policy (Weeks 5–10)"]
        direction TB
        P2A[Image scanning in CI]
        P2B[Pod Security Standards]
        P2C[Admission controllers]
        P2D[Default-deny Network Policies]
    end

    subgraph P3["Phase 3 — Supply Chain (Weeks 11–16)"]
        direction TB
        P3A[Signed images and SBOM]
        P3B[GitOps with production approvals]
        P3C[Separate build and deploy identities]
    end

    subgraph P4["Phase 4 — Advanced (Ongoing)"]
        direction TB
        P4A[Encrypted service-to-service traffic]
        P4B[Runtime threat detection]
        P4C[Automated benchmark compliance scans]
    end

    P1 --> P2 --> P3 --> P4

    style P1 fill:#e8f4fd
    style P2 fill:#d4edda
    style P3 fill:#fff3cd
    style P4 fill:#f8d7da

Phase 1 — Easy to implement (Weeks 1–4)

Enforce non-root, drop capabilities, read-only root FS where feasible
Eliminate :latest; pin image digests
Define CPU/memory limits on all workloads
Enable centralized logging and basic monitoring alerts
Audit RBAC; remove broad admin access where possible

Phase 2 — Policy Enforcement (Weeks 5–10)

Deploy admission policies to block privileged pods and unapproved registries
Adopt Pod Security Standards (restricted for new workloads)
Implement default-deny NetworkPolicies per namespace
Integrate image scanning in CI

Phase 3 — Supply Chain Integrity (Weeks 11–16)

Sign images; verify signatures at admission
Generate and store SBOMs per release
Use GitOps with branch protections and production approval workflows
Split CI build identity from CD deploy identity

Phase 4 — Runtime & Zero Trust (Never ending process)

Encrypt service-to-service traffic for sensitive tiers
Runtime anomaly detection and automated response playbooks
Continuous benchmark compliance scanning
Secret rotation automation

Threat Model: Before and After Hardening

flowchart LR
    subgraph Before["Before Hardening"]
        T1[Attacker] --> I1[Compromised App]
        I1 --> P1[Privileged Pod]
        P1 --> N1[Node + IAM Role]
        N1 --> C1[Cluster Admin / Cloud Account]
    end

    subgraph After["After Hardening"]
        T2[Attacker] --> I2[Compromised App]
        I2 -->|NetworkPolicy blocks| X1[Blocked Lateral Move]
        I2 -->|Non-root + seccomp| X2[Escalation Failed]
        I2 -->|Runtime alert| SOC[SOC Detects & Isolates]
        I2 -->|Scoped SA only| X3[No Cloud Metadata Access]
    end

    style Before fill:#f8d7da
    style After fill:#d4edda

Conclusion

Container security is not a single tool. It is architecture, process, and culture expressed through enforceable controls. The checklist your organization is implementing spans runtime isolation, resilient operations, observability, supply chain integrity, identity, network zero trust, runtime detection, governance, and platform hardening. Each domain reinforces the others.

As a security engineer, my advice is direct: start with what attackers exploit first privileged pods, public images, missing network segmentation, and over-permissioned CI/CD and automate denial of bad configurations at admission time. Scanning and monitoring catch what policy misses.

Container Security Hardening Guide and its Importance was originally published by Kailash Bohara at Kailash Bohara on July 21, 2026.

Hardcoded Credentials in an Android Application Leading to Unauthorized API Access and PII Exposure

2025-07-07T00:00:00+00:00

Description

During a security assessment of an Android application, hardcoded secrets, including the clientID and clientSecret, were discovered embedded directly in the application’s source code. These credentials were trivially accessible to anyone who decompiles or inspects the APK. With these credentials, an attacker could authenticate against the application’s backend APIs and retrieve sensitive data, including customers’ Personally Identifiable Information (PII).

Impact

By leveraging the hardcoded credentials, an attacker can:

Authenticate to backend APIs without any user interaction or authorization flow.
Extract PII such as names, email addresses, phone numbers, and physical addresses.
Enumerate and dump data across multiple API endpoints.

A breach of this nature can result in regulatory fines, legal consequences, reputational damage, loss of customer trust, and potential fraud.

Vulnerable Endpoints

The credentials were found in the following decompiled classes:

com/[redacted]/app/BuildConfig.java
com/[redacted]/app/StidClientModule.java

Steps to Reproduce

Decompile the APK (e.g., using jadx or apktool). In this case, we used MobSF.
Open the BuildConfig.java file. Multiple sensitive keys, tokens, and credentials are hardcoded in plaintext.
Following the API documentation, we identified the authentication flow for the backend services.
Construct a Basic Authorization header from the extracted clientID and clientSecret.
Exchange the Basic Auth token for an access_token via the token endpoint.
Using the access token, fetch the existing sites for this particular client.
Make a GET request to https://[redacted]/api/GetVirtualCardListV2/?siteId=[redacted]. The response returned thousands of records containing PII (email addresses, phone numbers, and other personal data).

Lessons Learned

Never hardcode secrets in client-side code.
Implement proper OAuth 2.0 flows where tokens are issued server-side and scoped appropriately.
Apply rate limiting and anomaly detection on API endpoints to detect bulk data extraction.
Conduct regular static analysis scans on mobile builds to catch hardcoded secrets before release.

Hardcoded Credentials in an Android Application Leading to Unauthorized API Access and PII Exposure was originally published by Kailash Bohara at Kailash Bohara on July 07, 2025.

Website Source Code Analysis To AWS Account Takeover

2024-05-06T00:00:00-00:00

We are going to discuss a vulnerability that I found by checking the source code of a website, which escalated to gaining access to the AWS account of an organization.

During the security assessment of an organization, I began by browsing their corporate website to understand their business purpose and the solutions they provide. Since the corporate website only had static information and nothing more, I started scanning for subdomains using the subfinder tool.

I found only three subdomains using Subfinder and didn’t bother to look for more because I was convinced with the result. Instead, I started looking into the admin subdomain, admin.target.com.

To my surprise, when I visited admin.target.com, I got a pop-up message from the Trufflehog browser extension.

If you don’t know about TruffleHog

TruffleHog is a browser extension that helps find and detect API keys, credentials, and other sensitive information that may be accidentally exposed in JavaScript code on websites

The Trufflehog pop-up gave me hope that the AWS Access key and AWS Secret key might exist. To confirm this, I browsed the mentioned JS file, i.e., https://admin.example.com/main.js, and searched for the keys. I also used the JavaScript beautifier tool to make the chunked JS code look organized, and the result looked like this:

In the image above, we found the AWS Access Key, Secret Key, Bucket and the upload path as well. Access and secret keys are very sensitive information.

In AWS Identity and Access Management (IAM), Access Key and Secret Key are credentials used to authenticate and authorize interactions with Amazon Web Services (AWS) APIs and services. Using these keys one can make requests to various AWS services.

Now using the AWS CLI, we can configure the found keys and can request AWS. AWS CLI is a utility tool which allows users to manage AWS services directly from the command line. To do so, we need to install AWS CLI first. After the installation of AWS CLI, I configured it using the following command.

aws configure

After this, I had to input the found access and secret keys. Once I provided the required information, I attempted to list the available buckets in that particular AWS account using the following command:

aws s3 ls

Damn! Both the keys were valid and all the S3 buckets were listed as shown.

I have masked the bucket names as they have misconfiguration in them and holds sensitive data. Checking the caller identity using the command It was found that the IAM user was specific for the S3 bucket.

aws sts get-caller-identity

Then, I attempted to directly visit the S3 bucket URL, as there might be cases of object listing enabled in public buckets due to poorly configured bucket ACLs. The result was alarming: multiple documents and SQL backup files were there.

Lessons Learned:

Avoid hardcoding secret keys or credentials in source code.
Regularly rotate AWS access/secret keys for added security.
Configure Bucket ACLs properly to prevent unauthorized object listings.

Website Source Code Analysis To AWS Account Takeover was originally published by Kailash Bohara at Kailash Bohara on May 06, 2024.

Cloudflare transform rules to get an A+ in the security header.

2023-08-10T00:00:00+00:00

In today’s digital age, security is a vital aspect of any website. One way to improve website security is to add security headers to your website. Security headers are a set of HTTP response headers that inform the browser how to behave when it comes to website security.

In this blog, we will show you how to add security headers to your static website using Cloudflare transform rules. The transform Rules allow us to manage the URI path, query string, and HTTP headers of requests and responses. By Applying the HTTP response header modification rules we will set all required security headers to get an A+ score. Let’s check our website score before configuring the rules using https://securityheaders.com.

We got an ‘F’ grade in website HTTP headers. 😀 The next approach would be fixing the headers and getting ‘A+’ grade. The main complexity here is the website https://kailashbohara.com.np/ is hosted using GitHub Pages and we have no control on the server to set HTTP headers as the server-level control is not available in GitHub. The next thing is we are using Jekyll on this website, if this has been made with PHP we can set headers directly in PHP code. Okay! let’s fix this issue using Cloudflare transform rules.

First, we need to confirm that we have enabled the “orange cloud” so that traffic flows through Cloudflare and we can implement various features on it.

The next step is to create a list of rules in Cloudflare Transform rules. From your Cloudflare dashboard, select the target website and then go to Rules>Transform Rules>modify Response Header. Then create a new rule checking All incoming requests and set the static response header as shown below. Here, we have implemented X-Frame-Options: SAMEORIGIN header for preventing clickjacking attacks.

In a similar way, set more security headers as shown below.

This adds seven security headers to our website:

Content-Security-Policy: base-uri 'self'; default-src *; //sets rules for resources that can be loaded on a web page
Permissions-Policy: accelerometer=(), ambient-light-sensor=(), autoplay=(), battery=(), camera=(), cross-origin-isolated=(), display-capture=(), document-domain=(), encrypted-media=(), execution-while-not-rendered=(), execution-while-out-of-viewport=(), fullscreen=(), geolocation=(), gyroscope=(), keyboard-map=(), magnetometer=(), microphone=(), midi=(), navigation-override=(), payment=(), picture-in-picture=(), publickey-credentials-get=(), screen-wake-lock=(), sync-xhr=(), usb=(), web-share=(), xr-spatial-tracking=() //provides a mechanism to allow and deny the use of browser features in a document or within any iframe
Referrer-Policy: same-origin //controls how much referrer information should be included with requests
Strict-Transport-Security: max-age=31536000; includeSubDomains //informs browsers that the site should only be accessed using HTTPS
X-Frame-Options: SAMEORIGIN //indicate a browser not to render a page in a <frame>, <iframe>, <embed> or <object> tag
X-Permitted-Cross-Domain-Policies: none //limit which data external resources, such as Adobe Flash and PDF documents, can have access on the domain
X-XSS-Protection: 1; mode=block //stops pages from loading when they detect reflected cross-site scripting (XSS) attacks

After setting up these headers and turning on the transform rules, let’s check our score on https://securityheaders.com/ and we got an A+ grade.

That’s it! By following these simple steps, we can add security headers to our static website using Cloudflare transform rules. This will help boost the security of any website (static/dynamic) protecting it from common security threats.

Reference: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

Cloudflare transform rules to get an A+ in the security header. was originally published by Kailash Bohara at Kailash Bohara on August 10, 2023.

Comprehensive Blog on the Exploitation and Prevention of AWS Route 53 Vulnerabilities

2023-04-10T00:00:00+00:00

Route53 is a service that holds DNS records for our domain and the hosted zones. The services offered by an organization cannot be listed all in a main domain. Hence, an organization often creates subdomains to host different services.

For example, if we have example.com as a domain. Then, we can create a list of the following domains for different purposes.

support.example.com - Customer support service

blog.example.com - To host an organization blog

mail.example.com - To host email service

careers.example.com - Job page

Modern websites often use third-party services in subdomains to provide different services. Third-party services like Zendesk, JIRA, Salesforce, Gitlab, Email services, etc. can be integrated into a subdomain.

The subdomain takeover vulnerability usually occurs when the service used in our subdomain is discontinued but the DNS records remain in our route 53 records. In this case, an attacker can re-register for the service and the DNS records are already in place. This makes the service alive in the targeted subdomain and the control of the subdomain is transferred to an attacker. An attacker can host any malicious or false content after the successful subdomain takeover.

To demonstrate the subdomain takeover in Route 53 We will create a static website in the S3 bucket and then we’ll point that S3 bucket in Route 53.

Later, we’ll delete the bucket but we will not delete the Route 53 record keeping this vulnerable to an attacker. Then, we will take over the subdomain by creating the deleted bucket in our AWS account.

Part -1: Creating a Static website in the S3 bucket.

In this part, we will create an s3 bucket upload an HTML file to it and configure it for static website hosting.

Go S3 bucket and create a new bucket with the blog.enhancingsecurity.com

Make sure you check “ACLs enabled” in object ownership and uncheck “Block all public access”, as this is a website and its file should be accessible to the public.

Now, we will write a simple HTML file and upload it into the bucket.

After successful upload, Go to bucket properties and scroll to the bottom of the page. There you can see the feature of enabling “Static website hosting”. Make sure you enable this. While enabling this we need to specify the default page for our website. We will input “index.html” as the default page for our blog website.

Once the static website is created we can see our website address as shown below.

Now, we’ll make the bucket objects public by selecting all the objects of the bucket and going to the Actions menu and selecting “Make public using ACL”

Once we make the objects public the website should render as shown below by visiting the bucket website endpoint.

Part -2: Pointing S3 static website to a subdomain

We have successfully created a static website in the s3 bucket. The bucket website endpoint is http://blog.enhancingsecurity.com.s3-website-ap-southeast-1.amazonaws.com and now we will point this address to blog.enhancingsecurity.com so that this bucket address resolves to our subdomain.

Go to Route 53 and select a hosted zone for enhancingsecurity.com. We can see the DNS records below.

Now we will create another subdomain with the name blog. The final subdomain will be blog.enhancingsecurity.com
While creating a subdomain, select record type as “A record”, enable Alias and select Route traffic to Alias to S3 Website endpoint. And then select the bucket region as Singapore (we created a bucket in this region in Step 1). You’ll option to select the s3 bucket endpoint as shown below.

Now we can see blog.enhancingsecurity.com pointed to s3-website-ap-southeast-1.amazonaws.com. which resolves to our static s3 website.

As we can see our S3 static website content in the blog.enhancingsecurity.com

Part -3: Deleting the S3 Bucket

In this section now we will delete the S3 bucket where we have hosted content for our blog. To do this simply go to Amazon S3 and delete the bucket content and then delete the bucket.

Now try to resolve the subdomain http://blog.enhancingsecurity.com/ and we can see the following error message.

The error message indicates that the bucket does not exist. This means that anyone can register the bucket with the same name and host the desired content. Now, we will do the same in part -4.

Part -4: Taking over the Subdomain

Now we will log into another AWS account and create a s3 bucket with the same name blog.enhancingsecurity.com in the Asia Pacific (Singapore) ap-southeast-1 region.

Like before we will upload a file and make the bucket publicly accessible and also make the object public access using ACL. Then we will upload an HTML file with our takeover message as shown below.

Like before we are enabling the static website hosting feature and specifying the index.html file as an index document which has a subdomain takeover message.

Now if we visit the blog.enhancingsecurity.com we can see that we can host our content on that website by creating a s3 bucket in our AWS account.

This is how we can take over the subdomain of a website if it has existing DNS records and is eligible for takeover. You refer to this GitHub repo to check which services are vulnerable to takeover and which are not. Can I Take Over XYZ

Elastic Beanstalk:

AWS Elastic Beanstalk is a service that makes it easy to deploy and scale web applications and services. If an Elastic Beanstalk environment is misconfigured or becomes unused, an attacker could potentially register the same subdomain that was previously used by the Elastic Beanstalk application. This could allow the attacker to take control of that subdomain and potentially gain access to sensitive information or resources associated with the original application.

Identifying vulnerable Elastic Beanstalk domains is quite easy. We only need to check that we get an NXDOMAIN response to our DNS query and that the pointed domain has the form ..elasticbeanstalk.com

Go to the Elastic Beanstalk service in AWS and create a new app with the following configuration.

On the same page, we will select a basic app code to make it run. For now, we are selecting a NodeJs web application.
After completing all the steps we will see our application is launching with a unique AWS Elastic Beanstalk domain as shown below.

Opening the Elastic Beanstalk domain we can see NodeJs default page below.

Now we’ll point this elastic beanstalk app to route53 DNS record to point it to myapp.enhancingsecurity.com. We will create an “A record” for our subdomain that points to our created beanstalk environment.

After the successful point, we can see our default NodeJS app is loaded in myapp.enhancingsecurity.com

Now we’ll delete the Beanstalk app but not the Route 53 record and check the ns record using the command

 nslookup myapp.enhancingsecurity.com

If we see the message “** server can’t find myapp.enhancingsecurity.com: NXDOMAIN,” this confirms that our subdomain is vulnerable to takeover.

Now, we will create the elastic beanstalk app with the same name in the same region in another AWS account. This will point our beanstalk app to the subdomain myapp.enhancingsecurity.com. This time, we are selecting a web app as PHP, and we get the beanstalk domain response as below.

Checking the subdomain http://myapp.enhancingsecurity.com/ we get our PHP application is running.

AWS Route53 DNS Security Practices

Periodically audit and clean up outdated or unused DNS records to reduce the attack surface.
Enable Domain Privacy Protection in AWS Route 53 to protect domain owners’ personal information.
Enable Auto-Renewal for a Domain. This prevents service disruptions or loss of ownership.
Restrict access to Route 53 resources with finely tuned Identity and Access Management (IAM) policies, granting the least privilege permissions only to users and applications that need them.
For private hosted zones, limit access to Route 53 resolvers to only trusted VPCs to protect internal DNS data.

Comprehensive Blog on the Exploitation and Prevention of AWS Route 53 Vulnerabilities was originally published by Kailash Bohara at Kailash Bohara on April 10, 2023.

Exploiting thousands of Domains for XSS

2023-01-02T00:00:00+00:00

This blog post is about Cross-Site Scripting (XSS) vulnerability found on the secure page of GoDaddy.

While pen testing in wide scope for a client I found a subdomain as files.example.com. Opening in browser results as shown below

After that, I ran a Burp Suite auto scan over it, and the reflector (a Burps Suite extension) showed that some inputs got reflected in the response.

Now it’s time to find a vulnerability for script injection. After analyzing the suspicious parameter, I found a possible way for the execution of JavaScript code and was finally able to execute it as shown below. The vulnerable URL looks like: http://files.example.com/index.php/”onmouseleave=”alert(‘XSS’)”

But wait, what is the use of this webpage, and who added this subdomain? Checking the CNAME of this subdomain, I found that it belongs to Godaddy.

As a service provider, Godaddy must have thousands of clients using this service (probably the file-sharing feature), and all of them are vulnerable to the Cross-Site Scripting (XSS) vulnerability. To verify this, I thought of using simple Google Dork to find similar web pages.

However, this is not the appropriate way, hence I discussed with @smaranchand possible ways of gathering all the subdomains on the internet that are using files.secureserver.net as CNAME in their DNS records. He came up with the idea of using Silent Push. We used reverse CNAME lookup to find affected domains for the XSS vulnerability and found that around 13,092 domains were vulnerable. This is a very large number of vulnerable systems that we can impact with a vulnerability.

After confirming the vulnerability on a few subdomains, I decided to notify GoDaddy security and email them a detailed proof of concept using their email security@godaddy.com. However, they didn’t respond until. To my surprise, the vulnerability has been patched by them. After a few searches, I also came to know that the same vulnerability had previously been reported by turbobarsuchiha. She also did not receive any reasonable response from GoDaddy and decided to post on her blog.

Lesson Learned:

Always monitor third-party DNS entries and hosted applications for possible threats and vulnerabilities.
Never exclude static pages for security testing.
Examine each issue generated by Burp Suite manually.

Exploiting thousands of Domains for XSS was originally published by Kailash Bohara at Kailash Bohara on January 02, 2023.

How I bypassed PHP functions to read sensitive files on server

2022-02-04T00:00:00+00:00

During the penetration testing of a target, the nuclei results show that the website of an organization is vulnerable to code execution vulnerability i.e CVE-2017-9841. The CVE-2017-9841 vulnerability lets a user run PHP code on vulnerable websites remotely, by exploiting a breach in PHPUnit lets us run desirable PHP codes and read sensitive files.

After checking all the things, I verified the existence of vulnerability making the proper request in Burp suite, and confirmed by running of the PHP function, getcwd() that returns the current working directory. Now there won’t be any problem running system commands by using the shell_exec() function in PHP. This function executes user-supplied commands and returns output as a string. I did this by simply listing all the home directories/files of the current user. Finally, reading the config file was just easy as reading this post. I stopped over here and thought of reporting this issue to the organization but because of the tight schedule of my daily life I was unable to report the issue for 4-5 days. After a few days I thought of reporting the issue but wanted to confirm whether the vulnerability still exists or not. But to my surprise 😕 It wasn’t working as before 😂. As per my guess within 4-5 days, the administrator might have checked the logs or might be aware of the exploit that I tried and made fixation to it. Hence, the execution of shell_exec() function was forbidden. However, few other functions could still be executed except shell_exec(). From the image below I confirmed that the execution was forbidden by applying some filter in the phpinfo file. Along with shell_exec(), other functions like show_source(), system(),shell_exec(), exec(),popen() and proc_open() which can be used to read/write files were also disabled. After this I started looking for other possible ways to read the files again, and found we can use the glob() method to return an array of filenames and directories. I used following snippet of code locally and confirmed it returns the array of files and directories.

<?php
print_r(glob("*"));
?>

Eventually, I was able to list the files again as shown below, and now all that’s left is to find a way to read those listed files. At the end, I figured out that I had to combine multiple functions together to read files.

<?php $a = '../../../../../../../public_html/application/config/database.php';
$b = explode(',',file_get_contents($a));
print_r($b); ?>

In the above code,

$a variable is used to set target file which we are going to read. The target file was found using print_r(glob())
In the $b variable, we used explode function to return array of strings. file_get_contents() reads contents of database.php from public_html/application/config/database.php and contents array is returned.
Finally, printed contents of $b variable using print_r() or var_dump() can also be used.

How I bypassed PHP functions to read sensitive files on server was originally published by Kailash Bohara at Kailash Bohara on February 04, 2022.

MSSQL Injection In JSON Request

2021-05-16T00:00:00+00:00

SQL injection is a web security vulnerability that allows an attacker to interfere with the queries that an application makes to its database. It generally allows an attacker to view data that they are not normally able to retrieve. The impact of the SQL Injection can be extracting data from the database, dropping data, gaining OS or SQL shell access etc.

As it was private scope, I do not want to disclose the application name. So, I was testing the android application of it. I had to bypass SSL pinning to intercept the application requests. Finally, I was able to do it. The first page was the registration page while opening an app, I filled in all the necessary details. An OTP code was sent to our provided phone number. I used a random six-digit code and intercepted the OTP validation request as shown below. Then I sent the above request to Repeater tab in Burp suite and added a single quote on DeviceId parameter. Modified requests look like "DeviceId":"lol'" And the response was like: This confirms the existence of the vulnerability. To be assured I used the time delay command for few databases as SLEEP(10) WAITFOR DELAY '0:0:10' SELECT pg_sleep(10) and second one worked as shown below.
Then in the response time, we can see 10ms delays. It confirms MSSQL Injection. To make proof of concept I decided to create a database object using the query 'CREATE TABLE kailash (line varchar(8000));--'

After discussion with the development team, it was confirmed that the above query executed successfully.

Note: I used different devices during the assessment so you may find difference in parameter values in used screenshots.

MSSQL Injection In JSON Request was originally published by Kailash Bohara at Kailash Bohara on May 16, 2021.

Blind XSS on Google Internal System

2021-05-13T00:00:00+00:00

Blind cross-site scripting (XSS) refers to a type of code injection where an attacker inserts XSS payload in user input fields and they are going to be stored somewhere and executes in an application that is not in control of an attacker.

I ended up finding blind XSS in one of the Google’s internal system (GUTS ticketing system). I used blind XSS payload from xsshunter and filled up randomly input fields on the form from Google supplier portal. The forms from the supplier portal must be tracked from GUTS, that’s what I assume and my payload gets executed.

What happened ?

I get a response in my xsshunter after a very long time and at the moment I was unknown which parameter I tested for. I tried to read the DOM so that we may know the possible parameter. Unfortunately, XSS hunter keeps loading and the browser gets frozen. Only Referer and Cookies are known. I passed the information that I have to the Google team and they finally managed to know the actual cause and rewards me.

I requested to disclose a vulnerable endpoint as seen above but ended up with the following message. As part of Google’s Vulnerability Reward Program, the panel has decided to issue a reward of $5000 for this issue as it affects the sensitive application.

Giveaway ?

Always take a log where we tested for XSS. We don’t know when our luck hits in bug bounty.

Blind XSS on Google Internal System was originally published by Kailash Bohara at Kailash Bohara on May 13, 2021.

GraphQL IDOR in Facebook streamer dashboard.

2020-11-18T00:00:00+00:00

Description:

While viewing our stream dashboard data from creator studio, there is an endpoint from where we can see our dashboard status. There is parameter called profile_id in GraphQl request which can be misused to access data of other pages by using facebook page_id.

Steps to Reproduce:

Start burpsuite and intercept the request.
Go to https://www.facebook.com/gaming/streamer and you will be redirected to creator studio.
We will forward all the intercepted request since it’s difficult to spot the correct request which has vulnerable parameters in multiple requests.
Meanwhile we will use find feature in burpsuite. we’ll search for “GamesVideoStreamerDashboardProfileQuery”.
Once our search query matches we will forward that particular request to repeator and replace profileID with desired game steaming pageID to see their stream stats. The response of the above request looks like as shown below. According to facebook only highlighted information i.e. “l30_live_earnings” and “supporter_count” are sensitive which should not be disclosed to a user which does not have any role in the page.

Conclusion:

After reviewing this issue, Facebook decided to award a bounty of $2000 and they fixed the issue by not displaying those information in the response to a users which does not have any role in page.

GraphQL IDOR in Facebook streamer dashboard. was originally published by Kailash Bohara at Kailash Bohara on November 18, 2020.

Stored Cross Site Scripting on Mdaemon Webmail (20.0.0)

2020-07-15T00:00:00+00:00

Two different cross site scripting vulnerabilities were found on version below 20.0.1 and reported to Mdaemon team. As per the resposne from their side both issues were addressed on latest version 20.0.1 released on 18th August 2020.

Case One:

E-mail attachment field is vulnerable to XSS. A attachment with XSS payload as a file name can be uploaded to trigger execution of code. To do that follow steps below:

Rename a file and set it’s name as <img src=x onerror=alert(1)>.jpg
Go to New mail, select recipient and the select attachment. Code gets executed as right after upload so it becomes self XSS.
Let’s send the mail to recipient and open from his/her side. Opening just a mail doesn’t executes the code but when the victim clicks on forward button, XSS pop-up is shown.
Like this a stored self XSS can also becomes perfect XSS for victim users.

Case Two:

So the next vulnerable endpoint is Distribution list. A distribution list holds name and email address of persons. We can also refer it as a address book. Following steps can be followed to execute the vulnerability.

Go to contact section and distribution list menu. Create a new distribution list.
Contact name field was vulnerable to XSS. Use the payload <img src=x onerror=alert(1)>
We can see execution code and after saving it, each time we visits the distribution list section the XSS pop-up is seen.

Stored Cross Site Scripting on Mdaemon Webmail (20.0.0) was originally published by Kailash Bohara at Kailash Bohara on July 15, 2020.

CVE-2020-10596 in OpenCart

2020-05-29T00:00:00-00:00

Cross-site scripting attacks (XSS), are a type of attack in which malicious scripts are injected into websites and web applications and run on an end user’s platform. Vulnerable endpoints are found and JS code is injected to execute it for malicious purposes. Such endpoints can be search fields, profile information fields, file upload functions and many more.

An authenticated attack refers to the conditions where an attacker must be logged to exploit the vulnerability. In OpenCart 3.0.3.2 it is possible to execute cross site scripting attack since the profile image upload feature in admin panel is not escaping user inputs.

To execute follow the steps below.

Login to the admin panel, navigate to system > users > edit an existing user.
Go to the Image change section and select a file with the XSS payload as "><svg onload=alert("XSS")> and save it.
Thats it.

What’s the solution ???

The Same payload gets executed for the directory name too. So, I suggested a regex which replaces special characters in filename/directory names with whitespaces and removes white spaces too.

// Sanitize the filename
$filename = basename(html_entity_decode($file['name'], ENT_QUOTES, 'UTF-8'));
//Using regex to filter filename
$filename=preg_replace('/[^A-Za-z0-9\-\.]/','',$filename);
// Validate the filename length
if ((utf8_strlen($filename) < 3) || (utf8_strlen($filename) > 255)) {
$json['error'] = $this->language->get('error_filename');
}
class GO_Example_Model_Thing extends GO_Base_Db_ActiveRecord {
    ...

Outcome:

But this won’t work if the file containing the payload is uploaded using the FTP service. So one of the solution on issue I have opened on GitHub was preg_replace('/[^a-zA-Z0-9\_\.\?]/', '', basename(html_entity_decode($this->request->post['x'], ENT_QUOTES, 'UTF-8'))); by straightlight. Let’s see how they add a fix in the main code of the opencart in the next release.

CVE-2020-10596 in OpenCart was originally published by Kailash Bohara at Kailash Bohara on May 29, 2020.