rssLink RSS dla wszystkich kategorii
 
icon_orange
icon_red
icon_red
icon_blue
icon_blue
icon_blue
icon_green
icon_red
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_blue
icon_red
icon_blue
icon_orange
icon_red
icon_blue
icon_blue
icon_blue
icon_blue
icon_green
icon_blue
icon_blue
 

FS#16227 — Problem z zabezpieczeniami

Przydzielony do projektu— Manager
Nagła usterka
dowolne
ZAMKNIĘTE
100%
Witam,

Kilka dni temu odkryliśmy, że wewnętrzne zabezpieczenia w sieci wewnętrznej w naszym biurze w Roubaix zostały naruszone. Po weryfikacji odnaleźliśmy hakera, któremu udało się otrzymać dostęp do konta email jednego z administratorów systemów. Dzięki temu uzyskał on dostęp do wewnętrznego protokołu VPN innego pracownika. Następnie udało mu się uzyskać dostępy jednego z administratorów systemu, który jest odpowiedzialny za wewnętrzny backoffice.

Wewnętrzne zabezpieczenia opierały się na 2 poziomach weryfikacji:
- geograficznym: obecność w biurze lub korzystanie z VPN-a, na IP źródłowym
- osobistym: hasło


Podjęte kroki
-------------------------

Po włamaniu natychmiast zmieniliśmy wewnętrzne zasady bezpieczeństwa:
- hasła wszystkich pracowników zostały zmienione na każdym poziomie dostępu.
- uruchomiliśmy nowy VPN w zabezpieczonej sali PCI-DSS z ograniczonymi dostępami
- sprawdzanie wewnętrznych emaili jest teraz możliwe tylko w biurze lub poprzez połączenie VPN
- wszystkie osoby posiadające krytyczne dostępy przechodzą na 3 poziomy weryfikacji:
- ip źródłowe
- hasło
- osobisty token hardware (YubiKey)


Wnioski
-------------------------

Podczas wewnętrznego postępowania dotyczącego tego problemu odkryliśmy, że hakerzy wykorzystali prawdopodobnie uprzywilejowane dostępy dla 2 operacji:
- uzyskanie dostępu do bazy danych naszych klientów w Europie
- uzyskanie dostępu do systemu instalacji serwerów w Quebecu.

Baza danych klientów w Europie zawiera dane osobowe klientów takie jak: nazwisko, imię, nic, adres, miejscowość, kraj, telefon, faks, zaszyfrowane hasło.
Szyfrowanie hasła opiera się na SHA512, aby uniknąć brutforce. Potrzeba wielu środków technicznych, aby odzyskać hasło. Jest to jednak możliwe. To dlatego zalecamy wam zmianę hasła do panelu klienta. Dziś prześlemy do wszystkich klientów email z wyjaśnieniami i z zaleceniem zmiany hasła. Informacje o kartach bankowych nie były widoczne. Nie przechowujemy ich w naszej infrastrukturze.

W przypadku systemu instalacji serwerów w Quebecu ryzyko jest następujące: jeśli klient nie usunął z serwera naszego klucza SSH, haker mógłby połączyć
się z naszego systemu i odzyskać hasło zapisane w pliku .p. Z klucza SSH nie można skorzystać z innego serwera. W przypadku gdy klient nie usunął naszego klucza SSH i nie zmienił hasła root, zmieniliśmy natychmiast hasło do serwera w serwerowni w BHS, aby uniknąć tego ryzyka. Dziś prześlemy email z nowym hasłem. Klucz SSH będzie usuwany systematycznie po dostarczeniu serwera zainstalowanego w Quebecu i w Europie. Jeśli klient będzie potrzebował pomocy OVH, będzie musiał zainstalować nowy klucz SSH.

W ciągu kilku miesięcy backoffice przejdzie na normę PCI-DSS, która pozwoli nam na zagwarantowanie, że w przypadku problemu związanego z włamaniem nie będzie wpływu na nasze bazy danych. Chcemy chronić wasze dane i zabezpieczyć się na wypadek szpiegostwa przemysłowego, ukierunkowanego na osoby pracujące w Ovh.

Składamy również skargę do instytucji sądowych. Aby nie zakłócać pracy śledczych, nie podamy więcej szczegółów.

Przepraszamy za tą sytuację. Dziękujemy za zrozumienie.

Pozdrawiam
Octave
Data:  środa, 31 lipiec 2013, 13:26
Powód zamknięcia:  Done