Steam on QubesOS (Debian 12 Bookworm)

Just wanted to play ThreatGen Red vs Blue and figured I’d update my template, so here goes:

In dom0:

sudo qvm-template install debian-12

In Qube Manager clone the debian-12 to a “debian-12-Steam” template and give it plenty of storage and memory:

Initial memory 4000MB
Max Memory 16000MB
System storage max size: 50GB (depending on what games you play)

Install steam in this qubes following the guide here: /https://itslinuxfoss.com/install-steam-debian-12/

Start steam for the first time in the template to finish the install.

Create AppVM Qube with enough memory and disk also:

Then run steam and the background is completely white and you have to move the mouse up in the left corner of the white area and select settings:

Then move down and select “interface” and deselect everything regarding graphics acceleration:

That’s it. Install ThreatGen :

If you want to install the game in the template, don’t install it here, but there 🙂

Enjoy

Huawei MateView on QubesOS

If your display is configured @ 3840 x 2160, then you might not be satisfied with the lack of 1.5 million pixels on the screen or the occasional blinking /blacking of the screen

Go to Dom0 and write:

cvt 3840 2560 30

xrandr –newmode <output after modeline >

xrandr –addmode DP-1 –mode 3840x2560_30.00

xrandr –output DP-1 –mode 3840x2560_30.00

If you are using HDMI-1 instead of DP-1 us that. Check with following command

xrandr <enter>

TryHackMe on QubesOS Kali AppVM

unman has provided templates for Kali-enthusiasts to QubesOS (v. 4.1 only) and you need to enable the repository in /etc/qubes/repo-templates/qubes-templates.repo. The mentioned command using “enable-repo …” mentioned in the forum did not work for me, so I had to edit the 1 directly in the file 🙂

Edit the repo-file:

Install the template:

Then I created an AppVM based on the Kali template and vupti, everything works perfectly.

That is except for reverse shell 🙂

I had an issue with reverse shell’s not working on Qubes Kali AppVM, due to firewall restrictions even though I disabled the firewall following these instructions(Spoiler:NOT working in Qubes AppVM).

I got no SYN-ACK to my SYN’s, and with the firewall “disabled” I tried searching elsewhere for answers. It turned out that disabling the local firewall in Kali is not enough and I am afraid to mess up security by following the guides incorrectly.

To resolve the issue, clean out the firewall rules on the local AppVM (or template VM for persistance):

──(root💀kali-max)-[~]
└─# iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT
iptables -t nat -F
iptables -t mangle -F
iptables -F
iptables -X

┌──(root💀kali-max)-[~]
└─# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

┌──(root💀kali-max)-[~]
└─# 

This can be done in a more optimal way opening up only for the specific endpoints/IP-range’s from TryHackMe, but this just gets your reverse shells working right now.

The other, safer way, that works (if there is no inbound firewall on target host), is to change the payload in metasploit from reverse_tcp to bind_tcp with a sample:

set PAYLOAD payload/linux/x86/meterpreter/bind_tcp

Enjoy

Qubes 4.1rc3 on Intel NUC10i7FNK

BXNUCi7FNK2 with 1TB NVMe, 64GB memory and 4K monitor support

I did this once before on Qubes 4.0 with help From Frédéric Pierret, but left Qubes on my NUC for Xubuntu due to too many issues with hardware. Intel NUC is not overly Linux friendly friendly. Microsoft is their primary focus.

