Tag Archives: Security

KRACK attack: beware of public Wi-Fi

Why can KRACK be so dangerous?

Cybersecurity experts have discovered a critical weakness in Wi-Fi connections that could make your private information vulnerable to cyber criminals. The threat is called KRACK (key reinstallation attacks) and could allow someone to steal information sent over your private Wi-Fi or any open connections you might access in public places like coffee shops.

KRACK is dangerous because it affects so many people. Most people who connect wirelessly to the internet through Wi-Fi on their phone, tablet, laptop, etc. do so using the WPA2 (Wi-Fi Protected Access) protocol that helps keep your information safe by encrypting it—making it a secret code. Only now, KRACK has made it much less protected because thieves may be able to decypher the code that protects your information, and read it whenever they want.

Cyber criminals can also use KRACK to modify wirelessly transmitted data to and from the websites you visit. You might think you’re going to your bank’s website, when in reality you’re at a fake phishing site made to look like it. You unknowingly enter your username and password, and the thieves now can record that information.

How do I protect myself?

Update your operating system

Update your OS ASAP. In the meantime, Apple, Google and others are presumably working to roll out a patch to protect against KRACK.

Microsoft just announced it included a patch in an October 10th security update. For Windows customers who have their “Windows Update enabled and applied the security updates,” they’re automatically protected from the KRACK threat, according to Windows Central.

However, don’t assume you’re protected. Even if you’re a Windows user, double check you have the latest security updates.

Use Wi-Fi networks only when necessary

Until you’ve installed the security KRACK patch, avoid using Wi-Fi connections, both at home and especially public hotspots. Your home Wi-Fi connection is slightly more secure only because cyber thieves need to be relatively close to your physical location to steal your data. But that doesn’t mean you’re safe at home or in public.

If you absolutely need to use a wireless network, make sure you’re not transmitting confidential info like your SSN, credit card number, or bank information.

If possible, hardwire your wirelessly connected devices back to your modem/router. Cyber criminals can’t steal signals out of the air if they’re not there, so find that yellow ethernet cable you stashed somewhere in a drawer and use it to connect to as many devices as possible.

Update your wireless router’s firmware

Your router’s firmware helps it work correctly with your devices, so keep it up-to-date. When the security patch rolls out, you don’t want any issues with conflicting or unsupported firmware versions. Updating your router’s firmware is a relatively painless process.

Configure your router so only your approved devices can connect to the network. Each of your devices has a media access control (MAC) address that uniquely identifies it to work with the network. Configure your router to only allow listed devices. The process may differ depending on your router brand.

Hide your Wi-Fi network so even those close enough to detect your signal won’t see it listed. Hiding your network won’t stop dedicated hackers from eventually finding it, but it will create another step they must go through, which is your goal until the patch comes through. It’s likely it will take developers some time to adequately address KRACK, so stay vigilant.

Avoid unencrypted websites

Encrypted websites contain an HTTPS at the beginning of their URL’s. The information you send and receive to them is secure. Websites that only use the HTTP are NOT encrypted. So use HTTPS sites as much as possible. HTTPS Everywhere is a browser plugin that automatically switches thousands of sites from HTTP to HTTPS.

Get some good cybersecurity software

Having cybersecurity software always helps mitigate risk. For critical attacks like KRACK, it’s especially important to add as many layers of protection as possible.

What information can be stolen?

Anything you can send wirelessly over the internet. So, pretty much everything. Passwords, credit card numbers, voice messages, pictures, texts, and the like. Again, this goes for both public and private wireless networks, so your info could be stolen while you’re signed in to the library’s Wi-Fi network or when you’re texting someone from your living room. Deactivate your cell phone’s Wi-Fi connection until you’ve gotten the fix from your OS developer or stay on 3G network for data transfer.

Can it affect my devices?

Strictly speaking, no. Neither your wirelessly connected devices nor your router are being directly targeted. Unlike ransomware, thieves aren’t KRACKing into your device and threatening to destroy your information. It’s more of an elaborate heist job than a hostage situation. They want to decrypt the protocol, to eavesdrop on what your devices are saying. They’re interested in the info not who is talking. More importantly, thieves want to go unnoticed.

