Wyzwania informatyki bankowej 2016
wyzwania_informatyki_bankowej_0 wyzwania_informatyki_bankowej_0
(z ang. Virtual Environments). Popularnym w tej chwili sposobem wykorzystania kontenerów jest Docker, który pierwotnie bazował właśnie na mechanizmie lxc w systemie Linux. Docker – podobnie, jak jego inny popularny konkurent Vagrant – to tak naprawdę kolejna warstwa abstrakcji, działająca ponad warstwą wirtualizacyjną. Rozwiązania te przyjęły się z kilku prostych powodów: • Kontenery w implementacji takiej jak lxc są lżejsze od całych maszyn wirtualnych, jednak nie oferują tak doskonałej izolacji jak typowe maszyny wirtualne – ma to swoje konsekwencje z perspektywy bezpieczeństwa. • Docker i Vagrant zapewnieją łatwiejsze zarządzanie i przygotowanie maszyn wirtualnych (lub kontenerów) do wielokrotnego użycia oraz dystrybucji. • Kontenery są często tworzone do chwilowych zadań, np. testów, demonstracji czy określonej sesji. Są też popularnie wykorzystywane w procesach Continous Integration (CI). Ta chwilowość także ma swoje konsekwencje z perspektywy bezpieczeństwa. Ze względu na ograniczone miejsce, omówię tylko dwie wskazane powyżej kwestie bezpieczeństwa: • Niedoskonała izolacja – nie jest w tym nic złego pod warunkiem, że ma się świadomość takiego ograniczenia. Niektóre zastosowania nie wymagają pełnej izolacji. Kolejnym problemem może być kontrola dostępu. Vagrant np. domyślnie wykorzystuje SSH do dostępu do maszyny wirtualnej, jednak z poziomu użytkownika, który utworzył maszynę lub kontener każdy ma dostęp do klucza SSH. • Tymczasowość kontenerów – zwłaszcza w przypadku użycia rozwiązania typu Vagrant – może być bardzo złudna. To że maszyna wirtualna jest zatrzymywana (np. poleceniem vagrant halt) lub niszczona (vagrant destroy 1 ) wcale nie oznacza, że dane przetwarzane w niej faktycznie uległy nieodwracalnemu zniszczeniu. W praktyce są to po prostu pliki kasowane z poziomu hypervisora – nie jest to więc operacja gwarantująca bezpieczne usunięcie danych. Innym problemem tymczasowości są aktualizacje. Kontenery zazwyczaj nie są uwzględnione w procesie patch management. 1 W przypadku Vagrant także usunięcie potem boksa poleceniem vagrant box remove nie ma znaczenia Cybersecurity – moda, mit czy rzeczywistość? 173
Podatności w SSL/TLS oraz algorytmach kryptograficznych Ostatnie lata obfitowały w podatności w implementacjach protokołów SSL i TLS. Co więcej starsze wersje tych protokołów, choć od dawna uznawane za niebezpieczne nadal są stosowane w wielu rozwiązaniach. Podobnie sytuacja wygląda z funkcją skrótu SHA-1, która od 2005 r. nie jest uznawana za bezpieczną na skutek ataków z użyciem kryptoanalizy. SHA-1 nie jest wyjątkiem, jeśli chodzi o używanie niebezpiecznych funkcji skrót. Nadal popularne jest wykorzystywanie funkcji MD5, o której od wielu lat wiadomo, że nie jest bezpieczna. Kardynalnym przykładem wykorzystania jej słabości jest robak Flame. Wracając do podatności w implementacji protokołów SSL/TLS należy pamiętać, że ponad połowa używanych dzisiaj rozwiązań współdzieli kod z biblioteką OpenSSL (albo wręcz wykorzystuje samą bibliotekę). Rosnąca liczba podatności w OpenSSL spowodowała powstanie projektu LibreSSL, który w założeniu miał być bezpieczną reimplementacją funkcjonalności OpenSSL. W praktyce jednak, twórcy LibreSSL także nie ustrzegli się od błędów prowadzących do podatności. Omawiając podatności związane z protokołami SSL/TLS oraz ich implementacjami nie wolno zapomnieć o dwóch istotnych atakach: • DROWN – pozwala atakującym na odczytanie zaszyfrowanej komunikacji. Według jego autorów 33% serwerów HTTPS jest podatnych na ten atak [1]. W uproszczeniu jest on możliwy, gdy włączona jest obsługa SSLv2. • HeartBleed [2] – pozwala na odczytanie zaszyfrowanej komunikacji. Atak jest możliwy na skutek błędu w obsłudze rozszerzenia heartbeat w starszych wersjach OpenSSL. Analizując powyższe problemy z bezpieczeństwem warto się zapoznać z podatnościami: CVE-2016-0703, CVE-2016-0704, CVE-2015-0293 i CVE- 2014-0160. Innym istotnym protokołem używanym powszechnie – zwłaszcza w wielu usługach IaaS i PaaS w chmurze – jest SSH. Tutaj sytuacja wygląda lepiej, ponieważ rynek serwerów SSH jest praktycznie zdominowany przez implementację OpenSSH, która domyślnie od dawna ma wyłączoną obsługę protokołu v1 uznawanego za niebezpieczny. Jednakże nawet wyłączenie określonej funkcjonalności domyślnie przez twórcę nie gwarantuje, że użytkownicy lub producenci nie włączą jej ponownie. Idealnie obrazuje to podatność xauth 174 Aleksander P. Czarnowski, AVET
- Page 124 and 125: Piotr Pinchinat-Miernik, Paweł Muc
- Page 126 and 127: Jeszcze na początku lat 90. równi
- Page 128 and 129: System ten pozwala klientom na wyda
- Page 130 and 131: Najnowsze rozwiązanie, czyli wszys
- Page 132 and 133: Korzyści dla wierzycieli • Łatw
- Page 134 and 135: Płatności G2C oraz G2B W przyszł
- Page 136 and 137: Andrzej Kawiński, Giesecke & Devri
- Page 138 and 139: nia jest ograniczona, co ogranicza
- Page 140 and 141: W Polsce Państwowa Wytwórnia Papi
- Page 142 and 143: Europejskie standardy przechowywani
- Page 144 and 145: gotówka (często liczona, paczkowa
- Page 146 and 147: urządzeń zainstalowanych w sortow
- Page 148 and 149: Zagraniczne doświadczenia pokazuj
- Page 150 and 151: Andrzej Gibas, Microsoft, Karol Maz
- Page 152 and 153: • duża zmienność rynków i wra
- Page 154 and 155: Dominujące dzisiaj podejście do a
- Page 156 and 157: procesorów budowanych w oparciu o
- Page 158 and 159: SDC uzyskało oszczędności na poz
- Page 160 and 161: też zostanie przeprowadzony jednor
- Page 163 and 164: Aleksander P. Czarnowski Prezes AVE
- Page 165 and 166: z co najmniej 2-, a jeszcze lepiej
- Page 167 and 168: Ransomware czyli różne oblicza sz
- Page 169 and 170: system nigdy nie dostarcza pełnego
- Page 171 and 172: Rys 2. Przykład fałszywej wiadomo
- Page 173: IoT Internet of Things z pewności
- Page 177 and 178: instalacja i konfiguracja serwera S
- Page 179 and 180: w krótkim czasie. Dla niektórych
- Page 181 and 182: Adam Marciniak Dyrektor Pionu Rozwo
- Page 183 and 184: 50 tys. komputerów w tym samym cza
- Page 185 and 186: które łącznie pozwoliły wyprowa
- Page 187 and 188: skutkując izolacją kraju od reszt
- Page 189 and 190: tacji branżowych narodziła się k
- Page 191 and 192: Ciekawym przykładem z ojczyzny Int
- Page 193 and 194: Z inicjatywy Rady Bankowości Elekt
- Page 195: • Opracowanie ogólnobankowej, sp
- Page 198 and 199: Maciej Gawroński, Sławomir Szepie
- Page 200 and 201: • Sprecyzowanie katalogu wyłącz
- Page 202 and 203: • Płatnik (posiadacz rachunku ba
- Page 204 and 205: Zagraniczne podmioty profesjonalnie
- Page 206 and 207: gulacje odnośnie opłat interchang
- Page 208 and 209: nikacji między poszczególnymi pod
Podatności w SSL/TLS oraz algorytmach kryptograficznych<br />
Ostatnie lata obfitowały w podatności w implementacjach protokołów SSL<br />
i TLS. Co więcej starsze wersje tych protokołów, choć od dawna uznawane<br />
za niebezpieczne nadal są stosowane w wielu rozwiązaniach. Podobnie sytuacja<br />
wygląda z funkcją skrótu SHA-1, która od 2005 r. nie jest uznawana za<br />
bezpieczną na skutek ataków z użyciem kryptoanalizy. SHA-1 nie jest wyjątkiem,<br />
jeśli chodzi o używanie niebezpiecznych funkcji skrót. Nadal popularne<br />
jest wykorzystywanie funkcji MD5, o której od wielu lat wiadomo, że nie jest<br />
bezpieczna. Kardynalnym przykładem wykorzystania jej słabości jest robak<br />
Flame.<br />
Wracając do podatności w implementacji protokołów SSL/TLS należy pamiętać,<br />
że ponad połowa używanych dzisiaj rozwiązań współdzieli kod z biblioteką<br />
OpenSSL (albo wręcz wykorzystuje samą bibliotekę). Rosnąca liczba<br />
podatności w OpenSSL spowodowała powstanie projektu LibreSSL, który<br />
w założeniu miał być bezpieczną reimplementacją funkcjonalności OpenSSL.<br />
W praktyce jednak, twórcy LibreSSL także nie ustrzegli się od błędów prowadzących<br />
do podatności.<br />
Omawiając podatności związane z protokołami SSL/TLS oraz ich implementacjami<br />
nie wolno zapomnieć o dwóch istotnych atakach:<br />
• DROWN – pozwala atakującym na odczytanie zaszyfrowanej komunikacji.<br />
Według jego autorów 33% serwerów HTTPS jest podatnych na ten atak<br />
[1]. W uproszczeniu jest on możliwy, gdy włączona jest obsługa SSLv2.<br />
• HeartBleed [2] – pozwala na odczytanie zaszyfrowanej komunikacji. Atak<br />
jest możliwy na skutek błędu w obsłudze rozszerzenia heartbeat w starszych<br />
wersjach OpenSSL.<br />
Analizując powyższe problemy z bezpieczeństwem warto się zapoznać<br />
z podatnościami: CVE-<strong>2016</strong>-0703, CVE-<strong>2016</strong>-0704, CVE-2015-0293 i CVE-<br />
2014-0160.<br />
Innym istotnym protokołem używanym powszechnie – zwłaszcza w wielu<br />
usługach IaaS i PaaS w chmurze – jest SSH. Tutaj sytuacja wygląda lepiej,<br />
ponieważ rynek serwerów SSH jest praktycznie zdominowany przez implementację<br />
OpenSSH, która domyślnie od dawna ma wyłączoną obsługę protokołu<br />
v1 uznawanego za niebezpieczny. Jednakże nawet wyłączenie określonej<br />
funkcjonalności domyślnie przez twórcę nie gwarantuje, że użytkownicy lub<br />
producenci nie włączą jej ponownie. Idealnie obrazuje to podatność xauth<br />
174 Aleksander P. Czarnowski, AVET
Change language