A fast and convenient tool (API client) for your JS security tasks powered by jsmon.sh.

What is jsmon-cli?

A command-line interface designed to act as an API client for jsmon.sh. Whatever you can do at the webapp, most of these features can be used via jsmon-cli. It calls the same API endpoints which the webapp uses. The public github repo for tool is at https://github.com/rashahacks/jsmon-cli.

What is jsmon.sh?

jsmon.sh is a JS security framework made for security enthusiasts, bugbounty hunters, penetration testers and security-focused enterprises to keep track of secrets, exposures and intel over the javascript files. As input, jsmon.sh can use a JS URL, a file (containing JS URLs), and even a domain name. The services present inside scans JS responses for domains, URLs, API paths, GraphQL operations, client-side vulnerabilites, GUIDs, JWTs, IP addresses, emails, S3 domains, and 100+ api keys. Embedded IP rotation, report generation, JS monitoring, and advanced notification service are also present. Well, this is about jsmon-cli, let's focus on that.

Installation Instructions (jsmon-cli)

git clone https://github.com/rashahacks/jsmon-cli
cd jsmon-cli
go build -o jsmon

The following commands will output a binary by name jsmon.

Authentication (API Key)

In order to authenticate with your account via jsmon-cli. First, get your API key by logging in at the website. Once you are logged in, click on JSMON API in nav bar, and go to API Keys. You can regenerate the API key if it gets expired, by clicking on regenerate icon. Now, there are two methods to authenticate with jsmon-cli.

1. Add your API key at ~/.jsmon/credentials file. At first line, just paste the API key. No dash, or curly braces are required. Paste the key in first line, that's it.

2. You can provide the API key to -apikey flag present in the CLI tool.

Usage

Usage of ./jsmon:
  ./jsmon [flags]

Flags:
INPUT:
  -scanUrl <jsmonId>         URL or scan ID to rescan
  -uploadUrl <url>       URL to upload for scanning
  -scanFile <fileId>        File ID to scan
  -uploadFile <file.txt>      File to upload (local path)
  -scanDomain <example.com>      Domain to automate scan

AUTHENTICATION:
  -apikey <XXX-XXXX-XXXX-XXX>          API key for authentication

OUTPUT:
  -automationData <example.com>  Get all automation results
  -scannerData            Get scanner results
  -urls                   View all URLs
  -size int               Number of URLs, automationData to fetch (default 10)
  -files                  View all files
  -usage                  View user profile

CRON JOB:
  -cron string            Set, update, or stop cronjob
  -notifications string   Set cronjob notification channel
  -time int               Set cronjob time
  -vulnerabilitiesType    Set type of cronjob (URLs, Analysis, Scanner)
  -domains string         Set domains for cronjob
  -domainsNotify string   Set notify (true/false) for each domain

ADDITIONAL OPTIONS:
  -H string               Custom headers (Key: Value, can be used multiple times)
  -words string           Comma-separated list of words to include in the scan
  -getDomains             Get all domains for the user
  -Emails <example.com>          View all Emails for specified domains
  -S3Domains <example.com>       Get all S3 Domains for specified domains
  -ips <example.com>             Get all IPs for specified domains
  -DomainUrls <example.com>      Get Domain URLs for specified domains
  -api <example.com>             Get the APIs for specified domains
  -compare <example.com>         Compare two JS responses by JSMON_IDs (format: ID1,ID2)

URL Input

jsmon -uploadUrl https://example.com/main.js
jsmon -scanUrl <jsmonId> #change detection

File Input

jsmon -uploadFile jsmon-jsurls.txt
jsmon -scanFile <fileId>

Domain Input

jsmon -scanDomain jsmon.sh

Querying Data

jsmon -usage
jsmon -automationData jsmon.sh -size 10
jsmon -ips jsmon.sh
jsmon -Emails jsmon.sh
jsmon -S3Domains jsmon.sh
jsmon -api jsmon.sh
jsmon -DomainUrls jsmon.sh
jsmon -getDomains
jsmon -urls -urlSize 15
jsmon -scannerData
jsmon -files

Conclusion

jsmon-cli is a powerful and efficient tool that extends the capabilities of the jsmon.sh platform to the command line, making it easier for security professionals to automate and streamline their JS security tasks. With simple installation and flexible authentication methods, it offers a convenient way to leverage the robust features of jsmon.sh, including scanning, monitoring, and reporting, directly from your terminal.

Feedback

If you want to report some bugs, add something inside CLI or webapp, let us know by mailing at support@jsmon.sh for anything.

Thanks,

Inderjeet Singh (Founder, jsmon.sh)

Hello hackers! Today, I'll describe a way through which I got multiple privilege escalations.

Background:

It's a vast application with tenants and user roles. For testing basic privilege escalations first, I created two accounts: admin user and least privilege user. Least privilege user is the user with zero permissions or the least possible access.

I have been hacking this app for the last 3 months so I became aware of most of the API calls, objects and error codes.

Technicalities:

There is a search functionality with a common endpoint architecture for every object: GET /api/v1/EMAIL/search. Here, the object code is EMAIL for searching emails. Similarly, there are many object codes that I got in my burpsuite history like PHONE, USER, INVOICE, PHOTO, DOCUMENT, etc.

Exploitation Steps:

1. I read the API docs of the application and found that all the object codes are documented for every version of the API.
2. Copy the object codes into a file (objCodes.txt).
3. Copy the cookies/auth-token of the least privileged user (LPU), who doesn't have access to most of the objects.
4. Take the HTTP request GET /api/v1/EMAIL/search into Repeater and substitute it with the session of LPU.
5. Send this request to Intruder, and set the object code EMAIL as the payload position. Use objCodes.txt for the wordlist. Start intruder attack.
6. I got around 40+ 200 status codes. Later, I figured out that many of the objects are still visible to LPU in the UI as well. LPU has some default access inside this app.
7. Time to filter out, which object codes shouldn't have read access as per docs but the API call is giving 200 OK and the whole response.
8. This took around 15-16 hrs to filter since it was a lot of work to review all of the features and docs properly.
9. I got 4 privilege escalations at the end.

Conclusion:

• Every IDOR or priv esc is not a vulnerability if the data is already public.
• Always save your burpsuite projects to keep track of operations, query names, endpoints, methods, error codes, etc.
• Always review the API docs, JS files and organization's GitHub for fetching operation names, objects, query names or endpoints.

Author: Inderjeet Singh, aka encodedguy

Twitter: https://twitter.com/3nc0dedGuY

Happy hacking!!

Greetings, Bug Bounty community! I'm Krishna Jaishwal, also known as jarvis0p, a Computer Science student and bug bounty hunter. Today, I'm excited to share my recent $2000 bounty journey with you, where I discovered a significant Insecure Direct Object Reference (IDOR) vulnerability in a video content streaming platform.

The Application

While testing the application I was thoroughly checking for access controls on every functionality. But for hacking over a day I couldn't find anything. Despite robust authorization checks and ever-changing session cookies and CSRF tokens, I persisted in my hunt. My breakthrough came when exploring the Need Support? feature.

Need Support?

The way that it works is that users have to create a support ticket where they will describe the issue details and the team will look into it to assist them. You can continue chatting with the team on this ticket to explain the issue or get assistance from the team. Users can also add images and attachments to show details of the issue. So I immediately created a support ticket to see how all of this was working on the programming level. There was nothing I could do with the creation of tickets as it was protected by CSRF tokens and session cookies. But my eyes got caught up when I saw how they were fetching data on these tickets. The request had two IDs in it. First was the user ID and second was the ticket ID.

POST /account/support/discussion/load-topic/<user-id>/<ticket-id>

I immediately thought that this did not look right because the application can find/authorize the user from the session cookie. Then why user-id?

Getting to an IDOR

First I wanted to try whether changing the user-id and ticket-id to another user IDs, will give me his chats. I had another testing account, so I tried to fetch other's account chats but the server gave me 403 Forbidden.

At this point, I thought this endpoint again had authorization checks. But I still was not sure why user-id is in the request if you have session cookie. So I tried putting random cookie to fetch chats and again 403. Finally, I tried removing the cookie header completely from the request, and to my surprise, it worked !!

So basically if you know user-id of a person and the ticket-id then you can see the chats between any users and the support team in an unauthenticated session. The user ID was a 9-digit number and the ticket ID was a 7-digit number. These are most probably assigned in sequencing order because when I tried creating consecutive tickets, the ticket IDs were very close.

Exploitation

I needed the user ID of other users to show the exploit of this bug. I scrolled through the burpsuite proxy and found an endpoint where I was able to get the user ID of another user on the basis of the username/channel name.

You can see in the response HTML, I found my user-id to be 730723625

Now to get ticket-id, there was no other option other than fuzzing, and that I wanted to avoid because the application was very serious about rate limitation. On almost every endpoint, it immediately throws 429  too many requests, if I use burp intruder. But to my luck, this endpoint did not have any rate limitation checks. So I fuzzed the ticket-id for other users using ffuf and got some hits.

On opening those tickets I was able to see chats between that user and the support team.

Fetching Attachments

As I told this feature also allows users to add attachments i.e. screenshots. This was the endpoint that was fetching the attachment URL.

GET /account/support/<attachment-id>/<ticket-id>/<user-id>/attachment/1

Guess what? This endpoint was again vulnerable to the same improper authorization. So on removing the cookie header, I was able to get attachments. The attachment ID was again 7-digit numbers, so this can be easily fuzzed.

Hence this vulnerability can allow any attacker to get complete chats between any user and support team.

Conclusion

• The application had improper authorization on two endpoints allowing to get complete chats of any users including attachments with the support team in an unauthorized session.
• Those endpoints have no rate limitation checks to prevent attackers from fuzzing the API endpoints.
• The application uses weak IDs to identify its resources, making it vulnerable to IDOR. Instead strong IDs like UUIDv4 can be used which are not prone to fuzzing attacks

Timeline

• 31 October 2023: I made a detailed report explaining the issue and submitted it with High(7.5) severity according to CVSS.
• 01 November 2023: The report was triaged and fixed immediately.
• 01 November 2023: They gave me a bounty of $1500 and a $500 bonus
• 03 November 2023: Awarded $50 for restest.

Tips

1. Go for manual hacking. It is more effective, more fun, and avoids duplicates.
2. Test access controls on each and every feature. Maybe all features have good security checks but there could be some features where developers forgot to put the checks properly.
3. The way APIs are made is such that every resource has a unique ID assigned to it which they use to perform CRUD operations. So wherever you find IDs, try IDOR. IDOR is present everywhere.
4. Try changing/removing session-maintaining tokens or cookies, if resources are still accessible then it could be a bug. You can also do this with Burpsuite's Autorize extension.

Thank you for reading. if you have any questions, DM me and I will get back to you!

Happy Hacking!!

Author: Krishna Jaishwal

