Skip to content
KitploitKITPLOIT
ИнструментыБлог
Отправить
ИнструментыБлог
Отправить

Инструменты для хакинга, пентеста и кибербезопасности — ваш арсенал защиты!

Kitploit — это каталог инструментов для хакинга, кибербезопасности и пентестинга. Находите последние обновления проектов для поиска уязвимостей, анализа систем, автоматизации тестирования и усиления вашей безопасности.

··Ленты·Контакты·Конфиденциальность·© 2026 Kitploit

Каталог инструментов

Категории

Все категории
Loading categories
asus-cmd — Выполнение команд с правами root через UDP Broadcast в infosvr маршрутизаторов ASUS | Kitploit
Инструменты/GitHubGitHub/jduck/asus-cmd
Безопасность встроенных системБезопасность IoTАнализ уязвимостейЭксплуатацияСетевая безопасностьТестирование на ПроникновениеБезопасность оборудования и IoT
GitHubjduck/asus-cmd

asus-cmd

Выполнение команд с правами root через UDP Broadcast в infosvr маршрутизаторов ASUS

Репозиторий
2523511 лет назадПроверено Kitploit

Популярное

Смотреть все →

Откройте для себя самые используемые инструменты нашего сообщества.

Изучить все инструменты

Просмотрите нашу коллекцию инструментов

Смотреть все инструменты →
Поделиться

ASUS Router infosvr: выполнение команд с правами root через UDP Broadcast

Ряд моделей роутеров ASUS включает службу infosvr, которая прослушивает UDP-широковещательный порт 9999 на интерфейсе LAN или WLAN. Она используется одним из инструментов ASUS для упрощения настройки роутеров путём автоматического обнаружения роутеров в локальной подсети. Эта служба работает с привилегиями root и содержит уязвимость выполнения команд без аутентификации. Исходный код этой службы, как и остальной части роутера, доступен на сайте поддержки ASUS.

CVE

Уязвимости присвоен идентификатор CVE-2014-9583 (увы, в итоге не CVE-2014-10000 :-/).

Затронутые версии

В настоящее время предполагается, что все известные версии прошивок для соответствующих роутеров (RT-AC66U, RT-N66U и т. д.) уязвимы. Тестирование проводилось на версии 3.0.0.376.2524-g0013f52.

Подтверждено, что следующие роутеры/версии прошивок уязвимы:

РоутерВерсия прошивкиКем подтверждено
RT-N66U3.0.0.4.376_1071-g8696125Friedrich Postelstorfer
RT-AC87U3.0.0.4.378_3754David Longenecker
RT-N56U3.0.0.4.374_5656@argilo
RT-AC68U3.0.0.4.376_3626-g9a8323e@Arie
DSL-N55U3.0.0.4.374_4422-gc83c78f@S2-
DSL-AC68U3.0.0.4.376_2158-g340202b@magJ, @gitFurious
RT-AC66R3.0.0.4.376_2524-g0013f52@asgh
RT-AC66R3.0.0.4.376_3602@facerolling
RT-AC55U3.0.0.4.376_6587-gaa506e9@pellaeon
RT-N12HP_B13.0.0.4.374_1327@vittee
RT-N163.0.0.4.220@xorrbit

Кроме того, роутеры с прошивками на основе поддерживаемого сообществом asuswrt-merlin уязвимы до версии 376.49_5.

Роутеры, использующие ревизии прошивок, выпущенные 12 января 2015 года или позже, не должны быть подвержены уязвимости. В следующей таблице приведены сообщения о не подверженных уязвимости роутерах/прошивках.

РоутерВерсия прошивкиКем подтверждено
RT-AC66R3.0.0.4.376_3754-g5ef7c1f@asgh
RT-N12HP_B13.0.0.4.376_3754-g5ef7c1f@vittee

Технические подробности

Рассмотрим следующий фрагмент из проекта ASUSWRT-Merlin, который является расширенным форком кода ASUS. Вы можете просмотреть файл целиком (рекомендуется для дополнительного веселья) здесь.

