Daily Archives: October 10, 2018

Control Flow Integrity in the Android kernel


Posted by Sami Tolvanen, Staff Software Engineer, Android Security & Privacy

[Cross-posted from the Android Developers Blog]

Android's security model is enforced by the Linux kernel, which makes it a tempting target for attackers. We have put a lot of effort into hardening the kernel in previous Android releases and in Android 9, we continued this work by focusing on compiler-based security mitigations against code reuse attacks.
Google's Pixel 3 will be the first Android device to ship with LLVM's forward-edge Control Flow Integrity (CFI) enforcement in the kernel, and we have made CFI support available in Android kernel versions 4.9 and 4.14. This post describes how kernel CFI works and provides solutions to the most common issues developers might run into when enabling the feature.

Protecting against code reuse attacks

A common method of exploiting the kernel is using a bug to overwrite a function pointer stored in memory, such as a stored callback pointer or a return address that had been pushed to the stack. This allows an attacker to execute arbitrary parts of the kernel code to complete their exploit, even if they cannot inject executable code of their own. This method of gaining code execution is particularly popular with the kernel because of the huge number of function pointers it uses, and the existing memory protections that make code injection more challenging.
CFI attempts to mitigate these attacks by adding additional checks to confirm that the kernel's control flow stays within a precomputed graph. This doesn't prevent an attacker from changing a function pointer if a bug provides write access to one, but it significantly restricts the valid call targets, which makes exploiting such a bug more difficult in practice.

Figure 1. In an Android device kernel, LLVM's CFI limits 55% of indirect calls to at most 5 possible targets and 80% to at most 20 targets.

Gaining full program visibility with Link Time Optimization (LTO)

In order to determine all valid call targets for each indirect branch, the compiler needs to see all of the kernel code at once. Traditionally, compilers work on a single compilation unit (source file) at a time and leave merging the object files to the linker. LLVM's solution to CFI is to require the use of LTO, where the compiler produces LLVM-specific bitcode for all C compilation units, and an LTO-aware linker uses the LLVM back-end to combine the bitcode and compile it into native code.

Figure 2. A simplified overview of how LTO works in the kernel. All LLVM bitcode is combined, optimized, and generated into native code at link time.
Linux has used the GNU toolchain for assembling, compiling, and linking the kernel for decades. While we continue to use the GNU assembler for stand-alone assembly code, LTO requires us to switch to LLVM's integrated assembler for inline assembly, and either GNU gold or LLVM's own lld as the linker. Switching to a relatively untested toolchain on a huge software project will lead to compatibility issues, which we have addressed in our arm64 LTO patch sets for kernel versions 4.9 and 4.14.
In addition to making CFI possible, LTO also produces faster code due to global optimizations. However, additional optimizations often result in a larger binary size, which may be undesirable on devices with very limited resources. Disabling LTO-specific optimizations, such as global inlining and loop unrolling, can reduce binary size by sacrificing some of the performance gains. When using GNU gold, the aforementioned optimizations can be disabled with the following additions to LDFLAGS:
LDFLAGS += -plugin-opt=-inline-threshold=0 \
-plugin-opt=-unroll-threshold=0
Note that flags to disable individual optimizations are not part of the stable LLVM interface and may change in future compiler versions.

Implementing CFI in the Linux kernel

LLVM's CFI implementation adds a check before each indirect branch to confirm that the target address points to a valid function with a correct signature. This prevents an indirect branch from jumping to an arbitrary code location and even limits the functions that can be called. As C compilers do not enforce similar restrictions on indirect branches, there were several CFI violations due to function type declaration mismatches even in the core kernel that we have addressed in our CFI patch sets for kernels 4.9 and 4.14.
Kernel modules add another complication to CFI, as they are loaded at runtime and can be compiled independently from the rest of the kernel. In order to support loadable modules, we have implemented LLVM's cross-DSO CFI support in the kernel, including a CFI shadow that speeds up cross-module look-ups. When compiled with cross-DSO support, each kernel module contains information about valid local branch targets, and the kernel looks up information from the correct module based on the target address and the modules' memory layout.

Figure 3. An example of a cross-DSO CFI check injected into an arm64 kernel. Type information is passed in X0 and the target address to validate in X1.
CFI checks naturally add some overhead to indirect branches, but due to more aggressive optimizations, our tests show that the impact is minimal, and overall system performance even improved 1-2% in many cases.

Enabling kernel CFI for an Android device

CFI for arm64 requires clang version >= 5.0 and binutils >= 2.27. The kernel build system also assumes that the LLVMgold.so plug-in is available in LD_LIBRARY_PATH. Pre-built toolchain binaries for clang and binutils are available in AOSP, but upstream binaries can also be used.
The following kernel configuration options are needed to enable kernel CFI:
CONFIG_LTO_CLANG=y
CONFIG_CFI_CLANG=y
Using CONFIG_CFI_PERMISSIVE=y may also prove helpful when debugging a CFI violation or during device bring-up. This option turns a violation into a warning instead of a kernel panic.
As mentioned in the previous section, the most common issue we ran into when enabling CFI on Pixel 3 were benign violations caused by function pointer type mismatches. When the kernel runs into such a violation, it prints out a runtime warning that contains the call stack at the time of the failure, and the call target that failed the CFI check. Changing the code to use a correct function pointer type fixes the issue. While we have fixed all known indirect branch type mismatches in the Android kernel, similar problems may be still found in device specific drivers, for example.
CFI failure (target: [<fffffff3e83d4d80>] my_target_function+0x0/0xd80):
------------[ cut here ]------------
kernel BUG at kernel/cfi.c:32!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP

Call trace:

[<ffffff8752d00084>] handle_cfi_failure+0x20/0x28
[<ffffff8752d00268>] my_buggy_function+0x0/0x10
Figure 4. An example of a kernel panic caused by a CFI failure.
Another potential pitfall are address space conflicts, but this should be less common in driver code. LLVM's CFI checks only understand kernel virtual addresses and any code that runs at another exception level or makes an indirect call to a physical address will result in a CFI violation. These types of failures can be addressed by disabling CFI for a single function using the __nocfi attribute, or even disabling CFI for entire code files using the $(DISABLE_CFI) compiler flag in the Makefile.
static int __nocfi address_space_conflict()
{
void (*fn)(void);

/* branching to a physical address trips CFI w/o __nocfi */
fn = (void *)__pa_symbol(function_name);
cpu_install_idmap();
fn();
cpu_uninstall_idmap();

}
Figure 5. An example of fixing a CFI failure caused by an address space conflict.
Finally, like many hardening features, CFI can also be tripped by memory corruption errors that might otherwise result in random kernel crashes at a later time. These may be more difficult to debug, but memory debugging tools such as KASAN can help here.

