Project Description
FIDO2 is set of specifications for multi-factor authentication. It is based on asymmetric cryptography with secrets stored in a HW token. The token must support the protocol to be usable. I own Nitrokey Start which is fundamentally similar but it speaks a different protocol (of GPG smart cards). I'm curious whether the device can serve as FIDO2 token too.
Goal for this Hackweek
There will be likely lots of impedance to match. Ideally, the secrets should never live out of the GPG smart card, however, I'm not sure if the signing protocols are compatible. (To study this is also a goal.) An alternative would be to use an established password manager (e.g. pass) and emulate the FIDO2 token in software with access to secrets in the password manager. The intention is to be able to authenticate via browser against a WebAuthn (web) service.
The goal is not to provide a more secure solution than real HW FIDO2 token.
Resources
Looking for hackers with the skills:
This project is part of:
Hack Week 21
Activity
Comments
-
over 2 years ago by jzerebecki | Reply
There are fido2 implementations for various stm32 boards, like the nitrokey start is one. But sadly I know of none that combine a fido2 and gpg implementation, though it is theoretically possible. E.g. https://github.com/solokeys/solo1 and there is also one in rust https://github.com/google/OpenSK
If you can't get your hardware key to cooperate with the fido2 protocol, then there are fido2 implementations using the tpm2 most laptops have available. E.g. https://github.com/psanford/tpm-fido
-
over 2 years ago by mkoutny | Reply
Report after Hackweek
- I started decomposition by studying FF
- the most important part is implemented in authenticator-rs
- later I found related projects
- https://github.com/ellerh/softfido
- https://blog.hansenpartnership.com/webauthn-in-linux-with-a-tpm-via-the-hid-gadget/ (Git repo)
- I've used the latter as a base for my experiment
- I decided to use GPGME library to interact with GPG (it's as convenient to use as gpg itself :-/)
- https://github.com/seiyak/GPGME-sample-code proved more useful that docs
- I manually generated nistp256 GPG subkey with Authenticate capability to honor U2F specification (that's predecessor of FIDO2 that allows only this particular signing algo)
- I suspect upstream kernel has inconsistent config definitions to build USB gadget for Tumbleweed, I applied following patch locally:
``` --- a/drivers/usb/gadget/udc/Kconfig +++ b/drivers/usb/gadget/udc/Kconfig @@ -471,7 +471,7 @@ source "drivers/usb/gadget/udc/aspeed-vhub/Kconfig"
config USBDUMMYHCD tristate "Dummy HCD (DEVELOPMENT)" - depends on USB=y || (USB=m && USBGADGET=m) + depends on USB=y || (USB=m && USBGADGET=y) help This host controller driver emulates USB, looping all data transfer requests back to a USB "gadget driver" in the same host. The host ``` - my quickly hacked program was able to register (aka provide public key) against https://webauthn.io/ but it's not able to authenticate (aka sign challenges) - my joy was stopped by RFC4880 that defines GPG signatures as follows (highlight mine):
> The concatenation of the data being signed and the signature data > from the version number through the hashed subpacket data (inclusive) > is hashed. The resulting hash value is what is signed.
- that's where I stopped but I realize
ssh-keygen -Y sign ...is the way forward (preferred to low-level communications with ssh-agent)- the point is that gpg-agent can act as ssh-agent too
- the goal of this project should be achieved with the ssh-agent detour
- I started decomposition by studying FF
Similar Projects
Migrate from Docker to Podman by tjyrinki_suse
Description
I'd like to continue my former work on containerization of several domains on a single server by changing from Docker containers to Podman containers. That will need an OS upgrade as well as Podman is not available in that old server version.
Goals
- Update OS.
- Migrate from Docker to Podman.
- Keep everything functional, including the existing "meanwhile done" additional Docker container that is actually being used already.
- Keep everything at least as secure as currently. One of the reasons of having the containers is to isolate risks related to services open to public Internet.
- Try to enable the Podman use in production.
- At minimum, learn about all of these topics.
- Optionally, improve Ansible side of things as well...
Resources
A search engine is one's friend. Migrating from Docker to Podman, and from docker-compose to podman-compose.
CVE portal for SUSE Rancher products by gmacedo
Description
Currently it's a bit difficult for users to quickly see the list of CVEs affecting images in Rancher, RKE2, Harvester and Longhorn releases. Users need to individually look for each CVE in the SUSE CVE database page - https://www.suse.com/security/cve/ . This is not optimal, because those CVE pages are a bit hard to read and contain data for all SLE and BCI products too, making it difficult to easily see only the CVEs affecting the latest release of Rancher, for example. We understand that certain costumers are only looking for CVE data for Rancher and not SLE or BCI.
Goals
The objective is to create a simple to read and navigate page that contains only CVE data related to Rancher, RKE2, Harvester and Longhorn, where it's easy to search by a CVE ID, an image name or a release version. The page should also provide the raw data as an exportable CSV file.
It must be an MVP with the minimal amount of effort/time invested, but still providing great value to our users and saving the wasted time that the Rancher Security team needs to spend by manually sharing such data. It might not be long lived, as it can be replaced in 2-3 years with a better SUSE wide solution.
Resources
- The page must be simple and easy to read.
- The UI/UX must be as straightforward as possible with minimal visual noise.
- The content must be created automatically from the raw data that we already have internally.
- It must be updated automatically on a daily basis and on ad-hoc runs (when needed).
- The CVE status must be aligned with VEX.
- The raw data must be exportable as CSV file.
- Ideally it will be written in Go or pure Shell script with basic HTML and no external dependencies in CSS or JS.
VulnHeap by r1chard-lyu
Description
The VulnHeap project is dedicated to the in-depth analysis and exploitation of vulnerabilities within heap memory management. It focuses on understanding the intricate workflow of heap allocation, chunk structures, and bin management, which are essential to identifying and mitigating security risks.
Goals
- Familiarize with heap
- Heap workflow
- Chunk and bin structure
- Vulnerabilities
- Vulnerability
- Use after free (UAF)
- Heap overflow
- Double free
- Use Docker to create a vulnerable environment and apply techniques to exploit it
Resources
- https://heap-exploitation.dhavalkapil.com/divingintoglibc_heap
- https://raw.githubusercontent.com/cloudburst/libheap/master/heap.png
- https://github.com/shellphish/how2heap?tab=readme-ov-file
OIDC Loginproxy by toe
Description
Reverse proxies can be a useful option to separate authentication logic from application logic. SUSE and openSUSE use "loginproxies" as an authentication layer in front of several services.
Currently, loginproxies exist which support LDAP authentication or SAML authentication.
Goals
The goal of this Hack Week project is, to create another loginproxy which supports OpenID Connect authentication which can then act as a drop-in replacement for the existing LDAP or SAML loginproxies.
Testing is intended to focus on the integration with OIDC IDPs from Okta, KanIDM and Authentik.
Resources
Contributing to Linux Kernel security by pperego
Description
A couple of weeks ago, I found this blog post by Gustavo Silva, a Linux Kernel contributor.
I always strived to start again into hacking the Linux Kernel, so I asked Coverity scan dashboard access and I want to contribute to Linux Kernel by fixing some minor issues.
I want also to create a Linux Kernel fuzzing lab using qemu and syzkaller
Goals
- Fix at least 2 security bugs
- Create the fuzzing lab and having it running
The story so far
- Day 1: setting up a virtual machine for kernel development using Tumbleweed. Reading a lot of documentation, taking confidence with Coverity dashboard and with procedures to submit a kernel patch
- Day 2: I read really a lot of documentation and I triaged some findings on Coverity SAST dashboard. I have to confirm that SAST tool are great false positives generator, even for low hanging fruits.
- Day 3: Working on trivial changes after I read this blog post:
https://www.toblux.com/posts/2024/02/linux-kernel-patches.html. I have to take confidence
with the patch preparation and submit process yet.
- First trivial patch sent: using strtruefalse() macro instead of hard-coded strings in a staging driver for a lcd display
- Fix for a dereference before null check issue discovered by Coverity (CID 1601566) https://scan7.scan.coverity.com/#/project-view/52110/11354?selectedIssue=1601566
- Day 4: Triaging more issues found by Coverity.
- The patch for CID 1601566 was refused. The check against the NULL pointer was pointless so I prepared a version 2 of the patch removing the check.
- Fixed another dereference before NULL check in iwlmvmparsewowlaninfo_notif() routine (CID 1601547). This one was already submitted by another kernel hacker :(
- Day 5: Wrapping up. I had to do some minor rework on patch for CID 1601566. I found a stalker bothering me in private emails and people I interacted with me, advised he is a well known bothering person. Markus Elfring for the record.
Wrapping up: being back doing kernel hacking is amazing and I don't want to stop it. My battery pack is completely drained but changing the scope gave me a great twist and I really want to feel this energy not doing a single task for months.
I failed in setting up a fuzzing lab but I was too optimistic for the patch submission process.
The patches