Connect with us

Security

HACKERS FOUND A (NOT-SO-EASY) WAY TO MAKE THE AMAZON ECHO A SPY BUG

Published

on

Since smart speakers like the Amazon Echo first began to appear in homes across the world, the security community has come to see them as a prime target. But that threat has remained largely hypothetical: No Echo malware has appeared in the wild, and even proof-of-concept attacks on the devices have remained impractical at best.

Now, one group of Chinese hackers has spent months developing a new technique for hijacking Amazon’s voice assistant gadget. It’s still hardly a full-blown remote takeover of those smart speakers. But it may be the closest thing yet to a practical demonstration of how the devices might be silently hijacked for surveillance.

 

At the DefCon security conference Sunday, researchers Wu Huiyu and Qian Wenxiang plan to present a technique that chains together a series of bugs in Amazon’s second-generation Echo to take over the devices, and stream audio from its microphone to a remote attacker, while offering no clue to the user that the device has been compromised.

Echo owners shouldn’t panic: The hackers already alerted Amazon to their findings, and the company pushed out security fixes in July. Even before then, the attack required some serious hardware skills, as well as access to the target Echo’s Wi-Fi network—a degree of difficulty that likely means it wouldn’t be used against the average Echo owner. But the effort nonetheless sheds new light on how an Echo eavesdropping technique might work against a high-value target.

“After several months of research, we successfully break the Amazon Echo by using multiple vulnerabilities in the Amazon Echo system, and [achieve] remote eavesdropping,” reads a description of their work provided to WIRED by the hackers, who work on the Blade team of security researchers at Chinese tech giant Tencent. “When the attack [succeeds], we can control Amazon Echo for eavesdropping and send the voice data through network to the attacker.”

The research also raises the specter of more direct physical access attacks on a victim’s Echo.

The researchers’ attack, though already patched, demonstrates how hackers can tie together a devious collection of tricks to create an intricate multistep penetration technique that works against even a relatively secure gadget like the Echo. They start by taking apart an Echo of their own, removing its flash chip, writing their own firmware to it, and re-soldering the chip back to the Echo’s motherboard. That altered Echo will serve as a tool for attacking other Echoes: Using a series of web vulnerabilities in the Alexa interface on Amazon.com that included cross-site scripting, URL redirection, and HTTPS downgrade attacks—all since fixed by Amazon—they say that they could link their hacked Echo with a target user’s Amazon account.

If they can then get that doctored Echo onto the same Wi-Fi network as a target device, the hackers can take advantage of a software component of Amazon’s speakers, known as Whole Home Audio Daemon, that the devices use to communicate with other Echoes in the same network. That daemon contained a vulnerability that the hackers found they could exploit via their hacked Echo to gain full control over the target speaker, including the ability to make the Echo play any sound they chose, or more worryingly, silently record and transmit audio to a faraway spy.

That requirement that the victim and attacker be on the same Wi-Fi network represents a serious limitation to the attack. It means that, even after some serious hardware hacking, an Echo attacker would have had to know a target’s Wi-Fi password or otherwise gain network access. But the researchers argue that an Echo spy could potentially brute force the Wi-Fi password, trick a victim into installing their altered Echo themselves and linking it to their Wi-Fi, or the attack could be performed on Echoes in environments with more widely shared passwords, like hotels and schools.

When WIRED reached out to Amazon about the attack, the company responded in a statement that “customers do not need to take any action as their devices have been automatically updated with security fixes.” The spokesperson also wrote that “this issue would have required a malicious actor to have physical access to a device and the ability to modify the device hardware.”

That last point, to be clear, isn’t as comforting as it sounds. The hackers would have had to have access to the victim Echo’s Wi-Fi, but would only need hands-on physical access to their own Echo, which they could alter to create their attack tool in the privacy of their lab.

‘They’d make phenomenal listening devices if you can exploit them.’

Former NSA Hacker Jake Williams

The research also raises the specter of more direct physical access attacks on a victim’s Echo, if a hacker can manage to get some alone time with it in the target’s home or hotel room. The researchers mention in passing that they were able to alter the firmware of their own Echoes in just minutes, suggesting that they might be able to physically plant spyware on a target Echo just as quickly. “After a period of practice, we can now use the manual soldering method to remove the firmware chip…from the motherboard and extract the firmware within 10 minutes, then modify the firmware within 5 minutes and [attach it] back to the device board,” they write. “The success rate is nearly 100 percent. We have used this method to create a lot of rooted Amazon Echo devices.”

