STE WILLIAMS

North Korea Seen Using ELECTRICFISH, BADCALL Malware Variants

The FBI and CISA issued an alert the same week researchers disclosed a new campaign launched by actors with North Korean ties.

The Cybersecurity and Infrastructure Security Agency (CISA) and Federal Bureau of Investigation (FBI) have issued malware analysis reports (MARs) on malicious activity from North Korea, which the US government calls Hidden Cobra. Attackers have recently been using “ELECTRICFISH” and “BADCALL” malware variants, they reported this week.

ELECTRICFISH is a “North Korean tunneling tool” with the primary purpose of tunneling traffic between two IP addresses, US-CERT explains in a May advisory. It attempts to create sessions with the attackers’ IP address and the target’s IP address; if a connection is made, the malware will implement a custom protocol that lets traffic efficiently transfer between the two machines.

BADCALL is a Trojan designed to force an infected system to act as a proxy server. It’s meant to turn a victim host into a “hop point” by relaying traffic to a corporate system. Attackers connecting to a target machine must first authenticate; if successful, they can issue a command to create a proxy session between the operator and another server. 

“FBI has high confidence that HIDDEN COBRA actors are using malware variants in conjunction with proxy servers to maintain a presence on victim networks and to further network exploitation,” officials write in the BADCALL MAR. Officials published this week’s reports to inform network defense and reduce exposure to North Korean malicious cyber activities.

The same week CISA and the FBI issued this update, Prevailion researchers spotted an attack group with ties to North Korea targeting US entities. They attribute the activity to the Kimsuky attack group, otherwise known as Smoke Screen. Its discovery of the coordinated threat campaign began with detection of Trojanized documents discussing nuclear deterrence, North Korea’s nuclear submarine program, and North Korean economic sanctions, they report.

This campaign, dubbed “Autumn Aperture,” marks attackers’ shift to obscure file formats including Kodak FlashPix, which aren’t typically picked up in antivirus products. These files are included in Microsoft Word documents sent in socially engineered emails. Researchers believe these emails would have been expected by victims, increasing the attackers’ chance of success.

Read the CISA and FBI’s full malware analysis reports here.

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/threat-intelligence/north-korea-seen-using-electricfish-badcall-malware-variants/d/d-id/1335793?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Indictments Do Little to Stop Iranian Group from New Attacks on Universities

Cobalt Dickens targeted more than 60 universities in the US and elsewhere this summer, according to a new report.

Cobalt Dickens, a threat group that the US has accused of working on behalf of the Iranian government, has launched a large global phishing campaign aimed at students, faculty, and staff at dozens of universities.

The goal, as with the group’s previous campaigns, appears to be to steal research data and other academic resources.

The US government indicted nine members of the group in March 2018 on charges related to the theft of some 31TB of academic data and intellectual property from universities, businesses, government, and nongovernmental organizations. There have also been multiple takedown attempts and public disclosures of the threat actor’s activities.

Even so, there’s no sign that Cobalt Dickens has stopped or even slowed its attacks, Secureworks said in a report this week on a new campaign the group conducted in July and August. According to the security vendor, the latest wave of phishing emails was sent to targets in over 60 universities across the United States, Canada, Australia, the United Kingdom, Switzerland, and Hong Kong.

The latest operation is similar to one Cobalt Dickens conducted last August when it used previously compromised university systems to send library-themed phishing emails to targeted individuals.

The messages purport to be about some library-related matter — such as an account expiring because of inactivity — and contain links to pages that are spoofed to look exactly like the login page of that specific university. When victims enter their username and password on the login page, the credentials are stored locally on the spoofed website and the user is then redirected to the valid university website, Secureworks said in its report this week.

Cobalt Dickens is gathering university credentials in order to access library and other proprietary systems, says Allison Wikoff, senior researcher at Secureworks Counter Threat Unit (CTU).”Past reporting and the US DoJ indictment suggests the credentials are used to take the intellectual property of these institutions as well as the library resources they have access to,” she says.

Wikoff says that Secureworks has not been able to determine a specific commonality among the targeted universities regarding their academic programs or areas of specialization. Cobalt Dickens also doesn’t appear to be limiting its focus to students, staff, and faculty working in specific disciplines or areas of research, she says.