Twitter: twitter.com/jarvis0p1
Linkedin: linkedin.com/in/krishna-jaishwal-3bb368237/

Welcome back, my aspiring cyberwarriors!

In recent days, a new and severe vulnerability has been found among the Android ecosystem that puts all Android devices, and even Apple iOS devices, at risk. It enables the attacker to send images via SMS and take control of the device with no user interaction! This vulnerability was first identified by Citizen Lab, a research lab based at the University of Toronto and famous for its tracking of the Pegasus malware. The vulnerability was first reported as CVE-2023-41064 but we have since learned that this vulnerability is ubiquitous throughout the Android ecosystem, Google chrome and many other Linux/Unix based systems. In addition, Telegram, the ToR browser, Brave, Gimp, LibreOffice and many other applications are vulnerable. This may be one of the most important vulnerabilities of our era!

The vulnerability involves a library (reusable code) developed by Google over a decade ago to process images known as libwebp. libwebp was designed to be a more efficient method of processing images than say jpeg or other image processes algorithms. As such, it is used throughout the mobile device world and many browsers.

The danger of this vulnerability is that it enables the attacker to install remote code on the device and take control with NO interaction from the user.

Let's delve a bit deeper into libwebp and this vulnerability.

What is libwebp?

libwebp is a library used by developers to compress graphic files for easier and more efficient transfer over the Internet. Nearly all graphic files you are familiar with such a jpeg, tiff, png, etc. are all compressed file formats. Without these compression algorithms, the Internet would move much slower. We also use compression in audio and video files such as mp3 and mp4.

libwebp was developed by Google and is widely used among phones, mobile devices and browsers. It's compression is significantly superior to other widely used compression algorithms such as jpeg (as much as 30-40% for efficient).

What is Lossless and Lossy Compression

Lossless compression is data compression in which the  original data can be perfectly reconstructed from the compressed data.  In other words, when a file undergoes lossless compression and is subsequently decompressed, no information is lost and the output is  identical to the original input. PNG, FLAC, GIF and ZIP are lossless compression algorithms. Lossless compression is used throughout the Internet where speed and efficiency are important but where integrity is also necessary.

Lossy graphic file compression is a method of data compression  where some of the file's data is permanently discarded during the  compression process. In the context of graphic files, this means that  some image information is lost when the file is compressed and cannot be  fully recovered upon decompression. The main objective is to  significantly reduce the file size to save storage space and decrease  load times, often at the cost of some degradation in image quality. Many graphic, audio and video files are compressed with lossy compression due to the fact that our eyes and ears are not so sensitive to pick up the change of a single pixel or note

How Does the Exploit Work

This exploit creates a buffer overflow in the image decoder enabling the attacker to install their own remote code and control the device. libwebp uses a Huffman tables (developed by David A. Huffman in 1952, is a popular  method for lossless data compression. The central principle of Huffman  coding is to use shorter binary codes for more frequent elements in the  data and longer codes for less frequent elements) for compression and decompression. The compressed image files contain information about the shape of the Huffman tables and those tables are constructed by the decoder. These Huffman tables are constructed in a heap (heap is a memory area what application data is stored). A specially crafted WebP file can create a Huffman tree that overflows the heap and allows the attackers code to run

Summary

The libwebp vulnerability affects nearly every mobile device whether Android or iOS. It also affects the most commonly used browsers and many applications that enable graphics manipulations. The libwebp vulnerability may be the most important mobile device vulnerability of our times!

Thank You for Reading!

I appreciate you taking the time to read my blog post. Your support means the world to me. If you enjoyed this content and would like to stay connected, feel free to follow me on social media:

• X (Formerly Twitter): bhaskarvilles
• Instagram: bhaskarvilles
• LinkedIn: bhaskarvilles

Your feedback, comments, and shares are always welcome and greatly appreciated. I look forward to engaging with you and sharing more insightful content in the future.

Remember, your support keeps this blog going. Thank you once again for being a part of our community!

Introduction

Soft deletion is the process of showing that an entry is removed but not actually removed from the databases. Is it GDPR compliant? No. As per GDPR (General Data Protection Regulation), unauthorized access and unlawful processing of personal data protection must be there.

I am Inderjeet Singh aka encodedguy, and today, I will describe how soft deletion works, why it's a bad idea for developers and what's in it for security people.

Table of Contents:

• Soft Deletion
• Why it's a bad idea?
• Security
• Finding Soft Deletion Vulnerabilities

Soft Deletion

How is it possible to show that my passport is not on the table but it's still there? In reality, it's not possible, but in computers (a world of illusion), it can be happen.

Developers while creating databases add a boolean field is_deleted for every record. When a user deletes some record from a table, the record's is_deleted value is set to true but the record is not actually removed from DB.

UPDATE users_passports SET is_deleted=true WHERE user_id =req.user.ID;

When a user sees the same records in the application, records won't appear.

SELECT * FROM users_passports WHERE (is_deleted=false & user_id=req.user.ID)

Developers use it for data collection, processing, and for analytics purposes to analyze user data.

Why it's a bad idea?

• Extra storage space is required because resources are never going to be hard deleted, and one extra field is_deleted is required in the table.
• It's not GDPR compliant. User have deleted their personal data but still it's present in the databases.

Security?

Since, soft deletion doesn't care about personal data protection, security researchers can report soft deletion vulnerabilities in pentests or bug bounty engagements. Hackerone submissions and Bugcrowd VRT have options for privacy related bugs.

Finding Soft Deletion Vulnerabilities