The Tencent researchers aren’t the first to demonstrate techniques that transform Echos into spy tools. British hacker Mark Barnes last year published a technique that uses physical access to a first-generation Echo to install malware on it via metal contacts accessible under its rubber base. Researchers at security firm Checkmarx later showed they could hijack an Amazon Echo remotely, but only when its owner downloads the attacker’s software extension—what Amazon calls a “skill”—to their device, the equivalent of sneaking a malicious Android app into the Google Play Store and tricking users into downloading it. Unlike the Tencent hackers’ work, neither earlier technique represented a targeted, over-the-network Echo-hacking technique.

A truly remote Echo hack wouldn’t be easy, says Jake Williams, a former member of the NSA’s elite hacking team Tailored Access Operations. He points out that the devices primarily accept only voice input and cloud communications via an encrypted connection with Amazon’s server, creating a very limited “attack surface” for hackers to exploit. Hence the Tencent researchers’ clever use of Amazon’s Echo-to-Echo communications instead.

But if spies could compromise a smart speaker like the Echo, it would make a powerful surveillance device, Williams notes. Unlike a phone, for instance, it picks up sound not only directly next to the device, but anywhere in earshot. “These smart speakers are designed to pick up all the noises in the room, listen and transcribe them,” says Williams. “As a result they’d make phenomenal listening devices if you can exploit them.”

Even the Tencent hackers’ work doesn’t prove that eavesdropper’s dream has come true just yet. But you’d be forgiven for eyeing your Echo warily in the meantime.

Continue Reading
Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Security

UPDATES ON CYBERSECURITY, WORDPRESS AND WHAT WE’RE COOKING IN THE LAB TODAY.

Published

on

Yes, You Should Probably Have A TLS Certificate

This entry was posted in General Security, WordPress Security on September 18, 2018 by Mikey Veenstra   9 Replies


Last week’s article covering the decision to distrust Symantec-issued TLS certificates generated a great response from our readers. One common question we received, and one that pops up just about any time SSL/TLS comes up, is how to determine when a site does and does not need such a certificate. Spoiler: Your site should probably have a TLS certificate.

A subject of some discussion in the web community surrounds the use of TLS certificates and the implementation of HTTPS that these certificates allow. While their use is critical on sites where sensitive data from visitors may be involved, like payment data or other personally identifiable information (PII), the debate concerns the use of HTTPS in cases where users aren’t providing sensitive input. In today’s post, we’ll take a practical look at the difference between HTTP and HTTPS traffic, and discuss the benefits of being issued a certificate regardless of the way users interact with your site.

What’s TLS? Is It Different From SSL?

Before we really dig in, let’s clear up some terminology for anyone who might be unfamiliar.

HTTPS (short for Hypertext Transfer Protocol Secure) allows for the secure transmission of data, especially in the case of traffic to and from websites on the internet. The security afforded by HTTPS comes from the implementation of two concepts, encryption and authenticationEncryption is a well-known concept, referring to the use of cryptographyto communicate data in a way that only the intended recipient can read. Authentication can mean different things based on context, but in terms of HTTPS it means verification is performed to ensure the server you’re connecting to is the one the domain’s owner intended you to reach. The authentication portion of the transaction relies on a number of trusted sources, called Certificate Authorities (CA for short). When a certificate is requested for a domain name, the issuing CA is responsible for validating the requestor’s ownership of that domain. The combination of validation and encryption provides the site’s visitors with assurance that their traffic is privately reaching its intended destination, not being intercepted midway and inspected or altered.

TLS, or Transport Layer Security, is the open standard used across the internet to facilitate HTTPS communications. It’s the successor to SSL, or Secure Sockets Layer, although the name “SSL” has notoriously picked up common usage as an interchangeable term for TLS despite it being a deprecated technology. In general when someone brings up SSL certificates, outside of the off chance they’re literally referring to the older standard, they’re probably talking about TLS. It’s a seemingly minor distinction, but it’s one we hope will gain stronger adoption in the future.

I Shouldn’t Use TLS Unless I Really Need To, Right?

There’s no shortage of conflicting advice across the web regarding when to implement TLS and when to leave a site insecure, so it’s no surprise that a lot of strong opinions develop on both sides of the issue. Outside of cut-and-dry cases like PCI compliance, where payment transactions need to be secure to avoid a policy violation, you’ll find plenty of arguments suggesting cases where the use of TLS is unnecessary or even harmful to a website. Common arguments against the wide use of TLS tend to fall into two general categories: implementation and performance.