Conclusion

We have implemented support for LLVM's CFI in Android kernels 4.9 and 4.14. Google's Pixel 3 will be the first Android device to ship with these protections, and we have made the feature available to all device vendors through the Android common kernel. If you are shipping a new arm64 device running Android 9, we strongly recommend enabling kernel CFI to help protect against kernel vulnerabilities.
LLVM's CFI protects indirect branches against attackers who manage to gain access to a function pointer stored in kernel memory. This makes a common method of exploiting the kernel more difficult. Our future work involves also protecting function return addresses from similar attacks using LLVM's Shadow Call Stack, which will be available in an upcoming compiler release.

Finding a Weak Link in the Chain

While supply-chain attacks pose serious risks, many can be avoided or mitigated by focusing on a defense-in-depth approach and basic security best practices.


Category:

CTU Research

While supply-chain attacks pose serious risks, many can be avoided or mitigated by focusing on a defense-in-depth approach and basic cybersecurity best practices.

Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation

The GandCrab ransomware, which first appeared in January, has been updated rapidly during its short life, with Version 5.0.2 appearing this month. In this post we will examine the latest version and how the authors have improved the code (and in some cases have made mistakes). McAfee gateway and endpoint products are able to protect customers from known variants of this threat.

The GandCrab authors have moved quickly to improve the code and have added comments to provoke the security community, law enforcement agencies, and the NoMoreRansom organization. Despite the agile approach of the developers, the coding is not professional and bugs usually remain in the malware (even in Version 5.0.2), but the speed of change is impressive and increases the difficulty of combating it.

The group behind GandCrab has achieved cult status in underground forums; the authors are undoubtedly confident and have strong marketing skills, but flawless programming is not one of their strengths.

Underground alliances

On September 27, the GandCrab crew announced Version 5 with the same showmanship as its earlier versions. GandCrab ransomware has gained a lot of attention from security researchers as well as the underground. The developers market the affiliate program like a “members-only club” and new affiliates are lining up to join, in the hope of making easy money through the large-scale ransomware extortion scheme.

The prospect of making money not only attracts new affiliates, but also leads to the formation of new alliances between GandCrab and other criminal services that strengthen the malware’s supply and distribution networks. One of these alliances became obvious during Version 4, in which the ransomware started being distributed through the new Fallout exploit kit. This alliance was again emphasized in the GandCrab Version 5 announcement, as the GandCrab crew openly endorsed FalloutEK.

The GandCrab Version 5 announcement.

With Version 5, yet another alliance with a criminal service has been formed. The malware crypter service NTCrypt announced that it is partnering with the GandCrab crew. A crypter service provides malware obfuscation to evade antimalware security products.

The NTCrypt-GandCrab partnership announcement offering a special price for GandCrab users.

The partnership between GandCrab and NTCrypt was established in a novel way. At the end of September, the GandCrab crew started a “crypt competition” on a popular underground forum to find a new crypter service they could partner with. NTCrypt applied and eventually won the competition.

The “crypt competition” announcement.

This novel approach emphasizes once more the cult status GandCrab has in the underground community. For a criminal business such as GandCrab, building these alliances makes perfect sense: They increase the ease of operation and a trusted affiliate network minimizes their risk exposure by allowing them to avoid less-trusted suppliers and distributors.

For the security community it is worrisome to see that GandCrab’s aggressive marketing strategy seems to be paying off. It is generating a strong influx of criminal interest and allows the GandCrab crew to form alliances with other essential services in the cybercriminal supply chain.

GandCrab overview

GandCrab Version 5 uses several mechanisms to infect systems. The following diagram shows an overview of GandCrab’s behavior.

GandCrab Version 5 Infection

Entry vector

GandCrab uses several entry vectors:

  • Remote desktop connections with weak security or bought in underground forums
  • Phishing emails with links or attachments
  • Trojanized legitimate programs containing the malware, or downloading and launching it
  • Exploits kits such as RigEK and others such as FalloutEK
  • PowerShell scripts or within the memory of the PowerShell process (the later mainly in Version 5.0.2)
  • Botnets such as Phorpiex (an old botnet that spread not only this malware but many others)

The goal of GandCrab, as with other ransomware, is to encrypt all or many files on an infected system and insist on payment to unlock them. The developer requires payment in cryptocurrency, primarily Dash (or Bitcoin in some older versions), because it is complex to track and quick to receive the payment.

The malware is usually, but not always, packed. We have seen variants in .exe format (the primary form) along with DLLs. GandCrab is effectively ransomware as a service; its operators can choose which version they want.

Version 5.0

This version has two releases. The first works only on Windows 7 or later due to a big mistake in the compiling time. Version 5.0 carries two exploits that try to elevate privileges. It checks the version of the operating system and the TokenIntegrityLevel class of the process. If the SID Subauthority is SECURITY_MANDATORY_LOW_RID (0x1000), it tries to execute the exploits if it also passed one previous check of a mutex value.

One release is the exploit released in August on Twitter and GitHub by the hacker “SandboxEscaper.” The original can be found at this link. The Twitter handle for this hacker is https://twitter.com/sandboxescaper.

This exploit tries to use a problem with the Task System in Windows when the operating system improperly handles calls to an advanced local procedure call.

The GandCrab authors claim there is no CVE of this exploit, but that is incorrect. It falls under CVE-2018-8440. This exploit can affect versions Windows 7 through Windows 10 Server. More information about this exploit can be found at this link.

In the first release of Version 5.0, the malware authors wrote the code exploit using normal calls to the functions. Thus at compiling time the binary has the IAT filled with the DLL needed for some calls. This DLL does not exist in Windows Vista and XP, so the malware fails to run in these systems, showing an error.

Import of xpsprint.dll that will not run on Windows XP or Vista.

The exploit using direct calls.

This release published an HTML file after encrypting the user’s files, but this file was faulty because it did not always have the information needed to decrypt the user’s files.

The second release uses dynamic calls and obfuscates the strings of the exploit, as shown in the previous image. (Earlier they were in plain text.)

The exploit with dynamic calls and obfuscated strings.

The second exploit is covered under CVE-2018-8120, which in Windows 7, Windows Server 2008 R2 and Windows Server 2008 allows an elevation of privileges from the kernel. Thanks to a faulty object in the token of the System process, changing this token in the malware results in executing the malware with System privileges.

Executing the exploit CVE-2018-8120.