Then today(of all days) I snuck an install of the promising Qubes 4.1rc3 on the box, and if started with a single error during final install [Start failed: internal error: Unable to reset PCI device 0000:00:1f.6: no FLR, PM reset or bus reset available, see /var/log/libvirt/libxl/libxl-driver.log for details”:

No networking was available upon startup. Disabling the PCI device in question [00:1f.6 Ethernet Controller….] in sys-net, made booting of sys-net possible and luckily wifi worked out-of-the-box.

Hope the above solution might help others in same situation.

Hardening websites with .htaccess

Always use latest php available from your hosting provider:

AddType application/x-httpd-php-latest .php

Using mod_rewrite:

<IfModule mod_rewrite.c>

RewriteEngine On

#Redirect HTTP to HTTPS:
RewriteCond %{HTTPS} off

RewriteRule (.) https://%{HTTP_HOST}%{REQUEST_URI}

#Disable compression:

RewriteRule ^(.)$ $1 [NS,E=no-gzip:1,E=dont-vary:1]

</IfModule>

Strict HSTS, CSP, XSFR headers:

<IfModule mod_headers.c>

Header set Content-Security-Policy "upgrade-insecure-requests"

Header set Referrer-Policy "strict-origin-when-cross-origin"

Header set Strict-Transport-Security "max-age=15811200"

Header set X-Frame-Options "DENY"

</IfModule>

Xubuntu and KeePassXC with no browserintegration (snap crap)

Having trouble connecting from browser on a freshly installed Xubuntu. My browser extensions in Firefox acted up. All because of snap is crap (in this regard anyways)

KeePassXC when installed in Xubuntu, uses “snap” and therefore the browser integration does not work. It has to go.

Remove the snap
Install the real thing. (Either by PPA for newest versions or normally with standard repositories.
The browser selection window is not visible in the snap version… but they are here. Enjoy.

Skype for Linux – unsigned – breaking template updates

Package skypeforlinux_8.62.0.83-1.x86_64.rpm is not signed

My daily patching of my Qubes fedora-32 template failed, and I just found our that Skype might be the reason. I tried starting skype, and found it to be requiring of an update:

Update, pretty please…

This proved faulty, since Microsoft might have given up on Skype, their last update was unsigned and broke updates on one of my fedora-32 templates.

Has the trainee Linux enthusiast been responsible for the full delivery?

Then I tried forcing the install, since I trusted the package origin, but I saw that the quality of the package might be below par(it does work, though), so I chose to part with Skype for now:

Updating / installing…
1:skypeforlinux-8.62.0.83-1 ################################# [100%]
Redirecting to /bin/systemctl start atd.service
Failed to start atd.service: Unit atd.service not found.

Goodbye Skype. Maybe we will meet again some day out of nostalgia alone.

Remember to remove the repo also, if you really mean it 🙂

/etc/yum.repos.d/skype-stable.repo

KeePassXC risk analysis based setup on fedora-30

Goal: If a new security vulnerability is found in KeePassXC(eg. 0-day), I would like to ensure the fastest possible update, risking the possibility of not being able to use the application.

By updating from an unstable repository, this can, of course, also introduce vulnerabilities, that has just not been detected yet.

I have decided to rather patch known vulnerabilities, using software with potential unknown vulnerabilities, rather than having unpatched known vulnerabilities. That is basically my risk analysis.

Also, if the application fails and is unusable, it might still be better using “forgot password” features, than using a piece of known insecure software. Depends on who you are, and what level you are comfortable with. Every decision needs to be risk based and subjective to the risk taker.

So, lets solely, enable KeePassXC packages, getting updates from a more unstable branch. Put this in your fedora-30 /etc/yum.repos.d/fedora-updates-testing.repo end of first paragraph:

adding “includepkgs=keepassxc”

This should be called the frog/rabbit method, since we are litterally jumping ahead of ourselves, just as the remark from Quentin Tarantino in “Four Rooms” movie, states.

And I need ALL testing packages, that actually works, ending up in stable. That’s a premise.

UPDATE: As Samuel Sieb described, it is important to have “–disableexcludes” on the commandline, every time you need to update a package from the testing repository. I just experienced, I could not update the 0-day emergency patch from mozilla to firefox, due to this.

SOLUTION: [user@fedora-30 yum.repos.d]$ sudo dnf upgrade –enablerepo=updates-testing –disableexcludes=updates-testing –advisory=FEDORA-2020-2713adc57f