Taiwanese manufacturer braced for twin threat

Read More

Russian cyber-criminals rented it out to other groups

Read More

This blog was written by an independent guest blogger.

Stop, look, listen; lock, stock, and barrel; “Friends, Romans, Countrymen…” The 3 Little Pigs; Art has 3 primary colors; photography has the rule of thirds; the bands Rush and The Police; the movie The 3 Amigos. On and on it goes – “Omne trium perfectum” – “Everything that comes in threes is perfect.”

While this article doesn’t provide perfection, we’ll focus on the top three API vulnerabilities (according to OWASP). OWASP’s international standard is important to read because it’s not only developed by professionals worldwide, but it’s also read by the threat actors who will take advantage of those vulnerabilities.

OWASP determines the risk of APIs based on the level of the API vulnerability’s Exploitability, Weakness Prevalence, Weakness Detectability, and Technical Impact. Therefore, the API Top 10 are in order of OWASP’s own risk methodology. Their risk method doesn’t consider the chance of materialization or the impact – that’s left up to each business. But these three are great places to start because they’ve affected large companies such as Peloton in 2021.

1. API1:2019 Broken Object Level Authorization (BOLA)

In this vulnerability, aka BOLA, APIs expose endpoints that handle object identifiers, which in turn allows visitors access to numerous resources. This attack is like Insecure Direct Object Reference (IDOR), where applications use user-supplied credentials to access objects. In the API sphere, BOLA is more accurate than IDOR – the problem is broken authorization over a sequence of API calls. Every call to a data source that uses user-provided input should include object level auth checks.

Here’s a simple example of how this works.

An API call has the following path: /customers/user/bob/profile. An attacker will attempt various names in place of “bob” to see what can be accessed, such as:

/customers/user/alice/profile

/customers/user/john/profile

Even if the name is replaced with long mixed characters, if those character sequences are sequential or otherwise guessable, the problem remains and is vulnerable.

Mitigation

Implement an authorization mechanism that relies on user policies and hierarchy.
Use an authorization mechanism to check if the logged-in user has authorization to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
Use random and non-guessable values for record IDs.
Evaluate the authorization checks.

2. API2:2019 Broken User Authentication

When authentication mechanisms are implemented improperly, attackers can compromise authentication tokens or exploit implementation flaws by assuming other users’ identities.

A prominent example of this vulnerability is the 2021 Parler breach. Other factors came into play in the whole breach, but at least one endpoint did not require authentication, giving anyone who found it (and someone did) unhindered access to images.

Mitigation

Use industry-standard authentication and token generation mechanisms (and read the accompanying documentation).
Be aware of all the possible API authentication flows in the product or service (mobile/ web/deep links that implement one-click authentication/etc.).
Treat “forget password” endpoints as login endpoints in terms of brute force, rate limiting, and lockout protection.
Use the OWASP Authentication Cheat Sheet.
Implement multi-factor authentication wherever and whenever possible.
Check for weak passwords.
API keys should be used for client app authentication, but not user authentication.

3. API3:2019 Excessive Data Exposure

Developers, designers, and/or engineers may not take data sensitivity into consideration. They may favor using client-side filtering, which means that data is not filtered before reaching the user.

When testing, ask “What should the user know?” and display the minimum amount of data necessary.

Mitigation

Test or capture the API calls (using, e.g., Postman or OWASP ZAP) and look for “token” or “key” to see what it reveals.
Threat model the data to review the flow and data filtering.
Never depend on client-side filtering of sensitive data.
Review the API responses. Do they contain valid data?
Determine what data type is crossing the wire. Is it sensitive, confidential, PII, etc.? If it is, then it poses both security and privacy threats.

An important aspect of security and risk management is acknowledging that nothing is 100% secure or risk-free. There’s always a risk. One concept in self-defense is appearing hard to get. Someone who walks tall and confidently, has no visible jewelry or purse, and is not distracted is considered a much harder target for being accosted than someone who slumps, lazes along, has visible necklaces and bracelets, and is on the phone (distracted). The former doesn’t eliminate risk but presents a greatly reduced risk.

Securing APIs needs to move toward a confident posture and reduced risk model. Attackers are looking at the OWASP API Top 10 and other lists of common attack mechanisms, then applying those to their targets. An API that has missed any of these is at much greater risk than an organization that has addressed these, even if there are some other security issues (and there are always security issues). But if attackers have a difficult time making headway on a target, then it’s more likely that they’ll move on. A major challenge for organizations is that one never knows when or what attackers are doing, so staying on top of security maintenance is another challenge (think of it as job security). One way to become better acquainted with API security is to examine the fundamental aspects.

Focusing efforts on a few high-risk items won’t solve all the vulnerabilities, but that focus provides immediate guidance for engineering, developers, security, and privacy teams. In turn, this provides a roadmap for projects and tasks and prevents any appearance of negligence. These active and engaged responses to known vulnerabilities increase service security and customer trust.

Read More

Cryptojacking definition

Cryptojacking is the unauthorized use of someone else’s compute resources to mine cryptocurrency. Hackers seek to hijack any kind of systems they can take over—desktops, servers, cloud infrastructure and more—to illicitly mine for crypto coins.

Regardless of the delivery mechanism, cryptojacking code typically works quietly in the background as unsuspecting victims use their systems normally. The only signs they might notice is slower performance, lags in execution, overheating, excessive power consumption, or abnormally high cloud computing bills.

How cryptojacking works

Coin mining is a legitimate process in the cryptocurrency world that releases new cryptocurrency into circulation. The process works by rewarding currency to the first miner who solves a complex computational problem. That problem completes blocks of verified transactions that are added to the cryptocurrency blockchain.

To read this article in full, please click here

Read More

MongoDB CISO Lena Smart wants to make a good impression on prospective employees.

So she’s attentive to what goes into the ads she posts when seeking to hire.

“I think people forget that these are the first introductions that many candidates have to their companies, and first impressions matter,” she says.

That may matter more today than ever before, given how much movement there is in the labor market overall and, more specifically, how fierce competition is for cybersecurity talent.

Of course, writing a compelling job posting isn’t an exact science, but Smart seems to have a knack for it. Even in this employee-driven market, one of her recent openings attracted 1,000 applicants.

To read this article in full, please click here

Read More