Or... the Department of Warmongers (nee DoD) addresses on the device are evidence of a supply-side attack targeting the DoW and carried out using the aforementioned github admin token.
... I mean, while we're in here speculating about truffles and all.
I have looked around before but I only found genuinely dev-oriented kits that weren't even in a shell, and crazy priced.
edit: seems there are some options now (or I missed them before), e.g. https://www.goodcam.io/#for-independent-developers
You can curse the storm, but the wind will come.
Least you can do.
With many IoT type things I block access to the public internet. I think with cameras specifically a lot of people even set it up physically on a different network that can only talk to the NVR.
But tldr, basing the cameras on IP invites some of the things in this article. Anyone deploying these devices needs to think about securing them.
Add a skill to your repo that does some basic checks at least, not that hard
The Canadian Navy very recently made a major choice and agreed with you
https://www.google.com/search?client=firefox-b-d&q=hanwha+oc...
Some cameras do support thingino, so you can override their firmware. Then there's this: https://openipc.org/supported-hardware/featured
There are tons of ONVIF-compliant and cheap PoE cameras, and with this setup you really don't care about the security of the manufacturer firmware since you aren't exposing them to the network publicly. However, you do need to be extra diligent when configuring your VLAN/network segmentation.
Was the website's security based on MAC, which presumably is supplied by the client? If so, I guess.. typical IoT.
You could fix this by adding an exception to the CSS rule so it skips links starting with your site's name:
a[href*="://"]:not([href^="https://hhh.hn"])::after> Stránka nenalezena
> There's been a glitch...
> We're not quite sure what went wrong. You can go back, or try looking on our homepage.
n.b., it's the Department of Defense, just like the Kennedy Center doesn't have Trump's name attached, and the large body of water by Texas is the Gulf of Mexico.
I feel like every security blog (or even just tech blog) I've read recently has had paragraphs and paragraphs of largely LLM generated explainer waffle. This felt refreshingly focused and to the point.
and while i currently don't hate china as much as i do US rn (because canadian; sorry) i can also say -- due to being an aforementioned leaflandian -- that due to very personal experience i have zero faith in anything from china that has the ability to connect to any type of network :')
And so yeah at this point if I can't at the very least get a whatever-wrt firmware (preferably a proper linux distro nowadays; not to say the *-wrt firmwares aren't a real OS but, y'know) on the device i just avoid them entirely since, well... it's all i can do at this point because even if there were baked in hardware-based backdoors i as an individual can't do much more than that.
IPs having a global distinction between public/private is a convention, but local routing can widely differ.
Same with the "China Cyberattacks" - the guys sitting on top of my outgoing fiber can simulate any IP address they want to me.
You know, I'm not sure I can explain how I feel about this properly without waving the shotgun around.
22.0.0.0/8 - it's basically free real estate!
That said, I've done some consulting work on shopify stores, and I wouldn't be shocked at all to see something like that at all. The bar for code quality that a lot of low end consultants/designers deliver is just abysmal.
Anyone who cares about security will be using App Attest or the Google store equivalent.
Short story: buy one cheap dongle on Amazon, dump the MAC (00:11:22:AA:BB:CC IIRC; it's been 15 years since I cared) and you have auth to all of the apps everywhere.
Reminder: the Bluetooth logo comes, mostly, from self-certification.
192.0.0.0/24, 10/8, 172.16/12, and various other subslices of 192/8 are reserved for local use and are not publicly routable.
On the shotgun, or adjacent, I do tend to prefer ammo classes for my nets... 10.22.x.y, where x may be 1, 38, 45, etc. Allows for site to site vpn with friends/family a bit easier to remember.
If you're gonna do that, though, it's better if you use fd00:... or one of the other assigned ranges so it's still in the standard range. OSes use this as a heuristic for source address selection.
Why? I rarely have security objectives where remote attention would help, and it has a huge impact on user freedom. For B2C attestation is just an evil captcha.
I have something hilarious to tell you about IoT apps
*almost, I have two things that need an app. My Vaillant boiler and my Yale alarm system. Both apps are terrible, but I have a 10 year warranty on the boiler and my alarm is up to scratch from a home insurance point of view.**
Entirely without LLMs, I'm imagining an office of North Korean compsci graduates doing astonishingly tedious tasks, for whom an office job on a basic Linux computer and slightly better diet and nice apartment put them in the top 1-2% of living standard in the country.
Tech enthusiasts: My entire house is smart.
Tech workers: The only piece of technology in my house is a printer and I keep a gun next to it so I can shoot it if it makes a noise I don’t recognize
Internally they're all Bluetooth to serial chips, and another pic16xxxx chip which does serial to canbus.
I guess the Bluetooth serial chips probably have programmable Mac addresses, but equally they normally ship with a globally default one unless you flash a different one onto it.
Old thin clients are typically in the same hardware class, and probably cheaper by the time you add the exploding MSRP of a Pi, and a PSU, and a case and heatsink, and maybe some storage that doesn't suck ass. But if you already own the Pi, yeah, go for it.
(Yes ok, RSA4096 is technically a matter of cost, you just need an infinite amount of money)
But one of our vendor networks uses 10.32.x.x/32 for various radio gateways, and the radios themselves all locally expose (this is where I give away too big a clue as to what I do) 10.0.0.101 as a management address that emits important link status data.
So you can imagine what a godawful bùrach everyone's routing tables are.
Just to chime in agreeing with sibling comments, the issue is when it's not about just your house and you're deep into self-hosted stuff with a lot of different properties and businesses other people's houses all sharing resources. Without a lot of coordination and consideration, which in practice doesn't really happen easily given the adhoc nature such things tend to organically develop out of, and all the random stuff that wants specific addresses at least for setup, it actually gets pretty easy to run into collisions. Allocations typically are definitely inefficient in many respects but also made sense in the context they were first done and of course can be a certain amount of effort to change.
In an ideal world I sorta feel like "IPv6" should have been more along the lines of <12 octet prefix>:<IPv4>, everyone gets a prefix or set of prefixes that they actually own and are consistent worldwide, or at least only change when geographic location changes, and then can just have the entire 32-bit IPv4 space for LAN however they want. Then you only have to care about prefix between LANs and it could all be extremely automated, internally you only need to use something that looks like IPv4 with the network hardware transparently able to handle prefixes for WAN. Backwards compatibility story would be a lot more straight forward too. Oh well.
@kotaKat: that's a great idea and I don't know why I forgot I played with that like 15 years ago. Really handy as a backup space that almost certainly won't collide with any commercial hardware at least.
Also, just in case this comment isn't pedantic enough, 10.22 would be a firearm range, not an ammo range. And AFAIK they only ever chambered that for .22 rimfire cartridges. ;)
Google's DNS worked fine, but Cloudflare's didn't. No idea if they ever fixed it... I'm using it as a backup for my main connection, eventually I'll setup autofailover on my router (OpnSense). For now, I just swap the cables.
I'm not familiar with IPv6's details, could you elaborate on this? To me, this reads like you're saying that IPv6 solves the problem by having low adoption rates rather than an actual function of the protocol.
Vailant boiler - I wonder if there's a debug interface you can use. Not knowing specifics of your model, i foudn this: https://github.com/jayme-github/esphome_vaillant
Codex can help probably further heh.
i have been thinking a bit more about security cameras again, because of AXIS starting to push more for every one of their cameras to be able to easily run linux applications on them, they're far more serious targets in an enterprise environment and need to be managed as such for vulnerabilities and credential management etc. someone brought up to me a company that sounded new to me, Hanwha (Vision.) I took a look at the site, and found that they had accessible firmware blobs for each model of camera, which is always a treat.
i took the image and threw it at binwalk hoping it was just a rootfs or something, but inside there was a separate tarball with some AI stuff for the camera and a fwimage.tgz that binwalk was flagging as encrypted.
I was googling around and saw that Matt Brown has a writeup on these cameras that got me through. basically the passphrase is HTW + the model number so HTWXNP-9300RW worked.
seems like they do some more stuff now, because inside of that tarball was another fwimage.tgz that was encrypted but it wasn't the same scheme, so we can't just re-use the same setup from Matt Brown. I kinda figured I was gonna have to give up and that Hanwha was doing something more advanced, like burning a key into the hardware (which isnt foolproof obviously but you at least need to own the camera to start.) Anyways, there was a fwupgrader binary that was in that outer tarball, so I threw it into ghidra and started poking around.
well I would have been poking around if it was 2023 or something, but i pointed claude code at it and went to make a lovely dinner and spent time with my partner instead, and came back a bit later to a description and a nice rootfs.
Hanwha had built some obfuscation into the fwupgrader to hide how they decrypt the actual rootfs. the AES key is XOR'd against a small static key table in the binary and reassembled at runtime ( the IV is just plaintext in there) the fwupgrader just shells out to the openssl CLI, and even the command fragments are XOR-obfuscated the same way.
reconstructed the command looks like this:
openssl enc -md sha256 -aes-256-cbc -d \
-K <KEY> -iv <IV> -in <INPUT> -out <OUTPUT>
Since the key and iv are just hardcoded (the same across the model line), I will publish them here:
KEY = dfa049bb922e63e2decc764af5628068e5b7a2662e479a615b14643e567579b0
IV = 53f926801b81454a4f889c9a390db6e6
and with that we have a full rootfs to dig into normally.
since we finally can just look at stuff I ran trufflehog immediately to see if there was anything obvious, and there was a github token duplicated in like 30 files... I checked what repos the token had access to, and it had admin privileges to hundreds of repositories in their github organization.
this isn't my first rodeo with an org shipping a Github token in their firmware though... but that's a story for a different blog post. Why would this org put this token in like 30 files though? it looks like they build the UI for these cameras with vite, and one of the variables is being set to the entirety of process.env at build time, which means the entirety of the CI job's environment is being written to these files.
var W = {
DATAPORT: "9090",
GIT_LFS_SKIP_SMUDGE: "1",
npm_command: "run-script",
KUBERNETES_SERVICE_PORT_HTTPS: "443",
GITHUB_NPM_TOKEN: "<snip>:ghp_…REDACTED…",
npm_config_userconfig: "/home/docker/.npmrc",
// etc
I don't have any of these cameras to test, but I think this would mean that anyone accessing the admin ui of these cameras likely has had this github token sent to them over the wire and (hopefully) nobody evil noticed. Maybe it didn't get actually served and just lived on disk, though.
there were some other... interesting bits of data in the environment though: there were some env vars with IP addresses in them, but they are assigned to the US Department of Defense:
huh... is this just a coincidence and one of those weird instances where people have taken IP space for internal services when they know they will never interact with it (insane practice btw...) or is Hanwha more directly tied with the US DoD?
let's look at the wikipedia page for Hanwha Vision:
Hanwha Vision (Korean: 한화비전), founded as Samsung Techwin, is a video surveillance company. It is a subsidiary of Hanwha Group.
Former products
K9 Thunder self-propelled artillery, K10 ammunition resupply vehicles, sub-systems for K2 Black Panther, sentry gun robot SGR-A1.
oh... okay.... I remember reading about the SGR-A1 when I was in high school, but I never thought I would be accidentally finding keys to the kingdom of the manufacturer on the ground later in my career... my life is kinda weird sometimes...
even still, these aren't American devices, or anything like that. Why would Hanwha Vision need anything remotely related to the DoD? Is it possible that their CI is provided by some centralized team at their parent company Hanwha, where the needs of their sister company Hanwha Aerospace cause the shared platform to have these entries in the CI environment variables? Or maybe because of their other sister company, Hanwha Defense USA, where they make other large scary steel machines
![]()
I wanted to make sure this wasn't some kind of fluke, and that there weren't hundreds of other different github tokens in their firmware, so I scraped the Hanwha website to download every firmware for every camera i could find, and ended up with around ~500 firmwares (there were like 600 smth cameras but not all of them had firmware listed) and I was able to extract 62% of them with the same approach as above, and only three of them had github tokens, and they were all the same token.
not really sure why the others didn't work, but it's close enough for me to feel satisfied.
I wrote up a very small email with enough information to identify where the token was and sent it over to Hanwha, who have a nice open email for reporting security issues, and they responded within 12 hours notifying me that the token had been revoked. Sure they shouldn't have ever had a gh token in there but I have never had such a prompt response and resolution.
we really gotta stop making these mistakes so often, how am I supposed to be sleeping at night?
thanks computer, until next time
RE obfuscation and nation states - nation states have finite budgets too, both in terms of resources and attention. They can crack any system at any time, but they can't afford to crack all of the systems all of the time.
https://www.google.com/search?client=firefox-b-d&q=permissio...
https://medium.com/@mrtcve/atts-misuse-of-cloudflare-dns-ip-...
Sounds like they blocked Cloudflare but couldn't block Google
https://yalehome.co.uk/yale-sync-hub
It's not really something I want 'home rolled', I just want it to work.
Same goes for the boiler really. If it stops working I can phone Valliant and they'll send someone round to fix it.
Crucially, we set aside the common 10.1 and 10.10 ranges as nonroutable, so any devices that default into those have to be dealt with before they can live on the wider network.
Newcomers get handed a block and have to renumber, or NAT into it, or whatever, but they cannot emit bogons. At a small scale (first-name basis), this works.
It's a much better compromise and ergonomics to migrate from IPv4 to an IPv4 respecting successor, where IPv6 is just the academic snobbery and utterly alien mental model for not-enough benefits.
For the same reason Unix stuck around and beat up its own successor Plan 9/inferno. That inertia even decades later is the same reason IPv4 still beats IPv6.
IPv8 is more of a linux to unix than a plan 9.
fc00::/7 is for "Unique Local Addresses". Basically, private, non-globally-routable addresses from which you can freely pick space. Kind of like RFC1918. It's deliberately huge and you should only use as much from it as you need. The idea being that if you merge with another organization or connect to them via VPN, it's unlikely your addresses will collide like with RFC 1918.
There's even a website (sites?) to register your ULA space on a volunteer basis to reduce collision chances.
It's not about low adoption, it's that there are unimaginably many IPv6 addresses.
...which is a major reason for why it has low adoption
192.168.1.0/24 -> fd00:1::/64
192.168.2.0/24 -> fd00:2::/64
192.168.240.0/24 -> fd00:240::/64
It's not a great idea, but its no harder.
No need to mess around with setting up DHCP, remembering if your router is top or bottom of the subnet, and if you want 500 devices on a single subnet that's no problem.
Now if you still need ipv4 then yes, ipv6 is stupid as you have double the pain for none of the gain, but if you are ip6 only then its far easier.
The point of IPv6 was to make the addresses so long they are easy to manage.
Also, I had a DSL modem back in the day with its own terrible NAT built-in. I managed to log in (I may have been given the admin password from a friend who worked at the ISP, allegedly) and once I put it into bridge mode, I was able to acquire multiple public IPv4 addresses via DHCP.
B. I love that Euler is pronounced “oiler” which is North American slang for a drunk. I’ve been trying to find that constant my whole adult life.
lol, there is no doubt that had a massive opposite effect. To the point of nearly killing it in terms of willingness to adopt.
So it seems like it helps ISPs and large networks router… but they never had problems with address space running out at the high levels and almost all likely need to support v4 anyhow.
I think it’s been long enough to be honest that ipv6 was a spectacular failure by complicating an already complicated system into something no one actually asked for.
No human said “hey, networking sucks. Please make it much harder at my level!!”.
I know you can just block inbound non-established connections, but it feels like an extra step and complexity. Not to mention, that I really don't understand how IPs are supposed to be provisioned to devices on IPv6. Is there like a 50-100 page book you can recommend "for dummies" on IPv6, that hopefully contains at least a tiny amount of how to configure a common router and/or linux host.
There fixed that for you.
Anyone in IT who allocates 1.1.1.0/24 because 192.168.0.0/24 is hard, should be allocated to trash pickup.
Lte and 5G can be v6 only, usually they also have NAT64 and DNS64 so you can get everywhere, but the less stuff that needs v4, the smaller their nat boxes are.
like 1.1.1.1/192.168.45.4 ... for a router that understands IPv6, that's the direct route to the sub-network, otherwise it will have to use IPv4, and the subnet route is treated as NAT and otherwise isolated.
To me, that would make more sense... then internal IPv6 might be practically limited to 10. and 102.168. in the nearer term, but adoption would be MUCH simpler in practice, and distribution would mostly already be established, however unfairly, but can then be broken into single addresses and vNext adoption could be that much quicker as a result of piggybacking.
Not to mention, at home, most of the ads I do see (PiHole) are IPv6 addresses.
64 bits would be enough to avoid run out, but hierarchical allocation would still be a problem. 128 bits is long enough for many levels of hierarchy. (And yes, you can subnet all the bits, not just the first 64)
SLAAC is the only way that works across all IPV6 devices. In that mode, the router advertises the prefix and the device assigns its own address (prefix + its mac address).
DHCPv6 exists but is poorly supported. It sucks for people who like assigning IPs individually from an authoritative place (through static dhcp entries on the router). But people like us are "doing it wrong", you see? We must accept that in this brave new worlds an IP means nothing.
I assume you meant 10.x.x.x and 192.168.x.x -- (and 172.16.x.x?), ie the standard subnets for home router-modems (which are non-routing and so can't be used on the internet).
So I have 1.2 million million million million IPv6 addresses available.
That ought to be enough, eh?
Again, I don't know any of IPv6 enough to use it really right or wrong.
Split subnets at four bit chunks.
Allocated networks, like to a home or small office, should be /56 or /60.
Then you have to think about link-local addresses and privacy addresses, and how to hand out IPv6 and configure DNS: SLAAC vs. DHCPv6 or some combination.
I have a rough draft of a beginner document but it's not ready. :)
Going smaller than /64 is against best practice and unnecessary. People coming from IPv4 need to understand that trying to be careful with subnet sizing for purposes of preserving space is not a thing in IPv6 below /64. Maybe if a residential user has a /64 from their crappy ISP settings they'd need to do it, but not in a properly configured scenario and certainly not in enterprise.
So yeah, having to relearn a bunch of basic network knowledge that worked just fine for decades is a PITA, and I’m 100% positive a design process that focused more on the people that need to configure networks could have yielded a much friendlier, and therefore a much easier to adopt standard.
its really extremely simple, just dont NAT, is that really so hard? just because you dont NAT, doesnt mean you have to let the traffic pass through, that is also an extremely simple concept, no?
There are a shitload of people who maintain networks, like home or small business networks, that aren’t network administrators. Most of those people are not prepared to have their Chinese WiFi cameras, myriad smart appliances, and heck, even home computers easily individually accessible from the internet. It’s an extremely simple concept, no?