How did the KRACK vulnerability happen?

Your cell phone and Wi-Fi device (i.e. modem) need to “talk” to each other decide on how to work together transmit data. The language they use is called a protocol, or system of rules. The protocol is encrypted for privacy. It’s like if two people switched to a different language to discuss something privately. If you don’t know the language, you’re in the dark. That’s how your information is kept private when sent over Wi-Fi.

But the KRACK attack gives cyber criminals an opening to decrypt the information sent. It would be like someone bringing an interpreter to the couple’s private discussion. They now can overhear everything that’s being said.

Can I tell if someone’s stealing my info over Wi-Fi?

As of yet, there’s no way to know if someone is KRACKing your wireless access. That’s why it’s especially important to keep an eye out for an update, and to follow the safety recommendations above.

 

 

The post KRACK attack: beware of public Wi-Fi appeared first on Panda Security Mediacenter.

Read More

Is Fileless Malware an Undetectable Threat?

Unlike the malware that we’re “used to”, fileless malware is able to infect and cause damage without leaving a trace. Its secret, as its name indicates, is not to record any type of file on the hard disk. All action takes place “in the air”, that is, on memory. The moment the system restarts the virus will disappear, but the damage will already be done. Can you fight an enemy that leaves no trace? Of course the answer is yes.

What is Fileless Malware?

Fileless malware is a type of Advanced Volatile Threat or AVT, malicious code that is designed to not write itself onto the hard drive and work from the RAM. In general, viruses and other types of malware need one or more files to act on the system. They are usually detected immediately by defense systems in operation and subsequently identified and quarantined. However, fileless malware does not need such files on the hard drive, so traditional protection systems are in fact completely unable to detect it. Naturally, it is much more difficult to defend against attacks using this technique, as these infections are not only difficult to detect, but also much more resilient and difficult to control.

They are also ephemeral malicious processes, since they disappear the moment the system is reset. Depending on the variants, we can find malware such as Phasebot, a fileless malware sold on the black market as a kit to make a virus specialized in data theft. Or Anthrax, a hybrid virus. Its modus operandi is to go into “fileless mode” once the infected executable has been opened. Once restarted, the virus passes by way of memory and infects new files. Poweliks forces the system to generate fraudulent visits and opens the door to new possibilities of infection through command and control servers (C&C).

The symptoms and damages caused by this fileless malware are very diverse. In any case, it is a serious problem for forensic system analysis, as well as protection strategies based on white lists, signature detection, hardware verification, or pattern recognition … In short, it gives all the tried-and-true methods of malware detection a run for its money.

Protecting Yourself Against Fileless Malware Is Possible

Fileless malware is a concept with a decades-long history behind it. However, its evolution has skyrocketed in recent times, seeing a record of viruses with incredibly harmful potential and overwhelming effectiveness. How can we defend against the threat of a code that leaves no traces on the hard drive? The secret is in behavior. Monitoring the system for malicious behavior is probably the most effective method. Panda Adaptive Defense 360 ​​is able to classify 100% of the active processes in the corporate network and detect any compromising activity, in real time, alerting users of any and all suspicious behavior as soon as it occurs.

In 220 efficacy tests performed with Adaptive Defense 360, 99.4% of the infection attempts were detected. In none of the cases was there a false positive, nor any lost data, including potential fileless viruses in the tests. According to data obtained in the last PandaLabs security report, among our corporate clients 2.67% of the machines protected by traditional solutions suffered attacks by unknown threats, a higher figure when compared to 1.27% of the machines protected with Adaptive Defense, which blocks attacks instantly and without any collateral damage.

A proactive strategy is, as always, the best strategy. The conventional wisdom certainly applies here: always keep your systems updated, monitor suspicious traffic, restricting the use of macros etc. Other less-known countermeasures include restricting scripting languages and disabling, if possible, Windows PowerShell, one of the main routes exploited by fileless malware. In the end, only dedication and healthy security practices, coupled with the right tools, will keep us safe from the malware that we cannot see.

The post Is Fileless Malware an Undetectable Threat? appeared first on Panda Security Mediacenter.

Read More

