In perhaps the most alarming development in Pokémon history yet, a new virus has been developed for English language Pokémon Red and Blue. Spreading silently when players unsafely trade Pokémon over link cable, at this moment it’s impossible to know how many people could be affected.
But this is just the latest iteration. The previous version of the virus destroyed the victim’s gamesave, left the game completely unplayable, produced obvious graphical glitches when it was transmitting itself to the victim, and couldn’t infect saves if the victim had already beaten gym leader Sabrina. All these issues have been fixed in the most recent version, meaning the virus is now much stealthier and more weaponized.
The virus runs custom code at all times during gameplay, ready and waiting to infect anyone you trade with. Currently there is only one way to determine if you have the virus: go to the S.S. Anne, surf to the truck, and use Strength to push the truck and reveal the Mew that was underneath the entire time! However, entering the Hall of Fame will remove the virus from your gamesave, leaving no trace.
This whole business has left even cynical, world-weary experts such as ourselves shocked and appalled. Is nothing sacred? We recommend players do the following to keep themselves safe:
APTs, the dreaded but rare threat that keeps CSOs up at night, are notoriously flexible. But they aren’t necessarily unstoppable, and knowledge of typical attack processes and methods are critical for improving defense. Analysis of Aleksey Belan’s attacks provide one such exposé.
Targeting West-coast tech firms, Aleksey is blamed for many of the large breaches of 2012 and 2013. Often starting from peripheral servers found via Google or LinkedIn, the attacker combined multiple techniques as necessary to gain access, and used captured information to expand access.
As an example, an initial compromise of a public WordPress site with a known vulnerability led to credential harvesting when altered authentication scripts logged credentials. These credentials could then be used to access the internal wiki, which was discovered by scanning from the compromised WordPress server. Information on administrative procedures from the wiki were then used to gain access to administrative tools, which, after more scanning and exploiting, eventually provided access to production databases.
While nothing is a silver bullet against skilled and determined attackers, some precautions can make the attacker’s job much more frustrating and give you a leg up on defending against them:
Bringing usable computers and software to everyone is a worthwhile goal, but very difficult. Just to start with, computers will need to support the incredibly diverse variety of characters and glyphs used by every language in the world. Hence, Unicode. Unfortunately, supporting the entirety of written human language in one standard is… hard. One unforeseen consequence is the myriad ways that different URLs can look similar to each other once Unicode is supported in domain names, making phishing attacks even sneakier.
Though Unicode domains are still ASCII under the hood, they’re often graphically represented in Unicode as intended for usability. Well, mostly. As Valentine discovered, actual full support for Unicode domains is mixed. For example, Gmail won’t even accept emails from Unicode domains, though Outlook365 and Yahoo do. However, the URL isn’t always rendered in Unicode in the From field UI, sometimes leaving the strange ASCII punycode version visible to the user.
Additionally, while many browsers do display Unicode in the URL bar, not all do, and some chat/SMS apps don’t render Unicode URLs, and sometimes don’t even handle them properly as clickable links. While Unicode domains can provide for some very sneaky imitation tricks ('www.gṃail.com' instead of the legitimate 'www.gmail.com'), these only seem to work in certain applications, and with certain email providers. Here’s a few things to do to stay a step ahead of this phishing technique:
Don't try this at home, kids! Nest security cameras are vulnerable to some nasty attacks that can force them to reboot, or temporarily stop recording. Luckily an attacker must be in Bluetooth range to exploit the cameras, but unfortunately it is currently not possible to disable Bluetooth on the cameras, and a patch is prepared but not yet released.
Examining the details, it seems that the bugs are relatively simple. Sending configuration information over Bluetooth with Wi-Fi SSIDs or passwords of unexpected length leads to crashes and reboots, temporarily taking the camera offline. Additionally, an attacker can tell the camera to connect to a new wireless network, forcing it to disconnect from its legitimate network connection. This process takes about a minute, during which time the camera is not recording video.
Though Bluetooth cannot currently be disabled on the cameras and a patch is not yet available, Nest is expected to release an update within days fixing the issues, so be prepared to update soon.