Jesper Andersen has decided to retire and will continue to serve on the Board of Directors.

**SANTA CLARA, Calif.****,** **Jan. 11, 2023****/PRNewswire/ --** Infoblox Inc., the leader in cloud-first DNS management and security, today announced that Jesper Andersen has decided to retire as Chief Executive Officer and the Board of Directors has appointed Scott Harrell as the new President and Chief Executive Officer. Andersen will continue to serve on the Board and support Harrell through the transition.

Harrell brings strong executive leadership and portfolio management experience having spent two decades in leadership roles at Cisco Systems and Intel. Prior to joining Infoblox, Harrell was the Senior Vice President and General Manager for Cisco's $20 billion Intent Based Networking business unit where he oversaw the entire portfolio and engineering teams across the enterprise, IoT and data center markets. He has an MBA from UNC-Chapel Hill, Kenan-Flaglar Business School, and a bachelor's in Industrial Engineering from Georgia Institute of Technology.

Vista Equity Partners and Warburg Pincus, Infoblox investors, have thoughtfully selected Harrell as Andersen's successor.

"We are thrilled to welcome Scott to Infoblox. His deep-domain expertise in building leading technology businesses at Fortune 100 companies makes him perfectly suited for Infoblox – as the company continues to invest in next-generation cloud-first DNS management and security solutions. We're confident that he will lead the business to continued growth and adjacent market expansion," said John Stalder, Managing Director, Vista Equity Partners.

Harrell joins Infoblox at a critical time where more and more enterprises are embracing a remote workforce and multi-cloud strategies – both of which drastically increase DNS management complexities and security challenges.

"Infoblox is an innovative company with an incredibly talented team that consistently executes at extremely high levels. I am thankful for all Jesper has done for the company and the incredible culture that has been built under his leadership," said Harrell. "Infoblox's solutions are critical to the ongoing operations, availability, and security of enterprises across the world. I'm thrilled to join a company that embraces an innovation mindset anchored by its technology and its people, and I look forward to further accelerating Infoblox's growth and market leading solutions."

Over the past decade, Infoblox has experienced expansive growth, including growing its customer base by 82%, growing its partner relationships by 43% and more than doubling its employee base, all while taking its technology solutions to innovative new heights. 

"On behalf of the Board, we thank Jesper for his invaluable contributions and tremendous impact to Infoblox – transforming the company into a cloud-first market leader in comprehensive, world-class security and networking solutions. Infoblox's momentum and growth is a testament to Jesper's leadership, passion, and dedication to employees, customers, and partners. While Jesper's retirement has been planned for a long time, we are excited to have him remain on the Board of Directors and continue to be an important strategic asset to the company," said Cary Davisand Parag Gupta, Managing Directors, Warburg Pincus. 

Jesper's continued passion and dedication for employees has fostered a very strong, collaborative culture, and one that continues to attract top talent and executives like Harrell.

"My time at Infoblox will remain the highlight of my career, where we were able to disrupt the industry and offer solutions to our customers unmatched by any competitor," said Jesper Andersen. "Beyond our leading technology, I am proud to have worked alongside Infoblox employees across the globe to create a culture-driven by our core values – to make Infoblox an incredibly positive, innovative, and supportive workplace that I know they will carry forward. I have incredible confidence in Scott and the executive leadership team to continue our mission to drastically simplify networking and security for our customers," added Andersen.

Learn more about Infoblox's networking and security solutions here.

**About Infoblox**

Infoblox is the leader in next generation DNS management and security. More than 13,000 customers, including 75% of the Fortune 500, rely on Infoblox to scale, simplify and secure their hybrid networks to meet the modern challenges of a cloud-first world. Learn more at

 https://www.infoblox.com.

Infoblox Appoints Scott Harrell to CEO

**San Francisco, CA, January 11, 2023** **–** Cloudflare, Inc. (NYSE: NET), the security, performance, and reliability company helping to build a better Internet, today announced several new Zero Trust email security solutions, compatible with any email provider, to protect employees from multichannel phishing attacks, prevent sensitive data being exfiltrated via email, and help businesses speed up and simplify deployments. Now, Cloudflare is providing organizations with its simple and robust phishing and malware protection that is deeply integrated with its Zero Trust platform, helping to secure all of an organization’s applications and data.

“You can’t have a complete Zero Trust solution without securing email, given that a huge proportion of all cyber attacks begin with phishing,” said Matthew Prince, co-founder and CEO of Cloudflare. “In 2022, Cloudflare Area 1 identified and kept almost 2.3 billion unwanted messages out of customer inboxes. Today we’re filling a void in the marketplace that has been underinvested in for the last ten years, with the first set of deeply integrated solutions that bring together Cloudflare Area 1 email security and our Zero Trust platform.”

Email is one of the most ubiquitous and also most exploited tools that businesses use every single day. The FBI’s latest Internet Crime Report shows that business email compromise and email account compromise, a subset of malicious phishing campaigns, are the most costly—with U.S. businesses losing nearly $2.4 billion. On top of that, email is also one of the hardest tools for businesses to secure, often resulting in multiple vendors, complex deployments, and a huge drain of resources for IT teams. Now, with Cloudflare’s Zero Trust SASE platform, customers can quickly and easily deploy comprehensive email security and data protection tools that are deeply integrated with their existing security stack and work with any email provider.

Cloudflare One provides a comprehensive Zero Trust SASE platform that is built natively into Cloudflare’s global network, spanning more than 275 cities in over 100 countries. This deeply integrated approach ensures a simple deployment in just a few clicks, without the need to change email providers, and lightning fast performance wherever users are. With Cloudflare Area 1’s new solutions, business will be able to:

*   **Automatically isolate suspicious links or attachments in emails:** With Link Isolation, If an employee clicks a link in an email it will automatically be opened using Cloudflare’s industry leading Remote Browser Isolation technology. Isolating any potentially risky links, downloads, or other zero day attacks from impacting that user’s computer and the wider corporate network.
*   **Identify and stop exfiltration of data:** With the rapid use of cloud-based email services within organizations, the amount of sensitive data that now resides outside a customer's premises has increased dramatically. By combining Cloudflare’s Data Loss Prevention and Area 1, businesses can create specific policies to scan for and block sensitive or protected content before it gets attached and sent.
*   **Onboard new Microsoft 365 domains in minutes:** Now it is as simple as possible to deploy Cloudflare Area 1 for Microsoft 365 domains via the Microsoft API. This means a single IT administrator can have the entire solution fully deployed, and running in minutes not days like legacy providers.

For more information on how to get started with Cloudflare Area 1 Security or Cloudflare One check out the information below:

*   Blog: Email Link Isolation: your safety net for the latest phishing attacks
*   Blog: How Cloudflare Area 1 and DLP work together to protect data in email
*   Landing Page
*   CIO Week

**About Cloudflare** Cloudflare, Inc. (www.cloudflare.com / @cloudflare) is on a mission to help build a better Internet. Cloudflare’s suite of products protect and accelerate any Internet application online without adding hardware, installing software, or changing a line of code. Internet properties powered by Cloudflare have all web traffic routed through its intelligent global network, which gets smarter with every request. As a result, they see significant improvement in performance and a decrease in spam and other attacks. Cloudflare was named to Entrepreneur Magazine’s Top Company Cultures 2018 list, ranked among the World’s Most Innovative Companies by Fast Company in 2019, awarded by Reuters Events for Global Responsible Business in 2020, named to Fast Company's Most Innovative Companies in 2021, and ranked among Newsweek's Top 100 Most Loved Workplaces in 2022.

**Forward-Looking Statements** This press release contains forward-looking statements within the meaning of Section 27A of the Securities Act of 1933, as amended, and Section 21E of the Securities Exchange Act of 1934, as amended, which statements involve substantial risks and uncertainties. In some cases, you can identify forward-looking statements because they contain words such as “may,” “will,” “should,” “expect,” “explore,” “plan,” “anticipate,” “could,” “intend,” “target,” “project,” “contemplate,” “believe,” “estimate,” “predict,” “potential,” or “continue,” or the negative of these words, or other similar terms or expressions that concern Cloudflare’s expectations, strategy, plans, or intentions. However, not all forward-looking statements contain these identifying words. Forward-looking statements expressed or implied in this press release include, but are not limited to, statements regarding the capabilities and effectiveness of the Cloudflare One suite of Zero Trust solutions (including Cloudflare Area 1, Remote Browser Isolation, and Data Loss Prevention), the benefits to Cloudflare’s customers from using the Cloudflare One suite of Zero Trust solutions (including Cloudflare Area 1, Remote Browser Isolation, and Data Loss Prevention) and Cloudflare’s other products and technology, the expected functionality and performance of the Cloudflare One suite of Zero Trust solutions (including Cloudflare Area 1, Remote Browser Isolation, and Data Loss Prevention) and Cloudflare’s other products and technology, the timing of when any new Cloudflare One features (including Cloudflare Area 1, Remote Browser Isolation, and Data Loss Prevention) will be generally available to all current and potential Cloudflare customers, Cloudflare’s technological development, future operations, growth, initiatives, or strategies, and comments made by Cloudflare’s CEO and others. Cloudflare’s actual results could differ materially from those stated or implied in forward-looking statements due to a number of factors, including but not limited to, risks detailed in its filings with the Securities and Exchange Commission (SEC), including Cloudflare’s Quarterly Report on Form 10-Q filed on November 3, 2022, as well as other filings that we may make from time to time with the SEC.

The forward-looking statements made in this press release relate to events as of the date on which the statements are made. Cloudflare undertakes no obligation to update any forward-looking statements made in this press release to reflect events or circumstances after the date of this press release or to reflect new information or the occurrence of unanticipated events, except as required by law. Cloudflare may not actually achieve the plans, intentions, or expectations disclosed in its forward-looking statements, and you should not place undue reliance on Cloudflare’s forward-looking statements.

Cloudflare Announces Email Security & Data Protection Tools

The first Patch Tuesday fixes shipped by Microsoft for 2023 have addressed a total of 98 security flaws, including one bug that the company said is being actively exploited in the wild.
11 of the 98 issues are rated Critical and 87 are rated Important in severity, with the vulnerabilities also listed as publicly known at the time of release. Separately, the Windows maker is expected to release

The first Patch Tuesday fixes shipped by Microsoft for 2023 have addressed a total of 98 security flaws, including one bug that the company said is being actively exploited in the wild.

11 of the 98 issues are rated Critical and 87 are rated Important in severity, with the vulnerabilities also listed as publicly known at the time of release. Separately, the Windows maker is expected to release updates for its Chromium-based Edge browser.

The vulnerability that's under attack relates to CVE-2023-21674 (CVSS score: 8.8), a privilege escalation flaw in Windows Advanced Local Procedure Call (ALPC) that could be exploited by an attacker to gain SYSTEM permissions.

"This vulnerability could lead to a browser sandbox escape," Microsoft noted in an advisory, crediting Avast researchers Jan Vojtěšek, Milánek, and Przemek Gmerek for reporting the bug.

While details of the vulnerability are still under wraps, a successful exploit requires an attacker to have already obtained an initial infection on the host. It is also likely that the flaw is combined with a bug present in the web browser to break out of the sandbox and gain elevated privileges.

"Once the initial foothold has been made, attackers will look to move across a network or gain additional higher levels of access and these types of privilege escalation vulnerabilities are a key part of that attacker playbook," Kev Breen, director of cyber threat research at Immersive Labs, said.

That having said, the chances that an exploit chain like this is employed in a widespread fashion is limited owing to the auto-update feature used to patch browsers, Satnam Narang, senior staff research engineer at Tenable, said.

It's also worth noting that the U.S. Cybersecurity and Infrastructure Security Agency (CISA) has added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog, urging federal agencies to apply patches by January 31, 2023.

What's more, CVE-2023-21674 is the fourth such flaw identified in ALPC – an inter-process communication (IPC) facility provided by the Microsoft Windows kernel – after CVE-2022-41045, CVE-2022-41093, and CVE-2022-41100 (CVSS scores: 7.8), the latter three of which were plugged in November 2022.

Two other privilege escalation vulnerabilities identified as being of high priority affect Microsoft Exchange Server (CVE-2023-21763 and CVE-2023-21764, CVSS scores: 7.8), which stem from an incomplete patch for CVE-2022-41123, according to Qualys.

"An attacker could execute code with SYSTEM-level privileges by exploiting a hard-coded file path," Saeed Abbasi, manager of vulnerability and threat research at Qualys, said in a statement.

Also resolved by Microsoft is a security feature bypass in SharePoint Server (CVE-2023-21743, CVSS score: 5.3) that could permit an unauthenticated attacker to circumvent authentication and make an anonymous connection. The tech giant noted, "customers must also trigger a SharePoint upgrade action included in this update to protect their SharePoint farm."

The January update further remediates a number of privilege escalation flaws, including one in Windows Credential Manager (CVE-2023-21726, CVSS score: 7.8) and three affecting the Print Spooler component (CVE-2023-21678, CVE-2023-21760, and CVE-2023-21765).

The U.S. National Security Agency (NSA) has been credited with reporting CVE-2023-21678. In all, 39 of the vulnerabilities that Microsoft closed out in its latest update enable the elevation of privileges.

Rounding up the list is CVE-2023-21549 (CVSS score: 8.8), a publicly known elevation of privilege vulnerability in the Windows SMB Witness Service, and another instance of security feature bypass impacting BitLocker (CVE-2023-21563, CVSS score: 6.8).

"A successful attacker could bypass the BitLocker Device Encryption feature on the system storage device," Microsoft said. "An attacker with physical access to the target could exploit this vulnerability to gain access to encrypted data."

Furthermore, Redmond has updated its guidance regarding the malicious use of signed drivers (called Bring Your Own Vulnerable Driver) to include an updated block list released as part of Windows security updates on January 10, 2023.