You can read more about this exploit on mcafee.com.

The malware checks the version of the operating system and type of user and whether it can get the token elevation information of its own process before employing the use of exploits. In some cases, it fails to infect. For example, in Windows XP the second release of Version 5 runs but does not encrypt the files. (We thank fellow researcher Yassine Lemmou, who shared this information with us.)

We and Lemmou know where the problem is in Version 5.0.2. A few changes to the registry could make the malware run correctly, but we do not want to help the malware authors fix their product. Even though GandCrab’s authors quickly repair mistakes as they are pointed out, they still fail to find some of the basic errors by themselves. (McAfee has had no contact with GandCrab’s developers.)

The second release writes a random extension of five letters instead of using the normal .CRAB or .KRAB extension seen in previous versions. The malware keeps this information as binary data in a new registry entry in the subkey “ext_data\data” and in the value entry of “ext.”

A new registry entry to hold the random extension.

The malware tries creating this new entry in the root key of HKEY_LOCAL_MACHINE. If it cannot—for example, because the user does not have admin rights—it places the entry in the root key HKEY_CURRENT_USER. This entry is deleted in some samples after the files have been encrypted.

Version 5.0.1

This version fixed some internal bugs in the malware but made no other notable changes.

Version 5.0.2

This version changes the random extension length from 5 to 10 characters and fixes some internal bugs. Other bugs remain, however, meaning files cannot always be encrypted.

The latest

This section is based on the latest version of the malware (Version 5.0.2 on October 4), though some elements appear in earlier releases of Version 5. Starting with this version, the malware uses two exploits to try to elevate privileges in the system.

The first exploit uses a dynamic call to the function IsWoW64Process to detect whether the operating system is running in 32 or 64 bits.

The dynamic call to IsWoW64Process with obfuscated strings.

Depending on the result, the malware has two embedded DLLs, encrypted with a simple operation XOR 0x18.

Decrypting the DLL to load with the exploit and fix the header.

The malware authors use a clever trick with fuzzing to avoid detection: The first two bytes of the DLL are trash, something that is later fixed, as we see in the preceding image.

After decryption and loading the exploit, this DLL creates a mutex in the system and some pipes to communicate with the main malware. The malware creates a pipe that the DLL reads later and prepares strings as the mutex string for the DLL.

Preparing the string for the DLL.

The DLL has dummy strings for these strings.

Creating the new mutex and relaunching the process.

This mutex is checked when the malware starts. The function returns a 1 or 0, depending on whether it can open the mutex. Later, this result is checked and if the mutex can be opened the malware will avoid checking the version and will not use the two new exploits to elevate privileges.

Opening the new mutex to check if there is a need to run the exploits.

As with GandCrab Version 4.x and later, the malware later checks the version. If it is Vista or later, it tries to get the “TokenIntegrityLevel” class and relaunch the binary to elevate its privilege with a call to “ShellExecuteExW” with the “runas” application. If the system is Windows XP, the code will avoid that and continue in its normal flow.

This mutex is never created for the main malware; it is created for the DLL loaded using the exploit. To better understand this explanation, this IDA snippet may help:

Explaining the check of mutex and exploits.

This version changes the desktop wallpaper, which is created at runtime and is filled with the extension generated to encrypt the files. (The ransom note text or HTML has the name: <extension_in_uppercase>_DECRYPT. <txt|html>) and the user name of the machine.)

Creating the new wallpaper at runtime.

The username is checked with “SYSTEM.” If the user is “SYSTEM,” the malware puts the name “USER” in the wallpaper.

Checking the name of the user for the wallpaper.

The wallpaper is created in the %TEMP% folder with the name pidor.bmp.

Creating the wallpaper in the temp folder.

Here is an example of strings used in the wallpaper name and to check the name of the user and the format string, whether it is another user, or the final string in the case of SYSTEM user with USER in uppercase.

The name of the wallpaper and special strings.

Finally, the wallpaper is set for any user other than SYSTEM:

Changing the wallpaper.

The malware detects the language of the system and decrypts the strings and writes the correct ransom note in the language of the system.

Coverage

Customers of McAfee gateway and endpoint products are protected against the latest GandCrab versions. Detection names include Ran-Gandcrabv4! and many others.

An independent researcher, Twitter user Valthek, has also created several vaccines. (McAfee has verified that these vaccines are effective.) The version for GandCrab 4.x through 5.0.2 can prevent the files from being encrypted.

For Version 4.x, the deletion of shadow volumes cannot be avoided but at least the files themselves are kept safe.

For Version 5.x, encrypting the files can be avoided but not the creation and changing of the wallpaper, which the malware will still corrupt. The malware cannot create random extensions to encrypt the files but will prepare the string. Running the vaccine a second time removes the wallpaper if it is in the %TEMP% folder.

The vaccine has versions with and without persistence. The version with persistence creates a random filename in a special folder and writes a special random entry in the registry to run each time with the system. In this case, the machine will always be protected against this malware (at least in its current state of October 10, and perhaps in the future).

 

Indicators of compromise

These samples use the following MITRE ATT&CK™ techniques:

  • File deletion
  • System information discovery
  • Execution through API
  • Execution through WMIC
  • Application process discovery: to detect antimalware and security products as well as normal programs
  • Query registry: to get information about keys that the malware needs to create or read
  • Modify registry
  • File and directory discovery: to search for files to encrypt
  • Discovery of network shares to encrypt them
  • Encrypt files
  • Process discovery: enumerating all processes on the endpoint to kill some special ones
  • Create files
  • Elevation of privileges
  • Change wallpaper
  • Flood the network with connections
  • Create mutants

Hashes 

  • e168e9e0f4f631bafc47ddf23c9848d7: Version 5.0
  • 6884e3541834cc5310a3733f44b38910: Version 5.0 DLL
  • 2d351d67eab01124b7189c02cff7595f: Version 5.0.2
  • 41c673415dabbfa63905ff273bdc34e9: Version 5.0.2
  • 1e8226f7b587d6cd7017f789a96c4a65: DLL for 32-bit exploit
  • fb25dfd638b1b3ca042a9902902a5ff9: DLL for 64-bit exploit
  • df1a09dd1cc2f303a8b3d5097e53400b: botnet related to the malware (IP 92.63.197.48)

 

The post Rapidly Evolving Ransomware GandCrab Version 5 Partners With Crypter Service for Obfuscation appeared first on McAfee Blogs.

CVE-2018-12596 (ektron_cms)

