The preface of the disclosure of CVE-2018-16225 (https://blog.francescoservida.ch/2018/09/16/cve-2018-16225-public-disclosure-qbee-camera-vulnerability/) contained a little lie: I did not find one vulnerability during the research for my master thesis, but four, three of which were still being patched by the vendor/under the 90 days disclosure timeframe given to the vendor. Continue reading “[CVE-2018-16222 to 16225] Multiple Vulnerabilities in QBee and iSmartAlarm Products”
Last week I had a simple idea, upgrade a xiaomi openwrt router to a whitebox running esxi, vyos and a couple other applications.
My current homelab setup was a site-to-site using Wireguard between the openwrt router and a USG3 with DHCP relayed from the remote (openwrt) site to the main site’s DCs, both sites are behind NAT (thanks to ISP routers without bridging -_- ) and thus wireguard is the best choice.
Checking vyos doc, wireguard is present, vyos has a dhcp-relay functionality. All good, should be as easy as installing vyos and configuring everything, right? Riiight?
Well no… apparently vyos uses ISC-DHCP-Relay (and server), and there is a known issue with virtual tunnels and the interfaces dhcp-relay can associate with: https://phabricator.vyos.net/T4280
Doh’, what to do?
Let’s switch to IPSec-VTI, maybe IPSec is better supported and it is a bug with Wireguard.
Hours later, the IPSec-VTI tunnel was up between the two sites (not pertinent for this guide, if you are configuring it between to routers behind NAT, play around with the “authentication remote-id” and “authentication id” options so that the IKE and IPSEC SA work).
Let’s change the interface the the vti one andddddddd nothing. SAME ERROR!
Ok, not possible that no-one had this error before, let’s scavenge the ISC repo, and maybe look at alternative free routers…
So, apparently pfsense and opnsense have the same problem and actually hide the WG interfaces instead of actually trying to patch the problem. Thanks…
However a couple people on the pfsense and ISC repo posted patches supposedly to make it work with tunnels, althouth none were integrated.
Fine, let’s compile and test the package manually.
Nothing, the error is always there, given the high “interface type” number I imagine it is combined with some VyOS weirdness.
At this point I spent too much time to just give up, although I did want to move a DC to the remote site and have local dhcp I did not want to lose the ability to have a remote DHCP backup in case I had to do maintenance.
Some googling afterward, Eureka! there is a package that does only dhcp relaying: dhcp-helper. Although it cannot run at the same time as ISC (obviously the listen port is the same), I can just drop all DHCP server functions on the router and handle all VLANs from the DHCP server on DC.
Luckily VyOS has an easy option to configure additional packages when building an image:
./configure –custom-package PACKAGENAME
It doesn’t work! For some reason in my build environment (docker vyos-build pulled from docker hub) I have to run
python3 scripts/build-config –custom-package PACKAGENAME
in order for the options to work. Anyway, easy fix.
Let’s add “dhcp-helper” and try to configure it somehow with boot scripts afterward. Easy right now? riiight?
Not even. dhcp-helper declares isc-dhcp-server and isc-dhcp-relay as conflict in the .deb configuration. So vyos-build tries to install it, cannot install isc-dhcp* and fails with dependency errors.
This is were the hacked way starts…
In desperation I decide that surely the conflicts of a deb package can be edited.
- I download the latest deb for amd64 of dhcp-helper.
- unpack the deb:
- dpkg-deb -b tmp_dhcp/ dhcp-helper_1.2-2_amd64.deb
- edit the tmp_dhcp/DEBIAN/control
- to remove the conflicting packages
- to rename the package to dhcp-helper-vyos, isc-dhcp-server and relay also have a conflicting option set which would stop this package from being installed.
- edit tmp_dhcp/etc/default/dhcp-helper
- to already match my configuration, maybe it will be easier to configure, notably in server mode (-s) and only excluding (-e) the WAN interface, this way it will listen on everything else and would not need much configuration changes.
- repack the deb:
- dpkg-deb -b tmp_dhcp/ dhcp-helper-vyos_1.2-2_amd64_noconflicts.deb
At this point, I follow vyos documentation and put the package in the “./packages” folder, rerun the build, attach the iso to a VM andddd nothing… apparently something is wrong and the .deb is not picked up… maybe only .deb files of declared packages can be used…
The last hope at this point is to host my own repository, add the package and use the custom-package option at build time with my custom package name. It was the last option before abandoning the project anddd… it worked!
I put the package in a new folder, followed this guide to create the required files:
- dpkg-scanpackages . /dev/null > Release
- dpkg-scanpackages . /dev/null | gzip -9c > Packages.gz
and uploaded the three files to my static server under the /debian path.
- python3 scripts/build-config –custom-package “dhcp-helper-vyos” –custom-apt-entry “deb [trusted=yes] https://STATIC_SERVER/debian/ ./”
- sudo make iso
Finally, too many hours later this is solved!
I’d juste hope that this is fixed upstream someway, by fixing ISC (but the relay is EOL) or by including both packages and leaving the option to fully disable ISC and just use dhcp-helper for the relay.
If you decide to go this route ensure you “delete service dhcp server” and “delete service dhcp relay” before enabling dhcp-helper or else it will not work.
Well that’s it for the story! (and for my doc, in case I ever need to update vyos),
During the research for my master thesis on IoT forensics: “Internet of Things: Traces, Vulnerabilities and Forensic Challenges” (more about it in the future), I found one vulnerability in the QBee Multisensor Camera (https://qbeecam.com/).
It’s been a while since i started playing with Hyper-V and even more since I was introduced to the virtualization world.
I started around 8 years back when i wanted to give a second try to the Linux world but without risking destroying the main partition of a production laptop while installing the system (To my past self: Use the whole disk means “The WHOLE disk”). Thanks to VirtualBox I managed to get Linux installed and get immersed in that new world. Since then i installed, reinstalled, rereinstalled etc… plenty of different distros, from Ubuntu to Kali to the forensics oriented CAINE Continue reading “Homelabbing with Hyper-V (Part 1) – HandsOn”
Ho letto oggi il comunicato del SISA sul cambiamento degli orari dei treni in vigore dall’11.12.’16, in seguito all’apertura di alptransit.
Ho quindi scritto direttamente al SISA chiedendo chiarimenti, e riporto qui di seguito le riflessioni fatte nella mail a loro indirizzata.
Continue reading “Apertura Alptransit – Un problema per gli studenti ticinesi… ma anche no.”
I decided to start this blog with my last creation: a water rocket launcher powered by a RaspberryPi.
It’s been a few years by now that I’m experimenting with water rockets; following tutorials from this cool Italian website and from the website of the Australian’s Air Command Water Rockets i initiated myself to this really cool summer hobby.