Monkey With A Shell
Some dingbat that occasionally builds neat stuff without breaking others. The person running this public-but-not-promoted instance because reasons.
- 0 Posts
- 48 Comments
WiFi pineapples are fun that way. I’ve taken one out on a drive going to our cabin in scanning mode and picked up 100+ different SSIDs along the way. It can also respond as a wildcard to any request that comes by or just be obnoxious and advertise them all at one.
Never setting an ‘auto connect’ for unsecured WiFi is a must in that case. Secured not so much an issue unless the interceptor has the key for the network at least.
It’s pretty much the same thing that ‘tile’ does, it’s scary that they do this as an opt-out though. Having that as a system level function effectively means they can enable or disable it at will without having to have a separate app.
One more bug to sort out with notifications and I’m full time onto GraphineOS.
It says right in there that they can’t see what you are sending or receiving, but seeing the SNI provides content on what you’re doing. Not seeing where it’s false at all.
Using that SNI header profile though if one was inclined and the site doesn’t enforce HSTS it would be simple enough to proxy traffic through their gateway, or to creating a phishing duplication of the site with a DNS redirect.
Discover/offer/request/acknowledge since it didn’t make a pretty picture for me.
Basically it’s just a case of who answers first. A DHCP discover is a broadcast message since the client doesn’t know where or even if there is a server on the net. Whoever gets back to the client first with an offer though will end up with the request/ack following up and get to provide whatever options they push along with the offer.
Claim: if you use HTTPS you are safe!
Overall a solid writeup, but this part could use some clarification. Assuming the VPN client doesn’t leak DNS this is only a concern after exploitation by DHCP option.
Another thing that might be noted, since this is a DHCP based issue the window for compromise is largely going to be at the time of connection unless the server has a particularly short lease time. If there are multiple DHCP servers on the same network answering requests it’s bound to raise some alarms if someone is watching the network so it makes 3rd person exploitation a very noisy method since you would have a race for who offered the lease first.
Edit: Really this attack isn’t just a problem for VPNs but could apply to any network connectivity. A rouge DHCP sever can cause all sorts of havoc. There used to be an single button APK called ‘firesheep’ that would do similar to this by presenting itself as the gateway, although that wouldn’t have allowed for the specific split routing config option push.
Short version of this attack, it involves split routing for the tunnels. A lot of clients will have a default route-all to send traffic through the VPN. There is however a limitation to this because the tunnel itself needs a route from the local nic to connect to the VPN endpoint and establish the tunnel, otherwise you end up with a chicken and egg where you can’t establish the VPN. By taking advantage of the DHCP option to set preferred routes (really anything more specific than 0.0.0.0/0) it can tell the host system to send the specified traffic through the local gateway rather than the tunnel’s virtual adapter.
One relatively simple fix if you happen to have a fancy router/firewall on the edge of the network that handles the VPN would be to use policy based routing rather than relying on the underlying network configuration. Static route tables would be possible too, but in theory that could be overridden by just sending a more specific route again than what was set statically.
A favored test by the AirVPN people. Gives a decent picture of your print. Thing is, they can pick all the scree resolutions and browser types they like, but it only does good with a location
Generally yes, it would matter a lot how it was structured. Today you couldn’t call up AWS and ask for the details on a service owner out of privacy reasons and there are ways to register things by proxy. If they started stripping those kind of protections away though there’s bound to be some pushback.
The problem with that line of thought though, while people generally expect/wish for private communication, few actually care to understand the mechanics of it. Nor should they have to, that’s what security engineers are for, to do all that archaic setup so people can just use it without having to check certificates and protocols and all that stuff.
I’d say that if we could just have a simple to use, no-click pgp style system things would be good and we no longer have to keep nagging people to set things up the ‘right’ way, but so much of the hassle comes in by people using 100 different communication platforms.
Of course though: https://xkcd.com/927/
How much simpler can I make this…
You have a primary ‘master’ server in the pool.
Replica/cache servers periodically ask the master for any updates.
Master gives a new update, which is a sinkhole for a marked malicious domain.
Replica/cache server now resolves malicious domain to the sinkhole address.
This is not a ‘feature’ you have to implement, it’s a basic function of running a redundant DNS system.
This has been a theory for a while, just not sure it was a specifically ruled precedent. The notion being similar to how they can force fingerprinting but not testimony. Access to a physical lock or location you can’t simply say ‘stay out’ but they can’t force you to divulge a password since it’s a thought in your mind.
Also, relying on biometrics is terrible, quick but immutable keys are a big no-no.
There’s two avenues for opening an encrypted file, attacking the password/access method or attacking the encryption itself.
Generally using a basic zip-lock is not going to have a second factor, a rate limiting mechanism, anything really other than the password to stop a random brute force effort if they got a hold of the file for local processing.
Using something with some front end protection like bit warden with 2FA or keepass with the key file option added in makes it more a task of going after the crypto itself which is a much much harder approach.
Roku enabled by chance? I have 2 of them plugged in on my IOT space and have 54K blocks to scribe.logs.roku.com in the past 30 days.
The opener version by necessity makes it apparent that you are running a node, but without some coordinated efforts to ‘surround’ you and be in control of all node points connecting to it nobody can verify what requests originated or ended at your host. It’s a plausible deniability state rather than pure anonymity as far as the neighbors go.
Very simple comparison, shout to everyone in the room you want a file, if they have it they’ll send it, if not they’ll ask their neighbors, but they never tell the neighbors it’s not for them they just ask for the file, this continues on until someone has the file and passes lt back to the one who requested it from them up the chain until the first person gets it. In this way even the second person who was the first peer doesn’t know who originally requested it, just that this person asked them.
Interesting, hadn’t looked recently to see that. Ian Clark, aka Toad, wrote both though and likely just wanted to take advantage of the name recognition from Freenet without all the uproar that happened when they announced the 0.5 to 0.7 rewrite of Freenet. Back then, it was migrating TCP to UDP now it’s moving from Java to Rust. Both though end up being an effective reset of the odd little sub-web we know as Freenet.
I’ve been off and on since the way back times. It seems to be frozen for some while ever since the original dev ‘Toad’ went off to do his own thing a few years back. Conceptually it’s a neat idea but suffers greatly from a ‘slowest link in the chain’ problem when looking to fetch sites since any given node only knows their immediate peer rather than the true source on either end of a request.
The transport between you and the endpoint will see an encrypted tunnel, nothing of what is passed through it. Unless your ISP also happens to control the VPN gateway and where the ISP carrier for the VPN they wouldn’t be able make a correlation.
The VPN provider knows all of the above, so if you’re really concerned with privacy make sure to pay the provider with untraceable means like a cash purchased debit card or crypto and use an email not used anywhere else for authentication.
It did work on Lineageos, but there where a lot of other aspects that where a bit flakey. Lack of auto support is really the reason I didn’t stay with Graphine. I may try Lineage again here now that I’ve figured out some of the new ‘featires’ of Android 14 (adaptive connectivity my ass, kept turning off my cell data to save power) since at least some removal of Google is better than none.
Metadata and the comm endpoints is one of the hardest parts to deal with. If an intermediary doesn’t have a pointer to a destination then delivering a message becomes problematic, envelopes without an address tend to sit in bins. It would be possible to simply store messages and allow recipients to poll for them but that gets really inefficient at scale. Plus it creates a central repo where messages sit until retrieved which is a liability in itself.
Things like OTR encryption are interesting as a transient system ad-hoc type encryption for things that don’t need or even want absolute assurance of identity, but if I want to talk to Alice and be sure it’s not Eve then it’s not ideal.
Depends on the application in use. The grail is end2end encryption with asymmetric encryption where no provider has access to the private keys. The difficulty is getting people on a common method where you can just look for your peer and get a public key handed to you without having to fuss around with where it was uploaded.
Maybe the most common/simple would be looking into things like PGP. You and I would both have a public/private key pair. When I send you messages it’s encrypted with your public key and signed with my private key, and as a result only your private key can decrypt the message and you know it came from me because only my private key could have signed it.
The ugly mechanics behind it don’t need to be anything you actually learn in detail, but just look for apps that offer end to end encryption where the encryption is set up locally rather than in the service provider’s host, if the host generated the keypair then functionally it’s useless because at that point they have the private key.
https://shop.hak5.org/products/lan-turtle
Assume physical access, someone walks in and has 5 minutes out of sight. A decent wpa2 password would take an extraordinary long time to brute force. Something like above gets deployed and allows remote access in seconds on an unprotected lan. As noted in another comment sketchy IOT gear is a threat people install willingly. The old test of leaving a loaded USB in the parking lot catches more people than is reasonable. Don’t assume a physical door is going to stop someone more than a proper technical barrier.
That’s the point of mentioning the physical access. Yes it’s easier to get at ‘physically’ in that it allows you to reach it through walls, but, if physical access WAS obtained what protections do you have in place for a lan jack? It’s possible to use 802.1x auth or such but for most home users it’s just a case of plug in a cable and you’re part of the network.
Adguard home with a few extra lists and custom rules. Just got the sync tool set up to auto replicate changes from one to another so no more copy/paste to a secondary. Great when I need to restart a VM and don’t want to take out the internet while it reboots.
Used pihole some while back but the feature list was tiny by comparison, though it was a good while back so probably unfair to compare.
Also ran with pfBlocker for a while, nice to have it right on the gateway but found it a bit opaque and lacking customization for my needs.
The federal government has had difficulty dealing with modern locked phones. The sim isn’t integral to the security of the device, it’s just a pointer for the carrier to route calls to. A modern phone with whole system encryption and a strong password is going to be protected against most everyone including nation state actors.
The only real advisory I like to put out with regards to phones is the same as most other devices, don’t reuse passwords and for two factor ideally use something other than email or SMS which makes it far more difficult to get the second factor.
The other thing that’s kind of a ‘best practice’ is using a password rather than any kind of biometric. The reason there is last I’d read (in the USA) the current legal guidance is that while authorities can compelle someone to put a finger on a screen or look at the device, they cannot compelle them to open the contents of their mind (forced testimony) due to the 5th amendment protections. Of course that kind of thing is more related to legal situations rather than lost/stolen devices.
Yeah, they’re a bit cart ahead of horse on that one.
Impulse purchases. You’re there looking for a thing that brings you to an area, put something tangentially related in easy view nearby. It’s the same sort of thing as why there are single serve candy and soda at the checkout ‘cheap, easy, convinient’ on items that will generally have high margin to them.
Some measure of accountability for getting an account needs to be kept in my opinion. Pure anonymity lends itself to things like 4Chan emerging, which is an intersting place to be sure but not exactly conducive to a reasoned discussion. Pretty hard to send some pictures to aunt judy if everyone is just anon.
There’s a possibility, but not a big one that any given WiFi has an decrypting proxy in place. Your device should be giving a big warning flag if a certificate was found issued by an untrusted cerificate authority. It’s possible if someone like Google or a government body ran the portal that they could issue ‘trusted’ certificates for sites on the fly through such a proxy and grab whatever they want while it’s decrypted mid stream.
The whole premise of HTTPS as security is based on the notion that the CAs at the end of the chain are trustworthy and wouldn’t do something like that, but it is possible.
Wrap the car in a large faraday cage? As a general rule it should be assumed that any device with a direct to internet connection capability has the potential to track the user, even of it’s at a very course level like IP history that in theory could be made more precise if the ISP was inclined to keep tabs on a mac address.
My own vehicle has the ability, if not the subscription, to use one of those manufacturer sponsored satilite connections. Plenty of new vehicles have such things as paid DLC and just lock it up behind software but the hardware is still there. Physical interferance through disconnecting the relevant modules in a clean reversible way has potential for some enterprising sort to either open a school or a specialty repair shop. Now if we could just do something about the phone the driver has with them at the same time.
Long ago I used a system called hushmail that promised a lot of the same as proton. Eventually I set up my own but it still has the problem of having to relay outgoing external mail through another box because of all the restrictions on home based dynamic IPs, so it’s largely relegated to system alerts in house rather than general use.
It’s a balancing act to be sure. VPNs stop local ISP inspection in exchange for potential viewing by the VPN host. DNS filters can only filter known threats. Things like P2P private nets can be infiltrated by 3rd parties via the ‘6 degrees of separation’ premise or even tracking pixels.
Making the picture muddy is about the best we can do, but it’s always worth the effort to not be another data point in the profile machine.