by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nicole Grinstead
    @nicolegrinstead
    Hey @defensivedepth I can't make any promises, but that's the current goal. It will still be a while before we get there though.
    Josh Brower
    @defensivedepth
    @nicolegrinstead great, thanks! I know this is difficult to do, but can you give really rough estimate? Like 6 months? 1 year?
    Nicole Grinstead
    @nicolegrinstead
    @defensivedepth hopefully closer to 6 months or less, but again no promises.
    Josh Brower
    @defensivedepth
    @nicolegrinstead Thanks, understood!
    Josh Brower
    @defensivedepth

    hey all - thanks again for your work on this great app! Looking for some feedback. My use case is such that within an organization, there are multiple teams that we want to make use of Stethoscope. However, there are different "checklists" or "profiles" for each of these teams. Rather than deploying multiple different builds of Stethoscope, we would like to deploy one build and allow the user to select the relevant checklist:

    When the app initially launches, a popup is displayed, and the user is asked to select a checklist: Baseline, Other. Selecting the Other option would allow the user to key in a unique code given to them by their team. Once the code has been entered and is found to be valid, the app will assess the device based on the team’s unique requirements.

    From a technical perspective, Stethoscope would connect to an API and:
    -Confirm that the code is valid
    -Download and store the checklist definitions for the code

    Thoughts or comments on this?
    Miguel David
    @minac
    Hi there! Has anyone else seen an error during the first run of the app (yarn start) where osquery says it's missing ../net module?
    I am on macOs mojave and did not have node or yarn installed, so I installed yarn and its dependencies using brew.
    Any help would be appreciated. Looks like a very promising app!
    Rob McVey
    @rmcvey
    Hey @minac, just saw someone have this issue this morning. It appears to be an issue with the /tmp/osquery.em socket not being available
    Miguel David
    @minac
    thanks @rmcvey. Do you know how that is solved or what the cause is?
    Erich Smith
    @erichs
    @defensivedepth my team is implementing something quite similar, but as a standalone agent that retrieves the needed stethoscope config via an API, then queries Stethoscope-app via the local GraphQL service.
    Josh Brower
    @defensivedepth
    @erichs Sounds really interesting! Will it be open sourced at some point?
    Erich Smith
    @erichs
    @defensivedepth, hmm... I hadn't considered that, to be honest. With a bit more work though, perhaps we could introduce a command pattern/make the API-specific portions generic. Will mull that over!
    Robert Davis
    @nocow4bob
    Since the stethoscope-app is all client side, what is to keep someone from running a bogus web server in place of the graphql API that responds with PASS on all policy checks to the web? Not a big deal for managed machines potentially since that should be detectable/not allowed, but for unmanaged machines, how can you trust the client policy status response?
    Jesse Kriss
    @jkriss
    @nocow4bob You're correct, the response from the app can be forged. We see Stethoscope as a preventative tool, built for the scenario where you can trust the owner not to maliciously circumvent the legitimate reporting.
    Robert Davis
    @nocow4bob
    @jkriss that makes sense. Combined with MFA for identity makes that trust level acceptable. Really dig the idea. Thanks!
    Eric
    @vector-sec
    Could probably do some sort of signature with a preshared secret to verify that the content is legitimate. That
    Erich Smith
    @erichs
    Hi! I've successfully cross-compiled a windows version of Stethoscope from a mac (osx 10.12.6, Mono JIT compiler version 5.18.0.225). The executable, when launched on a Win10 machine, latest patches, seems to go immediately into a death spiral, consuming all CPU resources and forcing a hard reset since the OS becomes unresponsive. Task manager shows WMI Provider Host service consuming all available CPU, and from what I could glean from the process details, there appear to be many, many "console host" and "taskkill" processes spawning. If I had to guess, I imagine that the Electron app is having difficulty launching osqueryd.exe. Are others successfully using Stethoscope on windows? Any advice on troubleshooting?
    Erich Smith
    @erichs
    To rule out cross-platform issues, I built this directly on Win10, with (Node v10.15.1 LTS). This had identical behavior when launching Stethoscope for the Spectron tests, except that the consoles were launched in the foreground. I'm happy to open an issue for this, but was wondering if others had any quick tips!
    Josh Brower
    @defensivedepth
    @erichs I am seeing the same issue.
    Have you found any workarounds ?
    Josh Brower
    @defensivedepth
    ah, I see the issue you created, nvm
    Rob McVey
    @rmcvey
    Hi @erichs, @defensivedepth and other interested parties - we finally open-sourced kmd (our osquery replacement) today, published it as a public npm package (kmd-script), and merged the changes into master. The new version is significantly faster and much more stable. You can review the kmd source here: https://github.com/Netflix-Skunkworks/kmd. Please let us know if you have any questions or run into any issues. I'll work on updating the documentation for kmd in the coming weeks to help you get started writing your own. More good news: we should be able to support Linux soon now that we aren't relying on osquery's chosen methods of deriving system info (many of which require root).
    Josh Brower
    @defensivedepth
    @rmcvey Good to hear! I was able to successfully build and run v3.0.1 on both MacOS and Win10 with no issues.
    Can you give some further context around the switch from osquery to kmd ?
    Rob McVey
    @rmcvey

    Hi @defenseindepth, glad the new version ran for you! Sure, I'd be happy to provide more context.

    TLDR; in our setup, osquery was far more trouble than it was worth.

    The first iteration of Stethoscope+osquery was shelling out to osqueryi for each request (e.g. osqueryi --json "select * from sharing_preferences"). This provided a fair amount of app stability and data collection reliability, the only problem was resource utilization from spinning up new shells - this was especially problematic on Windows. After engaging with the osquery community, it was recommended that we switch to launching osqueryd in ephemeral mode when the app starts and utilizing the Thrift socket that is made available for extensions. I was able to get this working after reverse-engineering Node thrift (no real documentation to speak of), but the connection code was super sketchy and once we deployed it we were getting reports of it randomly failing in the wild. After supporting the osqueryd/thrift based setup for 7-8 months, it was becoming obvious that the thrift connection was not reliable and extremely difficult to debug/reproduce issues.

    In addition to these technical issues, osquery was not really providing the level of platform abstraction we hoped it would. We had to maintain separate query sets for different platforms (as well as a set of bash/ps scripts for the data osquery doesn't cover), and the results for some of the queries that do work cross-platform were not normalized.

    I'm sure osquery works great for "typical" deployments where you just need the queries to run eventually and processes can respawn as needed, but it was not working as well in our on-demand setup.

    The vast majority of the system info we care about can be easily found using bash/powershell, so we wrote a little scripting language (kmd) to make parsing and extracting data from stdout easier.

    Some of the benefits to this approach:

    • the app is around 4x faster than the osquery version
    • it is much more obvious what is going on in the app
    • we can support linux!
    Josh Brower
    @defensivedepth
    @rmcvey Thanks much! Also, is there a public roadmap available anywhere?
    Rob McVey
    @rmcvey
    :thumbsup: @defensivedepth We don't currently have a public roadmap, I'll bring it up at our next meeting though.
    Josh Brower
    @defensivedepth
    @rmcvey My particular use case requires the option for the user to swap out scan profiles (policy.yaml). Is this something that your team would want to accept into core? Quick Demo: https://www.screencast.com/t/Tw9zTbZSS Code: https://github.com/defensivedepth/stethoscope-app
    Rob McVey
    @rmcvey
    @defensivedepth wow, that is really awesome! We have our Stethoscope meeting today, I will definitely bring this up to the team. We have discussed the ability to swap out policies, I was working on a change that would allow authorized hosts to POST a new policy to the app so that small policy changes (e.g. Mac released a new update) wouldn't require a full redeploy of the app, but I like your approach, will let you know what the team thinks. Thanks!
    Josh Brower
    @defensivedepth
    @rmcvey Sounds good! The backend API is currently just a simple Azure Logic App that has a case statement that returns different yaml depending on the 4 digit code submitted. Like I mentioned, my use case is being able to deploy a single build to multiple environments that require different policies.
    Josh Brower
    @defensivedepth
    hey all - was wondering how things are going with the mobile app? Is it somewhat close to a public release? Thanks!
    Jesse Kriss
    @jkriss
    @defensivedepth Unfortunately, we haven't had a chance to put any real effort towards it recently. If it's something you'd be interested in working on, I could talk to the team about making the source available, even though it's really just a proof of concept at this point.
    Josh Brower
    @defensivedepth
    @jkriss Thanks for the update - Yes, would love to see the source. Not sure if it is something I could use, but am very interested in what you guys put together.
    Erich Smith
    @erichs
    Same! Also would love to see even a PoC.
    Josh Brower
    @defensivedepth
    @jkriss Any update on the possibility of making the source available?
    Jesse Kriss
    @jkriss
    @defensivedepth @erichs Yes! The team is on board with publishing the source. We want to do some basic cleanup (updating dependencies and such) and then will make it available via the Netflix Skunkworks org on GitHub.
    Josh Brower
    @defensivedepth
    @jkriss Fantastic! Looking forward to seeing it
    rodgerramjet26
    @rodgerramjet26
    Did the Stethescope mobile PoC get made available? I had a look in the Netflix Skunkworks repo but couldn't see it
    Nicole Grinstead
    @nicolegrinstead
    Hi Everyone, today we made the Stethoscope Mobile repo public: https://github.com/Netflix-Skunkworks/StethoscopeMobile
    Josh Brower
    @defensivedepth
    @nicolegrinstead Fantastic, thanks so much!
    Erich Smith
    @erichs
    Just FYI, there appears to be an issue building for Win32 on MacOS Catalina. I've opened an issue upstream for this: electron-userland/electron-builder#4448
    Erich Smith
    @erichs

    Posting my recent experiences with cross-platform builds for Stethoscope-app, in case it helps anyone else:

    The Docker-based build suggested here works for Windows and Linux, and should probably be the preferred build option for those platforms: https://www.electron.build/multi-platform-build#build-electron-app-using-docker-on-a-local-machine.

    MacOS builds still require a native MacOS machine for DMG build targets, as electron-builder shells out to hdiutil, a MacOS binary.

    Windows code-signing is still best done via Virtualbox VM, with Stethoscope mounted as a Shared Folder, and using signtool.exe

    Erik Bille
    @erikbille

    Hey guys,
    We're trying to implement the dockerised backed with Jamf but are running into issues when the application is trying to fetch the device details off the user record in Jamf.

    The error message is:

    [2020-02-19 09:38:27.059517 ERROR    stethoscope.api.utils] /code/stethoscope/api/utils.py:59
    [get_devices_by_email] failed to retrieve data for 'jamf(erik.bille@kullander.se)':
    [Failure instance: Traceback: <class 'TypeError'>: the JSON object must be str, not 'bytes'
    /usr/local/lib/python3.4/site-packages/treq/client.py:61:connectionLost
    /usr/local/lib/python3.4/site-packages/treq/content.py:36:connectionLost
    /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:459:callback
    /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:567:_startRunCallbacks
    --- <exception caught here> ---
    /usr/local/lib/python3.4/site-packages/twisted/internet/defer.py:653:_runCallbacks
    /usr/local/lib/python3.4/json/__init__.py:312:loads
    ]

    Have anyone encountered this before of know of a fix?

    TK
    @tkhan2020
    Hello Everyone!
    Apologies, if i am asking something that is very obvious. Does application scanning work for windows users ?
    applications:
      - name: Google Chrome
        assertion: ALWAYS
        paths:
            win32: HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall
    Rob McVey
    @rmcvey
    Hi @tkhan2020, we aren't currently using this functionality so it's hard to say with a high degree of confidence whether or not this is working as intended. You shouldn't need to specify paths, but it might help to add something like platform: win32: ">=81.0.4044"
    Hope this is helpful!