{"uuid": "1f3418a9-6d3e-45f9-a611-a369c2fcda90", "vulnerability_lookup_origin": "1a89b78e-f703-45f3-bb86-59eb712668bd", "author": "9f56dd64-161d-43a6-b9c3-555944290a09", "vulnerability": "CVE-2021-22908", "type": "seen", "source": "https://t.me/hacking_Attack/10385", "content": "Black Hat Ethical Hacking\nPulse Secure VPNs Get Quick Fix for Critical RCE\n\nhttps://www.blackhatethicalhacking.com/wp-content/uploads/2017/11/black-hat-locks-and-electronics.jpg Pulse Secure VPNs Get Quick Fix for Critical RCEPost Views: 160 \nReading Time: 1 Minute\nPulse Secure has issued a workaround for a critical remote-code execution (RCE) vulnerability in its Pulse Connect Secure (PCS) VPNs that may allow an unauthenticated, remote attacker to execute code as a user with root privileges.\nPulse Secure\u2019s parent company, Ivanti, issued an out-of-band advisory\u00a0on May 14. The company explained that this high-severity bug \u2013 identified as CVE-2021-22908\u00a0and rated CVSS 8.5 \u2013 affects Pulse Connect Secure versions 9.0Rx and 9.1Rx.\n\n\u201cBuffer Overflow in Windows File Resource Profiles in 9.X allows a remote authenticated user with privileges to browse SMB shares to execute arbitrary code as the root user,\u201d according to the advisory. \u201cAs of version 9.1R3, this permission is not enabled by default.\u201d\n\nThe CERT Coordination Center issued a report\u00a0about the vulnerability, explaining that the problem stems from a buffer overflow vulnerability in the PCS gateway. CERT/CC explained that the gateway\u2019s ability to connect to Windows file shares through a number of CGI endpoints could be leveraged to carry out an attack.\n\n\u201cWhen specifying a long server name for some SMB operations, the smbcltapplication may crash due to either a stack buffer overflow or a heap buffer overflow, depending on how long of a server name is specified,\u201d CERT/CC noted. PCS 9.1R11.4 systems are vulnerable: CERT/CC said that it\u2019s\u00a0 managed to trigger the vulnerability by targeting the CGI script /dana/fb/smb/wnf.cgi, although \u201cOther CGI endpoints may also trigger the vulnerable code.\u201d\nSee Also: 100M Android Users Hit By Rampant Cloud Leaks There\u2019s currently no practical solution to this problem, at least not that CERT/CC is aware of, according to Will Dormann, who both discovered the vulnerability and wrote up the CERT/CC report. He offered two workarounds: Fix No. 1: Apply XML WorkaroundPulse Secure has published a quick fix: a Workaround-2105.xml file with a mitigation to protect against the vulnerability. \u201cImporting this XML workaround will activate the protections immediately,\u201d according to Dormann\u2019s report, and \u201cdoes not require any downtime for the VPN system.\n\nThe workaround blocks requests that match these URI patterns: ^/+dana/+fb/+smb^/+dana-cached/+fb/+smbDormann advised users to note that Workaround-2105.xmlwill automatically deactivate the mitigations applied by an earlier workaround, Workaround-2104.xml. That makes it \u201cimperative that a PCS system is running 9.1R11.4 before applying the Workaround-2105.xmlmitigation,\u201d he said, to ensure that the vulnerabilities outlined in SA44784\u00a0aren\u2019t reintroduced as the result of applying the workaround.\n\nThe workaround will block the ability to use Windows File Share Browser.\nSee Also: Offensive Security Tool: Snallygaster Fix No. 2: Set a Windows File Access PolicyDormann said that a PCS system that started as 9.1R2 or earlier will retain the default Initial File Browsing Policy of Allow for \\\\*SMB connections, which will expose this vulnerability. He advised users to check out the administrative page for the PCS, at Users -> Resource Policies -> Windows File Access Policiesto view current SMB policy.\n\nA PCS policy that explicitly allows \\\\*or otherwise \u201cmay allow users to initiate connections to arbitrary SMB server names,\u201d Dormann advised, telling users to \u201cconfigure the PCS to Deny connections to such resources to minimize [...]\n\n___________________________ \n@hacking_Attack\n@Hacking_Video", "creation_timestamp": "2026-09-01T20:02:41.242064Z"}