True Crypt a backdoor

Areopagita

Bardzo aktywny
Zasłużony
Dołączył
18 Sierpień 2010
Posty
1046
Reakcje/Polubienia
15
Miasto
różne
Przekonujący dowód z kompilacji ze źródeł: w truecrypt.exe nie ma furtek
Strona główna Aktualności25.10.2013 14:47OPROGRAMOWANIE

TrueCrypt jest jednym z najpopularniejszych narzędzi do szyfrowania dysków i tworzenia wirtualnych, zaszyfrowanych napędów, a jednocześnie jednym z najbardziej kontrowersyjnych narzędzi tego typu. Nie wiadomo, kto jest jego autorem, nie jest też jasne, jak licencja, zgodnie z którą jest udostępniany, ma się do innych opensource'owych licencji. Co gorsza, gdy po aferze z PRISM branża zaczęła się poważnie zastanawiać nad obecnością w oprogramowaniu furtek wstawianych tam pod presją służb wywiadowczych, okazało się, że nikt nie potrafił uzyskać z dostępnego kodu źródłowego plików binarnych identycznych z tymi, które dostępne były na stronie projektu. Wątpliwości co do „szczelności” TrueCrypta zainspirowały jego użytkowników do zbiórki pieniędzy na publiczny audyt narzędzia. Od jego rozpoczęcia minęło raptem 10 dni, a już starania przyniosły ciekawe efekty.

Mimo że do zakończenia zbiórki pieniędzy zostało 50 dni, to widać, że społeczności na tej inicjatywie zależy. Choć celem miało być pozyskanie 25 tys. dolarów, to w serwisie IndieGogo zebrano już ponad 32 tys. dolarów, zaś w FundFill ponad 15 tys. dolarów i 27 bitcoinów (ok. 5 tys. dolarów po aktualnym kursie). Mimo zaś, że oficjalne prace audytorskie się jeszcze nie zaczęły, zaś strona IsTrueCryptAuditedYet.com wciąż na tytułowe pytanie odpowiada „nie”, to jednemu z badaczy, pracującemu niezależnie od inicjatywy audytu kodu, udało się osiągnąć bardzo interesujący rezultat.
Grafika

Jest już niemal pewne, że publicznie dostępna binarna wersja TrueCrypta 7.1a dla Windows powstała z oficjalnie dostępnych źródeł tej wersji. Kanadyjski programista Xavier de Carnavalet pokazał, jak odtworzyć proces kompilacji, tak by uzyskany plik wynikowy pasował do oficjalnej binarki. Co prawda nie udało się uzyskać stuprocentowej zgodności, ale de Carnavalet dość jasno wyjaśnia przyczyny drobnych różnic.

Sam proces kompilacji TrueCrypta na Windows nie wygląda zbyt atrakcyjnie. Należy dysponować Visual C++ 2008 SP1 Professional Edition, Visual C++ 1.52, skonfigurowanym dla Visual C++ SDK for Windows 7 oraz zestawem Windows Driver Kit 7.1.0 (wszystko to od Microsoftu), a także nagłówkami Cryptographic Token Interface od RSA, assemblerem NASM i kompresorem gzip. Konieczne jest też zainstalowanie określonych łatek dla Visual Studio, gdyż najdrobniejsze zmiany w użytych wersjach tych narzędzi prowadzą do zmian w plikach wynikowych – a to właśnie do tej pory było powodem podejrzewania obecności furtek NSA w TrueCrypcie.

Po zbudowaniu własnej wersji TrueCrypta, kanadyjski programista porównał je bajt po bajcie, by uzasadnić znalezione różnice. Wynikać one mają przede wszystkim z podpisania oficjalnych binarek certyfikatem (czego oczywiście Xavier de Carnavalet zrobić nie mógł), niemożliwości osadzenia binarki w pliku instalacyjnym bez takiej podpisanej wersji, oraz oczywiście innych czasoznaczków niż przy oryginalnej kompilacji. Po ich pominięciu, obie binarne wersje są identyczne.