In its report, Secureworks described the threat actor as taking advantage of free online services and publicly available tools wherever possible in its latest campaign. For example, it registered at least 20 new domains using Freenom, a provider of free top-level domains.

Many of the domains use valid SSL certificates issued by Let’s Encrypt, a nonprofit that issues free SSL certificates. Similarly, to copy the login pages of the targeted universities, Cobalt Dickens has been using SingleFile, a publicly available tool on GitHub, and HTTrack Website Copier, another free application, the security vendor said.

So far, Cobalt Dickens has targeted some 380 universities in 30 countries in its phishing campaigns. The number includes the 30 or so universities that were targeted in the latest wave in July and August.

The group’s continued attacks despite the indictments and public exposure of its tactics and techniques are an indication of how difficult it can be to stop some threat groups.

“CTU researchers surmise the operations have been successful, so there’s little incentive to stop,” Wikoff says. “Regarding takedown activity, infrastructure is easily rebuilt. We are aware our disclosure may not impact operations in the long term but hope that it minimally tampers it for some time,” she says.

 

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

Jai Vijayan is a seasoned technology reporter with over 20 years of experience in IT trade journalism. He was most recently a Senior Editor at Computerworld, where he covered information security and data privacy issues for the publication. Over the course of his 20-year … View Full Bio

Article source: https://www.darkreading.com/attacks-breaches/indictments-do-little-to-stop-iranian-group-from-new-attacks-on-universities/d/d-id/1335795?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Instagram Bug Put User Account Details, Phone Numbers at Risk

The vulnerability, now patched, is the latest in a series of bad news for Facebook.

A now-patched Instagram vulnerability could have exposed users’ account data and phone numbers to cyberattackers, parent company Facebook confirmed in a new report from Forbes.

The bug was discovered by an Israeli hacker who goes by the handle @ZHacker13. It could have potentially been used to access user data including names, full phone numbers, and Instagram account numbers and handles – all an attacker needs to narrow their focus on a specific person.

It’s the latest in a series of bad news for Facebook, which recently patched an account-takeover flaw in Instagram that would have let an attacker take over any account by resetting its password. Earlier this month, 419 million phone numbers belonging to Facebook users were found publicly accessible in a third-party database left online without password protection.

This particular vulnerability existed in Instagram’s contact importer, which, when subject to brute force attacks, could grant an attacker access to the data. An attacker could use an algorithm to verify individual phone numbers to see which are linked to an Instagram account. Exploiting a second process could give them the name and number linked to the phone number, enabled by the Sync Contacts tool that lets users find their contacts on the platform.

In theory, an attacker could leverage a wealth of bots to brute force Instagram’s login form and collect legitimate phone numbers, Forbes points out in its report. Instagram caps syncing to three times per day, per account; however, an attacker with enough bots could bypass this limitation. While this bug was difficult to exploit, it was possible for an attacker to build a collection of user data.

“This vulnerability further demonstrates the over-reliance of phone numbers as a strong form of authentication to digital platforms like Instagram,” said Zack Allen, director of threat operations at ZeroFox, who in an email called the importance of phone numbers as identifiers on modern Internet platforms “harrowing.”

“A database such as the one leaked last week with millions of phone numbers, and a vulnerability like this to tie accounts to phone numbers, sets a dangerous precedent for those vulnerable to SIM swaps,” he added.

@ZHacker13 shared his findings with Facebook in early August. Facebook initially responded, saying these types of vulnerabilities, which show a given email address or phone number is linked with a specific account, are “extremely low risk.” However, bugs that let an attacker figure out which user ID an email address or phone number is linked to are another story.

After further communication in which the company reportedly expressed little urgency to fix the problem, Facebook told @ZHacker13 this was “a valid issue.” It has now addressed the problem; the researcher has tested his exploit and confirmed with Forbes it no longer works. There has not yet been evidence indicating account data was misused as a result of the vulnerability.

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

Kelly Sheridan is the Staff Editor at Dark Reading, where she focuses on cybersecurity news and analysis. She is a business technology journalist who previously reported for InformationWeek, where she covered Microsoft, and Insurance Technology, where she covered financial … View Full Bio

Article source: https://www.darkreading.com/risk-management/instagram-bug-put-user-account-details-phone-numbers-at-risk/d/d-id/1335797?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Escaping Email: Unlocking Message Security for SMS, WhatsApp