Concerns about implementation difficulties with TLS, like the cost of purchasing a certificate, difficulty in setting up proper HTTPS redirects, and compatibility in general are common, but are entirely manageable. In fact, TLS has never been more accessible. Let’s Encrypt, a free certificate issuer which launched in early 2016, has issued just under two-thirds of the active TLS certificates on the internet at the time of this writing. Following the flood of free certificates into the marketplace, many popular web hosting companies have begun allowing Let’s Encrypt certificates to be installed on their hosted sites, or are at least including their own certificates for free with their hosting. After all, site owners are more security-conscious now than ever, and many will happily leave a host if TLS is a cost-prohibitive endeavor.

Other pain points in the implementation of HTTPS, like compatibility with a site’s existing application stack, are no different than the pain points you’d see following other security best practices. Put simply, avoiding the use of HTTPS because your site will break is the same as avoiding security updates because your site will break. It’s understandable that you might delay it for a period of time so you can fix the underlying issue, but you still need to fix that issue.

The other arguments against widespread TLS are those of performance concerns. There’s certainly overhead in play, considering the initial key exchange and the processing necessary to encrypt and decrypt traffic on the fly. However, the efficiency of any system is going to depend heavily on implementation. In the case of most sites, the differences in performance are going to be negligible. For the rest, there’s a wealth of information available on how to fine-tune an environment to perform optimally under TLS. As a starting point, I recommend visiting Is TLS Fast Yet? to learn more about the particulars of this overhead and how best to mitigate it.

My Site Doesn’t Take Payments, So Why Bother?

Each debate ultimately hinges on whether the site owner sees value in HTTPS in the first place. A lot of the uncertainty in this regard can be traced to unfamiliarity with the data stored in HTTP requests, as well as the route that these requests travel to reach their destination. To illustrate this, let’s take a look at the contents of a typical WordPress login request.

The request contains a number of interesting pieces of information:

  • The full URL of the destination, including domain and file path
  • User-Agent details, which describe my browser and operating system
  • My referer, which reveals the page I visited prior to this one
  • Any cookies my browser has stored for this site
  • The POST body, which contains the username and password I’m attempting to log in with

The implications of this request falling into the wrong hands should be immediately recognizable in the fact that my username and password are plainly visible. Anyone intercepting this traffic can now establish administrative access to my site.

Contrast this with the same request submitted via HTTPS. In an HTTPS request, the only notable information left unencrypted is the destination hostname, to allow the request to get where it needs to go. As far as any third party is concerned, I’m sending this request instead:

Outside of examples as obvious as login security, the thing to keep in mind above all is the value of privacy. If a site’s owner hasn’t installed a TLS certificate, even though the site is purely informational and takes no user input, any traffic to that site can be inspected by the user’s ISP, or even the administrator of the network they’re connected to. This is notably problematic in certain cases, like when someone might be researching private medical or legal matters, but at the end of the day the content of a site is irrelevant. Granted, my hat probably contains a bit more tinfoil than most, but there’s no denying this is an era where browsing habits are tracked wherever possible. Real examples exist of ISPs injecting advertising into unencrypted traffic, and the world has a nonzero number of governments happy to inspect whatever traffic they can get their hands on. Using HTTPS by default shows your site’s users that their privacy is important to you, regardless of whether your site contains anything you might consider private.

Conclusion

The internet at large is rapidly adopting improved security standards, and the majority of web traffic is now being delivered via HTTPS. It’s more important than ever to make sure you’re providing your users with the assurance that their traffic is private, especially with HTTP pages being flagged as “Not Secure” by popular browsers. Secure-by-default is a great mindset to have, and while many of your users may never notice, the ones who do will appreciate it.

Interested in learning more about secure networking as it pertains to WordPress? Check out our in-depth lesson, Networking For WordPress Administrators. It’s totally free, you don’t even need to give us an email address for it. Just be sure to share the wealth and help spread the knowledge with your peers, either by sharing this post or giving them the breakdown yourself. As always, thanks for reading!

 

 

 

 

Source: https://www.wordfence.com/blog/2018/09/yes-you-should-probably-have-a-tls-certificate/?utm_source=list&utm_medium=email&utm_campaign=091818&_hsenc=p2ANqtz-9wsW46ldFq1FvaoJN0ugMmuxiGBmSjZlqju3IE8PTbFjL2_C24pPWIzlN1ZdbI4H9QBr74OLQmdZsp-niu-7fojYFBDQ&_hsmi=66025383

Continue Reading

Security