Yet Another Linux Kernel Privilege-Escalation Bug Discovered

Security researchers have discovered a new privilege-escalation vulnerability in Linux kernel that could allow a local attacker to execute code on the affected systems with elevated privileges.

Discovered by Venustech ADLab (Active-Defense Lab) researchers, the Linux kernel vulnerability (CVE-2017-15265) is due to a use-after-free memory error in the Advanced Linux Sound Architecture (ALSA) sequencer interface of the affected application.

The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system, and also bundles a userspace driven library for application developers, enabling direct (kernel) interaction with sound devices through ALSA libraries.

Successful exploitation of this vulnerability requires an attacker—with local access on the targeted system—to execute a maliciously crafted application on a targeted system, which allows the attacker to elevate his privilege to root on the targeted system, a Cisco advisory warned.

The vulnerability affects major distributions of the Linux operating system including RedHat, Debian, Ubuntu, and Suse, and is triggered by a slip in snd_seq_create_port().

This “snd_seq_create_port() creates a port object and returns its pointer, but it doesn’t take the refcount, thus it can be deleted immediately by another thread,” the researchers wrote in an advisory published Wednesday. 

“Meanwhile, snd_seq_ioctl_create_port() still calls the function snd_seq_system_client_ev_port_start() with the created port object that is being deleted, and this triggers use-after-free.”

The vulnerability has been patched in Linux kernel version 4.13.4-2, which was fixed just by taking the refcount properly at “snd_seq_create_port()” and letting the caller unref the object after use.

Administrators are advised to apply the appropriate updates on their Linux distributions as soon as they receive them from their respective distro. They’re also recommended to allow only trusted users to access local systems and always monitor affected systems.

This flaw is yet another privilege escalation vulnerability recently uncovered in the Linux kernel.

Last month, a high-risk 2-year-old potential local privilege escalation flaw was patched in the Linux kernel that affected all major Linux distributions, including Red Hat, Debian, and CentOS.

In February, another privilege-escalation vulnerability that dates back to 2011 disclosed and patched in the Linux kernel which also affected major Linux distro, including Redhat, Debian, OpenSUSE, and Ubuntu.

Powered by WPeMatico

Hackers demand nude images instead of money

We thought that we’d seen everything but hackers managed to hit a new low. Last month the news about a new ransomware that demands nude photos instead of the usual cryptocurrency started circulating the online world. The new ransomware is called nRansomware and works very similar to Locky – it is a malicious software that infects your device and locks some of the files on your system. Luckily the new threat is not a state of the art malicious software. While Locky encrypts your data, nRansomeware is known only to lock your screen. It is unfortunate enough but not absolutely devastating.

Up until now, when a PC was infected with ransomware, the cybercriminals behind it were after immediate monetary gain. However, hacker’s shady techniques are continually evolving. Online troublemakers are starting to realize that Bitcoin and most of the virtual cryptocurrencies are not as secure and untraceable as they initially thought. Payments can easily be tracked, so they decided to get creative by releasing ransomware that demands ten nude photos from the victims to “unlock” their computer.

The new ransomware feels like a yet another episode of the modern-day nightmares described in the hit TV series Black Mirror. When infected, your computer displays the text below instead of your desktop. The ruthless message from the hackers is placed on a background containing offensive language and multiple images of Thomas the Tank Engine.

Your computer has been locked. You can only unlock it with the special unlock code. Go to protonmail.com and create an account. Send an email to 1_****_yourself_1@protonmail.com. We will respond immediately. After we reply, you must send at least ten nude pictures of you. After that, we will have the verify that the nudes belong to you. Once you are verified, we will give you your unlock code and sell your nudes on the deep web.

It does sound gross, doesn’t it? The last thing you want is perverts bidding over imagery of your naked body. Hackers have been stealing intimate images from celebrities for a long time. Sadly, now they are starting to realize that they can make a buck by extorting regular people too. You no longer have to be rich or famous to attract hackers’ attention.

Is it a prank or a sign of the new way hackers will be making money out of the innocent? The time will show. One is for sure, cryptocurrencies are not untraceable, and cyber bullies with twisted minds exist out there. They are not afraid to pray on the weak by continuously finding new ways to avoid being caught. The chances of becoming a victim of such ransomware are rare to impossible if you are protected and follow our tips for staying out of trouble.

