Урок за тестване на Fuzz (Fuzing).

Какво е Fuzz тестване?

Тестване на размиване или размиване е техника за тестване на софтуер, която въвежда невалидни или случайни данни, наречена FUZZ, в софтуерна система, за да се открият грешки в кода и вратички в сигурността. Целта на fuzz тестването е да се вмъкват данни с помощта на автоматизирани или полуавтоматизирани техники и да се тества системата за различни изключения, като срив на системата или повреда на вградения код.

Fuzz тестването първоначално е разработено от Бартън Милър в Университета на Уисконсин-Мадисън, който въвежда термина, след като шум от линията на модемната връзка е сривал програмите, които е използвал. Неговите студенти са стартирали първите fuzz-тестове през 1989 г. и са установили, че приблизително една трета от UNIX помощните програми, към които са се насочили, са се сринали или са замръзнали. Fuzz тестването е... тестване на софтуер техника и е вид Тестване на сигурността.

Диаграмата по-долу показва основния цикъл на размиване (fuzzing loop), при който генерираните данни се изпращат към тестваното приложение и се наблюдава отговорът.

Защо да правите Fuzz тестване?

Фъзингът си заслужава мястото в тестовия план, защото изследва входни данни, за които никой не се е сетил да напише тестов случай. Основните причини, поради които екипите го възприемат, са изброени по-долу.

• Fuzz тестването обикновено открива най-сериозните грешки и дефекти в сигурността, защото сривът е пряко доказателство за необработен входен път.
• Fuzz тестването дава по-ефективен резултат, когато се използва с черно Box Тестване, бета тестване и други методи за отстраняване на грешки.
• Fuzz тестването се използва за проверка на уязвимостта на софтуера и е много рентабилна техника за тестване, тъй като входните данни се генерират, а не се пишат на ръка.
• Fuzz тестването е една от техниките за тестване на черната кутия. Fuzzing тестването е и един от най-често срещаните методи, които хакерите използват, за да намерят уязвимост в системата, така че първото му изпълнение премахва най-лесния път за нападателя.

Видове fuzz тестване

Фъзърите обикновено се групират по това колко знаят за програмата, която атакуват. Колкото повече знае фазърът, толкова по-дълбоко в кода може да го внедри.

Тип	Какво знае пухкавият	Типична употреба
Размиване на черната кутия	Нищо за вътрешните компоненти; вижда само входове и изходи.	Quick smoke работи срещу двоичен файл или активна крайна точка.
Бяла кутия размива	Пълен изходен код, често комбиниран със символно изпълнение за решаване на труднодостъпни разклонения.	Задълбочен анализ на компонент, чийто източник е наличен.
Сива кутия, размътваща	Без преглед на изходния код, но с обратна връзка по време на изпълнение, например до кой код е достигнал даден вход.	По подразбиране за съвременни двигатели като AFL++ и libFuzzer.

Втора, по-стара раздяла разделя тъпо размазване от интелигентно размиванеГлупавият фазър обръща битове без никаква представа за входния формат, така че по-голямата част от данните му се отхвърлят от първия парсер, с който се сблъска. Интелигентният фазър разбира контролни суми, полета за дължина и структура на съобщението, така че входните му данни оцеляват след валидирането и достигат до логиката отдолу. Размиване, ръководено от покритието е усъвършенстването на сивата кутия, което направи размиването мейнстрийм: двигателят инструментира двоичния файл, запазва всеки вход, който достига до нов клон, и мутира оцелелите, така че корпусът постоянно еволюира към неизследван код, вместо да се рестартира от случаен шум.

Как да направите Fuzz тестване

Стъпките за fuzz тестване включват основните стъпки на тестване:

Стъпка 1) Идентифицирайте целевата система — изберете крайната точка на двоичния файл, библиотеката, услугата или протокола, която ще бъде атакувана, и потвърдете, че имате право да я тествате.

Стъпка 2) Идентифицирайте входовете — избройте всяка входна точка, от която целта чете: файлове, аргументи на командния ред, променливи на средата, мрежови пакети, полета на формуляри и полезни товари на API.

Стъпка 3) Генериране на Fuzzed данни — генерират деформирани входни данни чрез мутиране на валидни образци, чрез генерирането им от модел на формата или чрез комбиниране на двете.

Стъпка 4) Изпълнете теста, използвайки размити данни — стартирайте целта спрямо генерираните входни данни, в идеалния случай в цикъл, който рестартира процеса автоматично след всеки неуспех.

Стъпка 5) Наблюдавайте поведението на системата — следете за сривове, замръзвания, неуспешни твърдения, прекомерно използване на паметта и отчети за дезинфекция, вместо само да проверявате отпечатания изход.

