Category Archives: Uncategorized

Update now! WordPress hackers target Easy WP SMTP plugin

Two hacking groups have been spotted targeting websites running unpatched versions of the WordPress plugin Easy WP SMTP.

Easy WP for SMTP, which has more than 300,000 installs, is marketed as a plugin that lets WordPress sites route their bulk emails via a reputable SMTP server as a way of ensuring they aren’t spamholed by suspicious email providers.

Unfortunately, version 1.3.9 is vulnerable to a security flaw that allows attackers to set up ordinary subscriber accounts with hidden admin powers or hijack sites to serve malicious redirects.

According to WordPress firewall developer Defiant (formerly WordFence), the problem lies with the Import/Export functionality added to 1.3.9:

The new code resides in the plugin’s admin_init hook, which executes in wp-admin/ scripts like admin-ajax.php and admin-post.php.

This does not check the user capability, which means any logged-in user, including a subscriber, could trigger it.

It’s not clear from the plugin changelog how long 1.3.9 has been in use but a second firewall company, Ninja Technologies, said it first picked up attacks exploiting the weakness “since at least March 15.”

One campaign appears to be exploiting the vulnerability to grab admin privileges, while a second the second sends visitors to malicious sites before…

Injecting malicious <script> tags into all PHP files on the affected site with the string “index” present in their name. This obviously affects files named index.php, but also happens to impact files like class-link-reindex-post-service.php, present in Yoast’s SEO plugin.

from Naked Security – Sophos http://bit.ly/2Ymf4eM
via IFTTT

New ratings point to keyless cars that can stand up to relay attacks

Do you dislike the idea of standing in an empty driveway that should be occupied by your car, obediently waiting to unlock after you chirp-chirp your keyfob at it?

If so, you might want to take a gander at the security ratings for new cars put out by Thatcham Research, a nonprofit insurer research center in the UK.

Thatcham rated 11 cars that were launched so far in 2019 and plans to continue to assess new cars for security. It rated six of those 11 cars as being poor for security.

Specifically, it’s looking at those wireless keys: matchbox-sized fobs that have proven woefully susceptible to what’s known as relay attacks.

That’s when thieves use two relay devices that are capable of receiving, and extending, wireless signals from the car through walls, doors and windows, to reach the fob inside a car owner’s house. The relay devices are cheap to pick up online.

Standing next to the car, they just have to scan for signals transmitted by the wireless keys and then amplify them to open the cars, hop in and drive off.

Is your car a wireless sitting duck?

When the German General Automobile Club (ADAC) tested 237 keyless cars from 30 brands in January this year, it found that nearly all of them – 230 – are vulnerable to relay attack.

In the ADAC’s research, the only cars that could fully resist a keyless hacker attack come from Jaguar Land Rover: the Jaguar I-Pace, as well as the latest versions of the Land Rover Discovery and Range Rover Evoque. Four other cars could be either unlocked or started, and all remaining 230 vehicles were vulnerable to all kinds of hacker attacks.

For its part, Thatcham got good results from the Audi E-tron, Jaguar XE, Range Rover Evoque and Mercedes-Benz B-Class: cars with wireless fobs that resist the attacks by either using more secure wireless technology or by going to sleep when they haven’t been used for a set time.

Thatcham Research chief technical officer Richard Billyeald told WhatCar? that Thatcham focused on relay attacks because they’re so good at blowing past whatever car manufacturers have done to boost security:

We’re focusing on keyless theft in particular because it gives thieves the ability to bypass 20 years of security improvements in a matter of seconds.

Precisely, that would be about 60 to 90 seconds, as we’ve seen in recent car thefts.

from Naked Security – Sophos http://bit.ly/2HKQkbd
via IFTTT

Secure workloads without slowing down your DevOps flows

In this Help Net Security podcast recorded at RSA Conference 2019, David Meltzer, CTO at Tripwire, and Lamar Bailey, Senior Director of Security Research at Tripwire, discuss the challenges of securing DevOps.