The post Hackers demand nude images instead of money appeared first on Panda Security Mediacenter.

Read More

Apache Tomcat Patches Important Remote Code Execution Flaw

apache-tomcat-rce-exploit

The Apache Tomcat team has recently patched several security vulnerabilities in Apache Tomcat, one of which could allow an unauthorised attacker to execute malicious code on affected servers remotely.

Apache Tomcat, developed by the Apache Software Foundation (ASF), is an open source web server and servlet system, which uses several Java EE specifications like Java Servlet, JavaServer Pages (JSP), Expression Language, and WebSocket, and provides a “pure Java” HTTP web server environment for Java concept to run in.

Unlike Apache Struts2 vulnerabilities, which have recently been exploited to breach the systems of American credit reporting agency Equifax, Apache Tomcat flaws are less likely to be exploited.

The critical Remote Code Execution (RCE) vulnerability (CVE-2017-12617) discovered in Apache Tomcat is due to insufficient validation of user-supplied input by the affected software.

Only systems with HTTP PUTs enabled (via setting the “read-only” initialization parameter of the Default servlet to “false”) are affected.

“Tomcat versions before 9.0.1 (Beta), 8.5.23, 8.0.47 and 7.0.82 contain a potentially dangerous remote code execution (RCE) vulnerability on all operating systems if the default servlet is configured with the parameter readonly set to false or the WebDAV servlet is enabled with the parameter readonly set to false,” says Peter Stöckli of Alphabot Security.

Exploiting this vulnerability requires an attacker to upload a maliciously crafted Java Server Page (JSP) file to a targeted server running an affected version of Apache Tomcat, and the code contained in the JSP file would be executed by the server when the file is requested.

apache-tomcat-remote-code-execution-exploit

To upload the maliciously crafted JSP, the attacker just needs to send an HTTP PUT request to the vulnerable server, as mentioned in the proof-of-concept (PoC) exploit code published by Peter on the Apache mailing list.

apache-tomcat-rce

The exploit would eventually allow the attacker to execute malicious code on the targeted server.

“Since this feature is typically not wanted, the most publicly exposed system will not have readonly set to false and are thus not affected,” Peter explains.

This RCE vulnerability, marked as “important,” impacts all Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81, and has been addressed with the release of Tomcat versions 9.0.1 (Beta), 8.5.23, 8.0.47 and 7.0.82.

A similar security issue (CVE-2017-12615) discovered in Tomcat 7 on Windows was patched by the Apache Tomcat developers on September 19 with the release of version 7.0.81.

Administrators are strongly recommended to apply the software updates as soon as possible and are advised to allow only trusted users to have network access as well as monitor affected systems.

The researchers have not detected any incident of the exploitation of one of these Apache Tomcat vulnerabilities in the wild.

Powered by WPeMatico

All Yahoo Accounts Compromised in the 2013 Yahoo Data Breach

Recently Oath, owner of Yahoo, and a subsidiary of Verizon revealed that the biggest known cyber data breach ever recorded in the history of humankind was larger than Yahoo initially announced. As you may remember back in 2013 Yahoo suffered a cyber-attack – approximately one billion accounts were affected. Even though that it took Yahoo more than two full years to release the information about the data breach to the public, further investigation by the current owners confirmed that the incident was on a much larger scale. A few days ago, the current owners of Yahoo distributed a notice stating that every single Yahoo account might have been compromised during this very same attack. The total amount of user accounts that Yahoo had at the time was around the three billion mark.

The news is a significant blowback for Verizon as they might have been able to negotiate a better deal when acquiring Yahoo should they knew that the cyber-attack had affected every customer, instead of the initially announced one-third of the accounts. In the notice released earlier today, Chandra McMahon, Chief Information Security Officer at Verizon said;

Verizon is committed to the highest standards of accountability and transparency, and we proactively work to ensure the safety and security of our users and networks in an evolving landscape of online threats. Our investment in Yahoo is allowing that team to continue to take significant steps to enhance their security, as well as benefit from Verizon’s experience and resources.”