Depending on the application, way to find soft deletion could differ. Common idea is to delete something and find a way to access this resource after deletion via API endpoints or via other referenced table.

RestAPI

• GET /api/v2/passports/<UUID-A> : 200 OK with the passport data.
• DELETE /api/v2/passports/<UUID-A> : 204 No Content with passport data in response body.
• GET /api/v2/passports/<UUID-A>: 404 Not Found.
• Hit the DELETE endpoint once again with same UUID.
• DELETE /api/v2/passports/<UUID-A>: 204 No Content with same passport data in response body.

This shows that GET endpoint for fetching password data is not responding, but we can verify using DELETE endpoint that data is not hard deleted.

GraphQL

• query getUserPassport(){fields}: 200 OK with the passport data.
• mutation deleteUserPassport("passport":"<UUID-A>"): 204 No Content with passport data in response body.
• query getUserPassport(){fields}: 404 Not Found.
• Hit the delete mutation once again with same UUID.
• mutation deleteUserPassport("passport":"<UUID-A>"): 204 No Content with same passport data in response body.

Others

• Delete Profile Picture.
• Is the profile picture's CDN URL still accessible? If yes, privacy violated.
• Delete user uploaded data (videos, attachments, etc.)
• Are files still accessible? If yes, privacy violated.

Conclusion

Soft deletion method is used by businesses for data collection and analytics purposes and it's not GDPR compliant. If you ever counter, such soft deletion scenario while deletion, just click on Submit a Bug Report.

Thank you for reading!

Author: Inderjeet Singh

Twitter: twitter.com/3nc0d3dGuY

Hello security folks, before I start let me first introduce myself. I am jarvis0p, a college student in daylight and cyber security learner during shadows. This write up is going to be complete beginners friendly, a guide to perform 64-bit buffer overflow attack. Along the way you ll learn some fundamentals of assembly, payload creation, and getting code execution.

Setup Environment

Before we start, lets setup our working environment to perform this attack and make sure in anyway it is not going to harm our system. For this, I want to you to use a remote Virtual Private Server (VPS). You can achieve this easily by firing up an Ubuntu Machine on AWS  EC2 instance. After initializing, connect to the instance and run below commands to install necessary packages.

sudo apt update
sudo apt install gcc gdb checksec
bash -c "$(curl -fsSL https://gef.blah.cat/sh)"

There is one more thing you need to configure before we proceed. By default all Linux kernels are configured with a memory randomization protection known as Address Space Layout Randomization or ASLR. This is a security feature which randomizes the memory addresses at which various components of a program, including the stack, heap, shared libraries, and the executable itself. This randomization makes it more challenging for attackers to predict the memory addresses of specific functions or data structures, making it harder to execute successful buffer overflow attacks. This mechanism can be implemented on three levels.

• 2 = Full Randomization
• 1 = Conservative Randomization
• 0 = No Randomization

Run this command to see the current value of randomization.

sysctl kernel.randomize_va_space

You ll get it default value set to be 2. Yes, linux kernels are very protective!!!. So lets turn it off completely to 0 so that we don't have to deal with complex low level programming.

sudo sysctl kernel.randomize_va_space=0

With this we are all set with our environment.

Vulnerable Code

Take a look at this C code

#include <stdio.h>
#include <string.h>

void secret() {
    printf("You have successfully executed the secret function!\n");
}

void vulnerable_function(char *input) {
    char buffer[64];
    strcpy(buffer, input);
    printf("Buffer content: %s\n", buffer);
}

int main() {
    char input[128]; 

    printf("Enter input: ");
    if (scanf("%127s", input) != 1) {
        printf("Failed to read input.\n");
        return 1;
    }

    vulnerable_function(input);

    return 0;
}

This C program have three functions: main, vulnerable_function and secret. The main() function is reading array of characters as input. The vulnerable_function is then called with this input as argument. In this function a 64 bytes buffer array has been defined and then it is calling a literally very dangerous function strcpy() to copy bytes form input variable to buffer. The problem here with this function is that while copying it does not care about size of the buffer and keeps doing it even though the size 64 bytes is filled. The copying of extra bytes now start to mess around with other stacks in the programs memory. So suppose if we pass lots of 'A' to the input of the program, it will start overwriting other stacks and pointers ex stack pointer ESP, base pointer EBP. But there is one more secret function which is actually never been called in the code or program never intends to call it, but by the end I ll show you that using buffer overflow vulnerability how an attacker can execute this secret function.

Disable securities

Now let see this in live action and compile the program & run it with say 10 A's as input

gcc vuln.c -o vulnbin
./vulnbin

Okay, everything went smoothly, no problem. But we want to create problem, so this time try it with 100 A's. For that you can use our good old friend python3 to print these A's like this:

python3 -c 'print("A"*100)'

Ooops, looks like someone's hurt. Yess Linux and gcc does not like to be messed around. It says stack smashing detected so basically we are caught red hands. Here I want to you to use a tool that I earlier made you to install. It is designed to check the security of a binary.

checksec --file=vulnbin

This shows how securely the program was compiled. You ll see full relro, stack canary found, NX enabled, Position Independent executable (PIE), etc. I recommend to dig into these terms later but for now we atleast get that these green colors shows that this was the thing which was earlier detecting stack smashing. So to make these in red or I mean to say turn off these security protections, compile it like this and then again run the program with 100 A's.

gcc -fno-stack-protector -z execstack -no-pie vuln.c -o vulnbin

Overflow begins