secure devops workload

Here’s a transcript of the podcast for your convenience.

David: Welcome to the Help Net Security podcast. This is David Meltzer, the CTO at Tripwire. Today I’m joined by Lamar Bailey, Senior Director of Security Research at Tripwire. Today we’re going to be talking about DevOps and DevOps security.

Lamar, DevOps is certainly gaining a lot of traction in the security world and we’ve seen the proliferation of DevSecOps, SecDevOps, SecOps. What are you seeing happening this year around DevOps at RSA?

Lamar: It’s definitely a hot topic here at RSA and lots of companies are looking into it, trying to figure out how to merge between the security teams and the development teams. The development teams are definitely running ahead, trying to get things out to market and security teams are trying to make sure that everything they are pushing is secure and it’s going to the delivering processes. We’re seeing a lot of companies and services trying to bridge that gap, and make sure that those two teams can work together and be able to get their process and products out.

David: From an IT security perspective, starting to understand what are these DevOps parts of the organization doing, what’s a good way to get started?

Lamar: I’d say the best way to get started is to go talk to the developers and see what they’re planning. There’s a lot of open source DevOps tools that are out there, and we see a lot of developers going, grabbing those, working with those, playing with those, and I’m bringing those into the workplace and using them. A lot of times it becomes things that security teams don’t know about, IT doesn’t know about yet. But talk to them, see what they’re using and see how to bridge and make sure we can add security to those tools.

David: One of the things that I’ve seen myself talking to application developers is, how often security just wasn’t even in their considerations, as they started to adopt more of these DevOps tools, especially as they were moving to the cloud. As you see customers adopting cloud infrastructure, what are some of the top security challenges they’d need to be thinking about?

Lamar: One of the interesting security challenges of the cloud we see, is kind of a throwback, it’s access. It tends to be where everybody has root access. They don’t go through and take the time to set up all the least privilege. Everybody that has access to the cloud, has the same root access, and it causes problems.

David: What kind of solutions are there out there for figuring out where these access systems are misconfigured or where these settings exist?

Lamar: There’s not as many as you would think. It is pretty hard to configure the access in some of these cloud services. Some of the cloud services providers themselves have tools, but then they have to be set up correctly. You’re looking a lot of third parties to look to come in and manage that and look at that.

David: Containerization is another area. I’ve seen a whole lot of growth of over the last couple of years, people using Docker and now Kubernetes. Are there security challenges you’ve seen around those areas?

Lamar: Definitely. On the containers, it’s kind of the next segment from virtual machines and for a period of time people thought “oh, it’s just a container, there’s no security issues with it”, which we find that’s not the case. Scanning those containers need to happen pre-production and during production. There are tools out there that you need to be looking at and looking at your containers before they move into production, make sure they are secure and check compliance.

David: One of the Tripwire researchers I saw had been doing some assessments of open source operating systems available in containerized form, and actually found some of the default operating systems being shipped as containers were still vulnerable systems, as they existed.

Lamar: We’ve seen a lot of a lot of that actually, in some of the research. There’s a lot of free containers you can just go grab and start your work from there, but they’re not necessarily secure or they’re not configured correctly. So it’s like grabbing any open source, you’ve got to vet it. You’ve got to make sure it’s what you need for your environment, make sure is secure and then build on top of it.

David: That makes a lot of sense. In terms of looking into that pipeline, what are some of the key areas of integration that people should be thinking about as they start to figure out: “How do I work in this DevOps life cycle and insert security into it?”

Lamar: Definitely, preproduction. We’re seeing a lot of tools now where it’s easier for the developers to scan their own containers and scan their own even serverless, to see what their security stance is before they start. As long as that’s easy, they’ll continue to do that, and they don’t mind doing that. There’s an easy way to fix them before they move into production, because they want to get their code into production, and they don’t want to have IT or SecDevOps say: “All right, well we didn’t do this. Let’s hold off a week or a month.” They’re more interested in getting their code out, so they’ll follow the processes. Having it done beforehand is huge. Looking at it after you push into production, that’s also always going to be required.