Стъпка 6) Регистрирайте дефекти — запазете точния вход, който е задействал всеки неуспех, свийте го до най-малкия възпроизвеждащ се случай и го поставете в стека tracе приложен.

Примери за Fuzzers

Фъзърите също се класифицират по начина, по който изграждат входните си данни, а трите подхода по-долу са тези, които ще срещнете най-често.

• Фузъри, базирани на мутации променя съществуващи проби от данни, за да създава нови тестови данни. Това е много прост и ясен подход: той започва с валидни проби от протокол и продължава да променя всеки байт или файл.
• Базирани на генериране Fuzzers дефинират нови данни въз основа на входните данни на модела. Те започват да генерират входни данни от нулата въз основа на спецификацията.
• Протоколно-базирани фузери зависят от детайлно познаване на тествания формат на протокола, а това разбиране идва от спецификацията. Това включва записване на масив от спецификацията в инструмента, след което използване на техника за генериране на тестове, базирана на модел, за да се премине през спецификацията и да се добавят нередности в съдържанието на данните, последователността и т.н. Това е известно още като синтактично тестване, граматическо тестване или тестване за устойчивост. Фъзърът може да генерира тестови случаи от съществуващ такъв или може да използва валидни или невалидни входни данни.

Има две ограничения на базирания на протокол размиване:

1. Тестването не може да продължи, докато спецификацията не е узряла.
2. Много полезни протоколи са разширение на публикувани протоколи. Ако тестването на мъх се основава на публикувани спецификации, Тестово покритие за нови протоколи ще бъдат ограничени.

Най-простата форма на fuzzing техника е изпращането на произволен вход към софтуера, или като протоколни пакети, или като събитие. Тази техника за предаване на произволен вход е много мощна за откриване на грешки в много приложения и услуги. Съществуват и други техники, които са много лесни за изпълнение. За да приложим тези техники, просто трябва да променим съществуващите входове и можем да променим вход, просто като разменим неговите битове.

Видове бъгове, открити от Fuzz Testing

Тъй като фъзингът оценява изпълнението по това как се държи програмата, а не по очаквана стойност, дефектите, които той разкрива, се групират в три семейства.

• Неуспехи при твърдения и изтичане на памет: Тази методология се използва широко за големи приложения, където грешките засягат безопасността на паметта, което е сериозна уязвимост. Buffer Препълвания, използване след освобождаване и четения извън границите се появяват тук.
• Невалиден вход: При fuzz тестването, fuzz-ите се използват за генериране на невалиден вход, който се използва за тестване на процедури за обработка на грешки, и това е важно за софтуер, който не контролира входните си данни. Простото fuzzing може да се разглежда като начин за автоматизиране. отрицателен тест.
• Грешки в коректността: Размиването може да се използва и за откриване на някои видове грешки в „коректността“, като например повредена база данни или лоши резултати от търсенето. Диференциалното размиване, което подава един и същ вход към две реализации и сравнява отговорите, е обичайният начин за тяхното откриване.

Инструменти за тестване на Fuzz

Инструменти, използвани в уеб сигурността, могат да бъдат широко използвани при fuzz тестване, като например Burp Suite и Peach Fuzzer. Няколко от класическите имена по-долу вече са архивирани, така че текущото им състояние е посочено до всеки запис.

• Праскова FuzzerPeach Fuzzer осигурява по-стабилно покритие за сигурност от скенер. Други инструменти за тестване могат да търсят само известни заплахи, докато Peach Fuzzer позволява на потребителите да намират известни и неизвестни заплахи. Peach Tech беше придобита от GitLab и Community Edition v3 вече не се поддържа; поддържаният наследник е GitLab Protocol Fuzzer Community Edition.
• Спайк прокси: професионален инструмент, който търси уязвимости на ниво приложение в уеб приложения. SPIKE Proxy обхваща основите, като например SQL Инжектиране и междусайтово скриптиране, на напълно отворена среда Python инфраструктура и тя беше достъпна за Linux намлява WindowsНе е поддържан от много години и е включен тук за исторически контекст.
• WebScarabWebScarab е написан на Java и следователно е преносим към много платформи. Рамката WebScarab комуникира чрез HTTP и HTTPS протоколи и работи като прихващащ прокси: тя позволява на оператора да преглежда и променя заявки, създадени от браузъра, преди сървърът да ги получи, и да преглежда и актуализира отговорите, генерирани от сървъра, преди браузърът да ги получи. Всяка „вратичка“, която WebScarab открие, се добавя към списъка с докладвани проблеми. Хранилището е архивирано през април 2024 г. и вече е само за четене.
• OWASP WSFuzzerWSFuzzer е програма с GPL лиценз, написана на Python който е насочен към уеб услуги, а в последната си версия, базирана на HTTP SOAP услуги бяха основната цел. Доставяше се като част от WebScarab и беше пенсиониран заедно с него; OWASP ZAP и неговото допълнение Fuzzer са препоръчителната замяна.
• Поддържани алтернативи: АФЛ++ намлява libFuzzer са стандартните двигатели, управлявани от покритие, за нативен код, OSS Fuzz изпълнява ги непрекъснато и безплатно за проекти с отворен код, и глупак обхваща размиването на мрежовия протокол в PythonПо-широк списък е събран в ръководството за инструменти за тестване на сигурността.

