LZ2DMV

So expose_php is On and he filters X-Powered-By in the response when legal HTTP verbs are used, but nothing catches the illegal ones? Interesting.

I'm a bit curious how you found that.

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

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.

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

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.

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...

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.

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?