David: I remember the old way of doing security assessment which is someone makes a build, they put it into test, and they let security have at it for a couple of days, or they’ll spend a week doing their security assessment. Clearly, those approaches aren’t going to work anymore when people are trying to push code into production on an hourly basis. I think that’s the part that people are often missing around the DevOps cycle which is really all about agility and speed and the velocity that the developers are moving at. Any security solutions that we look at, absolutely have to be moving at the pace of DevOps. That means we have to rethink some of the traditional security controls, maybe even the idea of taking a few hours to do these assessments, really doesn’t work in this new world again, does it?

Lamar: Definitely not. We used to do Waterfall, and Agile killed that. Now DevOps is killing Agile. It’s just not fast enough and IT has got to be at that same pace. I think it’s imperative that you scan and your security is throughout your whole process, and like you say it’s minutes, it’s not hours, it’s not days. Then you’ve got to have a way to revert, if something is wrong, and revert has to be almost instantaneous also.

secure devops workload

David: When you are seeing those changes that are happening, and you’re trying to address the security issue right now, what’s the most effective way to deal with that? What are the new ways that people are thinking about securing the CI/CD pipelines that didn’t exist a couple of years ago?

Lamar: It’s integrations and automation mainly. Integration with different tools to check where you’re at in the process, check your pipeline. Once you get into production basically, it’s kind of the most effective way. Any change happens to production, then you just rollback. You don’t have to wait and see what the change was, you can do the forensics on the back end. But if this container changes, for instance, roll it back, put in the known good go container and go forward. That should be completely automated and be in a matter of seconds, not even minutes, for that to happen.

David: Let’s talk about one other topic which is something I hear DevOps talk a lot about which is immutable. That design pattern that everything that we move to production won’t change at all anymore. All the changes will happen from the developer perspective. Have you heard people talk about or use immutability? How does that affect the security of these applications that are built with this immutable paradigm?

Lamar: It is. It comes up a lot, and I think the theory is pretty good. But there’s also the gap of, once this is moved into production, even though the developer did the changes, IT made, and what changes happened. Should that particular device be doing something different now than it did before? You go back and ask the developer what was the change control, and the developer tells you: “Oh, that’s in GitHub or in my code control system to tell you what all my changes were.” There’s a gap there that’s happening, so they’re not as immutable as they think they are.

David: The other thing people also need to keep in mind is the idea that, even if the container or the immutable object itself doesn’t change, the threat environment is always changing. So, a system that might not have been vulnerable when we first scanned it a couple days ago, actually maybe a new vulnerability came out and is vulnerable today.

Lamar: Absolutely. Continuous scanning of these devices is required, these assets. You can’t scan like we used to. Companies will scan their assets once a week, once a quarter, once a month. That’s not valid anymore. Our landscape changes so fast. We’re looking at DevOps switched the code and the products are changing so fast, we almost need to be in a complete continuous security assessment.

David: When you see DevOps being applied in organizations, is it just a cloud thing that you’re seeing or is it happening for on-premise systems and virtualization environments as well?

Lamar: It’s happening all across the environments. It’s interesting because it’s not the same teams. What you’ll see in large enterprises is, maybe there’s multiple teams that are doing this, and some are doing it in cloud, some are doing it on-prem, and they don’t even use the same tool sets. There’s not as much standardization across here either, which is also an issue from an IT’s standpoint of trying to make sure everything’s secure.

David: Moving at the pace of the internet and trying to secure all those systems, certainly a difficult challenge. Thanks for sharing your thoughts on this. This has been Dave Meltzer, the CTO of Tripwire, along with Lamar Bailey, Senior Director of security research at Tripwire.

