Tag: Ethical Hacking

  • 5 Things You Should (and Shouldn’t) Take Away from the Starlink Hack

    “As a professional, ethical hacker, I’ve gotten questions from family, friends, and neighbors about what this means – from its impact on the cost of the service to the future of humanity, depending on the paranoia level of the person asking.”

    Scottie Cole, Lead Penetration Tester

    The big news from this year’s Blackhat and DEF CON 30 hacker conventions came from a presentation by an engineer from Belgium, Lennert Wouters, detailing how he successfully hacked the entire Starlink ground network using one of the company’s own Dishy McFlatface® receivers. The way oversimplified summary is that he built a circuit board that allowed him to introduce a fault into Starlink’s security, which he then exploited to run custom code on the device.

    After seeing some of the headlines, I now understand why some people are a little freaked out. So, as a public service, what follows is my opinion of what the non-hacker public should (and should not) take away from this news.

    1. Yes, it’s a big deal (but maybe not for the reason you think). Let me be clear from the start, Lennert Wouters is a genius who deserves great respect for both the creative thinking and tenacity it took to accomplish this feat. This was a very complex hack that required a lot of hardware and software expertise, as well as a great deal of time to complete. That’s why . . .
    2. The media’s “$25 in off-the-shelf components” is highly misleading. Scalpels are cheap, but you still don’t see a lot of DIY brain surgery. Expense usually isn’t a barrier to hackers, but expertise, time, and motivation frequently are. Wouters conceived of and executed the brilliant hack, but he was working on it because . . .
    3. It was part of Starlink’s bug bounty program, designed to engage and reward super smart white hat hackers for finding problems first. In that sense, Wouters didn’t defeat Starlink’s cybersecurity but rather was an integral part of it. Other bounty hunters are still busy working on other exploits that could prove more significant – as are the bad guys. In fact . . .
    4. The Russians (and likely others) have been trying to take down Starlink because the Ukrainian government now relies on the satellite network so heavily. State-sponsored hackers reportedly took down the Ukrainian government’s internet service early in the war. According to Starlink founder Elon Musk, however, the Russians have not been able to disrupt Ukraine’s access to the service or breach its network. Taken together, what all this means is that . . .
    5. The Starlink hack, though impressive, likely does not represent a significant threat to the company or its users. On the one hand, I think this is a great story because I’m an electronics and “gadget” guy. As a penetration tester, however, I worry when business owners place a lot of focus on high-risk, low-probability hacks simply because they make the news. Over the course of thousands of penetration tests, the most common vulnerabilities Raxis finds are ones that are much simpler to exploit. Weak passwords, missing software patches, insufficient network segmentation, and a host of other, more pedestrian problems. The vulnerabilities might not make news, but the successful attack that follows – on a business, a hospital, or a school – many times does.

    Wouters used a Starlink setup much like this one, plus “$25 in off-the-shelf materials” to carry out his hack. It’s a fascinating story, but there are much bigger threats facing businesses today.

    Wouters used a Starlink setup much like this one, plus “$25 in off-the-shelf materials” to carry out his hack. It’s a fascinating story, but there are much bigger threats facing businesses today.

    The most important takeaways are that the biggest corporate networks on Earth (and beyond) can be hacked. The most secure networks are those that have an effective testing protocol that identifies vulnerabilities before they become breaches.

     

  • ManageEngine Applications Manager Stored Cross-Site Scripting Vulnerability (CVE-2021-31813)

    I’m Matt Dunn, lead penetration tester here at Raxis.This is a summary of the third stored cross-site scripting vulnerability I discovered while testing several Zoho-owned ManageEngine products. This vulnerability exists in the Applications Manager product.

    Summary

    Recently I discovered a stored Cross-Site Scripting vulnerability in ManageEngine Applications Manager. The vulnerability exists in a users’ name fields when they are imported from Active Directory. This can be performed in any of the name fields and is executed when selecting the user for import on /admin/userconfiguration.do after fetching users from the domain. After the import loads and the user is selected, the user’s name is loaded with unescaped content, allowing malicious JavaScript to be reflected back to the user.

    Proof of Concept

    The vulnerability can be triggered by inserting html content, specifically script tags, into the first or last name of an Active Directory user. The following was inserted as a proof of concept to reflect the user’s cookie in an alert box:

    <script>alert(document.cookie)</script>

    An example of this in the Last Name field of one such user can be seen here:

    Stored XSS Payload

    After that user is selected and the details load on the “User Imported from Active Directory” page, the HTML is presented unescaped on the web page, which allows the script tags to be loaded as valid JavaScript. The unescaped HTML as loaded can be seen here:

    Unescaped JavaScript Tags

    After loading the selected user, the malicious content is executed, as shown below:

    JavaScript Execution to Display User's Cookie in an Alert Box

    Affected Versions

    Raxis discovered this vulnerability on Manage Engine Applications Manager 15, Build 15080.

    Remediation

    Upgrade ManageEngine Applications Manager to Version 15.1 Build 15130 or later immediately which can be found here:

    Disclosure Timeline

    • March 18, 2021 – Vulnerability reported to Zoho
    • March 18, 2021 – Zoho begins investigation into report
    • April 27, 2021 – Zoho releases fixed version 15.1 Build 15130
    • April 27, 2021 – CVE-2021-31813 is assigned to this vulnerability

    CVE Links