CISA on Tuesday also added CVE-2022-41080, an Exchange Server privilege escalation flaw, to the KEV catalog following reports that the vulnerability is being chained alongside CVE-2022-41082 to achieve remote code execution on vulnerable systems.

The exploit, codenamed OWASSRF by CrowdStrike, has been leveraged by the Play ransomware actors to breach target environments. The defects were fixed by Microsoft in November 2022.

The Patch Tuesday updates also arrive as Windows 7, Windows 8.1, and Windows RT reached end of support on January 10, 2023. Microsoft said it won't be offering an Extended Security Update (ESU) program for Windows 8.1, instead urging users to upgrade to Windows 11.

"Continuing to use Windows 8.1 after January 10, 2023 may increase an organization's exposure to security risks or impact its ability to meet compliance obligations," the company cautions.

**Software Patches from Other Vendors**

In addition to Microsoft, security updates have also been released by other vendors since the start of the month to rectify several vulnerabilities, including —

*   Adobe
*   AMD
*   Android
*   Cisco
*   Citrix
*   Dell
*   F5
*   Fortinet
*   GitLab
*   Google Chrome
*   HP
*   IBM
*   Intel
*   Juniper Networks
*   Lenovo
*   Linux distributions Debian, Oracle Linux, Red Hat, SUSE, and Ubuntu
*   MediaTek
*   Qualcomm
*   SAP
*   Schneider Electric
*   Siemens
*   Synology
*   Zoom, and
*   Zyxel

Found this article interesting? Follow us on Twitter __ and LinkedIn to read more exclusive content we post.

Microsoft Issues January 2023 Patch Tuesday Updates, Warns of Zero-Day Exploit

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.

CVE-2022-35401: TALOS-2022-1586 || Cisco Talos Intelligence Group

A denial of service vulnerability exists in the cfg_server cm_processConnDiagPktList opcode of Asus RT-AX82U 3.0.0.4.386_49674-ge182230 router's configuration service. A specially-crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger this vulnerability.

**SUMMARY**

A denial of service vulnerability exists in the cfg\_server cm\_processConnDiagPktList opcode of Asus RT-AX82U 3.0.0.4.386\_49674-ge182230 router’s configuration service. A specially-crafted network packet can lead to denial of service. An attacker can send a malicious packet to trigger 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**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

**CWE**

CWE-125 - Out-of-bounds Read

**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.

The cfg_server and cfg_client binaries living on the Asus RT-AX82U are both used for easy configuration of a mesh network setup, which can be done with multiple Asus routers via their GUI. Interestingly though, the cfg_server binary is bound to TCP and UDP port 7788 by default, exposing some basic functionality. The TCP port and UDP ports have different opcodes, but for our sake, we’re only dealing with a particular set of ConnDiag opcodes which look like such:

    struct tlv_holder connDiagPacketHandlers = 
    {
        uint32_t type = 0x5
        tlv_func *tfunc = cm_processREQ_CHKSTA
    }
    struct tlv_holder connDiagPacketHandlers[1] = 
    {
        uint32_t type = 0x6
       tlv_func *tfunc = cm_processRSP_CHKSTA
    }
    

The above TLVs are accessible from the cm_recvUDPHandler thread in a particular codeflow:

    0001ed90      cm_recvUdpHandler()
                  // [...]
    0001edf8      int32_t bytes_read = recvfrom(sfd: cm_ctrlBlock.udp_sock, buf: &readbuf, len: 0x7ff, flags: 0, srcaddr: &sockadd, addrlen: &sockaddsize) // [1]
                    // [...]
    0001ee00      if (bytes_read == 0xffffffff)
                    // [...]
    0001ee98      else if (sockadd.sa_data[2].d != cm_ctrlBlock.self_address)
                    // [...]
    0001f0e0          char* malloc_824 = malloc(bytes: 0x824) // [2]
    0001f0e4          struct udp_resp* inp = malloc_824
    0001f0e8          if (malloc_824 != 0)
    0001f184              memset(malloc_824, 0, 0x824)        // [3]
    0001f194              memcpy(inp, &readbuf, bytes_read)
    0001f198              int32_t ipaddr = sockadd.sa_data[2].d
    0001f19c              inp->bytes_read = bytes_read
    0001f1a4              int32_t ip = ipaddr u>> 0x18 | (ipaddr u>> 0x10 & 0xff) << 8 | (ipaddr u>> 8 & 0xff) << 0x10 | (ipaddr & 0xff) << 0x18
    0001f1d4              snprintf(s: &inp->ip_addr_str, maxlen: 0x20, format: "%d.%d.%d.%d", ip u>> 0x18, ip u>> 0x10 & 0xff, ip u>> 8 & 0xff, ror.d(ip, 0) & 0xff, var_864, var_860, var_85c, var_858, var_854)
    0001f1dc              int32_t var_838_1 = readbuf[4].d
    0001f1dc              int32_t var_834_1 = readbuf[8].d
    0001f1e8              if (readbuf[0].d == 0x6000000)      // [4]
    0001f1f0                  r0_6 = cm_addConnDiagPktToList(inp: inp)
    

At \[1\], the server reads in 0x7ff bytes from its UDP 7788 port, and at \[2\] and \[3\], the data is then copied from the stack over to a cleared-out heap allocation of size 0x824. Assuming the first four bytes of the input packet are “\\x00\\x00\\x00\\x06”, then the packet gets added to a particular linked list structure, the connDiagUdpList. Before we continue on though, it’s appropriate to list out the structure of the input packet:

    struct tlv_pkt {
        uint32_t type;
        uint32_t datalen;
        uint32_t crc;
        uint8_t data[];
    }
    

Continuing on, another thread is constantly polling the connDiagUdpList, and if a packet is seen, then we jump over to cm_processConnDiagPktList():

    00053ca8  int32_t cm_processConnDiagPktList()    
    00053cc8      pthread_mutex_lock(mutex: &connDiagLock)
    00053cd8      struct list* connDiagUdp = connDiagUdpList
    00053ce8      if (connDiagUdp->entry_count s> 0)
    00053d2c          for (struct listitem* item = connDiagUdp->tail; item != 0; item = item->next)
    00053d30              struct udp_resp* input_pkt = item->inp
    00053d38              if (input_pkt != 0)
    00053d44                  uint32_t null = terminateConnDiagPktList
    00053d4c                  if (null != 0)
    00053d4c                      break
    00053d50                  uint32_t hex_6000000 = input_pkt->req_type_le
    00053d58                  uint32_t dlen = input_pkt->datalen_le
    00053d68                  int32_t dlenle = input_pkt->bytes_read - 0xc  // [5]
    00053d6c                  uint32_t crcle = input_pkt->crcle
                                // [...]
    00053d80                  if (dlenle == (dlen u>> 0x18 | (dlen u>> 0x10 & 0xff) << 8 | (dlen u>> 8 & 0xff) << 0x10 | (dlen & 0xff) << 0x18)) //[6]
    00053e0c                      char* buf = &input_pkt->readbuf
    00053e18                      crc = do_crc32(IV: null, buf: buf, bufsize: dlenle) // [7]
    

