Crouching Tiger, Hidden User-SID-in-Registry…

I was poking around my Windows 10 registry and stumbled across an “account unknown” SID – which immediately triggered my “hack alert” (not to mention my OCD)…

I traced this inherited permission up to registry root – which got me really worried

I was about to just “try and clean it up” (e.g. search the entire registry for the same SID and delete it if no such value, i.e. reference, was found), but decided to quickly search the ‘net while waiting for regedit to complete the full tree search when I stumbled upon this.

TLDR: Don’t blindly delete any unknown SIDs…

<RANT> Trust Microsoft to do something stupid like this, all in the name of attempting to “hide” or obfuscate their spying (in the case of this specific SID “S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681” in question); I mean, why would Edge, one piece of software requiring outbound network connectivity, need to have read permissions of the entire freakin’ registry?!?). This looks like one massive data leak/breach (via an Edge exploit) waiting to happen.</RANT>

Clamping Down HARD on DHCPd MACs…

There is an eight year old issue (at the point of writing this) with pfSense DHCPd that somehow did not restrict DHCPd IP “handouts” despite the chosen setting to “Deny unknown clients”… Which, after some digging, turns out more to be of a misunderstanding than what the “common people” would think.

Despite the “Deny unknown clients” setting, certain clients requesting an IP from a pool/interface that does not explicitly list its MAC address will still get an IP address. It turns out that said client is considered “known” if the MAC is listed anywhere else (i.e. in some other MAC address list)…

Anyway, I got fed up with this seemingly insecure behaviour and managed to hack a fix… some 8+ months ago… Just that I never got around to posting the details for people willing to hack their own pfSense fix (unlike my other SSHd configuration fix which was documented in full)…

Well, to cut the long story short, the pull request (merged with another upstream fix) has now been accepted and merged (actual changes)… You will see this fix some-time-soon-now in some upcoming pfSense release… Enjoy!

2021/02/28 Update: A year later and only now is the DHCPd fixes released with a new stable release (2.5.0), instead of the expected 2.4.x! Well, it’s “finally out there”…

2021/06/01 Update: As of time of writing, it appears that 2.5.0 and 2.5.1 are, unfortunately, bugged and I do not recommend upgrading to 2.5.0/2.5.1…

2021/07/07 Update: pfSense 2.5.2 is now released… YMMV…

GNU getopt Needs A Helper

So, recently at work, I found myself knee deep in… scripts…

Most of my scripts had ugly positional parameters/arguments (you know, $1 was the value for this, $2 was the input for that)… So, I dug up getopt… But then I quickly spiralled down the time-sucking rabbit hole of trying to automate some other bits, like being able to print the “usage” by “simply” plucking out all the options given to getopt in the first place…

Continue reading

Securing pfSense SSH2…

So, as exposing the HTTPS administration page of pfSense to the big, bad, Internet is a big “no no”, the only proper way should be to set up SSH2 and allow port forwarding.

Now, there are already articles out there telling you that using username+passwords to secure SSH2 is not the way to go… Using certificates is. However, I wanted more… I wanted both… Why is it that pfSense will only allow one or the other when sshd already allows enforcement of both?

So, once again, rolling up my sleeves, I dived into the murky waters of the pfSense shell…

Continue reading