Messaging is growing in importance as dislike for email increases. That means knowing how to protect critical data in the messaging era is a must for IT security.

As messaging in forms as diverse as SMS, WhatsApp, and Facebook Messenger have become more popular, their use seems to have outrun IT security’s ability to protect data sent over these various systems. As more employees look to messaging for their business communication, what should companies do to make sure that rapid communication doesn’t equal insecure communication?

Image: wutzkoh via Adobe Stock

“The biggest challenge today is dealing with interactive and ephemeral content sources that are very difficult to process, review, and remediate with technologies designed for email,” says Robert Cruz, senior director of information governance at Smarsh.

As IT security groups look to secure their organizations’ data, two broad avenues can be taken for protecting messaging. They’ll sound familiar. The first is to focus on the technology, how the systems work, and the protections they offer (or don’t). The second is to focus on processes and procedures that include factors like the way employees use the services and think about the data they’re sharing.

Acceptto CEO Shahrokh Shahidzadeh points out some basic considerations that cybersecurity professionals should keep in mind when evaluating messaging services and formulating security policies around them.

“First, it is best to pick apps that offer end-to-end encryption, including the encryption of metadata,” he says.

End-to-end encryption is one of the factors many users cite when asked why they choose a messaging service like WhatsApp. And while that encryption is critical, it’s not the only consideration, especially when an employee seeks to use one of these public messaging services to communicate with customers or partners.

“Knowing what data exactly is captured from your device is a key factor. Apps that harvest the contact list or store any metadata associated with communication are problematic,” Shahidzadeh explains.

In addition, knowing how the messaging service itself protects the data (encrypted or not) it collects and that flows through its servers is important because of what NIST 800.53 calls “inherited risk.” That is, security and privacy controls that cover a very broad range (the organization and its suppliers) may introduce risk that must be accepted by much smaller units (like a department). In this case, the service relationship and its security have an impact on every department that has an employee using the service.

Of course, even encryption can be of limited use when malware uses a messaging app to infect the device itself. A recent campaign of commercial malware using WhatsApp to attack smartphones is merely the latest example of attackers using the “security” of WhatsApp to increase the effectiveness of an attack.

Best Practices Emerge
Because organizations can use some of the process- and data-related security principles that have informed security of other technologies, best practices are beginning to emerge for securing messaging apps. Cruz says the first of these is simple: The IT security group must become actively engaged in evaluating messaging services and products before employees use them — not after they’re already in wide use.

Next, “Policies must be updated to encompass new messaging, mobile and collaborative technologies — including explicit examples of acceptable and prohibited uses,” he says. Those explicit examples will go a long way toward eliminating confusion about how policies are to be applied, though security has to be sure to point out they are examples — not statements of the policy’s limits.

Cruz says training programs should be constantly updated to include permissible use of messaging for high-value organizational data. That training should include explicit language on scenarios when IT security should be engaged and brought into the conversation on new messaging services, he says.

That training also must include warnings against social engineering attacks that can use the special properties and relationships in services like WhatsApp for phishing campaigns, which are the latest variation of “smishing” attacks, making increasing use of mobile devices as an attack surface in the enterprise. These social engineering attacks can easily make even the comfortable confines of a restrictive “walled garden” like the Apple App Store ineffective against attacks and exploits.

Finally, Cruz points out, it important that IT security continually evaluate technology that can “preserve the context and metadata to track, inspect, and remediate security issues that can surface from interactive and non-text content sources.” It is, as always, difficult to protect what you cannot see and define.

Cybersecurity professionals must remember that, as NIST states in 800.53, “There is no single set of controls that addresses all security and privacy concerns in every situation.” As their employees look for new ways to stay in touch with colleagues, partners, and customers, security groups will have to continually evolve to stay if not ahead of their employees, then at least not too far behind.

Related Content:

 

Curtis Franklin Jr. is Senior Editor at Dark Reading. In this role he focuses on product and technology coverage for the publication. In addition he works on audio and video programming for Dark Reading and contributes to activities at Interop ITX, Black Hat, INsecurity, and … View Full Bio

Article source: https://www.darkreading.com/edge/theedge/escaping-email-unlocking-message-security-for-sms-whatsapp/b/d-id/1335794?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

Google experiments with DNS-over-HTTPS in Chrome