Finally this time we get different output. It says Segmentation fault. Its clear that we managed to break the program. Lets get into details of exactly what and where it broke. You can easily achieve this by using a tool dmesg which logs all kernel errors in it. You will need root permission for that so put sudo and pipe its output to tail command which will only show important last 5 lines of it.

sudo dmesg | tail

Take a look at the last line, here it says about our program vulnbin that some fault occured at instruction pointer ip at mem address 4011f0. Hmmmmm. This is not enough details but at least we get the idea that ip broke at somewhere 0x4011f0.  

Okay Finally its time to get our hands dirty with gdb. We will be using gdb gef (GDB enhanced feature) to assist us in exploit development. Fire up gdb with specifying the binary.

gdb vulnbin

You ll see that you have entered into a new command line. To get your way through you can type help and enter to see all commands of gdb gef. But before we run the program here, lets have deep dive in our binary and its functions address in memory. Run this inside gdb gef.

info functions

You can see all the functions used in the code are here. But we are interested in the secret function, so note its mem address i.e. 0x0000000000401196.

Now lets run our program by simply typing r and enter. This time we will again provide 100 A's as input to create buffer overflow scenario.

I know this is lot, even for me, but at least we can look around for things that we are familiar with, like esp or eip.

$rsp   : 0x00007fffffffe2d8  →  "AAAAAAAAAAAAAAAAAAAAAAAAAAAA"
this means that the actual value of $rsp (stack pointer) was  0x00007fffffffe2d8 but because we supplied input so long that it started interfering with the stack pointer and filled it with all A's

Same goes with $rbp (base pointer), and other stacks. What I want you to notice is that, it does not knocked out $rip (instruction pointer) address. Even though you supply any number of A's it may not effect it at all but this is what we want to achieve because instruction pointer controls which function to execute. If this was a 32-bit binary it would have worked, but why is this happening with x64 bit? Stuck? Lets take help. Take a quick read of this post and learn how calling convention works for x64 bit binary.

x64 calling convention

Learn about the details of the default x64 calling convention.

Microsoft LearnTylerMSFT

Hunt the offset

This is were gdb gef will assist us and make our work easy to find the exact number of A's or call it as offset after which we can put our payload which will overwrite ip address.

Run this command inside gdb to get a cyclic string of 100 bytes

pattern create 100

Now run the program using r command and copy paste the pattern as input. Then run this command to get value of offset bytes:

pattern search $rsp

Gef will find offset for you, 72 in this case with little endianess

Payload generation

We now know that 72 bytes is the exact number of stuffing we have to do to reach to instruction pointer and may be overwrite it. Here comes the part were we play with our input/payload to observe the behaviour of stacks and pointers. So lets try 72 A's and then 6 B's (exactly six because of calling convention of 64-bit ELF binary) and see what it does with the $rip. Again you can get this done by python3

python3 -c 'print("A"*72 + "B"*6)'

copy the payload and run it inside gdb.

Finlly we are able to overwrite instruction pointer. `$rip   : 0x424242424242`. (value of B in hex is 42). So this should be our payload structure:

72 A's + (address which we want to write in $rip)

Note we already saved the address of secret function and this address we will put after 72 A's. This will overwrite instruction pointer to the secret function address which will force it to move to the function and execute  it. So here is our final payload to execute secret function. Keep in mind I am on little endian arch, so writing secret function address in reverse order up to 6 bytes.

72 A's + "\x96\x11\x40\x00\x00\x00"

Since these hex may be non characters so we can not copy paste it, we have to pipe this as stdin to the binary. This time instead of using print function, I am using sys.stdout module to output non printable characters in bytes format.

python3 -c 'import sys; sys.stdout.buffer.write(b"A"*72 + b"\x96\x11\x40\x00\x00\x00")' | ./vulnbin

Yaaay, We successfully executed secret function.

Conclusion

If you think about root cause of this whole shenanigan, it all started due to strcpy() function which was blindly doing its work. Although we had to disable some security measures to see the attack it does not mean a hacker can not break those, it will only be more challenging but not impossible.

Thanks!!

Author: Krishna Jaishwal

Twitter: https://twitter.com/jarvis0p1

API Excessive Data Exposure

When the API sends extra response to the client than required, it is called as API Excessive Data Exposure. In layman's terms, client wants x but API sends x+y.

Is x+y a bug?

I am not saying x+y is a bug, but it can be.

For example, A client requires firstname and country to be visible on a public profile. API response contains username, firstname, country, countryCode, phonecode, avatarUrl, and isAdmin parameters.

This is not a bug. You can argue that this parameter isAdmin is extra here. Well, it's just a true/false value. You can use this to chain it with your further IDOR or BAC bug to get admin's data, but it's not worth reporting.

When is x+y a bug?

If excessive user personally identifiable information (PII) data, system data, internal data, infrastructure data, etc. is leaked in the API response. And, only when it's excessive or unauthorized.

For example, A client requires firstname and country to be visible on a public profile. API response contains email, auth_token. It's worth reporting.

One more, An error message is thrown, but within the API response contains errorCode, description, and whole stackTrace with internal paths, system usernames, etc. This is worth reporting.

Why does this happen?

Devs sometimes let the frontend server or client-side JS do the filtering for API responses. This creates a security hole because by hitting the API call, attacker can get more data then required if excessive data is present.

Conclusion

Today we have SOAP APIs, GraphQL, RestAPI, gRPC, WebSocket API, etc. Every API have different way of dealing with the HTTP request. Play with the requests and always watch carefully what is present in the response. If x is required, and x+y is visible, where y looks impactful, you just got a bug!

Author: Inderjeet Singh

