Телеграмм чат группы WebPwnChat страница 3638

2021 February 25

N

Есть POST-запрос на сервер c json нагрузкой:
{
"var_1": "string_1",
"var_2": 0,
"var_3": 0,
"var_4": "string_2"
}

Из-за некорректной валидации в запрос можно вставить либо однострочный, либо многострочный комментарий, многострочный можно закрыть в любом месте json нагрузки, например, так:

{
"var_1": "string_1",
"var_2": /*0,
"var_3": 0,
"var_4":*/ "string_2"
}

В таком случае бэкенд пытается присвоить переменной "var_2" значение "string_2" и выдает ошибку при попытке преобразования к булевому типу.
Судя по ошибкам, которые выдает сервер, все действие на бэкенде происходит на C#, начал копать в сторону десериализации и после замены нагрузки на пэйлоад, сгенерированный ysoserial.net, получаю такую ошибку:

"errors":{"$type":["Error resolving type specified in JSON 'System.Windows.Data.ObjectDataProvider,PresentationFramework, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. Path '$type', line x, position y."]}

Если кто-то сталкивался с таким, подскажите, правильно ли выбран вектор десериализации или это раскручивается как-то по-другому?
Или же, если направление правильное, то на что в таком случае стоит обратить внимание(кроме типа форматтера на бэке), чтобы докрутить уязвимость? Подробных райтапов по десериализации на C# не нашел, пока что копаюсь вот в этой презентации https://speakerdeck.com/pwntester/attacking-net-serialization?slide=15 от создателя ysoserial.net

Speaker Deck

Attacking .NET Serialization

2016 was the year of Java deserialization apocalypse. Although Java Deserialization attacks were known for years, the publication of the Apache Commons Collection Remote Code Execution (RCE from now on) gadget finally brought this forgotten vulnerability to the spotlight and motivated the community to start finding and fixing these issues. One of the most suggested solutions for avoiding Java deserialization issues was to move away from Java Deserialization altogether and use safer formats such as JSON.

.NET formatters such as BinaryFormatter and NetDataContractSerializer are known to share similar mechanics which make them potentially vulnerable to similar RCE attacks. However, the lack of RCE gadgets led some software vendors to not take this issue seriously as happened to Java before.

In this talk, we will analyze .NET serializers including third party JSON parsers for potential RCE vectors. We will demonstrate that RCE is also possible in .NET and present details about the serializers that are vulnerable…