SSRF в Microsoft Designer

SSRF в Microsoft Designer

SHADOW:Group

Сегодня я расскажу о эксплуатации SSRF (Server-Side Request Forgery), которую обнаружили и успешно использовали в одном из продуктов искусственного интеллекта Microsoft, а именно Microsoft Designer.

Microsoft Designer - это приложение для графического дизайна на основе искусственного интеллекта, которое помогает мгновенно создавать потрясающие посты в социальных сетях, приглашения, цифровые открытки, графику и многое другое.

Когда мы пытались найти IDOR в приложении, мы столкнулись с конечной точкой, которая принимает некоторые параметры, включая параметр с именем nextlink, извлекает изображение из него, а затем создает из него миниатюру и размещает ее на Onedrive. Увидев это, мы заподозрили SSRF и заменили исходный URL на URL с burp collaborator, и все, что мы получили, была ошибка с ответом 500 и небольшим заголовком, показывающим ошибку синтаксического анализа, как показано ниже:

После нескольких неудачных попыток воспроизвести слепую SSRF по URL, мы начали чувствовать, что просто тратим время впустую. Таким образом, мы решили отойти на шаг назад и изучить вывод исходного значения для следующего URL. Похоже, что это был объект JSON, представляющий drive object, и JSON имел следующую структуру:

{ 
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('elhabtiesoufiane%40gmail.com')/drive/special('approot')/children", "@odata.count": 33,
  "@odata.nextLink": "https://graph.microsoft.com/v1.0/me/drive/special/approot:/My%20stuff:/children?expand=thumbnails(select%3dmedium)&top=9&orderby=lastModifiedDateTime+desc&select=id%2cname%2ccreatedDateTime%2clastModifiedDateTime%2cthumbnails%2cfile%2cimage%2c%40microsoft.graph.downloadUrl&$skiptoken=Mjg",
  "value": [{
    "@microsoft.graph.downloadUrl": "https://public.am.files.1drv.com/y4mKouM8V3c8qPmNuxA6Xuar9ZLAjp5mc_nmElgmPbykqyEx6fA2fIOqOt9JmGK9T7wrPrpGIFl6thL91UYUXJeYAjkoJ29DLcrxIJtjk3XjCK8XSi2rkNL_MN9gSl8jgukYpYIR7H2tPIbSWswzXmxbxgo6dOg3q5FfTbPFAMvlvzNuUzfyIp8aVBL0e4PkG5Z7NXkOJ3S0_3wzzvo2UBH90XlTf5n97OBLcTNLz5fTjo",
    "id": null,
    "name": "check 9.jpg",
    "createdDateTime": "2023-08-29T17:44:24.92Z",
    "lastModifiedDateTime": "2023-08-29T18:07:58.943Z",
    "file": {
      "mimeType": "image/jpeg",
      "hashes": {
        "quickXorHash": "htg9DiY+4UVg4Utg7VVVLudD968=",
        "sha1Hash": "77C14952BFA9BBC809B6267C88385B6C428EFABA",
        "sha256Hash": "7225D72CBB652B45E5883BEB794BC5BB3F7B024CF5E6BAED24F243EEAB988918"
      }
    },
    "image": {
      "height": 800,
      "width": 800
    },
    "thumbnails@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users('elhabtiesoufiane%40gmail.com')/drive/special('approot')/children('FE1AD29AF25F99C0%2119434')/thumbnails",
    "thumbnails": [{
      "medium": { 
        "height": 176,
        "url": "SOME ONEDRIVE URL" 
      } 
    }]
  }
} 

После отладки мы поняли, что бэкэнд извлекал значение thumbnails.medium.url, поэтому мы разместили на своем собственном сервере аналогичный объект json и заставили бэкэнд отправить запрос к нему. Таким образом, мы создали эксплойт и отправили запрос, но, как вы догадываетесь, никакой ошибки, только пустой ответ, как показано ниже:

Но с позитивной стороны, мы получили обратный вызов на нашем burp collab от IP-адреса Microsoft:

На данный момент кажется, что мы можем получить только миниатюры изображений с помощью нашего эксплойта, пока вдруг мы не заметили заголовок запроса с именем Responsetype, который изначально был установлен в json, поэтому мы попробовали установить его в html, и мы получили полный ответ от нашего burp collaborator:

Наконец, мы поиграли с этим и получили доступ к локальному образу Microsoft Designer с внутреннего IP, а также запросили информацию об экземпляре с метаданными (мы не можем получить токены, так как это требует некоторых заголовков):

На этом все, спасибо за просмотр!

Оригинал на английском тут.

Подпишись на канал - @shadow_group_tg.

Report Page