ASUS Router infosvr UDP Broadcast root Command Execution

ASUS राउटर के कई मॉडलों में infosvr नामक एक सेवा शामिल होती है जो LAN या WLAN इंटरफ़ेस पर UDP ब्रॉडकास्ट पोर्ट 9999 पर सुनती है। इसका उपयोग ASUS के एक टूल द्वारा लोकल सबनेट पर राउटरों को स्वचालित रूप से खोजकर राउटर कॉन्फ़िगरेशन को आसान बनाने के लिए किया जाता है। यह सेवा root विशेषाधिकारों के साथ चलती है और इसमें एक अनप्रमाणित कमांड निष्पादन भेद्यता (unauthenticated command execution vulnerability) मौजूद है। इस सेवा के स्रोत कोड, साथ ही बाकी राउटर के सोर्स कोड, ASUS के सपोर्ट साइट पर उपलब्ध हैं।

CVE

इस मुद्दे को सौंपा गया CVE है CVE-2014-9583 (अफ़सोस, आखिरकार CVE-2014-10000 नहीं :-/)।

प्रभावित संस्करण

वर्तमान में, लागू होने वाले राउटरों (RT-AC66U, RT-N66U, आदि) के लिए सभी ज्ञात फर्मवेयर संस्करण असुरक्षित माने जाते हैं। परीक्षण 3.0.0.376.2524-g0013f52 के विरुद्ध किया गया था।

निम्नलिखित राउटर/फर्मवेयर संस्करण असुरक्षित पुष्टि किए गए हैं:

Router	Firmware Version	Verified By
RT-N66U	3.0.0.4.376_1071-g8696125	Friedrich Postelstorfer
RT-AC87U	3.0.0.4.378_3754	David Longenecker
RT-N56U	3.0.0.4.374_5656	@argilo
RT-AC68U	3.0.0.4.376_3626-g9a8323e	@Arie
DSL-N55U	3.0.0.4.374_4422-gc83c78f	@S2-
DSL-AC68U	3.0.0.4.376_2158-g340202b	@magJ, @gitFurious
RT-AC66R	3.0.0.4.376_2524-g0013f52	@asgh
RT-AC66R	3.0.0.4.376_3602	@facerolling
RT-AC55U	3.0.0.4.376_6587-gaa506e9	@pellaeon
RT-N12HP_B1	3.0.0.4.374_1327	@vittee
RT-N16	3.0.0.4.220	@xorrbit

इसके अतिरिक्त, समुदाय-समर्थित asuswrt-merlin पर आधारित फर्मवेयर चलाने वाले राउटर संस्करण 376.49_5 से पहले असुरक्षित हैं।

15 जनवरी 2015 या उसके बाद जारी किए गए फर्मवेयर संशोधनों का उपयोग करने वाले राउटर प्रभावित नहीं होने चाहिए। निम्न तालिका गैर-प्रभावित राउटरों/फर्मवेयरों की रिपोर्टों को ट्रैक करती है।

Router	Firmware Version	Verified By
RT-AC66R	3.0.0.4.376_3754-g5ef7c1f	@asgh
RT-N12HP_B1	3.0.0.4.376_3754-g5ef7c1f	@vittee

तकनीकी विवरण

ASUSWRT-Merlin प्रोजेक्ट से निम्नलिखित अंश पर विचार करें, जो ASUS के कोड का एक उन्नत फोर्क है। आप फ़ाइल को उसकी संपूर्णता में (अतिरिक्त मनोरंजन के लिए अनुशंसित) यहाँ देख सकते हैं।

   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 फ़ील्ड अपेक्षित मानों से मेल खाते हैं।

निम्नलिखित ब्लॉक में वह चीज़ है जिसे इस भेद्यता का मूल कारण माना जाता है।

   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 के आधार पर प्रोसेसिंग को वितरित करता है।

   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);