Following hot on Mozilla’s trail, Google officially announced its own DNS-over-HTTPS (DoH) experiment in Chrome this week.

Mozilla recently announced that it would turn on DoH by default for users of the Firefox browser’s desktop version in the US. This provides some privacy protections compared with regular DNS queries, although as Paul Ducklin explains in the Naked Security podcast, it is not without its issues:

Nevertheless, Google clearly doesn’t want to be outdone. It published a blog post on Tuesday providing more detail on DoH functionality that it will include in Chrome 78.

Google is taking a slightly different approach to Mozilla, though. For one thing, it won’t change the user’s DNS provider. When Chrome makes a web request, it will check to see if that provider is on a list of DoH-friendly DNS services which Google says it has vetted for strong security and privacy. Only if it is on that list will it switch to DoH. This brings a significant benefit, according to the search and advertising giant:

By keeping the DNS provider as-is and only upgrading to the provider’s equivalent DoH service, the user experience would remain the same. For instance, malware protection or parental control features offered by the DNS provider will continue to work.

Right now, there are six providers in that list alongside Google itself: CleanBrowsing, Cloudflare (which is Mozilla’s DoH provider of choice), DNS.SB, OpenDNS, and IBM’s Quad9.

Google is making the service available on all Chrome-supported platforms with the exception of Linux and iOS. However, that doesn’t include managed Chrome deployments, which means that users of Chrome Enterprise and education customers are out for the time being. That seems to be its way of sidestepping the split-horizon problem that we outlined in our story about Mozilla’s DoH-by-default implementation earlier this week.

For now, the experiment will roll out to “a fraction” of Chrome users, although Google didn’t respond to questions about how they will be selected or where they are. If you’re one of them, you will be able to opt-out by disabling the flag, accessible in Chrome 78 by typing the following into your address bar: chrome://flags/#dns-over-https

Chrome 78 will enter beta sometime between 19 and 26 September 2019, and is due for a stable release on 22 October 2019.

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/MXZMT9v3Sj8/

S2 Ep8: Facebook leak, $5m ransoms, DNS angst – Naked Security Podcast

Episode 8 of the Naked Security Podcast is now live!

This week I stepped in to host the show with Paul Ducklin, Ben Jones and special guest Peter Mackenzie.

Peter fights complex and advanced malware here at Sophos and joined us to share the latest ransomware trends [0’37”]. Ben discusses a recent leak of Facebook data that led to the exposure of more than 100 million phone numbers [15’50”] and Duck explains why not everyone is happy about Mozilla’s move towards DNS over HTTPS [31’36”].

Do you want us to answer your question next week? Simply comment below.

By the way – here’s our latest fun animation based on last week’s episode. Watch now and see if you can beat Duck’s limerick – comment below with your own verse! (For bonus points, try starting with the same first line: There was a young lady called Prue…)

Listen and rate via iTunes...
Sophos podcasts on Soundcloud...
RSS feed of Sophos podcasts...

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/TXt7zUSzyX4/

The Fight Against Synthetic Identity Fraud

Advanced data and innovative technology will help organizations more easily identify abnormal behavior and tell legitimate customers apart from “fake” ones.

Synthetic identity fraud — a type of fraud attack carried out by criminals who have created fictitious identities — continues to be a vexing challenge for many financial institutions and retail organizations, even prompting a recent white paper by the Federal Reserve. At the same time, many remain optimistic that initiatives on the near horizon may severely disrupt fraudulent behavior. Most notably, the Social Security Administration’s electronic Consent Based Social Security Number Verification service — the pilot program scheduled for June 2020 — is designed to bring efficiency to the process for verifying Social Security numbers directly with the government agency. That said, criminals still have a window of opportunity to maximize their inventory of synthetic identities before the program kicks in.

It typically takes fraudsters approximately 12 to 18 months to create and nurture a synthetic identity prior to “busting out” — the act of attempting to build a credit history, with the intent of maxing out all available credit and eventually disappearing. That means fraudsters are investing money and time building numerous tradelines — a term to describe credit accounts listed on a credit report —  to ensure these “fake” identities are in good credit standing in order to steal the largest amount of money possible. Any significant progress in making synthetic identities easier to detect could cost fraudsters significant time and money.

