Preorder drugiego tomu książki sekuraka: Wprowadzenie do bezpieczeństwa IT. -15% z kodem: sekurak-book
2 różne pliki exe z taką samą sumą SHA-1 oraz MD5
Wpis w formie małej rozrywki intelektualnej, nawiązującej do ostatnio głośnego tematu z kolizją SHA-1.
W procedurze, autor pisze o zapisaniu plików na dowolna partycję NTFS. A wcześniej – o rozpakowaniu plików z archiwum 7zip.
Dlaczego powyższa sztuczka działa? Wpisujcie pomysły w komentarzach, a ja podrzucę na start 2 hinty: 7ip / ADS.
Pamiętajcie też, że pliki pochodzą de facto z niezaufanego źródła i jeśli ktoś chce je rzeczywiście odpalać – należy to zrobić na odpowiednio odseparowanym środowisku.
–ms
bez kolizji też można
print name==sample2.exe?’Evil’:’Liev’
Czyżby program odczytywał swoją nazwę – i w środku miał instrukcję warunkową, która wypluwa inny output zależnie od nazwy pliku? ;)
Ale jak pogodzić to że oba programy dają na start tą samą sumę MD5/SHA1 ?!
To akurat nie ma znaczenia. Oba pliki mogą być identyczne. Sprawdza nazwę programu, bierze nazwa[6] – 1 i ma wartość 0 lub 1, potem odczyt z tablicy [] = { „Liev”, „Evil” } i już. Równie dobrze by można tam też wrzucić wskaźniki do dwóch funkcji i dawać zupełnie różne działanie programu.
Tylko to nie jest pewnie rozwiązanie :) A takie coś by było zwykłą ściemą do straszenia.
kolega ma racje pliki są identyczne
Ponieważ są takie same ? ;-) decyzję o tym co wyświetlić podejmują na podstawie nazwy pliku który jest uruchamiany.
Może to być dokładnie jeden i ten sam program (chociażby dwie kopie jednego pliku), wystarczy że odczyta zerowy argument swojego wywołania i w zależności od jego wartości wyświetli inny komunikat.
NO właśnie tak jak napisał Piotr. Jest to ten sam plik wykonywalny który w sprawdza jaką ma nazwę i wypluwa inny output.
example:
#include
using namespace std;
int main (int argc,char** argv)
{
if(arg[0]==”sample1.exe”) { // to nie zadziała ale chodzi o logikę
cout << "pierwszy tekst dla bajeru" << endl;
} else {
cout << "drugi test dla bajeru" << endl;
}
return 0;
}
Sekuraku, mógłbyś rozwinąć?
http://pastebin.pl/view/06b3c722
Przeczytajcie jeszcze raz komentarz @Piotr :)
W jego scenariuszu możecie przenieść programy na partycję FAT32 i porównać nawet bit po bicie – wciąć będzie się zgadzać.
A jak pogodzić to, że np. w Debianie pliki „/bin/bzcat”, „/bin/bunzip2” i „/bin/bzip2” dają tę samą sumę MD5/SHA1?
Ale skoro wskazówka mówi o ADS, to zapewne programy odczytują swoje ADS i w zależności od niego inaczej działają.
no bo liczenie hasha nie uwzględnia nazwy pliku, a kontent byłby taki sam
$ sha1sum sample*
18037f81fb0f22ba7808703523ff286b8ba1d716 sample1
18037f81fb0f22ba7808703523ff286b8ba1d716 sample2
$ md5sum sample*
40de78f14d2551c41af7a4acf0bbed04 sample1
40de78f14d2551c41af7a4acf0bbed04 sample2
$ ./sample1
Liev
$ ./sample2
Evil
$ cat src/main.rs
fn main() {
let executable_name = std::env::args().next().unwrap();
if executable_name.contains(„sample1”) {
println!(„Liev”);
} else if executable_name.contains(„sample2”) {
println!(„Evil”);
}
}
Tam są 3 pliki (jeden pod adsem ale tą samą nazwą). 7-zip od 2015-06-14 obsługuje ADSy. Co wygrałem?
Drugim pomysłem mogłoby być po prostu sprawdzanie nazwy programu wywołującego i zmiana kodu zależnie od nazwy.
Wygrałeś suszarkę, która lekko kopie prądem :-D
Hurra!
Można wrzucać własne zagadki tego typu?
Też tak potrafię :-)
ts:/tmp$ md5sum evil good
ddc5ab93edc5507208d23ded81c0f8ed evil
ddc5ab93edc5507208d23ded81c0f8ed good
ts:/tmp$ sha384sum good evil
239c8da53c7f1a9e79bf6db4024f36fda5d977c083eb2c13c42a01286b8e8ec000afc91fb49ee8b638db2d450534a631 good
239c8da53c7f1a9e79bf6db4024f36fda5d977c083eb2c13c42a01286b8e8ec000afc91fb49ee8b638db2d450534a631 evil
ts:/tmp$ ./good
Good
ts:/tmp$ ./evil
Evil
nie wygrałeś suszarki ;-)
Zabawa jest prosta, wystarczy 1 warunek.
http://imgur.com/Oyt9zlq
To ten sam plik, funkcją losową generuje ciąg z tych samych 4 liter.
Evil, liev… jakby to samo, ale w innej kolejności? Endianness, albo bredzę…
Pliki takie same tylko każdy z nich ma dopisany inna zawartość alternatywnego strumienia danych stad ta różnica. Exe sprawdza strumien ADS i tyle ;) spakowanie 7z jest potrzebne bo inaczej strumien zostałby utracony przy konwersji a zapis na NTFS jest konieczny bo ten system plików obsługuje takie strumienie. Polecam odczytać strumienie dla obu plików i wszystko sie rozjaśni :) ale zagadka fajna
wreszcie jakaś od a do z odpowiedź (tzn. taka mi pasuje na logikę i hinty które dał twórca wpisu) – bo brak czasu na sprawdzenie :(
niestety też jeszcze tego nie sprawdziłem doświadczalnie tylko tak na szybko wymyśliłem jakby to zrobić :) może jutro sprawdzę i podeślę info
No niestety nie. To nie są alternatywne strumienie. :)
Pliki skopiowane na ext4 i ponownie na NTFS – nadal działa.
Skopiowane na ExFAT i ponownie na NTFS – nie działą z komunikatem „I will not reveal my secrets to you”.
Nie miałem czasu na razie pogrzebać bardziej, ale stawiam na atrybuty pliku, któryś z tych, których normalnie nie widać (a który przetrwa spakowanie 7zipem i rozpakowanie). Jak będę miał jeszcze chwilę, to pogrzebię, ale ciężko znaleźć narzędzie, które pokaże wszystkie atrybuty.
Podeślij analizę jak już będziesz miał wszystko opykane ;-)
No bez jajów. Też tak umiem
{ fun } » cat good.sh
#!/bin/bash
ME=`basename $0`
if [ $ME = „good.sh” ] ; then
echo „Good”;
else
echo „Evil”
fi
{ fun } » ./good.sh && ./not-good.sh
Good
Evil
{ fun } » md5sum *
798c6cb6220b64ad1755b7dcbd18a521 *good.sh
798c6cb6220b64ad1755b7dcbd18a521 *not-good.sh
{ fun } » sha1sum *
16732a52c94b3b038108f9e733d278edea273893 *good.sh
16732a52c94b3b038108f9e733d278edea273893 *not-good.sh
Oczywiście może się zdarzyć kolizja haszy, ale niech autor pokaże źródła obu programów.
Damn… A już się napaliłem na tę suszarkę. Muszę się bardziej postarać ;-)
ts:/tmp$ cat evil.c #include #include #include main(int argc, char **argv) { char *p; if ((p=strrchr(argv[0], '/'))==NULL) p=argv[0]; else p++; *p=toupper(*p); printf("%s\n", p); } ts:/tmp$ make evil cc evil.c -o evil ts:/tmp$ cp evil goodcos jak ponizej, spakowane to .wim z wlaczona obsluga ads (-sns)?
C:\Users\q>file1.bat
123qwe
live
C:\Users\q>file2.bat
123qwe
evil
C:\Users\q>fciv file1.bat -both
//
// File Checksum Integrity Verifier version 2.05.
//
MD5 SHA-1
————————————————————————-
a3498381a0375501ec9815a546e607e0 ae333262f2b325639e126c5a577e5a4b9a7cffcf file1.bat
C:\Users\q>fciv file2.bat -both
//
// File Checksum Integrity Verifier version 2.05.
//
MD5 SHA-1
————————————————————————-
a3498381a0375501ec9815a546e607e0 ae333262f2b325639e126c5a577e5a4b9a7cffcf file2.bat
C:\Users\q>more < file1.bat
@echo 123qwe
@more more < file2.bat
@echo 123qwe
@more more more < file2.bat:a.txt
evil
Sorki, rozjechala mi sie koncowka…
C:\Users\q>more more < file2.bat:a.txt
evil
Przepraszam, ale wklejenie komend z jakiegos powodu daje zupelnie inny efekt w komentarzu :).
W kazdym razie oba pliki rzeczywiscie wygladaja identycznie:
file1.bat=file2.bat:
echo 123qwe
more < %0:a.txt
Rozni sie ADS dla obu plikow:
file1.bat:a.txt = live
file2.bat:a.txt = evil
Nie znam się to się wypowiem :)
Pliki są identyczne więc to że sumy md5 i sha są takie same nie są niczym dziwnym i nie jest to żadna kolizja.
diff -s sample1.exe sample2.exe
Pliki sample1.exe i sample2.exe są identyczne
A sposoby na wypisanie przez jeden program różnych komunikatów zostały podane powyżej, i to pewnie znacznie prostsze niż użyte w tych plikach. Co więc w tym takiego nadzwyczajnego?
Zobacz na pierwszy listing tutaj: https://sekurak.pl/alternate-data-streams-ads/
też pliki badane diffem czy dowolnym hashem będą takie same – bo to na NTFS bada 'główny stream’, a nie 'alternatywne streamy’.
Czy ktoś rozwiązał tę zagadkę? Mnie się nie udało, a jestem bardzo ciekaw. Na pewno NIE chodzi o dodatkowe strumienie plików.
Hello? Anybody?