यदि कोई हमलावर NET_CMD_ID_MANU_CMD का OpCode मान निर्दिष्ट करता है, तो पूर्ववर्ती ब्लॉक पैकेट को PKT_SYSCMD स्ट्रक्चर में कास्ट करके प्रोसेस करता है। इस प्रकार, syscmd के किसी भी सदस्य को हमलावर द्वारा पूरी तरह नियंत्रित किया जाता है। कमांड स्ट्रिंग को NUL समाप्त करने का ध्यान रखने से पहले (तिल्ली), लेखक पंक्ति 514 पर कमांड निष्पादित करता है। कमांड निष्पादित करने के बाद, आउटपुट अस्थायी फ़ाइल से पढ़ा जाता है और आरंभ करने वाले पैकेट के स्रोत पते पर वापस भेजा जाता है।

अनुशंसाएँ

अंतिम उपयोगकर्ता: फर्मवेयर को संशोधन 3.0.0.4.376.3754 या नए में अपडेट करें। यह ध्यान रखना महत्वपूर्ण है कि राउटर की "अपडेट की जाँच करें" कार्यक्षमता ठीक से काम नहीं कर सकती है। आपके द्वारा चलाए जा रहे फर्मवेयर के संस्करण की मैन्युअल रूप से जाँच करें और, यदि पुराना है, तो नया फर्मवेयर डाउनलोड/इंस्टॉल करें।

ASUS/Merlin: इस सेवा से रिमोट कमांड निष्पादन कार्यक्षमता को हटा दें। भले ही इसे मजबूत प्रमाणीकरण के साथ संरक्षित किया गया हो, पूरे लोकल नेटवर्क पर पासवर्ड प्रसारित करना वास्तव में वांछनीय नहीं है। यदि कमांड निष्पादन वास्तव में वांछित है, तो इसे SSH या समान सुरक्षित तंत्र के माध्यम से प्रदान किया जाना चाहिए।

समाधान (Workaround)

David Longenecker बूट पर infosvr प्रक्रिया को मारने के लिए script_usbmount nvram सेटिंग के संयोजन में एक स्क्रिप्ट (JFFS) का उपयोग करने की सलाह देते हैं। अधिक जानकारी के लिए उनका ब्लॉग पोस्ट देखें।

Eric Sauvageau (@RMerl) पोर्ट 9999 को फ़ायरवॉल करने की सलाह देते हैं। अधिक जानकारी के लिए Small Net Builder फ़ोरम पर उनका पोस्ट देखें।

वैकल्पिक रूप से, हर बूट के बाद प्रक्रिया को मारकर infosvr सेवा को अक्षम करें। अतिरिक्त मनोरंजन/विडंबना के लिए, ऐसा करने के लिए एक्सप्लॉइट का उपयोग करें:

$ ./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 ने आपूर्ति किए गए कमांड को निष्पादित करने से पहले ateCommand_flag nvram वेरिएबल को 1 पर सेट करना सुनिश्चित करके समस्या का समाधान किया। यह वेरिएबल सामान्य बिल्डों में सेट नहीं होता है।

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

एक्सप्लॉइट

जिस रिपॉजिटरी में यह एडवाइज़री मौजूद है, उसमें इस मुद्दे के लिए एक कार्यशील एक्सप्लॉइट शामिल है।

उदाहरण एक्सप्लॉइट आउटपुट:

$ ./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-side security hole - mitigation"
http://forums.smallnetbuilder.com/showthread.php?t=21774

"Got an Asus router? Someone on your network can probably hack it"
http://arstechnica.com/security/2015/01/got-an-asus-router-someone-on-your-network-can-probably-hack-it/

"ASUS bug lets those on your local network own your wireless router"
http://dnlongen.blogspot.com/2015/01/asus-bug-lets-those-on-your-local.html

"Exploit allows Asus routers to be hacked from local network"
http://www.itworld.com/article/2867255/exploit-allows-asus-routers-to-be-hacked-from-local-network.html

"Asus Wireless Routers Can Be Exploited By Anyone Inside the Network"
http://it.slashdot.org/story/15/01/09/1349229/asus-wireless-routers-can-be-exploited-by-anyone-inside-the-network

"Most Asus routers affected by hijack bug; exploit posted" http://www.zdnet.com/article/asus-routers-vulnerable-to-network-attack-exploit-published/

"Root Command Execution Flaw Haunts ASUS Routers" http://threatpost.com/root-command-execution-flaw-haunts-asus-routers/110276