For instance, an organized crime ring may be sitting on a large pool of “developed” synthetic identities. Just like perishable food in a grocery store, these synthetic identities now have an expiration date: June 2020. To monetize as many of these identities as possible, some organized crime rings, as well as other fraudsters, may increase their volume of synthetic identity fraud attacks in the coming months.

With the Social Security Administration’s pilot program not scheduled for launch until the middle of next year, how can financial institutions and other organizations bridge the gap and adequately prepare for a potential uptick in synthetic identity fraud attacks? It comes down to a multilayered approach that relies on advanced data, analytics, and technology — and focuses on identity.

Far too many financial institutions and other organizations depend solely on basic demographic information and snapshots in time to confirm the legitimacy of an identity. These organizations need to think beyond those capabilities. The real value of data in many cases lies between the data points. We have seen this with synthetic identity — where a seemingly legitimate identity only shows risk when we can analyze its connections and relationships to other individuals and characteristics. The use of advanced analytics (such as machine learning) and innovative technology (such as device intelligence and behavioral biometrics) can help organizations detect patterns and anomalies that indicate potentially fraudulent behavior.

Additionally, evaluating the historical behaviors and velocity in which basic demographic attributes are used can provide more confidence during the verification process. For example, if a Social Security number is used frequently to apply for credit within a short period of time — particularly with different addresses — it could indicate fraudulent behavior. Once potentially fraudulent behavior is detected, financial institutions need to deploy secondary identity checks prior to a lending decision, such as one-time passocdes or remote document verification.

Beyond the ability to minimize and prevent future losses associated with synthetic identity fraud, proper identity management practices can also save financial institutions money during the prescreen process. Because many synthetic identities appear to have good credit — which can often pass prescreen criteria – if organizations can identify high-risk accounts, it diminishes the cost to review these identities during the application stage.  

While there are programs and initiatives in the works to help financial institutions and other organizations combat synthetic identity fraud, it’s important to keep in mind there’s no silver bullet — a multilayered approach is required. The evolving patterns in the fraud landscape suggest we may see a burst in activity around synthetic identity bust-out in the coming months. Now is the time to apply additional layers of intelligence to the problem. The use of advanced data and innovative technology will position organizations to more easily identify abnormal behavior and recognize legitimate customers from “fake” ones.

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

Kathleen Peters is Experian’s senior vice president and head of fraud identity, where she is responsible for the strategic direction of the company’s fraud and identity products and capabilities. In 2018 and 2019, Kathleen was named a “Top 100 Influencer in Identity” by One … View Full Bio

Article source: https://www.darkreading.com/risk/the-fight-against-synthetic-identity-fraud/a/d-id/1335734?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

APIs Get Their Own Top 10 Security List

OWASP’s new list of API weaknesses focuses on issues that have caused recent data breaches and pose common security hazards in modern cloud-based applications.

The Open Web Application Security Project (OWASP) has unveiled its first release candidate for a top 10 list focused on the most critical classes of security issues affecting the communications between online applications, mobile devices, and Web services.

The top issues identified in the API Security Top 10 list, published today, include broken authorization and authentication functions, excessive data exposure, and a failure to focus on rate limiting and resource limiting attacks. While the group’s most well-known list — the OWASP Top 10 rankings — focuses on online services and Web application, and includes security issues that are caused by application programming interfaces (APIs), it does not focus on the specific problems plaguing the communications technique, says Erez Yalon, one of the leaders of the API Security Top 10 project and director of security research at software security firm Checkmarx.

“Modern applications that are built on these APIs directly expose the business logic,” he says. “Since these APIs are directly exposed, there is a new class of attacks that are specific to APIs. Hence, we have to think about APIs and their security in a whole new way.”

Currently labeled as an incubator project, the list focuses on issues that have caused recent data breaches and pose common security hazards in modern cloud-based applications. A number of major data breaches have been caused by cloud infrastructure and Web-based applications that have exposed insecure APIs. 

In 2018, for example, a research fellow with the Mozilla Foundation scraped nearly 208 million transactions on the peer-to-peer payment app Venmo, revealing the purchase profiles of its users— from lovers to weed dealers. In June, another 7 million transactions were scraped using the company’s developer API over six months, despite the company’s limiting for API calls. The issues exploited by the attack include excessive data exposure and a lack of rate limiting. 

