Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



26.08.2021

Firma Fortinet rozszerzyła...

Firma Fortinet rozszerzyła ofertę o usługę FortiTrust, która dołączyła do innych usług...
26.08.2021

Aplikacje biznesowe

Ready_™ AppStore
26.08.2021

Automatyzacja chmur...

Integracja z Red Hat Ansible
26.08.2021

Backup kodu źródłowego

GitProtect.io dostępny na Github
26.08.2021

Wsparcie pracy hybrydowej

Zdalny SD WAN
26.08.2021

Nowy monitor Philips 498P9Z

Nowy monitor Philips 498P9Z to model wyposażony w 49-calowy, zakrzywiony panel VA o...
26.08.2021

Wytrzymały punkt dostępowy

D-Link DIS-2650AP
26.08.2021

Ekonomiczne dyski

SSD bez DRAM
26.08.2021

Petabajty pojemności

Serwery QNAP

Dependency confusion

Data publikacji: 29-04-2021 Autor: Maciej Olanicki

Uniwersalna metoda na wstrzykiwanie złośliwego kodu do serwerów produkcyjnych tysięcy firm, w tym takich branżowych mocarzy jak Microsoft czy Apple, brzmi bardziej jak scenariusz słabego filmu akcji niż faktyczny scenariusz ataku. A jednak był w stanie tego dokonać działający samodzielnie ekspert, umiejętnie eksploatując ryzyko, jakie niosą współczesne metodyki rozwoju oprogramowania.

 

Ataki skutkujące przejęciem łańcucha od lat spędzają sen z powiek CISO, CSO i innym ekspertom odpowiedzialnym za cyberbezpieczeństwo. Jeśli przyjrzeć się najważniejszym kampaniom skutkującym gigantycznymi stratami i paraliżem infrastruktury całych korporacji czy miast, to nierzadko na którymś z etapów ataku dochodziło do przejęcia łańcucha dostaw właśnie. Można sięgać w przeszłość, jak choćby do kampanii Petya/NotPetya z 2017 roku, ale nie brakuje świeższych przykładów, jak choćby tegoroczna SUNBURST, którą Brad Smith, dyżurny prawnik Microsoftu, określił jako największy i najbardziej złożony atak w historii.

Ataki na łańcuch dostaw są szczególnie groźne dziś, gdy rzadko tworzy się oprogramowanie od podstaw, a częściej łączy się rozwijane niezależnie od siebie dalece wyspecjalizowane moduły. Serwer dystrybuujący dowolny z nich może zostać przejęty przez cyberprzestępców, co poskutkuje tym, że potencjalnie złośliwy kod będzie rozsiewał dowolny program czy usługę wykorzystującą dany komponent. Gdy rozwiązania konstruuje się z użyciem trudnej do oszacowania liczby mniej lub bardziej prekonfigurowanych klocków, wystarczy, że jeden będzie wadliwy, by cała budowla runęła.

Zauważył to Alex Birsan, o którym bez przesady można powiedzieć, że jest zawodowym zwycięzcą w konkursach bug bounty i hakerem w białym kapeluszu o imponującym dorobku. Dostrzegając ryzyko, jakie niesie za sobą nadużywanie zależności pomiędzy bibliotekami dostępnymi w najpopularniejszych repozytoriach, Birsan przedstawił całkowicie nowy scenariusz ataku na łańcuch dostaw – dependency confusion. Ataku, w wyniku którego udało się z wykorzystaniem serwerów między innymi Microsoftu, Apple'a, Amazona, Slacka czy Ubera rozpowszechnić potencjalnie złośliwe oprogramowanie wśród kilkudziesięciu korporacji, o których na co dzień czytamy na pierwszych stron branżowej prasy.

ZACZĘŁO SIĘ OD PAYPALA

Birsan twierdzi, że pomysł ataku dependency confusion zakiełkował w jego głowie latem 2020 r., gdy próbował włamać się na serwery PayPala. Wówczas to trafił na będący w wewnętrznym użyciu firmy plik packages.json, w którym wylistowane były zależności z pakietami NPM, czyli menedżera pakietów niezwykle popularnego javascriptowego frameworku Node.js. Rzecz w tym, że zależności te odnosiły się do zasobów przechowywanych w niepublicznych repozytoriach PayPala.

 

[...]

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2019 Presscom / Miesięcznik "IT Professional"