Най-добри практики за fuzz тестване

Фъзър, насочен към цел и оставен на мира, рядко намира много. Практиките по-долу разграничават кампания, която генерира регистрирани дефекти, от такава, която само изразходва процесорно време.

• Започнете с добър корпус от семена. Събирайте реални, валидни входни данни, които приложението вече приема. Мутирането на истински файл достига до код за парсиране много по-бързо от мутирането на произволни байтове.
• Напишете малък, бърз набор от инструменти. Входната точка трябва да прави едно нещо на изпълнение, да избягва мрежови извиквания и записи на диск и да се връща бързо, защото пропускателната способност се измерва в изпълнения в секунда.
• Включете дезинфектантите. Тихото повреждане на паметта често не води до срив. AddressSanitizer и UndefinedBehaviorSanitizer го превръщат в незабавен, диагностицируем отказ.
• Бягайте дълго и бягайте непрекъснато. Едночасов или двучасов процес улавя плитки грешки; дълбоките пътища обикновено изискват много часове, поради което размиването е част от нощна CI задача, а не от ръчна сесия.
• Минимизирайте и премахнете дублиранията на всеки срив. Свиване на неуспешния вход до най-малката му форма и групиране на сривовете по стек tracд., в противен случай един бъг пристига като стотици билети.
• Поддържайте регресионен корпус. Добавете всеки възпроизвеждащ се вход към постоянен набор, който се изпълнява при всяка компилация, така че фиксиран дефект да не може тихо да се върне.
• Определете целта по законен начин. Размиването на активна услуга на трета страна без писмено разрешение е неразличимо от атака.

Предимства на Fuzz тестването

Използвано с реалистични очаквания, размиването добавя стойност, с която други техники трудно могат да се сравнят.

• Fuzz тестването подобрява тестването за сигурност на софтуера.
• Грешките, открити при размиването, понякога са сериозни и често са същите, използвани от атакуващите, включително сривове, течове на памет и необработени изключения.
• Ако някои грешки не бъдат забелязани от тестерите поради ограничения във времето и ресурсите, тези грешки се откриват и при fuzz тестване.
• Входните данни се генерират от машина, така че покритието продължава да расте за една нощ без допълнителни ръчни усилия.

Недостатъци на Fuzz тестването

Същите свойства, които правят фъзинга евтин, ограничават и това, което той може да докаже.

• Самото fuzz тестване не може да предостави пълна картина на цялостната заплаха за сигурността или набор от грешки.
• Fuzz тестването е по-малко ефективно при справяне със заплахи за сигурността, които не причиняват сривове на програмата, като например някои вируси, червеи и троянски коне.
• Fuzz тестването може да открие само относително прости грешки или заплахи и няма да разсъждава върху бизнес логиката.
• За да се изпълнява ефективно, е необходимо значително машинно време.
• Задаването на гранично условие със случайни входни данни е много проблематично, въпреки че тестерите сега решават голяма част от това с детерминистични алгоритми, управлявани от потребителски входни данни.

Fuzz тестване срещу тестване за проникване

И двете дейности търсят дефекти в сигурността, но отговарят на различни въпроси и рядко са взаимозаменяеми.

Критерии	Fuzz тестване	Проверка на проникването
Каран от	Автоматизиран двигател, генериращ деформиран вход	Умел тестер, който разсъждава за системата
Търси	Сривове, замръзвания и проблеми със сигурността на паметта	Слабости, които могат да бъдат използвани, включително логически и конфигурационни недостатъци
Дълбочина	Много широко покритие на входните данни, повърхностно разсъждение	Тесен обхват, дълбоки разсъждения
Продукция	Възпроизвеждане на входни данни и стек traces	Доклад с констатации с пътища на експлоатация и оценки на риска
Най-добър момент	Непрекъснато, в процеса на изграждане	Периодично, срещу кандидат за освобождаване

На практика двете се подхранват взаимно: размиването (fuzzing) изчиства евтините, автоматизирани сривове, така че ограниченото време на тестващия да се насочи към недостатъците, които само човек може да забележи.

Въпроси и Отговори