Twitter: https://twitter.com/3nc0d3dGuY

Happy Hacking!!

Summary:

A payment application requires 2FA verification by your number and email both when editing user details including name, email or phone number. I found an easy bypass for the implemented 2FA flow through which an attacker can edit the user details without his phone/email access that finally leads to an account takeover.

Steps to Reproduce:

1. Go to Edit section, start editing the email field.
2. 2FA prompt will ask you for an OTP on current email.
3. Enter the wrong OTP "123456". Intercept the response.
4. Change response from {"success":"false"} to {"success":"true"}.
5. 2FA prompt will again ask you for an OTP on current phone number.
6. Enter the wrong OTP "123456". Intercept the response.
7. Change response from {"success":"false"} to {"success":"true"}.
8. Prompt will ask you to enter email to be changed, input attacker email here.
9. Enter the OTP that came in your email inbox.
10. Refresh the dashboard, email changed.

Why It Happened?

Generally, after 2FA verification (1st HTTP request) a token is assigned and this token will be used with email change request (2nd HTTP request). Here, no such token was sent when entering OTP (in 1st HTTP response). This is a common case to check in case of multi-stage actions.

Reporting Timeline

10 May 2023 - Reported via Hackerone

11th May 2023 -  Status changed to Triaged

7th June 2023 - Retest completed 50$ and Resolved

10th June 2023 - 5000$ reward + 500$ bonus

Author: Inderjeet Singh

Hackerone: https://hackerone.com/encodedguy

Twitter: https://twitter.com/3nc0d3dGuY

Happy Hacking!!

Summary

Attacker can login into any account by entering their phone number and confirmation OTP 1234. The target was not in production, 1234 must be hardcoded or used as a default OTP.

Reproduction Steps

1. Go to foo.bar.target.com and click on Login.
2. Enter your phone number.
3. Enter confirmation OTP: 1234.
4. Login successful.

Timeline

1. 19 September 2022 - Reported via Hackerone
2. 21 September 2022 - Status changed to PPR
3. 23 September 2022 - Triaged
4. 27 September 2022 - Rewarded
5. 3 October 2022 - Resolved

A scam is a dishonest or fraudulent scheme or activity conducted by individuals or groups to deceive or defraud others for personal gain. Scams are typically designed to manipulate victims into providing money, sensitive information, or access to their assets under pretences. Scammers employ various tactics such as false promises, misrepresentation, impersonation, or coercion to trick their targets into taking actions that benefit the scammer at the expense of the victim. Scams can occur through different mediums, including phone calls, emails, text messages, social media platforms, online marketplaces, or in-person interactions. The ultimate goal of a scam is to exploit the trust, vulnerability, or ignorance of the victim for financial or personal advantage.

The term "scammers" refers to individuals or groups who engage in dishonest or fraudulent activities to deceive or defraud others. Scammers employ various deceptive tactics to manipulate and exploit their victims for personal gain, often financially.

Scammers may use false identities, misleading information, or coercion to trick their targets into providing money, sensitive personal information, access to their assets, or other valuable resources. They often exploit people's trust, vulnerability, or lack of knowledge to carry out their fraudulent schemes.

The term "scammers" can encompass a wide range of individuals or groups involved in fraudulent activities, including:

1. Online scammers: These scammers primarily operate on the internet, using various channels such as emails, social media platforms, fake websites, or online marketplaces to target victims.
2. Phone scammers: These scammers make unsolicited phone calls to potential victims, employing tactics like impersonation, false claims, or coercive techniques to deceive and defraud people.
3. Fraudulent businesses: Scammers may set up fake businesses or websites that appear legitimate, offering products, services, or investment opportunities that are either non-existent or deceptive.
4. Impersonators: Scammers sometimes pose as reputable individuals, organizations, or professionals to gain trust and exploit their victims. They may impersonate government officials, financial institutions, charities, or well-known companies.
5. Advanced fee fraudsters: These scammers entice victims with the promise of a large sum of money but require an upfront payment or fee before the funds can be released. However, the promised funds never materialize, and the victims are left empty-handed.

The statement that scammers are earning more money in recent days is a broad claim and may not be universally true. However, it is possible that certain types of scams have become more prevalent or effective in certain regions or industries. The reasons for this can vary, but here are a few possible factors:

1. Advancements in technology: Scammers often adapt to advancements in technology to devise new ways of deceiving people. With the increasing use of digital platforms and online transactions, scammers may exploit vulnerabilities in systems or manipulate unsuspecting individuals through various online channels.
2. Increased connectivity: The interconnectedness of the world through the internet and social media has provided scammers with a wider pool of potential victims. They can cast a broader net and target individuals across different geographical locations without physical limitations.
3. Social engineering techniques: Scammers employ sophisticated psychological tactics to manipulate people's emotions, trust, and vulnerabilities. They may use persuasive language, create a sense of urgency, impersonate authoritative figures, or exploit people's fears and desires to convince them to part with their money.
4. Lack of awareness and education: Despite efforts to raise awareness about scams, many people still fall victim to them due to a lack of knowledge or understanding. Scammers continually adapt their techniques, making it challenging for individuals to stay updated on the latest threats.
5. Global events and crises: During times of uncertainty or crises, scammers often seize the opportunity to exploit people's fears or offer fraudulent solutions. For example, during the COVID-19 pandemic, there was a rise in scams related to fake vaccines, personal protective equipment, and financial relief programs.

To raise awareness about scammers and their tactics, it's important to educate yourself and others about common warning signs.