While privacy is often a major casualty of lax API security, insecure API infrastructure can also allow attackers to take control. Just last month, Cisco patched several critical vulnerabilities that could have allowed an attacker to send malicious API requests to the Web management interfaces and compromise its small-business switches and big-data packages. This underscores the hazards of broken authentication mechanisms and broken function-level authorization flaws — both issues on the top 10 list.

“Every modern architecture concept, like mobile, IoT, microservices, cloud environments, and single-page applications, deeply rely on APIs,” Yalon says. “The majority of enterprises cite APIs as important to digital transformation and API security as their top challenge.”

Publication of the list comes as companies increasingly worry that a combination of the move to developing applications for the cloud and undocumented APIs are leaving their businesses open to attack. Six in 10 companies have more than 400 APIs, and nearly half of companies do not have confidence that they can detect the malicious use of their APIs, according to a survey of 100 security and IT professionals conducted by security firm Ping Identity.

“We’re quickly moving from a world where the average enterprise manages a handful of APIs and web services to one where they are contending with thousands of APIs and microservices,” said Jason Bonds, vice president of intelligence at Ping Identity, in a statement. “And, these are spanning multiple infrastructure providers and regions around the globe.”

For that reason, many API security issues are often hidden, resulting in some serious data breaches. 

In perhaps the worst failure in recent memory, First American Financial allowed anyone with a browser to send requests to its server for sensitive financial documents provided as part of the mortgage process. The documents were serialized — meaning the identifiers incremented in sequence — allowing anyone to harvest 885 million files dating back to 2003

And even when the API itself is secure, many developers inadvertently leak credentials online as part of backing up files to a repository, such as GitHub. Last month, the company — now a subsidiary of Microsoft — revealed its automated scanning service found, in a single year, a billion authentication tokens in the code libraries that developers placed online.

For that reason, companies should make sure they are inventorying their APIs, including requiring DevOps engineers to document a secure process for creating and deploying new API hosts and tracking old APIs, says Checkmarx’s Yalon. They also need to review and analyze their authentication and authorization mechanism, as well as the process by which developers modify the code behind the API.

“Having a very clear understanding of the APIs, with a well-maintained inventory and documentation … is very critical in the world of APIs,” Yalon says. “It helps developers prevent shadow APIs and excessive data exposure.”

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

Veteran technology journalist of more than 20 years. Former research engineer. Written for more than two dozen publications, including CNET News.com, Dark Reading, MIT’s Technology Review, Popular Science, and Wired News. Five awards for journalism, including Best Deadline … View Full Bio

Article source: https://www.darkreading.com/application-security/apis-get-their-own-top-10-security-list/d/d-id/1335786?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

NetCAT Vulnerability Is Out of the Bag

Researchers discover a side-channel vulnerability that exploits the network performance-enhancing capabilities of recent Intel server CPUs.

A new side-channel vulnerability it out, but this one comes with a twist: Rather than exploiting weaknesses in speculative execution routines within the CPU, the vulnerability — named NetCAT by the researchers who found it — uses performance-enhancing networking capabilities to potentially leak information transmitted during an SSH-protected session.

NetCAT, discovered by Michael Kurth, Ben Gras, Dennis Andriesse, Cristiano Giuffrida, Herbert Bos, and Kaveh Razavi, of ETH Zurich, Switzerland, takes advantage of Data-Direct I/O (DDIO), a feature of recent Intel server-grade CPUs that allows peripherals to read/write from/to the fast (last-level) cache. It was introduced to improve performance of servers in high-speed network environments.

With NetCAT, an attacker on a remote system can, by merely sending packets to the targeted server, get information on the arrival timing of packets sent by a third system. After processing that information with statistical routines, an accurate decoding of text being typed on the third system can be created.

Intel has acknowledged the validity of the vulnerability and paid a bounty to the researchers. It recommends customers disable DDIO, which is enabled by default, to mediate the vulnerability.

Read more here and here.

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

Dark Reading’s Quick Hits delivers a brief synopsis and summary of the significance of breaking news events. For more information from the original source of the news item, please follow the link provided in this article. View Full Bio

Article source: https://www.darkreading.com/vulnerabilities---threats/netcat-vulnerability-is-out-of-the-bag/d/d-id/1335790?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple

A Definitive Guide to Crowdsourced Vulnerability Management

Knowing about a bug and actually securing it are very different things. These six steps will get you from “oh, sh*t” to fixed.