MEET THE MALWARE WHICH HIJACKS YOUR BROWSER AND REDIRECTS YOU TO FAKE PAGES

Published

on

The malware is currently being distributed through the RIG exploit kit.

The RIG exploit kit, which at its peak infected an average of 27,000 machines per day, has been grafted with a new tool designed to hijack browsing sessions. The malware in question, a rootkit called CEIDPageLock, has been distributed through the exploit kit in recent weeks.

According to researchers from Check Point, the rootkit was first discovered in the wild several months ago.

CEIDPageLock was detected when it attempted to tamper with a victim’s browser. The malware was attempting to turn their homepage into 2345.com, a legitimate Chinese directory for weather forecasts, TV listings, and more.

The researchers say that CEIDPageLock is sophisticated for a browser hijacker and now a bolt-on for RIG has received “noticeable” improvements.

Among the new additions is functionality which permits user browsing activities to be monitored, alongside the power to change a number of websites with fake home pages.

The malware targets Microsoft Windows systems. The dropper extracts a 32-bit kernel-mode driver which is saved in the Windows temporary directory with the name “houzi.sys.” While signed, the certificate has now been revoked by the issuer.

When the driver executes, hidden amongst standard drivers during setup, the dropper then sends the victim PC’s mac address and user ID to a malicious domain controlled by a command-and-control (C&C) server. This information is then used when a victim begins browsing in order to download the desired malicious homepage configuration.

If victims are redirected from legitimate services to fraudulent ones, this can lead to threat actors obtaining account credentials, victims being issued malicious payloads, as well as the gathering of data without consent.

CNET: That VPNFilter botnet the FBI wanted us to help kill? It’s still alive

“They then either use the information themselves to target their ad campaigns or sell it to other companies that use the data to focus their marketing content,” the team says.

The latest version of the rootkit is also packed with VMProtect, which Check Point says makes an analysis of the malware more difficult to achieve. In addition, the malware prevents browsers from accessing antivirus solutions’ files.

CEIDPageLock appears to focus on Chinese victims. Infection rates number in the thousands for the county, and while Check Point has recorded 40 infections in the United States, the spread of the malware is considered “negligible” outside of China.

“At first glance, writing a rootkit that functions as a browser hijacker and employing sophisticated protections such as VMProtect, might seem like overkill,” Check Point says. “CEIDPageLock might seem merely bothersome and hardly dangerous, the ability to execute code on an infected device while operating from the kernel, coupled with the persistence of the malware, makes it a potentially perfect backdoor.”

According to Trend Micro, exploit kits are still making inroads in the security landscape. RIG remains the most active, followed by GrandSoft and Magnitude.

 

 

Source:  https://www-zdnet-com.cdn.ampproject.org/v/s/www.zdnet.com/google-amp/article/meet-the-malware-which-hijacks-your-browser-redirects-you-to-fake-pages/?amp_js_v=0.1#amp_tf=From%20%251%24s&ampshare=https%3A%2F%2Fwww.zdnet.com%2Farticle%2Fmeet-the-malware-which-hijacks-your-browser-redirects-you-to-fake-pages%2F

Continue Reading

Security

GOOGLE CAMPUS DOORS HACKED, ALLOWED UNAUTHORIZED ENTRY – OTHER COMPANIES VULNERABLE

Published

on

Google engineer found that he was able to hack the supposedly secure doors at the search giant’s Sunnyvale offices. He was able to unlock doors without the RFID key, and even lock out employees who did have their key.

 

Forbes reports that David Tomaschik found what turned out to be a completely inexcusable vulnerability in the Software House devices used to secure the site.

Last summer, when Tomaschik looked at the encrypted messages the Software House devices (called iStar Ultra and IP-ACM) were sending across the Google network, he discovered they were non-random; encrypted messages should always look random if they’re properly protected.

He was intrigued and digging deeper discovered a “hardcoded” encryption key was used by all Software House devices. That meant he could effectively replicate the key and forge commands, such as those asking a door to unlock. Or he could simply replay legitimate unlocking commands, which had much the same effect […] And he could prevent legitimate Google employees from opening doors.

Worse, the hack left no trace in the security logs, so there would be no evidence of whether or not the exploit had ever been used.

The same Software House tech is widely used by other companies, meaning that any number of businesses could be left vulnerable.

Google has been forced to segment its network to prevent exploitation of the flaw, and while Software House has now come up with a solution, that will require new hardware. Software House said only that ‘this issue was addressed with our customers.’

 

Continue Reading
Advertisement

Trending