Here are some key points to be aware of:

1. Phishing emails and messages: Be cautious of unsolicited emails, text messages, or phone calls that request personal information, login credentials, or financial details. Legitimate organizations will not ask you to provide sensitive information through insecure channels.
2. Impersonation: Scammers often pose as trusted individuals or organizations, such as banks, government agencies, or popular websites. Double-check the authenticity of communications by independently verifying the contact information and reaching out to the organization directly.
3. Urgency and pressure: Scammers often create a sense of urgency or fear to prompt quick actions without thinking. They may claim that you've won a prize, face legal consequences, or need immediate payment. Take your time to assess the situation and verify the information before making any decisions.
4. Requests for money or financial information: Be cautious when someone asks you to send money, wire funds, or provide your bank account details. Scammers may use emotional stories, fake invoices, or fraudulent investment opportunities to deceive you. Always verify the legitimacy of such requests before taking any action.
5. Unsolicited remote access or tech support: Scammers may contact you claiming there is a problem with your computer, and they need remote access to fix it. They may also offer tech support services for a fee. Avoid granting remote access unless you initiated the contact or can verify the legitimacy of the service provider.
6. Job and employment scams: Be wary of job offers that require upfront fees, promise easy money, or request personal information early in the application process. Research the company, check for red flags, and be cautious when providing sensitive information.
7. Social media and online marketplace scams: Scammers can exploit online platforms by creating fake profiles, posting counterfeit products, or offering deals that are too good to be true. Exercise caution when making online purchases and use secure payment methods.

In conclusion, scammers arto deceive defraud or fraudulent activities with the intention of deceiving and defrauding others for personal gain. They employ various deceptive tactics, such as impersonation, phishing, coercion, and exploiting vulnerabilities, to manipulate their victims. While it may be true that certain types of scams have become more prevalent or effective in recent times, this can be attributed to factors like advancements in technology, increased connectivity, social engineering techniques, lack of awareness and education, and global events or crises. To protect yourself from scammers, it is important to stay informed, be vigilant, and exercise caution when dealing with unsolicited requests, providing personal or financial information, or engaging in online transactions.

Ref:

Scammerpayback: https://www.youtube.com/c/ScammerPayback

Nanobaiter: https://www.youtube.com/@NanoBaiter

Summary:

When doing recon on Yahoo assets during Hackerone AWC 2023, I found a host foo.bar.yahoo.com. I thought it must be some internal tool for engineers, few pages are listed but clicking on any of the pages redirects to Okta SSO. I found a bug during black box testing, http instead of https bypassed the Okta and the host was accessible.

Reproduction Steps:

1. Check the hostname foo.bar.yahoo.com on the wayback machine.
2. Found an indexed page: https://foo.bar.yahoo.com/page1/endpoint/
3. Go to this page and it redirects to Okta SSO.
4. Probe for https and http both ports with httpx .
5. http://foo.bar.yahoo.com/page1/endpoint also got in results.
6. Content-Length of both pages https and http were different.
7. Go to http://foo.bar.yahoo.com/page/endpoint and the whole page was directly accessible.

The host is showing adtraffic. I tried to google these terms, ended up reporting to the team directly since the terms and results were out of my brain's scope.

Timeline:

1. 14 March 2023 - Reported to Yahoo Team (via HackerOne)
2. 15 March 2023 - Status changed to Pending Program Review by HackerOne
3. 18 March 2023 - Triaged by Yahoo Staff
4. 7th April 2023 - Rewarded
5. 3rd May 2023 - Resolved

Causes of this finding:

I'm still curious to know how it worked. There are a few guesses I made on the reasons why it could have happened. I am still not sure why it worked this way.

1. Access port 80 instead of port 443 and bypass Okta?
2. Server misconfiguration while setting up SSL.

Future work: Research the cause by setting up Okta locally.

Happy Hacking!!

Summary

This bug allowed me to access a Management Information System Portal by bruteforcing common passwords. The admin panel allows changing theatre names, theatre status, changing ticket prices, user management, viewing system logs, etc. in South Asian countries.

Reproduction Steps

1. Find all the ASNs owned by The Walt Disney Company. Do enumeration to find more hosts using techniques described in my blogs.
2. Take all the enumerated passive and active hosts and run a masscan at common http ports.
3. Run httpx over all online hosts with status code, title, content type, etc. flags.
4. Got a host with "Admin Panel" title name and login window.
5. Entered "admin" and "encodedguy" and got different responses that helped to figure out that admin is the available username in the portal.
6. Entered 5 common passwords and got "5 fails, please wait 15 minutes...", but this error was only on the frontend and no server side protection was present.
7. Sent the login request to Intruder and fuzzed for passwords with a wordlist of 20K common passwords (thanks to danielmiessler).
8. Found this password "P@ssw0rd" with different content length.
9. Logged in using "admin":"P@ssw0rd" and got access to the portal.

This portal manages Disney theatres for countries like Indonesia, Thailand, and South Asian countries. An attacker could have changed theatre prices in all theatres in one click, changed the user management, status of these theatres, etc.

Timeline

1. 9 April 2022 – Report sent via Hackerone (The Walt Disney Company).
2. 13 April 2022 – Report triaged by internal triager.
3. 8 June 2022 – Retest completed and fix worked.
4. 10 June 2022 – Report resolved and bug is not reproducible.

Happy Hacking!!