Episerver Ektron CMS before 9.0 SP3 Site CU 31, 9.1 before SP3 Site CU 45, or 9.2 before SP2 Site CU 22 allows remote attackers to call aspx pages via the "activateuser.aspx" page, even if a page is located under the /WorkArea/ path, which is forbidden (normally available exclusively for local admins).

CVE-2018-12410 (spotfire_statistics_services)

The web server component of TIBCO Software Inc's Spotfire Statistics Services contains multiple vulnerabilities that may allow the remote execution of code. Without needing to authenticate, an attacker may be able to remotely execute code with the permissions of the system account used to run the web server component. Affected releases are TIBCO Software Inc. TIBCO Spotfire Statistics Services versions up to and including 7.11.0.

CVE-2018-12544 (vert.x)

In version from 3.5.Beta1 to 3.5.3 of Eclipse Vert.x, the OpenAPI XML type validator creates XML parsers without taking appropriate defense against XML attacks. This mechanism is exclusively when the developer uses the Eclipse Vert.x OpenAPI XML type validator to validate a provided schema.

CVE-2018-12541 (vert.x)

In version from 3.0.0 to 3.5.3 of Eclipse Vert.x, the WebSocket HTTP upgrade implementation buffers the full http request before doing the handshake, holding the entire request body in memory. There should be a reasonnable limit (8192 bytes) above which the WebSocket gets an HTTP response with the 413 status code and the connection gets closed.

How the McAfee Rotation Program is Providing Opportunities

 By: Darius, Sales & Marketing Rotation Engineer

“The sky is the limit.” It’s a phrase I heard frequently growing up, in school, college and university. To me, the phrase means there are endless opportunities. So, my nine-year-old self desired to be a racecar driver, my freshman year ambition was to be a developer and then my “final” plan was to work in power transmission/distribution or renewable energy.

After graduation, with all these possibilities, I still didn’t really have a clear picture of what I wanted to do. I focused on volunteering and earning great grades in school, but like many of my peers, I hadn’t really prepared for life after college. I hadn’t thought seriously enough about my career path.

What I did know was this: I wanted to use my technical skills while at the same time learn the business side of an industry. It was my broad interest that led me to the McAfee Rotation Program (MRP) in the summer of 2017.

Wide-ranging Experience

The MRP is perfect for anyone who is attracted to the cybersecurity industry but wants experience in a range of business units. I’m gaining extensive knowledge of cybersecurity products and services, developing my technical and business acumen, building communication skills and expanding my network.

The MRP consist of five four-month placements known as “rotations.” This includes our Professional Services, Pre-Sales Engineering, the Security Operations Center, Support and Sales Operations units.

During the first three of my five rotations, I’ve had the opportunity to build my brand, learn McAfee values and business strategies, make a real impact on the departments I’ve worked with and learn from outstanding mentors.

No Fear!

We innovate without fear—this is an important McAfee value. The MRP gave me several opportunities to become a trailblazer and make a real impact with fresh ideas.

During my first rotation in Professional Services, I helped to accelerate the sales cycle with a new opportunity tracking system that included weekly reports. My line management and I could see an instant difference with the new system, which was most satisfying. I am grateful to work for a company that encourages innovation and creative thinking.

Rapid Learning

In my second rotation with Pre-Sales Engineering, I took on detailed product knowledge in multiple solutions through the projects I worked on in my day-to-day job experience.

With mentorship from senior sales engineers, I put my new knowledge and understanding to the test when I demonstrated McAfee’s Endpoint Security and Threat Intelligence Exchange solutions to a customer. This also gave me the chance to work with technical and commercial departments simultaneously.

My rapid acquisition of knowledge, understanding and experience continued in my third rotation with our Security Operations Center (SOC). In the SOC, I have learned first-hand how vital security is and gained a broad spread of new skills and knowledge, applicable across all business units.

Opportunities Abound

The MRP has created opportunities that I could never have imagined. “The sky is the limit” has taken on a whole new meaning for me.

During my first year at McAfee, I have grown professionally, become a more well-rounded individual and experienced more about business operations than many people do throughout their entire career. I can’t recommend the McAfee Rotation Program enough. It’s given me confidence that I can achieve great things—but I’m also honing in on what I want to do with my career and where my skills are best suited. I can’t wait to see what the next two rotations bring!

For more stories like this, follow @LifeAtMcAfee on Instagram and on Twitter @McAfee to see what working at McAfee is all about.

Interested in the McAfee Rotation Program? Find out more here.

The post How the McAfee Rotation Program is Providing Opportunities appeared first on McAfee Blogs.

As Search Engines Blacklist Fewer Sites, Users More Vulnerable to Attack

Turns out, it’s a lot harder for a website to get blacklisted than one might think. A new study found that while the number of bot malware infected websites remained steady in Q2 of 2018, search engines like Google and Bing are only blacklisting 17 percent of infected websites they identify. The study analyzed more than six million websites with malware scanners to arrive at this figure, noting that there was also a six percent decrease in websites being blacklisted over the previous year.

Many internet users rely on these search engines to flag malicious websites and protect them as they surf the web, but this decline in blacklisting sites is leaving many users just one click away from a potential attack. This disregard of a spam attack kit on search engine results for these infected sites can lead to serious disruption, including a sharp decline in customer trust. Internet users need to be more vigilant than ever now that search engines are dropping the ball on blacklisting infected sites, especially considering that total malware went up to an all-time high in Q2, representing the second highest attack vector from 2017-2018, according to the recent McAfee Labs Threats Report.

Another unsettling finding from the report was that incidents of cryptojacking have doubled in Q2 as well, with cybercriminals continuing to carry out both new and traditional malware attacks. Cryptojacking, the method of hijacking a browser to mine cryptocurrency, saw quite a sizable resurgence in late 2017 and has continued to be a looming threat ever since. McAfee’s Blockchain Threat Report discovered that almost 30,000 websites host the Coinhive code for mining cryptocurrency with or without a user’s consent—and that’s just from non-obfuscated sites.

And then, of course, there are just certain search terms that are more dangerous and leave you more vulnerable to malware than others. For all of you pop culture aficionados, be careful which celebrities you digitally dig up gossip around. For the twelfth year in a row, McAfee researched famous individuals to assess their online risk and which search results could expose people to malicious sites, with this year’s Most Dangerous Celebrity to search for being “Orange is the New Black’s” Ruby Rose.