Te same wyniki przyniosła inżynieria wsteczna – dezasemblacja obu binarek przeprowadzona za pomocą 64-bitowej wersji MinGW zwróciła co do bajta identyczne pliki, co oznacza, że obie wersje wykonują dokładnie te same zadania, nie ma tu miejsca na ukrycie furtki. Oczywiście paranoicy w swoich kapeluszach z aluminiowej folii mogą argumentować, że przecież w obu wypadkach użyto do kompilacji zamkniętego, własnościowego kompilatora Microsoftu, co do którego nie można mieć pewności, czy nie padł ofiarą ataku, opisanego w 1984 roku przez Kena Thompsona. Atak ten polega na zmodyfikowaniu binarki kompilatora, tak by kompilator tworzył złośliwe wersje pewnych programów, w tym złośliwe wersje siebie samego. Wykrycie takiego ataku jest bardzo trudne, ale i jego przeprowadzenie pozostaje dziś bardziej w sferze teorii.

Bardziej prawdopodobny jest scenariusz, w którym furtka do TrueCrypta została wprowadzona jawnie, do kodu źródłowego, jest jednak tak subtelna, że na pierwszy rzut oka nie można jej wykryć. Może to być np. celowo nieprawidłowa implementacja jednego z kryptograficznych algorytmów, zmniejszająca poziom trudności siłowego ataku, którą wykryć może jedynie szczegółowy audyt kryptograficzny. Czy do czegoś takiego doszło, dowiemy się już w najbliższych miesiącach. Na korzyść TrueCrypta przemawia jednak fakt, że najwyraźniej nawet FBI nie posiada hipotetycznej furtki do tego programu – przykładowo w 2010 roku śledczy tej agencji przyznali, że nie są w stanie odszyfrować zawartości dysków twardych Daniela Dantasa, bankiera aresztowanego przez brazylijską policję pod zarzutem prania brudnych pieniędzy. Wówczas to policyjni technicy, narzekając że nie mają sposobu, aby zmusić twórców TrueCrypta do pomocy w tej sprawie, przez 12 miesięcy próbowali złamać hasło siłowo, aż w końcu zrezygnowani poddali się, a Dantas został wypuszczony na wolność.

Można więc założyć, że jeśli NSA faktycznie umieściła furtkę w TrueCrypcie, to stosuje ją wyłącznie w sprawach najwyższej wagi, dotyczących obronności kraju czy szpiegostwa przemysłowego w strategicznych dziedzinach. Ujawnienie jej istnienia w sprawach relatywnie małej wagi byłoby w tej sytuacji absurdem.
info:dobreprogramy.pl

Zaloguj lub Zarejestruj się aby zobaczyć!
 

remool

Bardzo aktywny
Fąfel
Dołączył
12 Maj 2011
Posty
2964
Reakcje/Polubienia
71
Znamy wyniki pierwszej analizy kodu źródłowego i binarnego TrueCrypta
Czy używanie TrueCrypta jest bezpiecznie? Czy są w nim ukryte tylne furtki zainstalowane przez NSA, CIA, MOSAD, KGB czy kto wie jeszcze czyje? Czy czarne, szare i białe kapelusze mogą spać spokojnie? Dziś już jesteśmy bliżej odpowiedzi na to pytanie.

Właśnie ukazał się raport
Zaloguj lub Zarejestruj się aby zobaczyć!

z pierwszego etapu analizy kodu źródłowego TrueCrypta, pomysłu zapoczątkowanego w październiku 2013. Pomijając zbędne budowanie napięcia przez kilka akapitów które nawet Alfred Hitchcock uważałby za nudne – ogłaszamy wszem i wobec: JEST DOBRZE.
Co udało się sprawdzić?
Na pierwszy rzut audytorzy wzięli dwa elementy: bootloader TrueCrypta oraz sterowniki pod Windows. Oprócz przeglądnięcia kodu i sposobu budowy oprogramowania dokonali oni również fuzzingu (testowanie poprzez wprowadzanie zarówno poprawnych jak i błędnych i nieoczekiwanych danych lub parametrów). Etap ten był bardzo ważny ze względu na to, że system Windows jest jedynym obsługującym i wspierającym pełne szyfrowanie dysku w TrueCrypcie oraz to, że kod który był audytowany, jest tym samym który udostępniany jest w skompilowanych plikach binarnych. Testy przeprowadzane były na udostępnianych plikach binarnych, a nie na ręcznie kompilowanej wersji.
Jakie błędy wyszły?
Mimo wielu uwag co do samej jakości kodu (w szczególności jakości (oraz braku) komentarzy), zanotowano w sumie tylko 11 błędów, z czego cztery z nich określone były jako średnio ważne, cztery o niskiej wartości i trzy informacyjne, mające jednak częściowy wpływ na całość bezpieczeństwa aplikacji.Wśród błędów o średnim znaczeniu, znalazł się np. błąd związany z zapisaniem do pliku wymiany wrażliwych informacji (w tym informacji o kluczu), w sytuacji, gdy atakujący doprowadzi do zapełnienia pamięci operacyjnej systemu ofiary (oczywiście problem ten opisany jest w dokumentacji technicznej, gdzie należy albo wyłączyć wspomniany plik wymiany, albo przechowywać go również na zaszyfrowanej partycji). Na podobnym problemie bazuje inny błąd o tym samym znaczeniu, a jego wyeliminowanie możliwe jest poprzez zastosowanie zamiast funkcji memset() funkcji burn(), dzięki czemu można uniknąć przesunięcia nieużywanych już danych z pamięci do pliku wymiany.