Introduction:
In today's interconnected digital landscape, websites play a crucial role in establishing an online presence and attracting visitors. However, the growing threat of Cross-Site Scripting (XSS) attacks poses a significant risk to both search engine optimization (SEO) efforts and website reputation. In this blog post, we will explore how XSS attacks can harm a website's search engine ranking and reputation, examine real-life examples, and provide strategies for recovery and prevention. Let's dive in!

1.Understanding XSS Attacks:
Before investigating into the impact of XSS on SEO and reputation, it's essential to understand the basics of XSS attacks. XSS occurs when an attacker injects malicious scripts into a web application, which are then executed on the victim's browser. This allows the attacker to steal sensitive information, deface the website, or redirect users to malicious sites.

To learn more about XSS attack: https://owasp.org/www-community/attacks/xss/

2.The SEO Consequences of XSS Attacks:
XSS attacks can have detrimental effects on a website's search engine ranking. Here are a few ways XSS can impact SEO:

• Content Manipulation: Attackers can modify website content, inserting links to spammy or malicious websites. Search engines may penalize the affected website for hosting suspicious or irrelevant content.

Example: In 2017, Forbes fell victim to an XSS attack where the attacker injected spammy links, causing the website's search engine rankings to plummet.

• Blacklisting by Search Engines: If a website is infected with XSS malware, search engines may identify it as harmful and blacklist it from search results, severely impacting organic traffic.

Example: In 2012, the official website of the European Space Agency (ESA) was compromised by an XSS attack, leading to blacklisting by Google for several days.

• User Experience and Bounce Rate: XSS attacks can disrupt the user experience, resulting in higher bounce rates and lower engagement metrics. Search engines consider these signals in their ranking algorithms.

3. Damage to Website Reputation:
Beyond SEO, XSS attacks can tarnish a website's reputation, causing trust issues among users and stakeholders. Some repercussions include:

• Data Breaches and Privacy Concerns: XSS attacks can expose sensitive user data, damaging the website's reputation and eroding user trust. Such incidents may lead to legal consequences and loss of credibility.

Example: The MySpace XSS worm in 2005 exploited an XSS vulnerability, compromising millions of user accounts and adversely affecting MySpace's reputation.

• Customer Perception and Brand Image: An XSS attack that defaces a website or displays inappropriate content can damage the brand's image and create a negative perception among visitors.

Example: In 2020, an XSS vulnerability allowed attackers to deface multiple high-profile websites, including the official website of the U.S. government's Federal Depository Library Program (FDLP).

4. Strategies for Recovery and Prevention:
To mitigate the impact of XSS attacks on SEO and website reputation, consider the following strategies:

• Regular Security Audits: Conduct comprehensive security audits to identify and patch XSS vulnerabilities proactively. Engage professional security firms or utilize automated tools to scan for potential threats.

• Secure Coding Practices: Implement secure coding practices, such as input validation and output encoding, to prevent XSS vulnerabilities from arising during the development process.

• Web Application Firewalls (WAFs): Employ WAFs that specialize in detecting and blocking XSS attacks. These solutions can provide an additional layer of protection by filtering malicious scripts before they reach the web application.

• Educate Staff and Users: Raise awareness among employees and website users about the risks of XSS attacks and provide guidelines on safe browsing habits and reporting potential vulnerabilities.

• Incident Response Plan: Develop a comprehensive incident response plan to address XSS attacks promptly. This plan should include steps to investigate and remediate the issue, as well as communication strategies to rebuild trust with users and stakeholders.

Conclusion:
XSS attacks pose significant threats to SEO efforts and website reputation. By understanding the impact of these attacks and implementing effective strategies for recovery and prevention, website owners and developers can safeguard their online presence and protect their users. Stay vigilant, prioritize security, and collaborate with experts to combat the evolving landscape of XSS attacks.

References:

• Forbes XSS attack: https://thehackernews.com/2012/01/multiple-cross-site-scripting-xss.html
• MySpace XSS worm: https://www.vice.com/en/article/wnjwb4/the-myspace-worm-that-changed-the-internet-forever
• FDLP website defacement: https://www.cbsnews.com/news/iran-hackers-briefly-deface-website-for-u-s-government-library-with-pro-iranian-message/

Hi folks! Hope you are doing great. This is Aravind (aravind0x7) here with an awesome write-up. I will discuss about one of my past finding on target.com(can’t reveal site here) where I was able to change the profile picture of any user of that website by just knowing their user id. Isn’t it cool? Let’s start the journey.

If you are a experienced hacker, then by this time you might have catched the type of vulnerability that existed on target.com. Anyways the main reason for this issue was “Insecure Direct Object Reference” IDOR, Already heard somewhere ? If not get know about it here.

https://portswigger.net/web-security/access-control/idor

Jumping into my finding, target.com had all the basic things like all other websites have. It had a account page which carries all information about the user and you can also set your own profile picture for your account. At first I tried to inject a XSS payload which was in .png format, into the upload field but nothing worked out. While watching the requests and responses with burp. I noticed that when we upload a pic, the user id is mentioned in the request. After seeing this I got an idea to change my user id to somebody else user id. Quickly I created another account and tested the same.

I made another account, captured the user id (say user 2) and stored it elsewhere. Now I went back to my previous account (say hacker) and uploaded the profile pic by changing my user id to the user id I took from user 2.

I was surprised to see that, the victims profile picture is changed now by just changing the user id. Quickly I made a report and submitted it to the security team of the website. That's a short story of my finding and I hope that you guys got some idea about hunting IDOR bugs. Let's catch-up soon in another blog. For more write-ups like this, subscribe and stay tuned.

Wanna get connected ? Visit here www.aravind0x7.in