Алваро Муньос работи като Staff Security Researcher в GitHub Security Lab. Неговите изследвания са фокусирани в различни програмни езици и фреймуърци, свързани с уеб приложения, уязвимости и несигурни API практики. Преди GitHub той е бил част от установяването на защитни програми в различни ентърпрайз организации като Application Security Consultant. Освен това презентира своя труд и познания на множество конференции като DEF CON, RSA, AppSecEU, Protect, DISCCON и много други. През декември той бе и един от многото лектори на Java2Days и CodeMonsters конференциите.

Вие работите като Staff Security Researcher в GitHub Security Lab. Можете ли да опишете каква е работата ви Ви там?

GitHub Security Lab беше създадена преди 1 година като част от инициатива в Github за подпомагане на сигурността на софтуера с отворен код. Ние сме екип от около 10 души, които търсят предимно уязвимости във високопрофилни open source проекти, като използваме различни методи. Например аз прилагам повече static analysis, докато други хора в екипа са ориентирани към други техники.
Също така искаме да помогнем на разработчиците да разберат сигурността. Част от нашата мисия е не само да намираме бъгове и да ги докладваме, но също така и да популяризираме и пишем публикации и съдържание около това как да изградим сигурен софтуер и как да помогнем за идентифицирането на уязвимостите в своите проекти. Основно, работата ни е свързана с open source в GitHub, която е платформата където са хоствани около 80% от open source софтуерите.

Какво ви доведе до конференцията Java2Days и CodeMonsters и какво мислите за събитието, което за пръв път е виртуално?

Всъщност за втори път съм част от тези конференции, като първият път беше преди две или три години. Работех в друга компания тогава, Fortify, която е доставчик на статични анализи. Бях поканен да представя някои изследвания направени от мен, представени на една от най-важните конференции за сигурност, DEF CON и Black Hat. Бях поканен да представя същото съдържание и тук, на Java2Days и CodeMonsters конференциите. За мен бе удоволствие да взема участие и затова поддържам връзка с организаторите. Казах им, че ако имат нужда или искат да представя нещо и да им помогна с организацията или презентациите, ще го направя. Те се свързаха с мен, за да видят дали искам да говоря и тази година в това виртуално издание на Java2Days и аз разбира се приех.
Липсват ми всички дейности, които са организирани за говорителите, както и реалното пътуване. Когато презентирах преди няколко години имаше около сто души в залата, а сега по време виртуалното издание забелязах разговори с около 300-1300 зрители. Това е и чудесна възможност да разширим посланието си, защото на физическите конференции нямаме толкова богата публика. Впечатлен съм от броя на хората.

Вашата лекция “How variant analysis helped the fight against COVID-19?” звучи много интересно. Можете ли да обясните какво представляват тези анализи ?

Анализът на вариантите е процесът на използване на известна уязвимост за намиране на подобни проблеми във вашия код. Откривате грешка или някои уязвимости в сигурността, което обикновено е manual процес, който отнема часове, дни или дори седмици, в които изследователят по сигурността разглежда source кода, за да го разбере и да намери уязвимост или модел. След като откриете уязвимост, тези грешки обикновено не се появяват изолирано.
Рядкост е да намерите грешка, която е специфична само за вашата кодова база.
Идеята с анализа на вариантите е да можете да моделирате знанията, които сте получили чрез намирането на тази уязвимост, и да можете да изразите това в заявка, така че да възпроизведете същия процес на намиране на уязвимостта, но да го автоматизирате по начин, по който можете да го направете в стотици или хиляди проекти едновременно.
Вие намирате уязвимостта и след това искате да намерите всички нейни екземпляри. Като вендор или като част от поддръжката на продукти с отворен код, получавате отчети за уязвимости в сигурността във вашия софтуер и след това ги поправяте. Възможно е да има подобни случаи на същата уязвимост, която да е все още в source кода и да оставите приложението отворено за подобни, които не са открити. Идеята с анализа на вариантите е да вземете това, което е вече известно от изследователя на сигурността, да го поставите в някаква заявка и след това да я изпълните във вашия source код, за да намерите всички подобни случаи.
Преглеждах една уязвимост, която открих в Nexus, от хранилището от Sonatype, и когато извърших анализа на основната причина, разбрах какъв е проблемът. Успях да използвам този модел в нашата заявка с CodeQL и да я изпълня в множество проекти с отворен код в GitHub. Открих, че много от тях са уязвими, така че ние oт екипа бяхме отговорни за разкриването на всички тези бъгове.
Една такава уязвимост беше в приложението Corona-warn, което се използва в Германия за проследяване на вируса.
Това бе същата уязвимост, която засягаше Nexus преди две години, от която успяхме да научим много. Още със самото стартирането на Corona приложението успяхме да открием уязвимости от същия модел. По този начин получихме достъп до сървърите, които хостваха структурата на COVID-19 app-а в Германия.