So, how can internet users protect themselves when searching for the knowledge they crave online, especially considering many of the most popular search engines simply aren’t blacklisting as many bot malware infected sites as they should be? Keep these tips in mind:

  • Turn on safe search settings. Most browsers and search engines have a safe search setting that filters out any inappropriate or malicious content from showing up in search results. Other popular websites like iTunes and YouTube have a safety mode to further protect users from potential harm.
  • Update your browsers consistently. A crucial security rule of thumb is always updating your browsers whenever an update is available, as security patches are usually included with each new version. If you tend to forget to update your browser, an easy hack is to just turn on the automatic update feature.
  • Be vigilant of suspicious-looking sites. It can be challenging to successfully identify malicious sites when you’re using search engines but trusting your gut when something doesn’t look right to you is a great way of playing it safe.
  • Check a website’s safety rating. There are online search tools available that will analyze a given URL in order to ascertain whether it’s a genuinely safe site to browse or a potentially malicious one infected with bot malware and other threats.
  • Browse with security protection. Utilizing solutions like McAfee WebAdvisor, which keeps you safe from threats while you search and browse the web, or McAfee Total Protection, a comprehensive security solution that protects devices against malware and other threats, will safeguard you without impacting your browsing performance or experience.

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

The post As Search Engines Blacklist Fewer Sites, Users More Vulnerable to Attack appeared first on McAfee Blogs.

How To Spot Tech Support Scams

When something goes wrong with your computer or devices, it can cause a panic. After all, most of us depend on technology not only to work and connect with others, but also to stay on top of our daily lives. That’s why tech support scams are often successful. They appear to offer help when we need it the most. But falling for these scams can put your devices, data, and money at even greater risk.

Although support scams have been around almost as long as the internet, these threats have increased dramatically over the last couple of years, proving to be a reliable way for scammers to make a quick buck.

In fact, the Internet Crime Complaint Center (IC3) said that it received nearly 11,000 tech support related complaints in 2017, leading to losses of $15 million, 90% higher than the losses reported in 2016. Microsoft alone saw a 24% increase in tech scams reported by customers in 2017 over the previous year, with 15% of victims saying they lost money.

Often, scammers convince users that there is a problem with their computer or device by delivering pop-up error messages. These messages encourage the user to “click” to troubleshoot the problem, which can download a piece of malware onto their machine, or prompt them to buy fake security software to fix the issue. In some cases, users wind up downloading ransomware, or paying $200 to $400 for fake software to fix problems they didn’t actually have.

And, in a growing number of instances, scammers pose as legitimate technology companies, offering phony support for real tech issues. Some even promote software installation and activation for a fee, when the service is actually provided for free from the software provider. They do this by posting webpages or paid search results using the names of well-known tech companies. When a user searches for tech help, these phony services can appear at the top of the search results, tricking people into thinking they are the real deal.

Some cybercriminals have even gone so far as to advertise fake services on legitimate online forums, pretending to be real tech companies such as Apple, McAfee, and Amazon. Since forum pages are treated as quality content by search engines, these phony listings rank high in search results, confusing users who are looking for help.

The deception isn’t just online. More and more computer users report phone calls from cybercrooks pretending to be technology providers, warning them about problems with their accounts, and offering to help resolve the issue for a fee. Or worse, the scammer requests access to the victim’s computer to “fix the problem”, with the hopes of grabbing valuable data, such as passwords and identity information. All of these scams leave users vulnerable.

Here’s how to avoid support scams to keep your devices and data safe:

  • If you need help, go straight to the source—Type the address of the company you want to reach directly into the address bar of your browser—not the search bar, which can pull up phony results. If you have recently purchased software and need help, check the packaging the software came in for the correct web address or customer support line. If you are a McAfee customer, you can always reach us at https://service.mcafee.com.
  • Be suspicious—Before you pay for tech support, do your homework. Research the company by looking for other customer’s reviews. Also, check to see if your technology provider already offers the support you need for free.
  • Be wary of callers asking for personal information, especially if they reach out to you first—Situations like this happen all the time, even to institutions like the IRS. McAfee’s own policy is to answer support questions via our website only, and if users need assistance, they should reach out here directly. Never respond to unsolicited phone calls or pop-up messages, warning you about a technical issue, and never let anyone take over your computer or device remotely.
  • Surf Safe—Sometimes it can be hard to determine if search results are safe to click on, or not. Consider using a browser extension that can warn you about suspicious sites right in your search results, and help protect you even if you click on a dangerous link.
  • Keep informed—Stay up-to-date on the latest tech support scams so you know what to watch out for.

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 Tech Support Scams appeared first on McAfee Blogs.

CVE-2018-12173 (compute_module_hns2600bp_firmware, compute_module_hns2600bpr_firmware, server_board_s2600bp_firmware, server_board_s2600bpr_firmware, server_board_s2600st_firmware, server_board_s2600str_firmware, server_board_s2600wf_firmware, server_board_s2600wfr_firmware, server_system_h2000g_firmware, server_system_h2000gr_firmware, server_system_r1000wf_firmware, server_system_r1000wfr_firmware, server_system_r2000wf_firmware, server_system_r2000wfr_firmware)

Insufficient access protection in firmware in Intel Server Board, Intel Server System and Intel Compute Module before firmware version 00.01.0014 may allow an unauthenticated attacker to potentially execute arbitrary code resulting in information disclosure, escalation of privilege and/or denial of service via local access.

CVE-2018-0062 (junos)

A Denial of Service vulnerability in J-Web service may allow a remote unauthenticated user to cause Denial of Service which may prevent other users to authenticate or to perform J-Web operations. Affected releases are Juniper Networks Junos OS: 12.1X46 versions prior to 12.1X46-D77 on SRX Series; 12.3 versions prior to 12.3R12-S10; 12.3X48 versions prior to 12.3X48-D60 on SRX Series; 15.1 versions prior to 15.1R7; 15.1F6; 15.1X49 versions prior to 15.1X49-D120 on SRX Series; 15.1X53 versions prior to 15.1X53-D59 on EX2300/EX3400 Series; 15.1X53 versions prior to 15.1X53-D67 on QFX10K Series; 15.1X53 versions prior to 15.1X53-D234 on QFX5200/QFX5110 Series; 15.1X53 versions prior to 15.1X53-D470, 15.1X53-D495 on NFX Series; 16.1 versions prior to 16.1R6; 16.2 versions prior to 16.2R2-S6, 16.2R3; 17.1 versions prior to 17.1R2-S6, 17.1R3; 17.2 versions prior to 17.2R3; 17.3 versions prior to 17.3R2. No other Juniper Networks products or platforms are affected by this issue.

CVE-2018-0060 (junos)