The good news is that this is not a new security issue, Yahoo and Verizon claim that they have done everything possible to secure the accounts of its current users.

Yahoo is currently sending email notifications to the additional affected user accounts. The forensic experts hired by Verizon highlighted the fact that the compromised data is not known to contain passwords in clear texts, nor any banking information such as credit card numbers and bank account details. However, the investigation is still considered as an ongoing matter.

If you are worried that you may be amongst the affected ones, and you hadn’t taken any precautions when the breach was initially reported, check out our top 5 things you should do immediately.

The post All Yahoo Accounts Compromised in the 2013 Yahoo Data Breach appeared first on Panda Security Mediacenter.

Read More

Google Finds 7 Security Flaws in Widely Used Dnsmasq Network Software

dnsmasq-network-services

Security researchers have discovered not one or two, but a total of seven security vulnerabilities in the popular open source Dnsmasq network services software, three of which could allow remote code execution on a vulnerable system and hijack it.

Dnsmasq is a widely used lightweight network application tool designed to provide DNS (Domain Name System) forwarder, DHCP (Dynamic Host Configuration Protocol) server, router ads and network boot services for small networks.

Dnsmasq comes pre-installed on various devices and operating systems, including Linux distributions such as Ubuntu and Debian, home routers, smartphones and Internet of Things (IoT) devices. A shodan scan for “Dnsmasq” reveals around 1.1 million instances worldwide.

Recently, Google’s security team reviewed Dnsmasq and discovered seven security issues, including DNS-related remote code execution, information disclosure, and denial-of-service (DoS) issues that can be triggered via DNS or DHCP.

“We discovered seven distinct issues (listed below) over the course of our regular internal security assessments,” Google’s security team wrote in a blog post published on Monday. 

“Once we determined the severity of these issues, we worked to investigate their impact and exploitability and then produced internal proofs of concept for each of them. We also worked with the maintainer of Dnsmasq, Simon Kelley, to produce appropriate patches and mitigate the issue.”

Since the vulnerabilities have now been patched by Dnsmasq developer and maintainer Simon Kelley, Google researchers have released details and proof-of-concept (PoC) exploit code for each of the vulnerabilities.

Out of seven vulnerabilities discovered by the team, three can be exploited to perform remote code execution, three can be used in denial of service attacks, and one information leakage flaw.

Here’s the List of All Vulnerabilities:

dnsmasq-network-services
  • CVE-2017-14491—A DNS-based remote code execution vulnerability in Dnsmasq versions before 2.76 is marked as the most severe that allows for unrestricted heap overflows, affecting both directly exposed and internal network setups.
  • CVE-2017-14492—Another remote code execution vulnerability due to a DHCP-based heap overflow issue.
  • CVE-2017-14493—Another noteworthy DHCP-based remote code execution bug caused by a stack buffer overflow. According to Google, this flaw is trivial to exploit if it’s used in conjunction with the flaw (CVE-2017-14494) mentioned below.
  • CVE-2017-14494—An information leak in DHCP which can be combined with CVE-2017-14493 to allow attackers bypass ASLR security mechanism and execute arbitrary code on a target system.
  • CVE-2017-14495—A flaw in Dnsmasq which can be exploited to launch a denial of service (DoS) attack by exhausting memory via DNS. The flaw impacts dnsmasq only if one of these options is used: –add-mac, –add-cpe-id or –add-subnet.
  • CVE-2017-14496—Google’s Android operating system is specifically affected by this DoS issue which can be exploited by a local hacker or one who is tethered directly to the device. However, Google pointed out the service itself is sandboxed, so the risk to Android users is reduced.
  • CVE-2017-14497—Another DoS issue wherein a large DNS query can crash the software.


Since all the issues have already been addressed with the release of Dnsmasq 2.78, Dnsmasq users are advised to update their installations as soon as possible.

To patch your devices, make sure to upgrade packages on your system. Google has updated its affected services and released the security fixes to Android partners on 5 September 2017 in October’s Android security updates.

Other affected Google services are also claimed to be updated. Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have also been updated with a patched Dnsmasq.