Kolejnym błędem o średnim znaczeniu, był tzw. atak złej pokojówki, gdzie poprzez modyfikację kodu bootloadera możliwe jest zmuszenie go do zapisania hasła w momencie wpisywania go przez użytkownika. Problem ten związany jest głównie z kiepską jakością kodu, o której piszemy w kolejnej części.

Wskazany został również problem związany z weryfikacją nagłówka wolumenu. Obecnie zamiast zastosowania dostępnych funkcji umożliwiających weryfikację integralności oraz autentyczności zaszyfrowanych danych (HMAC), stosowany jest dosyć słaby algorytm CRC32 (na podstawie deszyfrowania czterech pierwszych bajtów zawierających słowo „TRUE”, oraz sumy kontrolnej ostatnich 256 bajtów sprawdzana jest zgodność tych danych z danymi zawartymi w 8 bajcie zaszyfrowanych danych).
Przejrzystość kodu
Audytorzy zwrócili uwagę, że o ile sama aplikacja nie posiada większych problemów, o tyle, jakość kodu, jego przejrzystość jak i sposób komentowania nie spełniają ogólnie przyjętych standardów bezpieczeństwa. W tym wypadku nie powoduje to występowania problemów, ale przywołując przypadek nginx, warto zwracać szczególną uwagę na przedziały w jakich operują zmienne, choćby po to by uniknąć błędów przepełnienia bufora.
Co dalej?
To jeszcze nie koniec prac. W kolejnej części audytu analizie zostaną poddane błędy związane z samym szyfrowaniem. Weryfikację przejdą sposoby implementacji funkcji szyfrujących dane, poprawności wykorzystania dostępnych algorytmów oraz podatności na znane metody i ścieżki deszyfrowania danych, o czym z przyjemnością napiszemy ponownie
info:zaufanatrzeciastrona.pl
 

remool

Bardzo aktywny
Fąfel
Dołączył
12 Maj 2011
Posty
2964
Reakcje/Polubienia
71
Audyt Truecrypta zakończony, znaleziono dwa istotne błędy w implementacji....ale i tak jest dobrze
timthumb.php

Zakończyła się druga faza audytu Truecrypta, obejmująca jego mechanizmy kryptograficzne. Nie znaleziono żadnej tylnej furtki, za to trafiono na dwa błędy wymagające poprawy. Nie wpadajcie jednak w panikę – nie jest tragicznie.

Dosłownie dwie godziny temu opublikowano raport z drugiej fazy audytu Truecrypta. W sumie audytorzy badający kod źródłowy aplikacji zidentyfikowali cztery różne błędy, z czego dwa określono jako istotne. Istnieje jednak duże prawdopodobieństwo, że nie musicie wyrzucać dysków do Wisły.
całe info

Zaloguj lub Zarejestruj się aby zobaczyć!
Wynika z tego, że bez obaw możemy używać ostatniej pewnej wersji 7.1a......a co do tych błędów to miejmy nadzieję, że zostaną poprawione w rozwijanych forkach
 

Manila

Bardzo aktywny
Fąfel
Dołączył
15 Październik 2012
Posty
1213
Reakcje/Polubienia
58
Panikarzy pewnie to i tak nie przekona
cLKhHQq.gif
 
Do góry