If you want to find out more information about how DevOps is affecting security or the kind of solutions that Tripwire can provide to integrate into your CI/CD pipeline and help you with your DevOps security, go to www.tripwire.com.

from Help Net Security – News http://bit.ly/2OnEX9q
via IFTTT

Employee cybersecurity essentials part 1: Passwords and phishing

Your company may have state-of-the-art monitoring and the latest anti-malware and anti-virus programs, but that doesn’t mean you’re not at risk for a breach, or that – as an employee, that you’re not putting your company at risk.

Humans have always been the weakest link in the security chain. Phishing and social engineering schemes account for 93 percent of breaches, according to Verizon’s 2018 Data Breach Investigations Report. And passwords are easier for hackers to obtain than ever. One recently discovered file on the dark web contained 2.6 billion of them for sale.

With proper training and motivation, your employees can prevent phishing attacks and password hacks.

Education is essential, but if you do it wrong it can backfire, overwhelming workers with information and making them too worried about personal consequences to report problems.

As guidance, here are some of the most important things you can teach employees about passwords and phishing, along with tips for presenting the information in a way that will encourage them to comply.

Choosing a password

We know a strong password means one with uppercase and lowercase letters plus numbers and symbols. Passwords should be changed every 90 days. Everybody in security knows this because that’s what the U.S. National Institute of Standards and Technology (NIST) said to do back in 2003.

But, your employees defeated these rules. Because they’re human and have trouble remembering numbers and symbols not used in speech, they use combinations like P@s$w0rd!2 and 1L0v3U*7. It didn’t take hackers long to figure out that symbols were being substituted for letters they looked like and people who had to change passwords every three months simply added sequential numbers to the end.

What about employees using those password meters that tell you whether the password you’re creating is weak, medium, or strong? Researchers at Carnegie Mellon University actually found these to be inaccurate.

As a result, NIST recently admitted failure and revised its guidelines. Instead of using a hash of numbers and symbols, it says, you’re better off with a password that’s longer—at least 64 characters. Though this may sound difficult, it’s actually easier because you can create a pass phrase with spaces between words. Choose words that don’t normally belong together, like “big dog small horse.”

This is good news for employees, who are much more likely to remember words they have chosen than a string of numbers and symbols. Even better news for employees: once you have a good password, you may never have to change it, NIST now says. Just don’t use it for anything else.

However—and this is critical—NIST also says you shouldn’t rely on passwords alone except for low-risk applications. In other words, don’t run your business on them.

NIST is right about that. We view the phrase “strong password” as an oxymoron. Serious cybercriminals use computers to do their password guessing and, as a human, you can’t keep up with that kind of computing power. Today, the average laptop has at least five times the processing power of the NASA Space Shuttle.

That’s why it’s important to use multifactor authentication (MFA). However, passwords are still an important component of that system.
So, encourage your employees to choose a good password, and then move on to MFA and single sign-on (SSO), which will make their lives even easier while making your business more secure.

Spotting a phishing attack

Do your employees know not to click links or attachments from unknown senders and to think twice even when they come from an insider or someone they know? Do they know to hover their mouse over a link to see if the address is different from the hyperlink text? To notice whether the “Reply” line information matches the “From” line?

After years of security training, you might assume that they do. Although if you conduct a company-wide phishing test, the results may surprise you. Workers are busy and sometimes careless. Many believe that if they do click a bad link, your company’s antivirus and antimalware software will save them.

A phishing test provides an opportunity to educate workers about real problems the company faces and updates relevant internal security personnel on the phishing education level of employees company-wide. Training is more compelling and less dry when it deals with the here and now. You should incorporate the latest real-life examples in your industry to help them see how serious cybercrime is and how it’s very possible they can be the heroes who stop it.

Spotting a spear phishing or social engineering attack

While many hackers still get results from traditional phishing attacks, others have moved on to spear phishing and social engineering, also known as business email compromise. In these schemes, a particular individual is targeted and asked to fulfill a request, usually providing data or wiring money.