An improper input validation weakness in the device control daemon process (dcd) of Juniper Networks Junos OS allows an attacker to cause a Denial of Service to the dcd process and interfaces and connected clients when the Junos device is requesting an IP address for itself. Junos devices are not vulnerable to this issue when not configured to use DHCP. Affected releases are Juniper Networks Junos OS: 12.1X46 versions prior to 12.1X46-D40 on SRX Series; 12.3X48 versions prior to 12.3X48-D20 on SRX Series; 14.1X53 versions prior to 14.1X53-D40 on EX2200/VC, EX3200, EX3300/VC, EX4200, EX4300, EX4550/VC, EX4600, EX6200, EX8200/VC (XRE), QFX3500, QFX3600, QFX5100; 15.1X49 versions prior to 15.1X49-D20 on SRX Series; 15.1X53 versions prior to 15.1X53-D68 on QFX10000 Series; 15.1X53 versions prior to 15.1X53-D235 on QFX5200/QFX5110; 15.1X53 versions prior to 15.1X53-D495 on NFX150, NFX250; 15.1X53 versions prior to 15.1X53-D590 on EX2300/EX3400; 15.1 versions prior to 15.1R7-S2.

CVE-2018-0061 (junos)

A denial of service vulnerability in the telnetd service on Junos OS allows remote unauthenticated users to cause high CPU usage which may affect system performance. Affected releases are Juniper Networks Junos OS: 12.1X46 versions prior to 12.1X46-D81 on SRX Series; 12.3 versions prior to 12.3R12-S11; 12.3X48 versions prior to 12.3X48-D80 on SRX Series; 15.1 versions prior to 15.1R7; 15.1X49 versions prior to 15.1X49-D150, 15.1X49-D160 on SRX Series; 15.1X53 versions prior to 15.1X53-D59 on EX2300/EX3400 Series; 15.1X53 versions prior to 15.1X53-D68 on QFX10K Series; 15.1X53 versions prior to 15.1X53-D235 on QFX5200/QFX5110 Series; 15.1X53 versions prior to 15.1X53-D495 on NFX Series; 16.1 versions prior to 16.1R4-S12, 16.1R6-S6, 16.1R7; 16.2 versions prior to 16.2R2-S7, 16.2R3; 17.1 versions prior to 17.1R2-S9, 17.1R3; 17.2 versions prior to 17.2R2-S6, 17.2R3; 17.2X75 versions prior to 17.2X75-D100; 17.3 versions prior to 17.3R2-S4, 17.3R3; 17.4 versions prior to 17.4R1-S5, 17.4R2; 18.2X75 versions prior to 18.2X75-D5.

CVE-2018-0058 (junos)

Receipt of a specially crafted IPv6 exception packet may be able to trigger a kernel crash (vmcore), causing the device to reboot. The issue is specific to the processing of Broadband Edge (BBE) client route processing on MX Series subscriber management platforms, introduced by the Tomcat (Next Generation Subscriber Management) functionality in Junos OS 15.1. This issue affects no other platforms or configurations. Affected releases are Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S2, 15.1R8 on MX Series; 16.1 versions prior to 16.1R4-S11, 16.1R7-S2, 16.1R8 on MX Series; 16.2 versions prior to 16.2R3 on MX Series; 17.1 versions prior to 17.1R2-S9, 17.1R3 on MX Series; 17.2 versions prior to 17.2R2-S6, 17.2R3 on MX Series; 17.3 versions prior to 17.3R2-S4, 17.3R3-S2, 17.3R4 on MX Series; 17.4 versions prior to 17.4R2 on MX Series; 18.1 versions prior to 18.1R2-S3, 18.1R3 on MX Series; 18.2 versions prior to 18.2R1-S1, 18.2R2 on MX Series.

CVE-2018-0063 (junos)

A vulnerability in the IP next-hop index database in Junos OS 17.3R3 may allow a flood of ARP requests, sent to the management interface, to exhaust the private Internal routing interfaces (IRIs) next-hop limit. Once the IRI next-hop database is full, no further next hops can be learned and existing entries cannot be cleared, leading to a sustained denial of service (DoS) condition. An indicator of compromise for this issue is the report of the following error message: %KERN-4: Nexthop index allocation failed: private index space exhausted This issue only affects the management interface, and does not impact regular transit traffic through the FPCs. This issue also only affects Junos OS 17.3R3. No prior versions of Junos OS are affected by this issue. Affected releases are Juniper Networks Junos OS: 17.3R3.

CVE-2018-0055 (junos)

Receipt of a specially crafted DHCPv6 message destined to a Junos OS device configured as a DHCP server in a Broadband Edge (BBE) environment may result in a jdhcpd daemon crash. The daemon automatically restarts without intervention, but a continuous receipt of crafted DHCPv6 packets could leaded to an extended denial of service condition. This issue only affects Junos OS 15.1 and later. Earlier releases are unaffected by this issue. Devices are only vulnerable to the specially crafted DHCPv6 message if DHCP services are configured. Devices not configured to act as a DHCP server are not vulnerable to this issue. Affected releases are Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S2; 15.1X49 versions prior to 15.1X49-D160; 15.1X53 versions prior to 15.1X53-D235, 15.1X53-D495; 16.1 versions prior to 16.1R4-S11, 16.1R6-S6, 16.1R7-S2; 16.2 versions prior to 16.2R2-S7; 17.1 versions prior to 17.1R2-S9; 17.2 versions prior to 17.2R2-S6; 17.3 versions prior to 17.3R3-S1; 17.4 versions prior to 17.4R1-S5; 18.1 versions prior to 18.1R2-S3; 18.2 versions prior to 18.2R1-S2; 18.2X75 versions prior to 18.2X75-D20.

CVE-2018-0056 (junos)

If a duplicate MAC address is learned by two different interfaces on an MX Series device, the MAC address learning function correctly flaps between the interfaces. However, the Layer 2 Address Learning Daemon (L2ALD) daemon might crash when attempting to delete the duplicate MAC address when the particular entry is not found in the internal MAC address table. This issue only occurs on MX Series devices with l2-backhaul VPN configured. No other products or platforms are affected by this issue. Affected releases are Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S1 on MX Series; 16.1 versions prior to 16.1R4-S12, 16.1R6-S6 on MX Series; 16.2 versions prior to 16.2R2-S7 on MX Series; 17.1 versions prior to 17.1R2-S9 on MX Series; 17.2 versions prior to 17.2R1-S7, 17.2R2-S6 on MX Series; 17.3 versions prior to 17.3R2-S4, 17.3R3-S1 on MX Series; 17.4 versions prior to 17.4R1-S5 on MX Series; 18.1 versions prior to 18.1R2 on MX Series.

