Hacker Newsnew | past | comments | ask | show | jobs | submit | LZ2DMV's commentslogin

Only if the machine is directly connected to the internet and the malicious packet doesn't hit a firewall somewhere along the path.

Most laptops connected to Wi-Fi are indeed connected to an AP or a SOHO router that does NAT, so the attacker won't be able to directly reach it and this is a requirement for this to work.


The attacker can be on the LAN though.


Sure but security isn’t about being 100% protected which is impossible, but lowering your attack foot print. Unless you have a ton of people hooking to your LAN regularly then this still greatly lowers you chances of getting hit with this particular security flaw by people on the WAN


A useful target might be university networks, although IIRC our university printers weren’t available for discovery. Instead we would send our documents to a special email that would forward it to a local print server so we could get charged for it.


Plenty of laptops have a built in modem and this is becoming more ckmmoj every day. Those connect directly to the internet.

NAT only makes a difference if you use. IPv4 only. If you have dual stack, then your host is on the public internet.


Everyone, please go to your respective data centers, locate your rack and unplug the printer from the server.


Not every Linux machine is a server!

This is kind of a big deal for desktop and even more so for laptop users.


And the percentage of Linux desktops and laptops 1) with printers connected to them 2) directly exposed to the internet, is...?


The problem is mostly the insecure defaults. Every modern phone is configured to be backward compatible and connect to an older generation of network if a newer generation is not present (like in the case of being deliberately jammed by an adversary). In 2G, mutual authentication is not existent, it happens only one way - only the network authenticates the handset. If you are close enough to the victim (only screaming louder, i.e. more power than the legitimate network, but from a significant distance doesn't work, because of the RTT of the signal - TDMA-based systems are very time-sensitive in nature), nothing prevents you from operating your own mobile infrastructure and disable any encryption (i.e. in 2G, during the handshake, you just say A5/0 - no encryption, to the handset) - you can not enable encryption anyway, because you do not have the corresponding key that is on the SIM card, only the legitimate carrier has that.

Whether or not the victim will be notified about the absence of encryption, depends on the state of a single bit on the SIM card [1]. In 99% of the cases, there is no warning that the handset is currently using A5/0.

From now on, you are at the grace of the rogue network operator - they can send you anything from any number, sit in the middle of every call and capture every frame of data.

I don't think the current level of technological education of the general public is enough for most of them to know why it is important to force your phone to work only with modern network standards and that is what police and other government agencies interested in operating IMSI catchers exploit.

[1] http://blog.taddong.com/2011/02/does-your-phone-warn-you-whe...


> ...that is what police and other government agencies interested in operating IMSI catchers exploit.

Is encryption really significant to whether or not the police are able to monitor cellular phones? As bandwidth is already centrally allocated, there is a limited number of legal cellular network operators, and a competent authority could already compel (indeed, could have already compelled) mobile operators to provide master keys and diversification information under the Snooper Charter 2016[1].

https://www.legislation.gov.uk/ukpga/2016/25/


This implies compliance with the law and a formal procedure, and an authority might not always follow the law for various reasons. At least the use of encryption means one is less likely to be a subject of surveillance in an unlawful manner.

Consider intelligence operation abroad, for example.


You don't even need a card or a laptop. You can send deauth frames with an ESP8266, if the camera runs on 2.4 GHz, of course.


Apart from access control systems, it hardly has any good uses in the real world as a pen-testing device. If it was a pocket carry, true SDR, capable of recording RF signals as I/Q, performing actions on them, replaying them, etc, it would have justified its cost. But, with a limited set of modulations supported by the used RF chips, it is more like a toy for hacker wanna-be teenagers than a serious tool.

An investment in something like HackRF+PortaPack clone is far better, IMHO.


Totally agree that this isn't a good full pentesting device, but I also think that such a device doesn't need to be in order to be popular. Just look at the IM-ME when Samy Kamkar showed it off [0] and it sold out.

Most people don't need a full SDR like a HackRF in order to explore their RF devices and a Flipper gives that too them without the headache of software and the bulk of a full PortaPack.

(I love my HackRF and PortaPack for the record. The Flipper can't complete with the features and low-level access when you need it)

[0] https://hackaday.com/2015/06/08/hacking-the-im-me-to-open-ga...


Firmwares with extended TX and RX range: https://github.com/Tunas1337/UV-K5-Modded-Firmwares

Various miscellaneous modifications: https://github.com/amnemonic/Quansheng_UV-K5_Firmware/tree/m...

GNU/Linux ROM reading and writing tool: https://github.com/sq5bpf/k5prog


From the linked article, I'm left with the impression that this is only a problem for MSI (and a few other vendors) devices.

If Intel Boot Guard works by including a public key in a fuse in all CPUs from a set of series and now the corresponding private key is leaked, why isn't this a global problem? The same CPU with the same public key must be in every machine with an Intel CPU from these generations. What am I missing here?


In addition to the BootGuard public key, there is a chipset fuse with OEM configuration, https://www.securityweek.com/flawed-bios-implementations-lea...

> The boot chain uses an RSA public key (its hash is hard-coded inside the CPU) and an OEM private key. The OEM sets the final configuration and writes it to one-time-programmable Intel chipset fuses during the manufacturing process, thus making it almost impossible for an attacker to modify the BIOS without knowing the private part of the OEM Root Key. However, because some OEMs might fail to properly configure Intel Boot Guard, attackers could end up injecting code and permanently modifying BIOS.

> At Black Hat 2017, security researcher Alex Matrosov presented some vulnerabilities in poor BIOS implementations, explaining that not all vendors enable the protections offered by modern hardware. Because of that, attackers could elevate privileges, bypass protections, and install rootkits, he explained.

Some HP business devices don't use Intel BootGuard, because HP has their own proprietary solution for firmware integrity verification, https://news.ycombinator.com/item?id=35845073


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: