Peter's Quasi-Daily Blah-g

Russian unit, GRU officer linked to 2014 shoot-down of airliner over Ukraine

Posted on May 26, 2018 by peterjang73

Russian unit, GRU officer linked to 2014 shoot-down of airliner over Ukraine

https://ift.tt/2IPhk67

Enlarge /

Eliot Higgins (C), founder of online investigation group Bellingcat, addresses a press conference on findings within research on Malaysia Airlines flight MH17 in Scheveningen, The Netherlands, on May 25, 2018. – The Netherlands and Australia on May 25 accused Moscow of being behind the 2014 shooting down of flight MH17 over war-torn eastern Ukraine with the loss of 298 lives, in a move which may trigger legal action.

REMKO DE WAAL / Getty Images

Officials from the Netherlands and Australia today formally stated that they are convinced Russia was responsible for the deployment of the “Buk” anti-aircraft missile system that shot down Malaysian Airlines Flight 17 (MH17) in 2014. The announcement came a day after a Dutch-led joint investigation team released a report on their findings, which concluded the missile had belonged to the Russian Army’s 53rd anti-aircraft brigade, which was based outside the city of Kursk, north of the Ukrainian border.

Physical evidence collected by investigators, along with radar track and flight recorder data, pointed to the use of a specific warhead type associated with Buk surface-to-air missiles. Paint transferred from fragments of the missile to the aircraft’s fuselage was matched with recovered parts of the missile.

Russia has long denied that any of its military equipment ever crossed the border into eastern Ukraine, and the Russians presented several alternative scenarios—including blaming the downing of the airliner on a Ukrainian Air Force pilot. The Russians at first claimed to have radar evidence proving their allegation, but the country then said it was lost—only to claim they had found the evidence again just two days before the Joint Investigative Team’s 2016 press conference. The separate target that Russia claimed to have identified on radar was actually part of MH17’s fuselage breaking away after the missile detonated.

A significant portion of the evidence pointing to the involvement of the 53^rd brigade’s missile systems came from open source intelligence analysis, which used photos and videos posted by Russians to social media sites showing a convoy of vehicles from the 53^rd headed toward the Ukrainian border. Details from the images and videos, including license plates on the military vehicles and details of the surroundings that were matched with Google Street View photos, provided investigators with the route and timeline of the Buk missile systems’ movements.

VIDEO

A Dutch Safety Board video presenting the reconstruction of what happened to MH17 on July 17, 2014.

Further research from investigators and reporters at the open source intelligence research group Bellingcat, the Russian investigative news site The Insider, and McClatchy News Service’s Washington, DC bureau identified an officer of Russia’s Main Intelligence Directorate (Glavnoye razvedyvatel’noye upravleniye, abbreviated as GRU) who was tied to the deployment of the Buk antiaircraft system involved in the shoot-down of MH17.

Working from interviews with separatists, recorded phone calls, and calling application data, the team was able to track down Oleg Vladimirovich Ivannikov—even calling him on his associated number and getting him to identify himself, which provided a voice sample in the process. Ivannikov has been connected with other covert military operations, including serving under a pseudonym for eight years in the government of the Russian-backed separatists in South Ossetia—first as chairman of the security council and later as defense minister.

Russian journalists reported that Ivannikov’s current role included providing training and money for “private” military operations in Syria, such as the one that attacked US forces (and was beaten back with heavy casualties) earlier this year.

There has previously been ample evidence of Russia’s involvement with eastern Ukraine separatists. Russian social media has even provided videos made by Russians of rocket launches from the Russian side of the border targeting Ukraine. Google Earth images have shown evidence of Russian military vehicle movement and rocket launches. And Russian troops have even made social media posts from within Ukraine, including the strange case of “Sergeant Selfie”—a Russian soldier who left geo-tagging turned on while posting pictures of himself inside his armored vehicle.

Tech

via Ars Technica https://arstechnica.com

May 25, 2018 at 04:49PM

Posted in Family | Tagged Feedly, IFTTT | Leave a comment

FBI tells router users to reboot now to kill malware infecting 500k devices

Posted on May 25, 2018 by peterjang73

FBI tells router users to reboot now to kill malware infecting 500k devices

https://ift.tt/2ILS198

The FBI is advising users of consumer-grade routers and network-attached storage devices to reboot them as soon as possible to counter Russian-engineered malware that has infected hundreds of thousands devices.

Researchers from Cisco’s Talos security team first disclosed the existence of the malware on Wednesday. The detailed report said the malware infected more than 500,000 devices made by Linksys, Mikrotik, Netgear, QNAP, and TP-Link. Known as VPNFilter, the malware allowed attackers to collect communications, launch attacks on others, and permanently destroy the devices with a single command. The report said the malware was developed by hackers working for an advanced nation, possibly Russia, and advised users of affected router models to perform a factory reset, or at a minimum to reboot.

Later in the day, The Daily Beast reported that VPNFilter was indeed developed by a Russian hacking group, one known by a variety of names, including Sofacy, Fancy Bear, APT 28, and Pawn Storm. The Daily Beast also said the FBI had seized an Internet domain VPNFilter used as a backup means to deliver later stages of the malware to devices that were already infected with the initial stage 1. The seizure meant that the primary and secondary means to deliver stages 2 and 3 had been dismantled, leaving only a third fallback, which relied on attackers sending special packets to each infected device.

Limited persistence

The redundant mechanisms for delivering the later stages address a fundamental shortcoming in VPNFilter—stages 2 and 3 can’t survive a reboot, meaning they are wiped clean as soon as a device is restarted. Instead, only stage 1 remains. Presumably, once an infected device reboots, stage 1 will cause it to reach out to the recently seized ToKnowAll.com address. The FBI’s advice to reboot small office and home office routers and NAS devices capitalizes on this limitation. In a statement published Friday, FBI officials suggested that users of all consumer-grade routers, not just those known to be vulnerable to VPNFilter, protect themselves. The officials wrote:

The FBI recommends any owner of small office and home office routers reboot the devices to temporarily disrupt the malware and aid the potential identification of infected devices. Owners are advised to consider disabling remote management settings on devices and secure with strong passwords and encryption when enabled. Network devices should be upgraded to the latest available versions of firmware.

In a statement also published Friday, Justice Department officials wrote:

Owners of SOHO and NAS devices that may be infected should reboot their devices as soon as possible, temporarily eliminating the second stage malware and causing the first stage malware on their device to call out for instructions. Although devices will remain vulnerable to reinfection with the second stage malware while connected to the Internet, these efforts maximize opportunities to identify and remediate the infection worldwide in the time available before Sofacy actors learn of the vulnerability in their command-and-control infrastructure.

The US Department of Homeland Security has also issued a statement advising that “all SOHO router owners power cycle (reboot) their devices to temporarily disrupt the malware.”

As noted in the statements, rebooting serves the objectives of (1) temporarily preventing infected devices from running the stages that collect data and other advanced attacks and (2) helping FBI officials to track who was infected. Friday’s statement said the FBI is working with the non-profit Shadow Foundation to disseminate the IP addresses of infected devices to ISPs and foreign authorities to notify end users.

Authorities and researchers still don’t know for certain how compromised devices are initially infected. They suspect the attackers exploited known vulnerabilities and default passwords that end users had yet to patch or change. That uncertainty is likely driving the advice in the FBI statement that all router and NAS users reboot, rather than only users of the 14 models known to be affected by VPNFilter, which are:

Linksys E1200
Linksys E2500
Linksys WRVS4400N
Mikrotik RouterOS for Cloud Core Routers: Versions 1016, 1036, and 1072
Netgear DGN2200
Netgear R6400
Netgear R7000
Netgear R8000
Netgear WNR1000
Netgear WNR2000
QNAP TS251
QNAP TS439 Pro
Other QNAP NAS devices running QTS software
TP-Link R600VPN

The advice to reboot, update, change default passwords, and disable remote administration is sound and in most cases requires no more than 15 minutes. Of course, a more effective measure is to follow the advice Cisco gave Wednesday to users of affected devices and perform a factory reset, which will permanently remove all of the malware, including stage 1. This generally involves using a paper clip or thumb tack to hold down a button on the back of the device for 5 seconds. The reset will remove any configuration settings stored on the device, so users will have to restore those settings once the device initially reboots. (It’s never a bad idea to disable UPnP when practical, but that protection appears to have no effect on VPNFilter.)

There’s no easy way to know if a router has been infected by VPNFilter. For more advanced users, Cisco provided detailed indicators of compromise in Wednesday’s report, along with firewall rules that can be used to protect devices. Ars has much more about VPNFilter here.

Tech

via Ars Technica https://arstechnica.com

May 25, 2018 at 01:26PM

Posted in Family | Tagged Feedly, IFTTT | Leave a comment

Alexa’s recording snafu was improbable, but inevitable

Posted on May 25, 2018 by peterjang73

Alexa’s recording snafu was improbable, but inevitable

https://ift.tt/2LuFuV6

Engadget

Amazon’s Alexa recently made headlines for one of the strangest consumer AI mistakes we’ve ever heard of: A family in Portland, Oregon claims that the company’s virtual assistant recorded a conversation and sent it to a seemingly random person in the husband’s contact list. Alexa didn’t just make one slip-up — it made several that, when combined, led to a pretty remarkable breach of privacy. The company’s explanation, provided to news outlets yesterday, makes clear just how unlikely this whole situation was:

“Echo woke up due to a word in background conversation sounding like ‘Alexa,'” the statement reads. “Then, the subsequent conversation was heard as a “send message” request. At which point, Alexa said out loud “To whom?” At which point, the background conversation was interpreted as a name in the customers contact list. Alexa then asked out loud, “[contact name], right?” Alexa then interpreted background conversation as ‘right’.”

That is, without question, absolutely wild. Given a handful of factors at play here, though, it was likely inevitable that Alexa would’ve goofed spectacularly at some point. I’m not a betting man, but let’s look at the numbers: Right after Christmas, Amazon confirmed that it has sold “tens of millions” of Alexa-enabled devices around the world. New research indicates that Google has for the first time overtaken Amazon as the world’s premier purveyor of smart speakers, but no matter — people are or were talking to at least 20 million Alexa devices around the world. That amounts to a huge number of interactions for Alexa to interpret every day, and it was only a matter of time before the right set of circumstances produced a situation that Alexa just couldn’t handle.

Alexa’s cascading failure here isn’t simply due to a numbers game, either. It’s also because Alexa can be lousy at its job. Looking back through my own Alexa history — which contains recordings of every interaction I’ve ever had with it — reveals a handful of false positives that shouldn’t have triggered the assistant in the first place. In some cases, a droning voice on TV said a word that kinda-sorta sounded like “Alexa,” which prompted the assistant to try and interpret what else the person was saying. In others, the recording stored by Amazon didn’t include the Alexa wake word at all, leaving me perplexed as to why Alexa was trying to listen in the first place. It probably won’t come as a surprise that most of the recordings that lacked an audible “Alexa” were snippets from a television show or a conversation that was never meant for Amazon to hear.

Even now, Alexa is still a more mysterious figure in my life than I’d like. It once laughed at me out of nowhere in the middle of the night, a profoundly creepy feat that very nearly made me hurl my Echo out a window. My stored history also doesn’t include the handful of times when I’ve seen my Echo light up blue out of the corner of my eye. Alexa’s virtual ears clearly perked up, but the assistant never bothered to respond. Since Amazon’s Alexa history only seems to keep records of interactions where Alexa offers a verbal response, I can’t fully explain what’s going on in those moments when Alexa is triggered but remains silent. (Maybe it was one of those silent, Alexa-triggering signals we’ve known about for months.)

Considering the number of accidental triggers and responses in my history, it’s not hard to imagine how the right kind of conversation could have prompted Alexa to send a recording to a random contact. As Amazon says, this was incredibly unlikely, but as long as Alexa remains aggressive in attempting to pull signals from noise, these situations will never be completely impossible.

Amazon has said that it’s working on ways to make these kinds of situations even less likely, a tacit admission that Alexa still needs work. Even that may be an understatement. Through the process of recording a family and sending that recording to someone else, Alexa was doing exactly what it was designed to: It listened for signals regardless of their origin and took action based on those signals. Had Alexa been able to more fully understand what was being said in that conversation, it’s likely this whole thing would’ve never have happened. While Alexa has become one of the dominant voice assistants out there, it is in some ways surprisingly unsophisticated, and the only way to prevent these situations from happening again is to make Alexa smarter. Amazon is clearly keen to take on the task, but until the company’s engineers push some new boundaries, don’t be surprised if Alexa continues to surprise with its occasional incompetence.

Tech

via Engadget http://www.engadget.com

May 25, 2018 at 01:06PM

Posted in Family | Tagged Feedly, IFTTT | Leave a comment

Uber’s Self-Driving Car Saw the Woman It Killed, Report Says

Posted on May 25, 2018 by peterjang73

Uber’s Self-Driving Car Saw the Woman It Killed, Report Says

https://ift.tt/2ILEwX7

Uber's Self-Driving Car Saw the Woman It Killed, Report Says | WIRED

The federal investigators examining Uber’s fatal self-driving crash in March released a preliminary report this morning. It lays out the facts of the collision that killed a pedestrian in Tempe, Arizona, and explains what the car actually saw that night.

The National Transportation Safety Board won’t determine the cause of the crash or issue safety recommendations to stop others from happening until it releases its final report, but this first look makes two things clear: Engineering a car that drives itself is very hard. And any self-driving car developer that is currently relying on a human operator to monitor its testing systems—to keep everyone on the road safe—should be extraordinarily careful about the design of that system.

The report says that the Uber car, a modified Volvo XC90 SUV, had been in autonomous mode for 19 minutes and was driving at about 40 mph when it hit 49-year-old Elaine Herzberg as she was walking her bike across the street. The car’s radar and lidar sensors detected Herzberg about six seconds before the crash, first identifying her as an unknown object, then as a vehicle, and then as a bicycle, each time adjusting its expectations for her path of travel.

About a second before impact, the report says, “the self-driving system determined that an emergency braking maneuver was needed to mitigate a collision.” Uber, however, does not allow its system to make emergency braking maneuvers on its own. Rather than risk “erratic vehicle behavior”—like slamming on the brakes or swerving to avoid a plastic bag—Uber relies on its human operator to watch the road and take control when trouble arises.

Furthermore, Uber had turned off the Volvo’s built-in automatic emergency braking system to avoid clashes with its own tech. This is standard practice, experts say. “The vehicle needs one master,” says Raj Rajkumar, an electrical engineer who studies autonomous systems at Carnegie Mellon University. “Having two masters could end up triggering conflicting commands.” But that works a lot better when the master of the moment works the way it’s meant to.

1.3 seconds before hitting Elaine Herzberg, Uber’s car decided emergency braking was necessary—but didn’t have the ability to do that on its own. The yellow bands show distance in meters, and the purple indicates the car’s path.