CVE-2018-0052 (junos)

If RSH service is enabled on Junos OS and if the PAM authentication is disabled, a remote unauthenticated attacker can obtain root access to the device. RSH service is disabled by default on Junos. There is no documented CLI command to enable this service. However, an undocumented CLI command allows a privileged Junos user to enable RSH service and disable PAM, and hence expose the system to unauthenticated root access. When RSH is enabled, the device is listing to RSH connections on port 514. This issue is not exploitable on platforms where Junos release is based on FreeBSD 10+. Affected releases are Juniper Networks Junos OS: 12.1X46 versions prior to 12.1X46-D77 on SRX Series; 12.3 versions prior to 12.3R12-S10; 12.3X48 versions prior to 12.3X48-D75 on SRX Series; 14.1X53 versions prior to 14.1X53-D47 on QFX/EX Series; 15.1 versions prior to 15.1R4-S9, 15.1R6-S6, 15.1R7; 15.1X49 versions prior to 15.1X49-D131, 15.1X49-D140 on SRX Series; 15.1X53 versions prior to 15.1X53-D59 on EX2300/EX3400 Series; 15.1X53 versions prior to 15.1X53-D67 on QFX10K Series; 15.1X53 versions prior to 15.1X53-D233 on QFX5200/QFX5110 Series; 15.1X53 versions prior to 15.1X53-D471, 15.1X53-D490 on NFX Series; 16.1 versions prior to 16.1R3-S9, 16.1R4-S9, 16.1R5-S4, 16.1R6-S4, 16.1R7; 16.2 versions prior to 16.2R2-S5; 17.1 versions prior to 17.1R1-S7, 17.1R2-S7, 17.1R3; 17.2 versions prior to 17.2R1-S6, 17.2R2-S4, 17.2R3; 17.2X75 versions prior to 17.2X75-D110, 17.2X75-D91; 17.3 versions prior to 17.3R1-S4, 17.3R2-S2, 17.3R3; 17.4 versions prior to 17.4R1-S3, 17.4R2; 18.2X75 versions prior to 18.2X75-D5.

CVE-2018-0057 (junos)

On MX Series and M120/M320 platforms configured in a Broadband Edge (BBE) environment, subscribers logging in with DHCP Option 50 to request a specific IP address will be assigned the requested IP address, even if there is a static MAC to IP address binding in the access profile. In the problem scenario, with a hardware-address and IP address configured under address-assignment pool, if a subscriber logging in with DHCP Option 50, the subscriber will not be assigned an available address from the matched pool, but will still get the requested IP address. A malicious DHCP subscriber may be able to utilize this vulnerability to create duplicate IP address assignments, leading to a denial of service for valid subscribers or unauthorized information disclosure via IP address assignment spoofing. Affected releases are Juniper Networks Junos OS: 15.1 versions prior to 15.1R7-S2, 15.1R8; 16.1 versions prior to 16.1R4-S12, 16.1R7-S2, 16.1R8; 16.2 versions prior to 16.2R2-S7, 16.2R3; 17.1 versions prior to 17.1R2-S9, 17.1R3; 17.2 versions prior to 17.2R1-S7, 17.2R2-S6, 17.2R3; 17.3 versions prior to 17.3R2-S4, 17.3R3; 17.4 versions prior to 17.4R2; 18.1 versions prior to 18.1R2-S3, 18.1R3.

CVE-2018-0049 (junos)

A NULL Pointer Dereference vulnerability in Juniper Networks Junos OS allows an attacker to cause the Junos OS kernel to crash. Continued receipt of this specifically crafted malicious MPLS packet will cause a sustained Denial of Service condition. This issue require it to be received on an interface configured to receive this type of traffic. Affected releases are Juniper Networks Junos OS: 12.1X46 versions above and including 12.1X46-D76 prior to 12.1X46-D81 on SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 12.3R12-S10; 12.3X48 versions above and including 12.3X48-D66 prior to 12.3X48-D75 on SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 14.1X53-D47 on EX2200/VC, EX3200, EX3300/VC, EX4200, EX4300, EX4550/VC, EX4600, EX6200, EX8200/VC (XRE), QFX3500, QFX3600, QFX5100; 14.1X53 versions above and including 14.1X53-D115 prior to 14.1X53-D130 on QFabric System; 15.1 versions above and including 15.1F6-S10; 15.1R4-S9; 15.1R6-S6; 15.1 versions above and including 15.1R7 prior to 15.1R7-S2; 15.1X49 versions above and including 15.1X49-D131 prior to 15.1X49-D150 on SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 15.1X53 versions above 15.1X53-D233 prior to 15.1X53-D235 on QFX5200/QFX5110; 15.1X53 versions up to and including 15.1X53-D471 prior to 15.1X53-D590 on NFX150, NFX250; 15.1X53-D67 on QFX10000 Series; 15.1X53-D59 on EX2300/EX3400; 16.1 versions above and including 16.1R3-S8; 16.1 versions above and including 16.1R4-S9 prior to 16.1R4-S12; 16.1 versions above and including 16.1R5-S4; 16.1 versions above and including 16.1R6-S3 prior to 16.1R6-S6; 16.1 versions above and including 16.1R7 prior to 16.1R7-S2; 16.2 versions above and including 16.2R1-S6; 16.2 versions above and including 16.2R2-S5 prior to 16.2R2-S7; 17.1R1-S7; 17.1 versions above and including 17.1R2-S7 prior to 17.1R2-S9; 17.2R1-S6; 17.2 versions above and including 17.2R2-S4 prior to 17.2R2-S6; 17.2X75 versions above and including 17.2X75-D100 prior to X17.2X75-D101, 17.2X75-D110; 17.3 versions above and including 17.3R1-S4 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 17.3 versions above and including 17.3R2-S2 prior to 17.3R2-S4 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 17.3R3 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 17.4 versions above and including 17.4R1-S3 prior to 17.4R1-S5 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 17.4R2 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 18.1 versions above and including 18.1R2 prior to 18.1R2-S3, 18.1R3 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 18.2 versions above and including 18.2R1 prior to 18.2R1-S2, 18.2R1-S3, 18.2R2 on All non-SRX Series and SRX100, SRX110, SRX210, SRX220, SRX240m, SRX550m SRX650, SRX300, SRX320, SRX340, SRX345, SRX1500, SRX4100, SRX4200, SRX4600 and vSRX; 18.2X75 versions above and including 18.2X75-D5 prior to 18.2X75-D20.

CVE-2018-0051 (junos)