There is no shortage of vulnerabilities to find. According to a new report from Bugcrowd, the total number of vulnerabilities reported over the past year has nearly doubled. (Disclaimer: I am the chief security officer at Bugcrowd). Crowdsourced security programs have emerged as an effective way to help organizations find and fix these unknown vulnerabilities faster. But knowing about a bug and actually fixing it are very different things.

What’s needed is a clear and demonstrable intake channel to receive and process vulnerability submissions from external security researchers, plus consistent and repeatable processes and procedures to respond to the surfaced vulnerabilities.

So, what should that workflow look like? Here is a helpful checklist to guide your organization:

1. Take all submissions seriously. It’s easy to get wrapped up in just focusing on critical-level (P1 and P2) submissions. But it’s often the P3s and P4s that are chained together that lead to another critical exposure. Keep in mind that a person took his or her own time to identify a security issue and report it. Researchers are showing you a measure of respect, so do the same for them and review every report. Ignoring researcher submissions wastes their time and only prolongs your company’s exposure. The researchers may be wrong about the submission’s overall risk of impact. And that’s OK! They will appreciate your acknowledgement of their work.

2. Know the risk, get it fixed. After a critical issue has been identified, it’s important to think beyond just filing a ticket and waiting for engineering to fix it. While this might be out of your immediate scope, it’s now your responsibility to make sure the vulnerability gets remediated in a timely manner. Follow an agreed upon security development life cycle (SDLC): track down all the relevant parties, explain the risk, and escalate as needed. Critical findings should never get lost in the backlog, and security is no place for politics to endanger the trust of your end users. If the entire organization is aware of the risk and is onboard with security being a priority, then it makes a lot easier to get things fixed more quickly.

3. Thank the reporting researcher and have an open dialogue. Communication here is key. Make sure researchers know they are valued and welcome to continue hacking on your program. This is done by putting in the time, effort, and dollars. Be sure to tip if it’s a particularly valuable finding! Even if the submission is invalid, taking the time to understand the submission from the researcher’s perspective. Coaching them on true impact or how to better find vulnerabilities on your platform will earn their loyalty, which can pay off for future submissions. It’s not difficult to orchestrate these narratives with a managed vulnerability disclosure or bug bounty program. To avoid misunderstandings, be open and willing to have a conversation to completely appreciate what’s being reported and why.

4. Validate the fix. Often engineers may not fully understand what they’re fixing, or why. Or, maybe the problem was outsourced to someone who is three levels abstracted from where it was found, and they’re just looking to make the proof of concept go away. The fix may be partial (blacklisting one or two offending characters), uninformed, or ineffective altogether. Be sure the fix is sufficient; try to break it, review the code, and send it back if it’s incomplete.

5. Keep in touch. Once remediated, go back to the researcher and tell him or her what you’ve done to see if they can find a way around that hasn’t been considered by your team. Remember to thank them again for their work, and that you look forward to future findings.

6. Increase your scope and rewards. Having avoided disaster, now more than ever it’s important to double down on the reality that having a crowdsourced program can (and does) help you identify issues before they’re otherwise exploited in the wild. Make sure researchers are testing your full attack surface and are incentivized to do so.

Over the last few years, we saw mega-bugs like Meltdown, Spectre, ETERNALBLUE, Double Kill, and the notorious vulnerability in Apache Struts2 — which was responsible for the Equifax breach. These are just a few examples of bugs that were exploited in ways that made headlines and left many systems, users, and companies devastated.

Crowdsourced security programs are changing how we find and fix these software vulnerabilities, as well as helping companies avoid becoming tomorrow’s headline. With a strong crowdsourced vulnerability management program in place, organizations can easily take any bug from “oh, sh*t” to fixed.

Related Content:

Check out The Edge, Dark Reading’s new section for features, threat data, and in-depth perspectives. Today’s top story: “Community Projects Highlight Need for Security Volunteers.”

David Baker brings over 20 years of experience in enterprise data security, information security and government computer research to his role as CSO. Prior to Bugcrowd, David served as the Chief Security Officer at Okta. As CSO, David was responsible for the security of … View Full Bio

Article source: https://www.darkreading.com/risk/a-definitive-guide-to-crowdsourced-vulnerability-management-/a/d-id/1335747?_mc=rss_x_drr_edt_aud_dr_x_x-rss-simple