|
Why won't the iOS device save the credentials? I'd fix that rather than trying to make an obscured URL. I'm betting the reason is a bogus SSL cert since that definitely makes Chrome not want to save passwords, in which case Let's Encrypt is the answer.
|
#
¿
Mar 19, 2017 21:06
|
|
|
|
| # ¿ May 14, 2024 05:20 |
|
|
I totally agree. IoT is not inherently bad, it's just really easy to get wrong. Unfortunately it's also cheaper to get wrong in a lot of ways and consumers generally have no easy way to tell the good ones apart when they're looking to buy, so until getting it wrong starts costing the vendors money in the long term there'll be a constant stream of bad devices. If this bricker worm hits enough devices that are under some kind of warranty coverage it might actually help the situation by costing the vendors a lot there, but I suspect it'll take actual legal liability to really have an impact and I doubt that's going to happen any time soon (at least in the US). wolrah fucked around with this message at 19:39 on Apr 7, 2017 |
|
#
¿
Apr 7, 2017 19:36
|
|
|
EVIL Gibson posted:One of the few things that would help is an industry standard to clear before a product is released like, i dunno, maybe not leave the telnet port open with default creds "admin/admin" I'd take it further and say a LEGAL standard rather than just an industry standard. Releasing a device that's intended and expected to be exposed to the internet with a default password of any kind is negligence at this point, there's no way for a reasonable person developing these products to not be aware of the risk. Intentional backdoors I'd consider reckless at minimum. If companies start losing lawsuits because they released a steaming pile of vulnerable poo poo they'll start caring really fast. It's not like it's even that hard to not be horrible. 1. Don't have any backdoors. 2. Don't allow a default password to actually be used on a device in operation. Make it only work after a factory reset, where the password is required to be changed before the device will operate in any meaningful way. Those two simple things would knock out 95% of the low hanging fruit out there and take between zero and negative effort to implement. Bonus points for not listening to any traffic from outside of the local subnet unless explicitly configured to do so. Those things are easy to do, easy to test, don't inconvenience the user significantly, and raise the bar for a Mirai style worm from "can port scan and ask nicely to be let in" to "must find a pre-authentication vulnerability in an internet-exposed service".
|
|
#
¿
Apr 10, 2017 18:41
|
|
|
Thanks Ants posted:Randomly generate admin credentials when the product sticker is made (not derived from the MAC address, serial number etc.) use QR code in mobile app as part of setup process to set those credentials on the device. Advanced users can change it later if they want to. Double Punctuation posted:AT&T does the sticker thing for their routers. They don't have any symbols, but they're a reasonable length and are fairly random. Not true anymore...  Try having a 62 year old office manager who's half blind (the kind of person who complains to their boss when you disable their ability to set their 1920x1080 monitor to 1024x768) read that out over the phone.
|
|
#
¿
Apr 10, 2017 21:54
|
|
|
Thanks Ants posted:I meant that the device doesn't work out of the box, it just sits in a setup mode. Scanning the code into the mobile app writes that into the device itself, so there doesn't need to be any integration between sticker printing and device flashing. To pair more devices you need an existing paired device to put it in pairing mode, and then the second user can scan the code into their app. If you lose the only phone that is paired then you need to default the box. Ahh, so effectively there's a hidden default password or total lack thereof that the app uses to take the device out of setup mode and as part of that process set some other key that was randomly generated at print time or chosen by the user. That seems like it'd be fine for the most part as long as that setup mode can't be activated remotely, like with those Nest cameras recently.
|
|
#
¿
Apr 10, 2017 22:47
|
|
|
Guy Axlerod posted:You can still just turn the knob. One of my friends has this smoker: https://www.charbroil.com/smartchef-digital-electric-smoker For some idiotic reason the app is required to set the temperature. When he brought it down to my house a few weeks back during a LAN party the fact that my WiFi SSID has a space in it was the root cause behind a full hour of frustration when trying to get dinner going. This was with four people who all work in various IT fields prodding it and using monitor mode on Linux to watch the actual WiFi traffic. A normal person wouldn't have had a chance at figuring this out.
|
|
#
¿
Apr 13, 2017 16:45
|
|
|
Isn't WPA2 Enterprise roughly the same thing as 802.1x over a different medium?
|
|
#
¿
May 26, 2017 03:32
|
|
|
Get a better remote access solution. Teamviewer is able to interact with UAC dialogs just fine, I do it all the time. From what I've seen GoToMyPC/GoToAssist and Join.me both seem to be able to as well. Do not disable or weaken UAC and if you have any influence over the idiot who suggested to turn it off make sure he learns why that's a colossally dumb idea.
|
|
#
¿
Jun 9, 2017 19:36
|
|
|
wyoak posted:Yeah the client isn't going to be sending the server a TXT field, and if the queries are using common domains I don't even understand how the client and server would be talking to each other (unless the client is sending the DNS packets directly to the server, which seems to negate the biggest advantage of DNS tunneling to begin with). A lot of half-assed WiFi hotspot systems allow DNS traffic through across the board rather than just to their own servers before authentication. Same with ICMP. In those cases you can get away with bastardizing the protocol a lot more rather than actually trying to make something work through real DNS resolvers.
|
|
#
¿
Jul 21, 2017 16:56
|
|
|
Double Punctuation posted:If you've actually committed a crime, maybe you shouldn't go to a convention that's about stopping the crime you committed. Thanks to aggressive interpretations of vague computer crime laws you'd be hard pressed to find a security researcher who hasn't at least technically committed a crime. That said assuming these accusations have some merit this isn't exactly a case of a whitehat violating overbroad laws.
|
|
#
¿
Aug 4, 2017 02:01
|
|
|
EVIL Gibson posted:The flipping charge list is accusing him of helping develop the malware to be better and getting paid for it with the people that were using it for profit. Reread the second sentence of mine that you quoted. I completely agree that as far as this guy in particular it looks like they have some legitimate charges, but the post I was replying to was speaking in absolutes as if there aren't all sorts of ways for purely legitimate security researchers to end up considered criminals if they embarrass the wrong person/company.
|
|
#
¿
Aug 4, 2017 18:44
|
|
|
An ERL is a three-port router and yes, using the extra ethernet port will isolate the hub from the network. Even if it was a switch, many routers with built-in switches actually have basic managed switch chipsets which can be accessed by the user, if not on the official firmware then almost certainly with OpenWRT or similar if available. As noted the Ikea hub at least at this point seems to be well implemented, though we'll see if that changes as they add features.
|
|
#
¿
Aug 26, 2017 18:42
|
|
|
anthonypants posted:what the gently caress I've used this trick to run packet captures on a remote system that get routed in real time to Wireshark on my local system. SSH can be abused in all kinds of hilarious and useful ways.
|
|
#
¿
Sep 3, 2017 15:26
|
|
|
Furism posted:Can't you load the private key in Wireshark and still decrypt it on the fly? Genuine question, as I've only done it with recorded HTTPS myself. Like Subjunctive said I'm not capturing the SSH traffic, I'm running tcpdump on a remote system and sending the output to stdout, which gets piped over SSH to Wireshark on my local system. This me to view roughly real-time traffic captures from what might be a 400MHz ARM box with 16MB RAM and no local storage on the other side of the country. You actually don't want to capture the SSH traffic in this case, if you do it becomes an exponential explosion as it captures its own traffic sending its own traffic back to me. It definitely happens accidentally from time to time if I botch capture filters. wolrah fucked around with this message at 17:36 on Sep 3, 2017 |
|
#
¿
Sep 3, 2017 17:34
|
|
|
Typically when I'm doing this I'm capturing for VoIP troubleshooting purposes. All of the routers we support run some form of *nix and have tcpdump present so my trick gets me the traffic I need directly from their router's interface. I was just providing an example of interesting SSH trickery.
|
|
#
¿
Sep 3, 2017 18:30
|
|
|
RFC2324 posted:It seems like something that would be more efficiently solved in another way, to me. One of those 'can we do things in a sane reliable engineered way, or come up with some wacky ssh solution?' situations. For one, if those boxes server as backups for each other(you mean clustered, right?) wouldn't you want them to have a shared backing datastore? You're thinking redundancy, This is for backups. Backups sharing the same datastore would be nonsensical. As far as why do it this way, it's probably partially historical and partially Unix philosophy. Remote differential backups are often done using rsync over SSH. ZFS snapshot backups are basically that at the filesystem level. SSH provides a trustworthy, secure, reliable, and compression-capable tunnel even over the open internet, so why reinvent the wheel on that part? The Unix philosophy part comes in there too, do your thing and lean on other tools to do their part. If SSH ever falls out of favor for whatever reason it can be replaced relatively easily by whatever takes its place.
|
|
#
¿
Sep 4, 2017 03:55
|
|
|
RFC2324 posted:yes, but this is all true, but why wouldn't you use an actual backup solution instead of copying snapshots across the network via ssh? If you're using ZFS you're probably already taking a snapshot as part of your backup process, so why not skip the middleman, at least for your primary backups? Also useful for DR sites.
|
|
#
¿
Sep 4, 2017 07:41
|
|
|
cheese-cube posted:(All dogs are good dogs). Counterpoint: Purse dogs. Of course if your response is that those things are rodents pretending to be dogs then we're in agreement.
|
|
#
¿
Sep 13, 2017 18:03
|
|
|
Volguus posted:I have a small question about the WiFi security (or lack of). No. There is absolutely no security benefit to using a "hidden" SSID as long as you're using even the slightest bit of additional security. Think about it. If you're using any kind of encryption, even WEP, an attacker would need to be doing things far more complicated than passively sniffing a few channels. Hell even MAC filtering, the second most idiotic WiFi "security" option, is technically slightly harder to bypass. As noted you make it significantly more annoying to use the network legitimately while having basically zero impact on an actual attacker. The way I see it hiding the SSID actually has the opposite effect as most people are expecting, because for the client to find the AP they instead have to be constantly broadcasting "Hey <hidden SSID>, are you out there?" any time they're looking for networks to connect to. Now instead of their AP advertising its presence within its own range where any activity would be visible anyways, you have all the clients advertising that they're looking for a certain AP anywhere they go. That could probably be abused with fake AP attacks. If for some idiotic reason you have some WiFi device which can't be replaced or upgraded but doesn't even support WEP64 then technically MAC filtering + hidden SSID would be better than nothing for that specific case, but if there's even WEP's half-rear end flawed "security" then neither of those add anything more to the equation while both making legitimate use more annoying.
|
|
#
¿
Sep 15, 2017 19:15
|
|
|
So there's been a lot of talk about the update aspect from the AP side, but since this is an issue with the handshake wouldn't it also require client updates? If that's the case I think the APs would just be the tip of the iceberg.
|
|
#
¿
Oct 16, 2017 02:27
|
|
|
Maneki Neko posted:Reading through this, it’s bad, but not as bad as I thought (in that it mainly seems to require fixes on the client side only unless you’re implementing some specific features). While there are a lot of APs built in to home routers that'll never see updates, they're mostly not connected to high-value target networks. A lot of the major commercial AP vendors already have updates available, hell quite a few had already silently patched the issue in a publicly available firmware and then just announced it when disclosure time came around. Within a few weeks I expect that the majority of business-grade WiFi APs will be patched for this. On the other hand the client side is going to be vulnerable pretty much forever. As you note there are probably literally millions of Android devices that will never see an update again (if they ever did in the first place), all kinds of IoT things, all kinds of appliances. If it connects to a WiFi network it's probably vulnerable, and if it runs Linux it's apparently probably particularly vulnerable thanks to the wpa_supplicant bug.
|
|
#
¿
Oct 16, 2017 15:39
|
|
|
I don't deal with porting myself but from what I've seen this isn't really surprising. Sometimes ports get held up on the dumbest of things but the verification is hilariously bad. We've had numbers stolen from us and inadvertently stole numbers from others more than a few times thanks to various errors and how loose the system is.
|
|
#
¿
Oct 25, 2017 02:13
|
|
|
Internet Explorer posted:Holy poo poo. I think we need to start a company. SA goons could be rich. ID10T IPA - A 10%er to wash away the dumb PEBCAK Porter Tripel DES
|
|
#
¿
Nov 2, 2017 21:10
|
|
|
Absurd Alhazred posted:It's an i5! I'm safe! i5s are not safe. "6th, 7th & 8th Generation Intel® Core™ Processor Family" That means any i3, i5, i7, or i9 with a 6xxx through 8xxx model code. Also the older ones aren't necessarily safe, they're just using a different version of the ME hardware and software which hasn't been looked at as deeply because IIRC it can be fully neutered.
|
|
#
¿
Nov 22, 2017 14:53
|
|
|
BangersInMyKnickers posted:The older versions have similar risks and cannot be "fully neutered". 6th gen forward the ME engine moved to Minix and the security researchers are able to pick at it with more conventional tools. The ME engine before that was some kind of proprietary microkernel and they've been having a harder time picking it apart and analyzing. Impossible to say if that is a good or bad thing at this point, but most likely bad since governments have a lot more money to poke at this stuff and possibly access to proprietary Intel documentation on it. It seems there was a version number thing that was throwing off my memory. ME versions 1-5 can be fully disabled. ME version 6 added a watchdog system that shuts the PC down if the ME hasn't started up within 30 minutes of boot. In my head I associated this with the 6th-gen Core chips, but instead this was in the first-gen Core i-series. From here on out we can only neuter it to one level or another, not eliminate it. ME version 11 (Skylake) changed to the Minix-on-x86 platform used currently.
|
|
#
¿
Nov 22, 2017 16:39
|
|
|
Potato Salad posted:Works on Samsung 850s and PM851s That same trick was a thing when softmodding original Xboxes too. They used ATA password protection to prevent people from being able to just plug the hard drive in to a PC, but people discovered that if you hotswapped the IDE cable at just the right time you could get your PC to recognize it after the drive had been unlocked. You could then install your exploit of choice without even requiring one of the vulnerable games. This was also your only hope to unfuck it without a chip if you managed to screw up a softmod without backing up the EEPROM (which stored the ATA password) first.
|
|
#
¿
Dec 10, 2017 17:32
|
|
|
EVIL Gibson posted:Edit:. Posted a little bit more but can we return a good is of the Turbo button again? It used to bump the processor speed at the risk of a possiblity of inaccurate results compared to the slower speed which was always accurate. Nah, it wasn't any less accurate, it was literally just a speed control because some programs (mostly games) treated the PC like a console and timed things based on clock cycles rather than real time. "Turbo mode" was just running at the CPU's normal clock speed and if you "turned off turbo" it either reduced the clock speed of the CPU or triggered a TSR that ran meaningless instructions intermittently. Either way the goal was to slow down a program that was otherwise running too fast. For normal day-to-day operation you were supposed to leave it in "turbo". e;f:b As far as the idea of being able to turn these protections off, I guess maybe in an appliance type role where any kind of untrusted code execution means something's already gone wrong I could see the argument to be made (especially those appliances that run everything as root anyways so any code executing already has the keys to the castle), but the fact that these issues are apparently exploitable through the browser means basically any general purpose desktop should have the mitigations enabled. Even a dedicated gaming machine that you swear you never randomly browse the web on, most games these days embed a browser as do most of the game distribution networks. wolrah fucked around with this message at 05:18 on Jan 4, 2018 |
|
#
¿
Jan 4, 2018 05:11
|
|
|
feedmegin posted:Itanium doesn't (in the hardware sense, anyway). Not doing OoO type stuff is/was literally that CPU's whole schtick. Bonnell and Saltwell Atoms as well, though Silvermont and beyond have it and thus are affected. So my old netbook is immune, wheeee.
|
|
#
¿
Jan 10, 2018 23:24
|
|
|
Samizdata posted:Well, so far as I can tell, my old Core 2 Quad seems immune. So yay for my kitbashed old crap. For anyone wondering, here's the complete list of Intel x86 cores from the last 20 years which don't do out-of-order processing with speculative execution: Bonnell (First-gen Atom) Saltwell (Die-shrink of Bonnell) Knights Corner (First-gen Xeon Phi) Lakemont (Quark) Pentium Pro, Pentium II, III, 4, M, Celeron, Xeon, and Core lines are all vulnerable as are the later Atoms and Xeon Phis. On the AMD side of the fence it's everything from the K5 on up as far as I'm aware.
|
|
#
¿
Jan 12, 2018 02:42
|
|
|
EssOEss posted:What I do is disable the enter key at the end of the auto-type key sequence, so I can review exactly what box it stuck my password into. Just worth noting that while this will stop you from accidentally entering your password in to a random field, if a malicious site is trying to exploit autofill it could be reading the form values with Javascript or just submitting the form in the background.
|
|
#
¿
Jan 18, 2018 15:26
|
|
|
apseudonym posted:ADB is not the highest privilege level. Any devices that are exposing a root-capable ADB interface to the internet have gone through multiple tiers of actively stupid actions by the user and/or device vendor. Blaming Android for this is like blaming Windows for Lenovo's preinstalled spyware.
|
|
#
¿
Feb 14, 2018 15:54
|
|
|
cheese-cube posted:That's my WiFi story. This was about once a month for me in college. It was before there was official wireless in the dorms, so people would just hook up their own stuff and inevitably a bunch of them got hooked up with the LAN side connected to the campus network. They had nice switches but apparently hadn't enabled snooping and were really slow about actually doing anything about it. After the second time I came to the same conclusion about default passwords and would change the SSID to something obvious, disable DHCP, and then go out hunting. Locate the signal, knock on the door, and give them a bit of poo poo about it. If they were nice I'd help them get it set up properly, if they were lovely about it I'd play on their ignorance and tell them I was with IT (technically true) to threaten them with consequences. I couldn't actually enforce those things and didn't even work in the right department, but it usually worked. Repeat offenders may have had their device reflashed to OpenWRT.
|
|
#
¿
Mar 23, 2018 17:49
|
|
|
They were affecting network access for the entire building because their DHCP was faster to respond than the official one, and in previous times this had happened the official IT department took multiple days to resolve the problem. I bent the truth a bit to resolve the problem faster for myself and the rest of the people in the building. Like The Fool, official policy was confiscation and most of the people I dealt with in this way were nice so I helped them out instead. They got a properly configured WiFi network and the rest of us got our internet back. The shittier people got told the actual policy and got a meaningless warning while the rest of us got our internet back. Where's the actual harm in those cases? Everyone came out better than the official way. As far as the reflashing, I'll agree that it wasn't the best thing to have done but when the same person's broken your internet access for the fifth time that weekend and knows enough to work the reset button you start to consider more permanent measures. The device still worked and would even operate as a wireless access point and switch, I just disabled the DHCP server in the default config so their factory resets would stop breaking everything. Inept posted:I'd love to be a fly on the wall, I bet the entire interaction was awkward and awful.
|
|
#
¿
Mar 23, 2018 19:41
|
|
|
cheese-cube posted:Nah, those are shite excuses. It's called DHCP snooping and has been around for ages, that would have handled your rogue DHCP server issue. wolrah posted:They had nice switches but apparently hadn't enabled snooping and were really slow about actually doing anything about it. quote:Sounds like you ignored using technical solutions in favour of throwing your weight around to be the big network boy. quote:Unacceptable behaviour and the fact that you don't seem to realise this makes me fear for your current employer, assuming you're still in the industry.. As far as my employer goes, funny thing, at one point we deployed customized OpenWRT builds in smaller environments where we couldn't justify a commercial router that did what we wanted it to. This situation actually taught me a skill I've put to use at work.
|
|
#
¿
Mar 23, 2018 22:14
|
|
|
On the flip side of that, didn't Google get in trouble for logging data transmitted on open WiFi networks their cars observed? Data that's literally being freely broadcast to anyone in the area? I agree that if it's open, even unintentionally, that's the problem of those who wanted it closed and not those who accessed it. Unfortunately there are a lot of people, especially non-tech-savvy lawmakers, who will happily believe what a company tells them about how it's supposed to be private and only an evil hacker could discover that a company had a major software package exposed at <packagename>.<companyname>.<tld>
|
|
#
¿
Mar 27, 2018 14:18
|
|
|
Proteus Jones posted:Was it actual legal trouble? Or just a conviction in the court of public opinion? Looked it up and they did get sued a bunch, a few class actions were merged, and they lost. They tried to take it to the Supreme Court but were denied. https://www.wired.com/2014/04/threatlevel_0401_streetview/
|
|
#
¿
Mar 27, 2018 14:54
|
|
|
Avenging_Mikon posted:I think it's a situation of intent mattering. If you're on wifi, you're not intending for all your traffic to be broadcast, that's just how the technology was designed. Even if it's encrypted, it's still broadcast. 1. That basically then requires you assume it's private unless told otherwise. Go to your favorite restaurant and see "<restaurant> WiFi" SSID wide open? Unless there's a sign up saying "Free WiFi" or you're told by the server, you can't know their intent, they might have just made a mistake when setting up the device. 2. Idiots gonna idiot. Anyone who was using FRS/GMRS radios when they became a big thing has probably come across people who believe the CTCSS "privacy codes" actually provide any form of privacy and will whine about how you're on "their" channel. Those people had the intent to have a private conversation, and were even led to believe they could based on the marketing descriptions of the product's features. That still doesn't mean it'd be reasonable to charge someone who happened to be recording the FRS spectrum with wiretapping. The peak of CB radio was before my time but I've heard many stories of the same sorts of things happening then, where people would be having a "private" conversation broadcast openly over a huge distance. The fact that someone else assumed it was private when it really wasn't should not be relevant to the law. That's their mistake, not a wrongdoing of the person passively monitoring the airwaves. quote:If someone puts up a repository, they had the option of making it private in many different ways, so as a third-party, you'd be safe to assume if you can access it through a standard registration then the owning party doesn't care. How does this differ from WiFi? They had the option of making it private in many different ways, so as a third party you'd be safe to assume if it's being broadcast to you in the clear then the transmitting party doesn't care.
|
|
#
¿
Mar 27, 2018 15:44
|
|
|
Avenging_Mikon posted:Good thing the law specifically takes intent into account, so you're wrong. Good thing the law says this: quote:(g) It shall not be unlawful under this chapter or chapter 121 of this title for any person— In the Google case, the actual legal problem they had is that they also logged encrypted traffic. They obviously couldn't decode that traffic (well actually they probably could in most cases because they have a lot of CPU power and most wifi passwords suck, but that's another matter) but the courts decided that logging even the encrypted traffic was against the law. Had they only logged unencrypted traffic they'd have been fine. I don't disagree with that conclusion. Intent does sort of still matter, but only when such intent is actually demonstrated. You could use WEP64 and it'd still be considered private according to the law even if it's trivially broken and not really private, kinda similarly to how CSS encryption on DVDs is still considered to "effectively control access to a work" under the DMCA. The law basically says "as long as you tried". For the standard analogy to a business, it's the difference between having your doors wide open and having a screen door latched with one of those bent nail things. The actual security difference is basically zero, but the latter demonstrates intent to keep others out where the former does not.
|
|
#
¿
Mar 27, 2018 17:55
|
|
|
Thanks Ants posted:Yeah same, when only students could use it and there were no apps I think people were a lot more open with the stuff they shared.
|
|
#
¿
Apr 6, 2018 19:24
|
|
|
|
| # ¿ May 14, 2024 05:20 |
|
|
22 Eargesplitten posted:This seems like the thread to ask since in the past the Android thread has been no help. Is there a way to pull all of the data off of an old android phone and android-formatted SD card using Windows or Linux? I feel like there should be because of the old adage about physical access meaning you will eventually have data access, but I don’t know anything about that sort of thing. On Android devices by default the SD card is formatted FAT32 so you can just put it in a PC and read it straight up. Those with rooted phones also often added a second EXT4 partition and used something like APPS2SD to link it in with their system, but again that'll be readable on any Linux system or with addon drivers on Windows/Mac. Newer Android devices running 6.0 or newer have an optional mode called adoptable storage where the SD card is formatted entirely EXT4 but also encrypted with 128 bit AES. I do not know if there's an easy way to recover the key in these cases, or if it uses standard Linux disk encryption versus some Android-specific system. As far as reading the entire device, you can usually get a lot with ADB but newer versions have locked this down. If the device has an unlocked bootloader you can replace the recovery with something like TWRP and do a full device backup to SD or USB storage.
|
|
#
¿
May 31, 2018 19:24
|
|