Powered by WPeMatico

Strong Passwords Don’t Have to be Hard to Remember

Bill Burr blew it, and he knows it. The man responsible for the global password strength guidelines, which posit that you should always use alphanumeric characters and alternate uppercase and lowercase letters, recognizes his error. According to Burr, these rules “drive people crazy,” and yet, even so, do not necessarily make for good passwords.

Fourteen years of bad passwords

In 2003, while Burr was working at the National Institute of Standards and Technology, he published the report that would become the go-to reference for creating secure passwords, NIST Special Publication 800-63. Appendix A. The guide included two fundamental tips. The first is that passwords must have a combination of alphanumeric, uppercase and lowercase characters, and special characters. The second is that it should be changed every 90 days. Since its publication, the guide stipulated by Bill Burr became the foundation on which the creation of passwords is based. Numerous companies have made it an obligation and prohibit users from using passwords that do not meet these requirements. So what has changed? Why does Burr regret his role in establishing today’s password status quo?

The short answer: people are still using insecure passwords. In cases where a password is not required to comply with the recommendations of Burr and NIST, users often use easy-to-remember (and also hack) passwords such as “123456”, “111111” or “password”. But the problem goes beyond that. Even if you apply Burr and NIST logic and convert “password” to “P @ ssw0rd!”, It is still an easily hackable password. When many users use this password, it is a pattern that cybercriminals can use to access our account.

The solution

Burr isn’t the only one to have recognized that the method he invented has become obsolete and, in some cases, even insecure. NIST itself has updated its Digital Identity Guidelines to reflect the new changes. According to this agency, the key to a secure password is the use of compound phrases with words that we can easily remember, a principle that is on display in the comic below from the popular xkcd.

image: xkcd

The upper row shows a password with alphanumeric characters, capital letters and special characters (i.e., the “perfect password” according to the old thinking), which could be guessed in three days by brute force. The bottom row shows how a phrase combining four words increases the time it would take to guess the password to 550 years. For years we have resorted to passwords that are hard to remember for us but easy to guess for machines.

Time for a change

If you have not already, it’s time to review your company’s password policy. One of the reasons why many employees jeopardize the security of the company is by choosing passwords that are easy to remember, but also easy to crack. And sometimes, it turns out that some passwords that are difficult to remember are also quite vulnerable. It is important, therefore, to emphasize that this new method combines simplicity and security.

The new NIST guidelines do not recommend changing passwords regularly, but rather when it becomes necessary (after a security incident, for example). The reason is that users turn to the easiest option and make minor changes, minimizing the benefit of changing passwords. What’s more, having to insist and even require a change of password regularly could contribute to “security fatigue” among employees, an increasingly widespread problem among all types of companies.

Bill Burr and NIST have acknowledged that their method is ineffective. Now the responsibility is on us. Implementing the new guidelines will help create safer passwords and protect our business from cybercrime.

The post Strong Passwords Don’t Have to be Hard to Remember appeared first on Panda Security Mediacenter.

Read More

Strong Passwords Don’t Have to be Hard to Remember

Bill Burr blew it, and he knows it. The man responsible for the global password strength guidelines, which posit that you should always use alphanumeric characters and alternate uppercase and lowercase letters, recognizes his error. According to Burr, these rules “drive people crazy,” and yet, even so, do not necessarily make for good passwords.

Fourteen years of bad passwords

In 2003, while Burr was working at the National Institute of Standards and Technology, he published the report that would become the go-to reference for creating secure passwords, NIST Special Publication 800-63. Appendix A. The guide included two fundamental tips. The first is that passwords must have a combination of alphanumeric, uppercase and lowercase characters, and special characters. The second is that it should be changed every 90 days. Since its publication, the guide stipulated by Bill Burr became the foundation on which the creation of passwords is based. Numerous companies have made it an obligation and prohibit users from using passwords that do not meet these requirements. So what has changed? Why does Burr regret his role in establishing today’s password status quo?

