Support WR841N V14

[mcoops]

Attempt to redeem myself after last attempt.

Support TP link WR841N only v14. Seems that between each version, the code can change significantly and can't guarantee that this patch will work on older models.

The router also wants padding to be performed before the MD5 is calculated, otherwise the config file will fail to upload. Confirmed that it indeed does expect the padding during unpacking otherwise the hashes don't match and this is reliable with varying sizes of input.

Not seen v14 in big endian either.

[odolezal]

Hi, I also have TL-WR841N v14, with these parametres:

Firmware Version: 0.9.1 4.16 v0001.0 Build 180319 Rel.57291n
Hardware Version: TL-WR841N v14 00000014

Original python3 tpconf_bin_xml.py script seems working well:

$ python3 tpconf_bin_xml.py --littleendian conf.bin conf.xml
OK: appears your device uses little-endian.
OK: BIN file decrypted, MD5 hash verified, uncompressing…
Done.

So, I do not understand what is purpose of your fix.

BTW: decrypted conf.xml:

?xml version="1.0"?>
<DslCpeConfig>
  <InternetGatewayDevice>
    <DeviceSummary val="InternetGatewayDevice:1.1[](Baseline:1, EthernetLAN:1)" />
    <LANDeviceNumberOfEntries val=1 />
    <DeviceInfo>
      <ManufacturerOUI val=<REDACTED> />
      <SerialNumber val=<REDACTED> />
      <HardwareVersion val="TL-WR841N v14 00000014" />
      <SoftwareVersion val="0.9.1 4.16 v0001.0 Build 180319 Rel.57291n" />
      <AdditionalHardwareVersion val=00000020 />
      <UpTime val=4 />
      <X_TP_isFD val=1 />
      <X_TP_LogCfg>
        <ServerIP val=192.168.0.100 />
... (abbreviated)

I have noticed that decrypted XML has changed structure, e.g. section:

<Description val="<STRING>" />

mentioned in README is missing. My question: Is command injection possible via altered conf.xml?

[mcoops]

Agreed, decrypting and uncompressing the conf.bin works really well for me too.

However, going the other way, attempting to restore the config I got an obscure error. Having a quick dig into the code, it looks like the MD5 was failing to match. If you take the existing conf.bin from the router, unpack it, repack it and compare the MD5's they're different and it seems to be a padding issue.

So this patch makes it so you can re-encrypt the conf and restore the settings. @odolezal keen to hear if you can already restore the config after unpacking and repacking tho.

That's with firmware: TL-WR841N(US)_V14_210203

To your second question, to my knowledge it's not vulnerable to the existing command injection unfortunately. You can add the Description element to the config, and it seems to get used, but doesn't seem to trigger - so maybe patched? I haven't looked that deep yet. Although that's also trying to start another instance of dropbear not telnet as the later isn't installed.

[odolezal]

Great catch! Thanks for clarification. I will upgrade my TL-WR841N v14 to latest EU firmware first (I downgraded FW earlier during my experiments), and then try restore config with your fix.

I agree. I also think that XML command infection is no longer possible.

I done some research: most of public available exploits does not working, due to patches in v14 and latest FWs. Very common attack vector in the past was badly implemented HTTP Basic Auth. More recent web management versions does not use it any more.

Ad dropbear: You can run another instance easy, but it is useless due to dropbear server does not spawn shell at all. Only port forwarding is available. Purpose is explained here: https://github.com/ropbear/tmpcli

I think that Tether Management Protocol (TMP) described in repo above is key for new possible attack vector, but due to huge lack of documentation and only small amount of public research, it will be very time consuming, but no inpossible: https://www.zerodayinitiative.com/blog/2020/4/6/exploiting-the-tp-link-archer-c7-at-pwn2own-tokyo

I am planning publish some write-up about my research done so far.

Cheers! 😎

[sta-c0000]

Thanks very much mcoops! Merging. Apologies for the delay.