Unlike traditional phishing attacks, social engineering emails don’t usually contain malware. Instead, they rely on tricking the employee to act on the request.

Some hack the email of the individual they’re impersonating, while others rely on “spoofing,” or using an email address a letter or digit off. Others have figured out how to edit the “From” field to make the fake addresses identical to the real one—but if you click “Reply,” they are different.

Spear phishers comb LinkedIn and other business sites to learn about your company and its personnel and suppliers, your relationships with colleagues or partners and then use the information to craft plausible requests, such as wiring money to pay an invoice or handing over employees’ W-2 information.

Hackers go after small and large businesses alike, and even sophisticated companies have been fooled. For example, Merck & Co. reported an estimated loss of millions from the NotPetya cyberattack from business disruptions of its worldwide operations, including manufacturing, research and sales operations.

Outside of the professional sphere, social engineers target people based on their Facebook profiles. If a friend’s account is hacked, others in the network may be scammed through fake promotion schemes or tricked into downloading a keystroke logger.

Training is important in employee cybersecurity education, as is contextualization for how their own personal information can be used or exposed in these types of attacks too. Employees who realize that their personal information, as well as your business data is at stake are likely to pay more attention to training and become more vigilant.

Every company’s employees are different. Through employee security training and secure solutions, your employees should be able to recognize attacks and help protect the company and their own assets.

from Help Net Security – News http://bit.ly/2WljjW6
via IFTTT

What worries you the most when responding to a cybersecurity incident?

The clock starts ticking immediately following a cybersecurity incident with the first 24 hours vital in terms of incident response.

incident response preparedness

The majority (59 percent) of companies are not confident they could resume ‘business as usual’ after the first 24 hours, although 41 percent say they are, according to a new social media poll by NTT Security.

Asked about their number one focus in the first 24 hours after a security incident, nearly two-thirds (64 percent) of respondents say mitigating the threat is the main priority, while 36 percent say it is about identifying the cause.

David Gray, Senior Manager and Incident Response Practice Lead EMEA at NTT Security, believes that although there is much greater security awareness from top to bottom within organizations, there is a clear lack of preparation and planning when it comes to incidents, despite the potential impact.

“There is still an element of ‘head in the sand’, where organizations simply don’t think it is going to happen to them, despite everything we are seeing in the news. Our global Risk:Value report last year backs this up, with less than half (49 percent) of respondents admitting they have implemented an incident response plan. While most say they communicate their plans internally, it’s still only a minority who are fully aware of them. These figures have barely changed year on year and suggest that incident response planning is still not a priority.”

The NTT Security poll, which was conducted over Twitter and generated around 5,500 responses, points to a lack of resources that many organizations are struggling with today as a possible explanation for this.

Lack of skills in-house is what worries the majority of companies (59 percent) when responding to a cybersecurity incident or breach, while 41 percent worry about lack of budget.

David Gray adds: “The worry is that even if organizations do have an incident response plan in place they simply do not have the resources to execute it, losing valuable hours or even days identifying the right skills and setting up the necessary SLAs and contracts. This is precious time wasted. Even the most mature security teams are forced into a reactive stance when something happens. Those first 24 hours are crucial in minimizing the impact and cost of an incident and protecting valuable data, so they need to make them count!”

incident response preparedness

Steps to take in the first 24 hours of a security incident

NTT Security recommends adopting a triage process in the first 24 hours of a security incident to provide a head start in remediation and post-incident investigation. These steps provide a starting point to this process:

Detection: Understanding how and when an incident was first detected is the best place to begin. It may be some time since the systems were compromised, but asking questions, such as whether firewall logs are being used to their full potential to identify the initial compromise or if there are other SIEM solutions in place could help to uncover vital clues.

System framework: In order to provide an effective response you must know where the servers and/or endpoints are physically located. Equally important is the setup, i.e. operating systems, storage, virtualization as well as security configuration, i.e. user groups/permissions as well as a network map.