The short answer: people are still using insecure passwords. In cases where a password is not required to comply with the recommendations of Burr and NIST, users often use easy-to-remember (and also hack) passwords such as “123456”, “111111” or “password”. But the problem goes beyond that. Even if you apply Burr and NIST logic and convert “password” to “P @ ssw0rd!”, It is still an easily hackable password. When many users use this password, it is a pattern that cybercriminals can use to access our account.

The solution

Burr isn’t the only one to have recognized that the method he invented has become obsolete and, in some cases, even insecure. NIST itself has updated its Digital Identity Guidelines to reflect the new changes. According to this agency, the key to a secure password is the use of compound phrases with words that we can easily remember, a principle that is on display in the comic below from the popular xkcd.

image: xkcd

The upper row shows a password with alphanumeric characters, capital letters and special characters (i.e., the “perfect password” according to the old thinking), which could be guessed in three days by brute force. The bottom row shows how a phrase combining four words increases the time it would take to guess the password to 550 years. For years we have resorted to passwords that are hard to remember for us but easy to guess for machines.

Time for a change

If you have not already, it’s time to review your company’s password policy. One of the reasons why many employees jeopardize the security of the company is by choosing passwords that are easy to remember, but also easy to crack. And sometimes, it turns out that some passwords that are difficult to remember are also quite vulnerable. It is important, therefore, to emphasize that this new method combines simplicity and security.

The new NIST guidelines do not recommend changing passwords regularly, but rather when it becomes necessary (after a security incident, for example). The reason is that users turn to the easiest option and make minor changes, minimizing the benefit of changing passwords. What’s more, having to insist and even require a change of password regularly could contribute to “security fatigue” among employees, an increasingly widespread problem among all types of companies.

Bill Burr and NIST have acknowledged that their method is ineffective. Now the responsibility is on us. Implementing the new guidelines will help create safer passwords and protect our business from cybercrime.

The post Strong Passwords Don’t Have to be Hard to Remember appeared first on Panda Security Mediacenter.

Read More

2-Year-Old Linux Kernel Issue Resurfaces As High-Risk Flaw

linux-kernel-hacking

A bug in Linux kernel that was discovered two years ago, but was not considered a security threat at that time, has now been recognised as a potential local privilege escalation flaw.

Identified as CVE-2017-1000253, the bug was initially discovered by Google researcher Michael Davidson in April 2015.

Since it was not recognised as a serious bug at that time, the patch for this kernel flaw was not backported to long-term Linux distributions in kernel 3.10.77.

However, researchers at Qualys Research Labs has now found that this vulnerability could be exploited to escalate privileges and it affects all major Linux distributions, including Red Hat, Debian, and CentOS.

The vulnerability left “all versions of CentOS 7 before 1708 (released on September 13, 2017), all versions of Red Hat Enterprise Linux 7 before 7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red Hat Enterprise Linux 6 are exploitable,” Qualys said in an advisory published yesterday.

The vulnerability, which has been given a CVSS3 Base Score of 7.8 out of 10, resides in the way Linux kernel loads ELF executables, which potentially results in memory corruption.

Researchers find that an unprivileged local user with access to SUID (or otherwise privileged) Position Independent Executable (PIE) binary could use this vulnerability to escalate their privileges on the affected system.

In order to mitigate this issue, users can switch to the legacy mmap layout by setting vm.legacy_va_layout to 1, which will effectively disable the exploitation of this security flaw.

Since the mmap allocations start much lower in the process address space and follow the bottom-up allocation model, “the initial PIE executable mapping is far from the reserved stack area and cannot interfere with the stack.”

Qualys says this flaw is not limited to the PIEs whose read-write segment is larger than 128MB, which is the minimum distance between the mmap_base and the highest address of the stack, not the lowest address of the stack.

So, when passing 1.5GB of argument strings to execve(), any PIE can be mapped directly below the stack and trigger the vulnerability.

Linux distributions, including Red Hat, Debian, and CentOS, have released security updates to address the vulnerability.

The Qualys team has promised to publish a proof-of-concept soon exploit that works on CentOS-7 kernel versions “3.10.0-514.21.2.el7.x86_64” and “3.10.0-514.26.1.el7.x86_64,” once a maximum number of users have had time to patch their systems against the flaw.

Stay Tuned!

Powered by WPeMatico