root@kitploit:~
   177  char *processPacket(int sockfd, char *pdubuf)
   178  {
   ...
   202      phdr = (IBOX_COMM_PKT_HDR *)pdubuf;
   ...
   207      if (phdr->ServiceID==NET_SERVICE_ID_IBOX_INFO &&
   208          phdr->PacketType==NET_PACKET_TYPE_CMD)
   209      {
   ...

Функция processPacket вызывается после получения пакета размером INFO_PDU_LENGTH (512) байт. Конкретный уязвимый путь выполнения кода: main->processReq->processPacket. Затем служба приводит пакет к структуре и проверяет, что поля ServiceID и PacketType соответствуют ожидаемым значениям.

Следующий блок содержит то, что, как полагают, является корневой причиной этой уязвимости.

root@kitploit:~
   222          if (phdr->OpCode!=NET_CMD_ID_GETINFO && phdr->OpCode!=NET_CMD_ID_GETINFO_MANU)
   223          {
   224                  phdr_ex = (IBOX_COMM_PKT_HDR_EX *)pdubuf;       
   225                  
   226                  // Check Mac Address
   227                  if (memcpy(phdr_ex->MacAddress, mac, 6)==0)
   228                  {
   229                          _dprintf("Mac Error %2x%2x%2x%2x%2x%2x\n",
   230                                  (unsigned char)phdr_ex->MacAddress[0],
   231                                  (unsigned char)phdr_ex->MacAddress[1],
   232                                  (unsigned char)phdr_ex->MacAddress[2],
   233                                  (unsigned char)phdr_ex->MacAddress[3],
   234                                  (unsigned char)phdr_ex->MacAddress[4],
   235                                  (unsigned char)phdr_ex->MacAddress[5]
   236                                  );
   237                          return NULL;
   238                  }
   239                  
   240                  // Check Password
   241                  //if (strcmp(phdr_ex->Password, "admin")!=0)
   242                  //{
   243                  //      phdr_res->OpCode = phdr->OpCode | NET_RES_ERR_PASSWORD;
   244                  //      _dprintf("Password Error %s\n", phdr_ex->Password);     
   245                  //      return NULL;
   246                  //}
   247                  phdr_res->Info = phdr_ex->Info;
   248                  memcpy(phdr_res->MacAddress, phdr_ex->MacAddress, 6);
   249          }

Блок начинается с исключения пары значений OpCode, которые, предположительно, по замыслу не требуют аутентификации. Затем вызывается memcpy, и возвращаемое значение подозрительным образом сравнивается с нулём. Это явно указывает на то, что автор намеревался использовать memcmp. Тем не менее, даже если бы эта проверка была реализована правильно, знание MAC-адреса устройства вряд ли можно считать достаточной аутентификацией.

Следующий блок закомментирован, но показывает, что автор в какой-то момент экспериментировал с проверкой пароля. Правда, в этом случае пароль был жёстко прописан как «admin».

Далее следующий оператор switch распределяет обработку в зависимости от переданного OpCode.

root@kitploit:~
   251          switch(phdr->OpCode)
   252          {
   ...
   428                  case NET_CMD_ID_MANU_CMD:
   429                  {
   430                       #define MAXSYSCMD 256
   431                       char cmdstr[MAXSYSCMD];
   432                       PKT_SYSCMD *syscmd;
   ...
   440                       syscmd = (PKT_SYSCMD *)(pdubuf+sizeof(IBOX_COMM_PKT_HDR_EX));
   ...
   443                       if (syscmd->len>=MAXSYSCMD) syscmd->len=MAXSYSCMD;
   444                       syscmd->cmd[syscmd->len]=0;
   445                       syscmd->len=strlen(syscmd->cmd);
   446                       fprintf(stderr,"system cmd: %d %s\n", syscmd->len, syscmd->cmd);
   447  #if 0
   ...
   512  #endif
   513                       {
   514                          sprintf(cmdstr, "%s > /tmp/syscmd.out", syscmd->cmd);
   515                          system(cmdstr);

Если злоумышленник указывает значение OpCode NET_CMD_ID_MANU_CMD, предыдущий блок обрабатывает пакет, приводя его к структуре PKT_SYSCMD. Таким образом, все члены syscmd полностью контролируются злоумышленником. Прежде чем позаботиться (подмигивание) о NUL-завершении строки команды, автор выполняет команду в строке 514. После выполнения команды вывод считывается из временного файла и отправляется обратно на адрес источника инициирующего пакета.

Рекомендации

Конечные пользователи: обновите прошивку до ревизии 3.0.0.4.376.3754 или новее. Важно отметить, что функция роутера «Проверить обновление» может работать некорректно. Вручную проверьте версию установленной прошивки и, если она устарела, загрузите/установите новую прошивку.

ASUS/Merlin: удалите функциональность удалённого выполнения команд из этой службы. Даже если бы она была защищена надёжной аутентификацией, широковещательная передача пароля на всю локальную сеть — не то, что нужно. Если выполнение команд действительно необходимо, его следует предоставлять через SSH или аналогичный безопасный механизм.

Обходной путь

Дэвид Лонгенекер (David Longenecker) рекомендует использовать скрипт (JFFS) в сочетании с настройкой nvram script_usbmount, чтобы завершать процесс infosvr при загрузке. Дополнительную информацию см. в его сообщении в блоге.

Эрик Соважо (Eric Sauvageau, @RMerl) рекомендует закрыть порт 9999 межсетевым экраном. Дополнительную информацию см. в его сообщении на форуме Small Net Builder.

В качестве альтернативы можно отключить службу infosvr, завершая процесс после каждой загрузки. Ради дополнительного веселья/иронии воспользуйтесь эксплойтом, чтобы сделать это:

root@kitploit:~
$ ./asus-cmd "killall -9 infosvr"
[...]

ПРИМЕЧАНИЕ: на эту команду вы не получите ответа. И снова: это нужно будет делать каждый раз после перезагрузки устройства.

Выпущенные исправления

После первоначального раскрытия этой проблемы несколько сторон устранили её в своих кодовых базах.

2015/01/08 - Эрик Соважо (Eric Sauvageau) устранил эту проблему в кодовой базе asuswrt-merlin. Первым релизом, включившим исправление, стал 376.49_5. Его изменения можно посмотреть здесь, здесь и здесь. 2015/01/12 - ASUS выпустила новые ревизии прошивок для затронутых устройств (3.0.0.4.376.3754), которые, по сообщениям, не уязвимы.

ASUS решила проблему, обеспечив установку переменной nvram ateCommand_flag в 1 перед выполнением переданной команды. В обычных сборках эта переменная не установлена.

root@kitploit:~
loc_404958:
la      $v0, 0x400000
addiu   $a0, $v0, (aAtecommand_fla - 0x400000)  # "ateCommand_flag"
la      $v0, 0x400000
addiu   $a1, $v0, (g_ascONE - 0x400000)  # "1"
la      $v0, 0x400000
addiu   $t9, $v0, (check_nvram - 0x400000)
jalr    $t9 ; check_nvram
nop
lw      $gp, 0x290+var_270($fp)
bnez    $v0, lbl_execute_command
nop
sw      $zero, 0x290+var_14($fp)
b       lbl_return_zero

Эксплойт

Репозиторий, в котором находится данный advisory, содержит рабочий эксплойт для этой проблемы.

Пример вывода эксплойта:

root@kitploit:~
$ ./asus-cmd "nvram show | grep -E '(firmver|buildno|extendno)'"
[*] sent command: nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from 10.0.0.2:37625
    0c 15 0033 54ab7bc4 41:41:41:41:41:41
    0031 nvram show | grep -E '(firmver|buildno|extendno)'
[!] received 512 bytes from 10.0.0.1:9999
    0c 16 0033 54ab7bc4 xx:xx:xx:xx:xx:xx
    004e buildno=376
extendno_org=2524-g0013f52
extendno=2524-g0013f52
firmver=3.0.0.4

Другие ссылки

«ASUSWRT 3.0.0.4.376_1071 - LAN Backdoor Command Execution»
(это сподвигло меня на публикацию; его эксплойт также продублирован в каталоге others/)
http://www.exploit-db.com/exploits/35688/

«SECURITY: дыра в безопасности на стороне LAN - меры по снижению риска»
http://forums.smallnetbuilder.com/showthread.php?t=21774

«Есть роутер Asus? Кто-то в вашей сети, вероятно, может его взломать»
http://arstechnica.com/security/2015/01/got-an-asus-router-someone-on-your-network-can-probably-hack-it/

«Баг ASUS позволяет тем, кто находится в вашей локальной сети, получить полный контроль над вашим беспроводным роутером»
http://dnlongen.blogspot.com/2015/01/asus-bug-lets-those-on-your-local.html

«Эксплойт позволяет взломать роутеры Asus из локальной сети»
http://www.itworld.com/article/2867255/exploit-allows-asus-routers-to-be-hacked-from-local-network.html

«Беспроводные роутеры Asus могут быть взломаны кем угодно внутри сети»
http://it.slashdot.org/story/15/01/09/1349229/asus-wireless-routers-can-be-exploited-by-anyone-inside-the-network

«Большинство роутеров Asus подвержены багу захвата; опубликован эксплойт» http://www.zdnet.com/article/asus-routers-vulnerable-to-network-attack-exploit-published/

«Уязвимость выполнения команд с правами root преследует роутеры ASUS» http://threatpost.com/root-command-execution-flaw-haunts-asus-routers/110276

Скачать инструмент