Preliminary remediation: Providing accurate handover notes to an incident response team along with a record of the steps taken up until that point are recommended in order to prevent any cross-contamination or incorrect leads being pursued. To ensure IT, CISO and incident response single point of contacts are fully engaged with one another it is essential that this communication is continued throughout the course of the incident response plan.

Logs provide crucial evidence: Log files may be crucial in uncovering and identifying indicators of compromise (IoC) or detecting the intrusion. To avoid mislaying any evidence, logging must be fully enabled and retention periods applied and provided at the earliest opportunity to ensure a thorough review to determine IoCs.

Artefact preservation: The preservation of artefacts identified within data must be maintained to carry out comprehensive forensic analysis and so that an accurate timeline can be constructed. Each incident must be treated on an individual basis and this process should be employed whether or not external authorities are engaged. If they are involved then the reports could form key evidence.

from Help Net Security – News http://bit.ly/2TUHKgh
via IFTTT

Consumers willing to dump apps that collect private data, but can’t tell which are doing so

Consumers are increasingly leery of third parties using and capitalizing on their private data.

consumers care about private data

Two in three consumers are willing to dump data-collecting apps if the information collected is unrelated to the app’s function, or unless they receive real value – such as that derived through email or browsers, according to a consumer data privacy survey conducted in recent weeks for Anagog.

The survey, conducted by SurveyMonkey, also revealed optimism in the face of a looming data privacy crisis, with more than 70 percent of respondents saying they believe solutions exist that can cure the problem.

For instance, 42 percent said they’d like to have access to marketing deals on their mobile phones without having their personal data collected, and another 29 percent said they believe companies should use advanced technologies such as artificial intelligence to pull in relevant offers to their private phones, based on their profile calculated on their phones while keeping their anonymity, rather than sending their private data to marketers’ unknown external clouds.

Nearly all consumers surveyed about their data privacy concerns in the snapshot study said they are aware the major internet companies are collecting their personal information and using it for their own benefit and/or selling it to third parties (84 percent).

While 8 percent said they don’t think it is a “big deal” that internet giants collect their private data without permission, they were in the minority. A full 36 percent of participants called this a “global epidemic that needs a cure,” while 38 percent said they are resigned to the fact that it’s a problem, but it can’t be avoided. Another 19 percent said, “It’s absolutely criminal to take my personal data.”

But even armed with this awareness and skepticism about the intentions of internet giants and apps vendors, nearly 75 percent of respondents said they do not know how to tell when and if apps are collecting their personal information.

Consumers said their biggest fear about data collection is that identity thieves will get their hands on their private data (64 percent). Other concerns about who has their data include thieves who know where they live (12 percent), government agencies and foreign entities (10 percent each), and telemarketers (4 percent).

While about 25 percent of consumers surveyed said they accept mobile apps tracking their behaviors as “part of modern life,” not everyone agreed. 43 percent said they are mad about the situation but feel powerless to change it or are demanding they get their privacy back.

Five percent believe their data is already anonymized and that marketers and apps do not know who they are. About 15 percent said mobile apps tracking their behavior is an acceptable tradeoff for relevant marketing offers.

Consumers fired up about their privacy said they are even willing to pay to keep their personal information out of the hands of internet giants by paying a small monthly fee between $1 and $3 (54 percent).

“We use apps because they fit a particular need, but most of us pay little attention to what we’re giving away in exchange,” said Ofer Tziperman, CEO of Anagog.

“Consumers are inured to simply accepting whatever permissions are asked for and continuing with the download, and it’s causing a data privacy crisis around the world that’s being recognized at all levels, including at Apple. The good news is that our survey shows more consumers are aware of this issue and more companies are starting to search for solutions that address it.”

The survey polled more than 200 apps users from age 18 to 65+ years.

from Help Net Security – News http://bit.ly/2JBCJEQ
via IFTTT