Ubuntu 20.04 - Quest Container not setting up correctly about emba HOT 6 OPEN

It is also possible this could be happening on other OSes, but I don't have the ability to test those right now so would need someone else to confirm if the installer sets up the quest container properly.

from emba.

We improved the online check since the last release. Could you please test the latest master?

from emba.

The Quest container is a separate container for the Q-modules, which require internet connection.
Currently, @m-1-k-3 is working on a fix where the container doesn't work correctly behind a proxy.
Might this also be the case here?

from emba.

We improved the online check since the last release. Could you please test the latest master?

This was it, I figured that the tagged versions were what should be used like "stable" releases, but didn't realize that since there is just the one tag of the docker image that the master branch should probably always be used, and that the master branch is always supposed to be stable.

Would either of you be opposed if I opened up an MR for updating some of the documentation from what I have learned?

This is a separate question for clarification that I couldn't really understand from the docs, specifically about dangers of running full emulation:

If I am running EMBA with full emulation, which components of my setup have potential to be harmed?

Example setup:

• A server where sudo ./installer.sh -d has been ran inside an up to date EMBA repo on master branch.

User calls EMBA with:

• sudo ./emba -l ./logs -f ./firmware -p ./scan-profiles/default-scan-emulation.emba

Which would be in danger of being harmed, the server (host?), the network the server is hosted on, and/or the docker image that EMBA is running inside of?

From the docs it seems like the server (host?) is in danger of being harmed, but I am not sure why that is the case if the docker image is the one executing EMBA and doing the pentesting. If anyone is able to explain, I would like to add a version of that explanation into the docs.

from emba.

This was it, I figured that the tagged versions were what should be used like "stable" releases, but didn't realize that since there is just the one tag of the docker image that the master branch should probably always be used, and that the master branch is always supposed to be stable.

Would either of you be opposed if I opened up an MR for updating some of the documentation from what I have learned?

Does it work to open a PR for the Wiki? If so, please do it.

This is a separate question for clarification that I couldn't really understand from the docs, specifically about dangers of running full emulation:

If I am running EMBA with full emulation, which components of my setup have potential to be harmed?

Which would be in danger of being harmed, the server (host?), the network the server is hosted on, and/or the docker image that EMBA is running inside of?

From the docs it seems like the server (host?) is in danger of being harmed, but I am not sure why that is the case if the docker image is the one executing EMBA and doing the pentesting. If anyone is able to explain, I would like to add a version of that explanation into the docs.

The EMBA docker container is mostly read-only, the network (which is currently used for CVE-search) is isolated and the container is destroyed after execution. Nevertheless, the container is running in privileged mode and ...

... we have two emulation environments available in EMBA:

• 1st: User-mode emulation is primarly used for improving the SBOM, vulnerability and exploit detection. In this mode you are directly running untrusted code from the firmware in the docker container (within a chroot user-mode qemu). This could result in a breakout of the chroot, compromise of the container, escape from the container or attack your report and finally as a worst case szenario your host.
• 2nd: System-mode emulation is used to boot the complete firmware in qemu. which is also untrusted and can be used to perform further attacks in the qemu environment. Again, as worst case szenario an attacker could use a manipulated firmware to perform further attacks.

from emba.