A Denial of Service vulnerability in the SIP application layer gateway (ALG) component of Junos OS based platforms allows an attacker to crash MS-PIC, MS-MIC, MS-MPC, MS-DPC or SRX flow daemon (flowd) process. This issue affects Junos OS devices with NAT or stateful firewall configuration in combination with the SIP ALG enabled. SIP ALG is enabled by default on SRX Series devices except for SRX-HE devices. SRX-HE devices have SIP ALG disabled by default. The status of ALGs in SRX device can be obtained by executing the command: show security alg status Affected releases are Juniper Networks Junos OS: 12.1X46 versions prior to 12.1X46-D77; 12.3X48 versions prior to 12.3X48-D70; 15.1X49 versions prior to 15.1X49-D140; 15.1 versions prior to 15.1R4-S9, 15.1R7-S1; 15.1F6; 16.1 versions prior to 16.1R4-S9, 16.1R6-S1, 16.1R7; 16.2 versions prior to 16.2R2-S7, 16.2R3; 17.1 versions prior to 17.1R2-S7, 17.1R3; 17.2 versions prior to 17.2R1-S6, 17.2R2-S4, 17.2R3; 17.3 versions prior to 17.3R1-S5, 17.3R2-S2, 17.3R3; 17.4 versions prior to 17.4R2. No other Juniper Networks products or platforms are affected by this issue.

CVE-2018-0050 (junos)

An error handling vulnerability in Routing Protocols Daemon (RPD) of Juniper Networks Junos OS allows an attacker to cause RPD to crash. Continued receipt of this malformed MPLS RSVP packet will cause a sustained Denial of Service condition. Affected releases are Juniper Networks Junos OS: 14.1 versions prior to 14.1R8-S5, 14.1R9; 14.1X53 versions prior to 14.1X53-D48 on QFX Switching; 14.2 versions prior to 14.1X53-D130 on QFabric System; 14.2 versions prior to 14.2R4. This issue does not affect versions of Junos OS before 14.1R1. Junos OS RSVP only supports IPv4. IPv6 is not affected by this issue. This issue require it to be received on an interface configured to receive this type of traffic.

CVE-2018-0053 (junos)

An authentication bypass vulnerability in the initial boot sequence of Juniper Networks Junos OS on vSRX Series may allow an attacker to gain full control of the system without authentication when the system is initially booted up. Affected releases are Juniper Networks Junos OS: 15.1X49 versions prior to 15.1X49-D30 on vSRX.

CVE-2018-0044 (junos)

An insecure SSHD configuration in Juniper Device Manager (JDM) and host OS on Juniper NFX Series devices may allow remote unauthenticated access if any of the passwords on the system are empty. The affected SSHD configuration has the PermitEmptyPasswords option set to "yes". Affected releases are Juniper Networks Junos OS: 18.1 versions prior to 18.1R4 on NFX Series.

CVE-2018-13800 (simatic_s7-1200_v4_firmware)

A vulnerability has been identified in SIMATIC S7-1200 CPU family version 4 (All versions < V4.2.3). The web interface could allow a Cross-Site Request Forgery (CSRF) attack if an unsuspecting user is tricked into accessing a malicious link. Successful exploitation requires user interaction by a legitimate user, who must be authenticated to the web interface. A successful attack could allow an attacker to trigger actions via the web interface that the legitimate user is allowed to perform. This could allow the attacker to read or modify parts of the device configuration.

Securing the Social Security Number to Protect U.S. Citizens

With cyber criminals having more flexibility in funding and operations than ever before, U.S. citizens are vulnerable not only to breaches of security but also of privacy. In the United States, no article of personal information is meant to be more private or secure than the Social Security Number (SSN). This is for good reason. The SSN has become a common identifier in the U.S. and is now integrated into many identification processes across different institutions.

The SSN is also the gateway to all sorts of other personal information – health records, financial positions, employment records, and a host of other purposes for which the SSN was never designed but has come to fulfill. What do all these pieces of information have in common? They are meant to be private.

Unfortunately, the unforeseen overreliance on the SSN as an identifier has left citizens’ identities vulnerable. The reality is that the SSN can easily be stolen and misused. It is a low-risk, high-reward target for cybercriminals that is used for fraudulent activities and also sold in bulk on the cybercrime black market. This has resulted in major privacy and security vulnerabilities for Americans, with some estimates saying that between 60 percent and 80 percent of all SSNs have been stolen. For example, Equifax and OPM breaches exposed probably millions of SSNs.

This is not a new problem.

Twenty-five years ago, computer scientists voiced concerns about sharing a single piece of permanent information as a means of proving a person’s identity. The issue has only recently gained national attention due to major breaches where cyber criminals were able to access millions of consumers’ personal online information. So, why hasn’t there been any significant measure put in place to safeguard digital identities?

A major reason for a lack of action on this issue has been a lack of incentives or forcing functions to change the way identity transactions work. But it’s time for policymakers to modernize the systems and methods that identify citizens and enable citizens to prove their identity with minimal risk of impersonation and without overtly compromising privacy.

The good news is that the U.S. has the technology pieces to put in place a high-quality and high security identity solution for U.S. citizens.

There are reasonable and near-term steps we can take to modernize and protect the Social Security Number to create better privacy and security in identification practices. McAfee and The Center for Strategic and International Studies (CSIS) recently released a study on Modernizing the Social Security Number with the aim of turning the Social Security Number into a secure and private foundation for digital credentials. The report’s ultimate recommendation is to replace the traditional paper Social Security card with a smart card — a plastic card with an embedded chip, like the credit cards that most people now carry. Having a smart card rather than a paper issued SSN would make the SSN less vulnerable to misuse.

A smart card is a viable solution that already has the infrastructure in place to support it. However, there are other potential solutions that must not be overlooked, such as biometrics. Biometrics measure personal features such as voice, fingerprint, iris and hand motions. Integrating biometrics into a system that relies on two-factor authentication would provide a security and privacy threshold that would make it very difficult for cybercriminals to replicate.

What is most critical, however, is that action is taken. This is an issue that deserves immediate attention and action. Every day this matter remains unresolved is another day cyber criminals continue their efforts to compromise consumer data in order to impersonate those whose data has been breached.

With the Social Security Number serving as the ultimate identifier, isn’t it time that we modernize it to address today’s evolving privacy vulnerabilities? Modernizing the SSN will help with authentication, will provide more security, and will help safeguard individual privacy. Modernizing the SSN must be a high priority for our policymakers.

The post Securing the Social Security Number to Protect U.S. Citizens appeared first on McAfee Blogs.