At \[5\], the actual length of the input packet minus twelve is compared against the length field inside the packet itself \[6\]. Assuming they match, the CRC is then checked, another field provided in the packet itself. A flaw is present in this function, however, in that there is a check missing in this code path that can be seen in both the TCP and UDP handlers: the code needs to verify that the size of the received packet is >= 0xC bytes. Thus, if a packet is received that is less than 0xC bytes, the dlenle field at \[5\] underflows to somewhere between 0xFFFFFFFC and 0xFFFFFFFF. The check against the length field \[6\] can be easily bypassed by just correctly putting the underflowed length inside the packet. The CRC check at \[7\] isn’t an issue, since if the bufsize parameter is less than zero, it automatically skips CRC calculation. Since a CRC skip results in a return value of 0x0, we need to make sure that the crc field is “\\x00\\x00\\x00\\x00”. Conveniently, this is handled already for us if our packet is only 8 bytes long, since the buffer that the packet lives in was memset to 0x0 beforehand.

While we can pass all the above checks with an 8-byte packet, it does prevent us from having any control over what occurs after. We end up hitting cm_processConnDiagPkt(uint32_t tlv_type, uint32_t datalen, uint32_t crc, char *databuf, char *ipaddr) which just passes us off to the appropriate TLV handler. Since our opcode has to be “\\x00\\x00\\x00\\x06”, we always hit cm_processRSP_CHKSTA(char *pktbuf, uint32_t pktlen, uint32_t ipaddr):

    00052f20  int32_t cm_processRSP_CHKSTA(char* pktbuf, uint32_t pktlen, int32_t ipaddr)
    00052f50      char jsonbuf[0x800]
    00052f50      memset(&jsonbuf, 0, 0x800)
                                 // [...]
    00052f64      if (cm_ctrlBlock.group_key_ready != 0)
    00053004          char* groupkey = cm_selectGroupKey(which_key: 1)
    0005300c          if (groupkey == 0)
                                                  // [...]
    00053098              goto label_530a0
    000530c0          char* r0_11 = do_decrypt(sesskey1: groupkey, sesskey2: cm_selectGroupKey(which_key: 0), pktbuf: pktbuf, pktlen: pktlen) //[8]
    

Assuming there is a group key (which there should always be, even if the AImesh setting is not configured), then we end up hitting the do_decrypt function at \[8\], which decrypts the data of our input packet with one of the groupkeys. The do_decrypt function ends up hitting aes_decrypt as shown below:

    0001db18  void* aes_decrypt(char* sesskey1, char* pktbuf, char* pktlen, int32_t* outlen)
    0001db30      int32_t ctx = EVP_CIPHER_CTX_new()
    0001db38      int32_t outl = 0
    0001db3c      void* ctx = ctx
    0001db40      void* ret
    0001db40      if (ctx == 0)
                                        // [...]
    0001db6c      else
    0001db6c          char* bytesleft = nullptr
    0001db7c          int32_t r0_2 = EVP_DecryptInit_ex(ctx, EVP_aes_256_ecb(), 0, sesskey1, 0)
                                         // [...]
    0001db84          if (r0_2 != 0)
    0001dba0              *outlen = 0
    0001dbac              void* alloc_size = EVP_CIPHER_CTX_block_size(ctx) + pktlen
    0001dbb4              maloced = malloc(bytes: alloc_size)  // 0xc...
    0001dbbc              if (maloced == 0)
                                                         //[...]
    0001dbe4              else
    0001dbe4                  memset(maloced, 0, alloc_size)
    0001dbec                  void* mbuf = maloced
    0001dbf0                  char* pktiter = pktlen
    0001dc00                  void* inpbuf
    0001dc00                  void* r3_2
    0001dc00                  while (true)
    0001dc00                      inpbuf = &pktbuf[pktlen - pktiter]
    0001dc04                      if (pktiter u<= 0x10)
    0001dc04                          break
    0001dc10                      bytesleft = 0x10
    0001dc1c                      int32_t r0_8 = EVP_DecryptUpdate(ctx, mbuf, &outl, inpbuf, 0x10) //[9]
    0001dc20                      r3_2 = r0_8
    0001dc24                      if (r0_8 == 0)
    0001dc24                          break
    0001dc60                      int32_t outl_len = outl
    0001dc64                      pktiter = pktiter - 0x10
    0001dc6c                      mbuf = mbuf + outl_len
    0001dc74                      *outlen = *outlen + outl_len
    

For brevity’s sake, we can skip all the way to \[9\], where EVP_DecryptUpdate is called repeatedly in a loop over the input buffer. Since the pktlen argument has been underflowed to atleast 0xFFFFFFFC, it suffices to say that we have a wild read, resulting in a crash when reading unmapped memory.

**Crash Information**

    potentially unexpected fatal signal 11.
    CPU: 1 PID: 12452 Comm: cfg_server Tainted: P           O    4.1.52 #2
    Hardware name: Generic DT based system
    task: d04cd800 ti: d0632000 task.ti: d0632000
    PC is at 0xb6c7f460
    LR is at 0xb6d3ca04
    pc : [<b6c7f460>]    lr : [<b6d3ca04>]    psr: 60070010
    sp : b677c46c  ip : 00ff4ff4  fp : b6600670
    r10: b6c7ef40  r9 : 00000000  r8 : beec0b82
    r7 : b6600670  r6 : 00000010  r5 : b6620c38  r4 : 00ff5004
    r3 : b6c7f440  r2 : 00000000  r1 : 00000000  r0 : 00000000
    Flags: nZCv  IRQs on  FIQs on  Mode USER_32  ISA ARM  Segment user
    Control: 10c5387d  Table: 1048c04a  DAC: 00000015
    CPU: 1 PID: 12452 Comm: cfg_server Tainted: P           O    4.1.52 #2
    Hardware name: Generic DT based system
    [<c0026fe0>] (unwind_backtrace) from [<c0022c38>] (show_stack+0x10/0x14)
    [<c0022c38>] (show_stack) from [<c047f89c>] (dump_stack+0x8c/0xa0)
    [<c047f89c>] (dump_stack) from [<c003ac30>] (get_signal+0x490/0x558)
    [<c003ac30>] (get_signal) from [<c00221d0>] (do_signal+0xc8/0x3ac)
    [<c00221d0>] (do_signal) from [<c0022658>] (do_work_pending+0x94/0xa4)
    [<c0022658>] (do_work_pending) from [<c001f4cc>] (work_pending+0xc/0x20)
    

**TIMELINE**

2022-08-24 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-38393: TALOS-2022-1592 || Cisco Talos Intelligence Group

An information disclosure vulnerability exists in the cm_processREQ_NC opcode of Asus RT-AX82U 3.0.0.4.386_49674-ge182230 router's configuration service. A specially-crafted network packets can lead to a disclosure of sensitive information. An attacker can send a network request to trigger this vulnerability.

**SUMMARY**

An information disclosure vulnerability exists in the cm\_processREQ\_NC opcode of Asus RT-AX82U 3.0.0.4.386\_49674-ge182230 router’s configuration service. A specially-crafted network packets can lead to a disclosure of sensitive information. An attacker can send a network request to trigger 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**

7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

**CWE**

CWE-119 - Improper Restriction of Operations within the Bounds of a Memory Buffer

**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.

The cfg_server and cfg_client binaries living on the Asus RT-AX82U are both used for easy configuration of a mesh network setup, which can be done with multiple Asus routers via their GUI. Interestingly though, the cfg_server binary is bound to TCP and UDP port 7788 by default, exposing some basic functionality. The TCP port and UDP ports have different opcodes, but for our sake, we’re only dealing with the TCP opcodes which look like such:

    type_dict = {
       0x1    :   "cm_processREQ_KU",   // [1]
       0x3    :   "cm_processREQ_NC",   // [2]
       0x4    :   "cm_processRSP_NC",
       0x5    :   "cm_processREP_OK",
       0x8    :   "cm_processREQ_CHK",
       0xa    :   "cm_processACK_CHK",
       0xf    :   "cm_processREQ_JOIN",
       0x12   :   "cm_processREQ_RPT",
       0x14   :   "cm_processREQ_GKEY",
       0x17   :   "cm_processREQ_GREKEY",
       0x19   :   "cm_processREQ_WEVENT",
       0x1b   :   "cm_processREQ_STALIST",
       0x1d   :   "cm_processREQ_FWSTAT",
       0x22   :   "cm_processREQ_COST",
       0x24   :   "cm_processREQ_CLIENTLIST",
       0x26   :   "cm_processREQ_ONBOARDING",
       0x28   :   "cm_processREQ_GROUPID",
       0x2a   :   "cm_processACK_GROUPID",
       0x2b   :   "cm_processREQ_SREKEY",
       0x2d   :   "cm_processREQ_TOPOLOGY",
       0x2f   :   "cm_processREQ_RADARDET",
       0x31   :   "cm_processREQ_RELIST",
       0x33   :   "cm_processREQ_APLIST",
       0x37   :   "cm_processREQ_CHANGED_CONFIG",
       0x3b   :   "cm_processREQ_LEVEL",
    }  
    

Out of the 24 different opcodes, only 3 or so can be used without authentication, and so let’s start from the top with cm_processREQ_KU \[1\]. The simplest request, it demonstrates the basic TLV structure of the cfg_server:

    struct REQ_TLV = {
        uint32_t tlv_type;
        uint32_t size;
        uint32_t crc;
        char buffer[];
    }
    

For the cm_processREQ_KU request, type is 1 and the crc doesn’t actually matter, but the size field will always be the size of the buffer field, not the rest of the headers. Regardless, this particular request gets responded to with the server’s public RSA key. This RSA key is needed in order to send a valid cm_processREQ_NC\[2\] packet, which is where our bug is. The cm_processREQ_NC request is a bit complex, but the structure is given below:

    struct REQ_NC = {
        uint32_t tlv_type = "\x00\x00\00\x03",
        uint32_t size,
        uint32_t crc,
        uint32_t tlv_subpkt1 = "\x00\x00\x00\x01", //[3]
        uint32_t sizeof_subpkt1,
        uint32_t crcof_subpkt1,
        char master_key[ ],                        //[4]
        uint32_t tlv_subpkt2 = "\x00\x00\x00\x03",
        uint32_t sizeof_subpkt2,   
        uint32_t crcof_subpkt2,
        char client_nonce[ ],                      //[5]
    }
    

The cm_processREQ_KU request provides the server with two different items that are used to generate the session key needed for all subsequent requests, the master_key\[3\] and the client_nonce\[4\]. A quick note before we get to that: Everything in the packet starting from the tlv_subpkt1 field at \[3\] gets encrypted by the RSA public key that we get from the cm_processREQ_KU request, so there’s an implicit length limitation due to RSA encryption. Continuing on, the master_key\[4\] buffer is used as the aes_ebc_256 key that the server will use to encrypt the response to this packet, and the client_nonce buffer is used to generate a session key later on. Let us now examine what the server sends in return:

    [~.~]> x/60bx $r1
    0xb62014e0:     0x00    0x00    0x00    0x02    0x00    0x00    0x00    0x20 // headers
    0xb62014e8:     0x06    0x42    0x18    0x4f    
       
    0xb62014ec:     0x13    0x9f    0x09    0x97 // server nonce [6]
    0xb62014f0:     0x90    0x92    0x9b    0x85    0xe5    0x40    0xa1    0x38
    0xb62014f8:     0xd7    0x81    0x62    0x72    0xf6    0x88    0x5c    0xef
    0xb6201500:     0x61    0x86    0x5c    0xc0    0xef    0xc0    0x06    0x23
    0xb6201508:     0xa2    0x6d    0x6a    0x85    
                                     
    0xb620150c:     0x00    0x00    0x00    0x03                     // headers
    0xb6201510:     0x00    0x00    0x00    0x04    0x51    0xb3    0x28    0x43
    0xb6201518:     0xcc    0xcc    0xcc    0xcc // [...]            // client nonce [7]
    

Both the server_nonce at \[6\] and the client_nonce\[7\] are AES encrypted and sent back to us. Subsequent authentication consists of generating a session key from sha256(groupid + server_nonce + client_nonce). In order to hit our bug, we don’t even need to go that far. Let us take a quick look at how the AES encryption happens:

    0001d8b0    void *aes_encrypt(char *enckey, char *inpbuf, int32_t inpsize, uint32_t outsize){
    0001d8c8         int32_t ctx = EVP_CIPHER_CTX_new();
    0001d8d4         if (ctx == 0){ ... }
    0001d904         else {
    0001d914              int32_t r0_2 = EVP_EncryptInit_ex(ctx: ctx, type: EVP_aes_256_ecb(), imple: null, key: enckey, iv: nullptr);
    

We don’t need to delve too much into what occurs; it suffices to know that the key is passed directly from the enckey parameter straight into the EVP_EncryptInit_ex. Backing up to find what exactly is passed:

    00057534 int32_t cm_processREQ_NC(int32_t clifd, struct ctrlblk *ctrl, void *tlvtype, int32_t pktlen, void *tlv_checksum, struct tlv_ret_struct* sess_block, char *pktbuf, uint32_t client_ip, char *cli_mac){
    {...}
    00058b58    void *aes_resp = aes_encrypt(enckey: sess_block->master_key, inpbuf: nonce_buff, inpsize: clinonce_len + sess_block->server_nonce_len + 0x18, outsize: &act_resp_b_size);
    

We can see it involves the masterkey that we provided. Let’s back up further in cm_processREQ_NC to see exactly how it’s populated:

    00057534 int32_t cm_processREQ_NC(int32_t clifd, struct ctrlblk *ctrl, void *tlvtype, int32_t pktlen, void *tlv_checksum, struct tlv_ret_struct* sess_block, char *pktbuf, uint32_t client_ip, char *cli_mac){
    // [...]
    00057af4              int32_t req_type = decbuf_0x1002.request_type_le
    00057af4              int32_t req_len = decbuf_0x1002.total_len_le
    00057af4              int32_t req_crc = decbuf_0x1002.crc_mb
    00057b00              int32_t reqlen = req_len u>> 0x18 | (req_len u>> 0x10 & 0xff) << 8 | (req_len u>> 8 & 0xff) << 0x10 | (req_len & 0xff) << 0x18
    00057b08              int32_t reqcrcle_
    00057b08              if (reqlen != 0)
    00057b10                  reqcrcle_ = req_crc u>> 0x18 | (req_crc u>> 0x10 & 0xff) << 8 | (req_crc u>> 8 & 0xff) << 0x10 | (req_crc & 0xff) << 0x18
    00057b18                  if (reqcrcle_ != 0)
    00057bb4                      if (req_type != 0x1000000)  // master key [8]
                                        // [...]
    00057c48                      int32_t decsize_m0xc = size_of_decrypted - 0xc
    00057c50                      if (decsize_m0xc u< reqlen)  // [9]
                                        // [...]
    00057cf0                      char (* var_1048_1)[0x1000] = &dec_buf_contents
    00057d00                      if (do_crc32(IV: 0, buf: &dec_buf_contents, bufsize: reqlen) != reqcrcle_) [10]
                                        // [...]
    00057d94                      sess_block->masterkey_size = reqlen
    00057d9c                      char* aeskey_malloc = malloc(bytes: reqlen) // [11]
    00057da8                      sess_block->master_key = aeskey_malloc
                                        // [...]
    00057db8                      memset(aeskey_malloc, 0x0, reqlen);  
    00057dd8                      memcpy(aeskey_malloc, &dec_buf_contents, reqlen); 
    

Trimming out all the error cases, we start from where the server starts reading the bytes decrypted with its RSA private key. All the fields have their endianess reversed, and the sub-request type is checked at \[8\]. A size check at \[9\] prevents us from doing anything silly with the length field in our master\_key message, and a CRC check occurs at \[10\]. Finally the sess_block->master_key allocation occurs at \[11\] with a size that is provided by our packet.

Now, an important fact about AES encryption is that the key is always a fixed size, and for AES\_256, our key needs to be 0x20 bytes. As noted above however, there’s not actually any explicit length check to make sure the provided master_key is 0x20 bytes. Thus, if we provide a master_key that’s say, 0x4 bytes, a malloc, memset and memcpy of size 0x4 will occur. aes_encrypt will read 0x20 bytes from the start of our master_key’s heap allocation, resulting in an out-of-bound read and assorted heap data being included into the AES key that encrypts the response. While not exactly a straight-forward leak, we can figure out these bytes if we slowly oracle them out. Since we know what the last bytes of the response should be (the client_nonce that we provide), we can simply give a master_key that’s 0x1F bytes, and then brute force the last byte locally, trying to decrypt the response with each of the 0xFF possibilities until we get one that correctly decrypts. Since we know the last byte, we can then move onto the second-to-last byte, and so-on and so forth, until we get useful data.

While the malloc that occurs can go into a different bucket based on the size of our provided master_key, heuristically it seems that the same heap chunk is returned with a master_key of less than 0x1E bytes. A different chunk is returned if the key is 0x1F or 0x1E bytes long. If we thus give a key of 0x1D bytes, we have to brute-force 3 bytes at once, which takes a little longer but is still doable. After that we can go byte-by-byte again and leak important information such as thread stack addresses.

**Crash Information**

    $python infoleak.py
    
    Type: 1 (cm_processREQ_KU)
    Len:  0x4
    CRC:  0x56b642cd
    ===MSG===
    \x11\x22\x33\x44
    =========
    
    b'\x00\x00\x00\x01\x00\x00\x00\x04V\xb6B\xcd\x11"3D'
    [^_^] Importing:
    -----BEGIN PUBLIC KEY-----
    [...]
    -----END PUBLIC KEY-----
    
    Type: 3 (cm_processREQ_NC)
    Len:  0x100
    CRC:  0x92657321
    ===MSG===
    \x1a\x54\xd7\x4a\xf6\x7a\xe1\x4c\x16\x76\x69\x74\x2b\x96\x41\xc6\xa0\xbc\x57\x58\x45\x61\xa9\xa9\x04\x09\xae\xb4\xb2\x9c\x54\xdd\xb8\xd1\x8f\x0d\x25\xf6\x79\x07\xd6\x65\x12\x75\xbb\x7d\x2d\x4e\x41\xf0\xa9\x47\x75\xa5\x73\x2d\x4c\x02\x10\x9e\xb1\x3a\x2c\xa5\x1c\x11\xfe\x35\x8e\xd3\x95\x53\xe5\x90\x3a\x9a\x8b\xad\x9b\x10\x81\xde\xd3\x67\x19\x9d\x34\x44\x52\x75\x1d\x90\xc7\xbf\x19\xf1\x04\x15\x19\xd4\x11\x2d\x70\xbd\xa9\x87\xdf\x22\x59\xc2\xb0\xb1\xd5\x7b\x5a\xcb\xe7\xc7\x34\x0f\xcb\xa6\x9f\x81\x5c\xb3\x6d\xf7\x1c\x49\xd7\xed\x72\x54\x85\xe0\xca\x32\x96\xa9\xa2\x44\xda\x56\xfb\xf7\x96\x21\x53\xb7\xbe\x9c\xc9\x5f\x4a\x00\xdb\x2f\xd2\x6e\x1b\xf5\xdc\xa9\xa5\x8f\xde\xf5\x80\x83\xd7\xd8\x65\xe8\x6f\xd6\x0a\x3e\x10\x92\xca\xd2\xbf\x14\x1c\x06\xf0\x53\xb5\x41\xea\x2a\xe2\x5c\x2a\xa8\xb9\xa2\x92\xe7\xd5\x44\x55\x1c\x8e\x9b\xff\x13\x37\x60\x5b\x82\xfa\xa0\xe7\x44\x8f\x0b\xe9\x8f\x64\xcd\xa4\x50\xe9\xcd\xbc\x14\x34\xed\x57\xc5\x0a\xaf\xc3\x8d\x71\xee\x48\x35\x90\xa6\xb7\x08\x6c\xfb\xb1\xbf\xee\x0c\x72\x21\xdf\x4e\x29\xf9
    =========
    
    [^_^] Leaked Bytes: 0x0000b620
    b'\x00\x00\x00\x02\x00\x00\x00 \x1a=\xac\x11\xebVxU\xe7\\\xdb8\x02\\k\n<\x91_>\x17\xc6r\x08\xfc\xbc\xde\xf6\x1a\x1ev\xfa\x03_\xf0y\x00\x00\x00\x03\x00\x00\x00\x07\x10\xc1\x06\xa9\xcc\xcc\xcc\xcc\xcc\xcc\xcc\x01'
    

**TIMELINE**

2022-08-23 - Vendor Disclosure  
2022-11-16 - Vendor Patch Release  
2023-01-10 - Public Release

Discovered by Lilith >\_> of Cisco Talos.

CVE-2022-38105: TALOS-2022-1590 || Cisco Talos Intelligence Group

Did you miss our livestream focused on the APT section in the Cisco Talos Year in Review report? Join host Mitch Neff and special guests Jacob Finn, Asheer Malhotra, and Vitor Ventura as they discuss Talos' findings and experiences tracking APTs in 2022.

Tuesday, January 10, 2023 15:01

Did you miss our livestream focused on the APT section in the Cisco Talos Year in Review report? Join host Mitch Neff and special guests Jacob Finn, Asheer Malhotra, and Vitor Ventura as they discuss Talos' findings and experiences tracking APTs in 2022.  This livestream sheds light into the topic of APT TTPs, the geopolitical factors that influence the macro-environment and defensive guidance to improve security posture.

Visit the Year in Review page for the full report, each topic summary report, livestreams, and podcasts.  New content will be added with each topic summary release through February 2023.  You can access the full 2022 Cisco Talos Year in Review report directly here:

2022 Year in Review: APTs Livestream Replay

Vice Society is boasting that it compromised the San Francisco transportation system, while BART maintains operations and mounts an investigation.

The San Francisco Bay Area Rapid Transit System (BART) was listed this week by ransomware group Vice Society as being among its latest victims.

Brett Callow, threat analyst with Emsisoft, flagged the Vice Society BART brag on Jan. 6. However, BART's spokesperson Alicia Trost told Dark Reading there haven't been any service disruptions as a result of a cyberattack and that an investigation is ongoing.

"We are investigating the data that has been posted," Trost told Dark Reading by email. "To be clear, no BART services or internal business systems have been impacted. As with other government agencies, we are taking all necessary precautions to respond."

Vice Society was also behind a recent spate of school breaches in the US and beyond, most recently releasing the personal information stolen from a group of 14 schools in the UK.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

San Fran's BART Investigates Vice Society Data Breach Claims

Microsoft released its monthly security update on Tuesday, disclosing 101 vulnerabilities. Of these vulnerabilities, 11 are classified as “Critical”, 89 are classified as “Important”, no vulnerability classified as “Moderate.”

Tuesday, January 10, 2023 14:01

Microsoft released its monthly security update on Tuesday, disclosing 98 vulnerabilities. Of these vulnerabilities, 11 are classified as “Critical”, 87 are classified as “Important”, no vulnerability classified as “Moderate.”

According to Microsoft all “Critical“ vulnerability are either less likely or unlikely to be exploited, except of the security bypass vulnerability CVE-2023-21743 on Microsoft SharePoint Server machines. This vulnerability has a low complexity and can be easily triggered by an attacker. In a network-based attack, an unauthenticated user could make an anonymous connection to the targeted SharePoint server.

Two of the “Critical“ vulnerabilities, which Microsoft considers to be “less likely” to be exploited due to their complexity are CVE-2023-21535 and CVE-2023-21548. These are remote code execution (RCE) vulnerability in the Windows Secure Socket Tunneling Protocol (SSTP) which allow an unauthenticated attacker to send a specially crafted connection request to a RAS server, which could lead to remote code execution (RCE) on the RAS server and run unauthorized commands on the compromised system.

There are also five “Critical“ Remote Code Execution Vulnerability which affect the Windows Layer 2 Tunneling Protocol (L2TP). Successful exploitation could allow an unauthenticated attacker to execute code on RAS servers. These five vulnerabilities are CVE-2023-21543, CVE-2023-21546, CVE-2023-21555, CVE-2023-21556 and CVE-2023-21679.

The last “Critical“ vulnerability which we want to mention is CVE-2023-21730. It is a Remote Code Execution Vulnerability in the Windows Cryptographic Services. Microsoft did not released many details about the vulnerability, except that it is triggered from the network and of low complexity.

Developers are also at risk due to CVE-2023-21779 a Remote Code Execution vulnerability in Visual Studio Code flagged as “Important“. The user would have be enticed to open a malicious file in vscode. Users should never open anything that they do not know or trust to be safe.

Talos would also like to highlight 6 “Important“ vulnerabilities that Microsoft considers “more likely” to be exploited and can be used for privilege elevation.

*   CVE-2023-21532 Windows GDI Elevation of Privilege Vulnerability 
*   CVE-2023-21541 Windows Task Scheduler Elevation of Privilege Vulnerability 
*   CVE-2023-21552 Windows GDI Elevation of Privilege Vulnerability 
*   CVE-2023-21725 Microsoft Windows Defender Elevation of Privilege Vulnerability
*   CVE-2023-21726 Windows Credential Manager User Interface Elevation of Privilege Vulnerability
*   CVE-2023-21768 Windows Ancillary Function Driver for WinSock Elevation of Privilege Vulnerability

There are more vulnerabilities marked as “Important“ in the Microsoft advisory. This includes Microsoft Office and 3D Builder applications, a Microsoft ODBC Driver and others. A complete list of all the vulnerabilities Microsoft disclosed this month is available on its update page.

In response to these vulnerability disclosures, Talos is releasing a new Snort rule set that detects attempts to exploit some of them. Please note that additional rules may be released at a future date and current rules are subject to change pending additional information. Cisco Secure Firewall customers should use the latest update to their ruleset by updating their SRU. Open-source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack available for purchase on Snort.org.

The rules included in this release that protect against the exploitation of many of these vulnerabilities are 61060-61065. For Snort 3, the following rules are also available to protect against these vulnerabilities: 300358-300360.

Microsoft Patch Tuesday for January 2023  — Snort rules and prominent vulnerabilities

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Tuesday, January 10, 2023 12:01

_**Authors:** Gergana Karadzhova, Joe Schumacher, Pawel Bosek_

In this blog post, Cisco Talos Incident Response (Talos IR) presents some of the key benefits of remote IR support and offers a list of recommendations for working on a remote incident.

Some organizations see added value in having incident responders on site during an emergency. While this approach may offer certain benefits in terms of coordination, in Talos IR’s experience, the physical presence of a team on site is not crucial for the success of the overall IR. Cybersecurity threats are by definition intangible and bringing people physically together does not automatically facilitate an investigation. The traces of the malicious actors involved in a ransomware case, for example, are in the cyberspace made up by an organization’s network and the Internet, which means that, with sufficient connectivity, a remote responder team can work on the case from anywhere.

As a remote-first, follow-the-sun global team, Talos IR has extensive experience in creating a healthy, effective, and collaborative environment for customers and responders regardless of the stressful nature of IR activities. Trust needs to be built over time and proactive IR services offer the means to do this preemptively, ensuring that when an emergency happens, the responders will be able to gain appropriate access in a timely manner. Specific recommendations on how to strategically use proactive services in building this relationship are outlined in section “Adopting a ‘trust but verify’ approach.”

**Analyzing the advantages of remote IR support**

Criteria 

Remote 

On-Site 

Start of engagement 

15 minutes to four hours 

24 hours in transit 

Personnel utilization and treatment 

“Follow the sun” model, ensuring that team members rest in between shifts and lower the risk of burnout 

Usually limited to daytime. 

Risk of overstretching the team if working around the clock for multiple days 

Scalability  

Limited only by the IR team’s size  

1 – 2 people depending on the size of retainer 

Knowledge transfer between IR team and internal teams 

Primarily written  

Primarily verbal  

Efficiency  

Overall shorter period of time to start; easier to ramp up; better personnel utilization and care; transparent and lower cost 

Overall longer time to start; harder to ramp up; limited daily period of work; additional costs due to travel and accommodation 

Remote incident response offers the following key advantages in comparison to on-site support:

*   **Faster initial response –** The average industry service-level agreement for having on-site support is 24 hours in transit. Depending on the exact time when the incident was reported, the transportation options to the location, and the immediate availability of the consultants going on site, it can take anywhere between eight to 24 hours to reach the customer premises. This is significantly longer than the time needed to kick off a remote response, which in Talos IR’s experience is less than two hours.
*   **Easier to scale the response team –** IR is a team sport. Customers usually mainly interact with a few dedicated team members of the IR team, such as an Incident Commander and a few lead consultants. In the background, however, there are additional technology specialists, project managers and threat intelligence analysts working on the case. It is much easier to involve additional personnel in a remotely managed incident than to order people on site.
*   **More resource efficient –** The three most valuable resources in an incident are time, budget, and human power. In terms of human power, consider an incident which has been active for 48+ hours and is still ongoing. In such cases, having a remote team consisting of members in different time zones can ensure that work on the incident follows the sun without burning the team out. When it comes to cost management, remote incident support tends to provide great transparency of activities performed by the team, due to the centralized flow of communication and information exchange. Additional cost efficiency is generated by the fact that technical personnel do not need to set up their workplace in a new environment with emergency conditions and thus suffer a dip in productivity.

**Preparing for remote incident response**

From inception, Talos IR has been handling our emergency IR while fully remote as the norm, even predating the COVID-19 pandemic, due to the 24x7 nature of our service and global team distribution. Webex organically allows Talos IR to quickly and securely support our customers anywhere in the world. During the pandemic, we supported Cisco customers without any service interruption and created additional virtual infrastructure to ensure that all Talos IR proactive services could be securely delivered. This being said, if we do encounter a special case which might necessitate on-site presence of the response team, we discuss with the customer if it would augment the overall IR effort.

Remote IR comes with its own set of challenges. Talos IR recommends discussing your approach to the points listed below _before_ an actual emergency, as addressing shortcomings might require lead time and resources.

*   **Provisioning Access** – Having a process to get the remote IR team access to on-premises and remote consoles will accelerate the ability to investigate the incident. This process should include accounts related to, but not necessarily limited to, Virtual Private Network (VPN), Active Directory (AD), Endpoint Detection and Response (EDR), Multi-Factor Authentication (MFA), and other security controls.
*   **Regulatory & Compliance Requirements** – Data collection and sharing are often subject to country-specific laws, especially in the case of critical infrastructure and personally identifiable information (PII). Technical teams should work with the Legal Department and the Data Privacy and Governance Office to verify the exact legislation that is applicable to the different data sources that might be part of an incident. Any known limitations regarding remote collection of evidence and analysis of the data should be documented in the Incident Response Plan.
*   **Communication Cadence** – Having multiple means of communication and a set status update meeting will help ensure that everyone is kept on the same page. Communication is critical to get right during an incident but does not have to be in-person to be efficient or effective. People tend to be hyper-connected during IR, so bringing structure and predictability to the information flow benefits everyone.
*   **Gathering Evidence** – Remote evidence collection might not be possible in all incidents, but with some planning can be a viable alternative to traveling to a location or shipping an asset. You will want to ensure that there are technical representatives on-site who can assist the IR team with collecting forensic and triage data from in-scope assets.
*   **Sharing Evidence** – A reliable, high-speed network connection is essential for downloading and uploading large files to remote server(s). You will most likely be downloading the requested evidence from endpoints (e.g., workstations and servers) within your internal network and then uploading this data to a remote server for the incident responders to analyze.
*   **Scaling the Response** – Typically, an incident starts with one or two events across a large, networked environment and expands in scope as more indicators of compromise are discovered. Having the ability to contact people across the team as the incident evolves and to connect them to the investigation remotely will reduce the overall time to act and contribute to a more efficient incident response. When planning who and how you might need to engage during a possible incident, it is critical to consider your internal team along with the partners, contractors, and service providers that will be assisting with the incident response remotely.

Internal teams that will be involved in the implementation of the above preparation activities should familiarize themselves with the agreed approach as part of their preparation for IR and whenever possible, test the theoretical plan in the practice. It is highly recommended to document all relevant procedures and processes within the internal Incident Response Plan and Incident Response Playbooks, as this makes distribution and knowledge management easier in the long run.

**Adopting a “trust but verify” approach**

In the world of security there is the phrase “trust but verify,” and this mentality should be present when it comes to your IR service provider. Many companies have their first contact with the IR team during an emergency, which is one of the worst times for building trust and getting to know each other. A much better way to become familiar with your incident responders is to work with them on **proactive services**. These services by definition are non-emergency and offer more time for addressing the remote support considerations listed above through tabletop exercises, development of plans and playbooks, and threat hunts. In addition to improving your overall resiliency to cyber threats, proactive services will allow you to see what tools are typically leveraged by the IR team and what methodology they use for threat hunting. The engagements provide an opportunity for the responders and your internal teams to build trust and a better understanding of each other’s craft. An investment in the human element of virtual collaboration pays off during subsequent remote IR cases, as both sides feel more comfortable working together and can be more efficient in the execution of emergency response actions.

In most businesses, a level of remoteness was present long before the COVID-19 pandemic. Many organizations operate remotely or in different locations, whether that is multiple offices, data centers, or the homes of their employees. The increase of remote work in the last few years has led to optimization and normalization of virtual collaboration, the latter becoming an integral part of modern business operations. In a similar way, IR has grown increasingly independent of physical location as long as secure connectivity is possible. There will always be the need to physically travel to a location for response in some special cases, but that will not be the norm.

The expanded use of cloud services, the increase in remoteness in company operations, and the shortage of cybersecurity talent all speak in favor of an IR delivery model with remote-first support and members distributed around the globe. This trend emphasizes the importance of accountability and trustworthiness in each and every interaction with the IR team, whether physically or virtually. Talos IR recognizes this and is committed to delivering high-quality and efficient engagements during all emergency and proactive retainer projects.

Tag

#cisco