❌

Reading view

There are new articles available, click to refresh the page.

What is Cybersquatting?

Cybersquatting is the act of registering a domain name which looks similar to a target domain in order to perform malicious activity. This includes facilitating phishing campaigns, attacking genuine visitors who mistyped an address, or damaging a brand’s reputation. This article will cover the dangers of cybersquatting, what companies can do about it, and outline a plan for a tool which can be used to detect potentially malicious domains.

Many phishing campaigns use generic domains such as discountoffers.com which can be used against any company under the guise of offering discounts or money back. This can then be expanded to use a subdomain such as acme.discountoffers.com to more precisely target a specific brand. However, other more targeted campaigns will use names similar to a legitimate one owned by the target in the hopes that a victim either won’t notice the misspelling or think that the domain is genuine. A real-world example of this was the case of Air France who own www.airfrance.com, as a cybersquatter registered www.arifrance.com and www.airfranceairlines.comΒ to divert users to a website selling discount travel deals.

Companies spend huge amounts of money registering domains that are similar to their primary ones in an attempt to prevent them potentially being used maliciously in the future. Due to cost and logistics, it’s impossible to register every possible domain an attacker might take advantage of, and often by the time a company considers taking such a step, some domains have already been registered. In this latter case, as it’s too late for the company to register it themselves, the next best thing is to be aware of them so action can be taken accordingly.

Common Cybersquatting Techniques

There are several routes an attacker may take in order to choose a domain which is likely to be successful against their target. The following sections detail a few of the thought processes an attacker might go through when choosing a domain using β€œgoogle.com” as the sample target.

Misspelling

This is when a cybercriminal registers a misspelled domain, and is often known as typosquatting. These types of domains would be where the attacker is hoping a user will accidentally type the target name wrong. Some of these would be based on substituting letters for ones which are next to it on the keyboard or characters typed in a slightly different order. Examples include:

  • googel.com
  • gogle.com
  • soogle.com

As shown below, Google has proactively registered some domains to protect their users and their trademark, redirecting them to the genuine website.

Misspelt domain redirecting to legitimate Google website

Similar looking

These are URLs which look similar to the target and although they could be mistyped by a user looking to visit the target domain, they could also be ones designed to not be typed by the victim. For example, to be used as a link in a phishing email where the attacker hopes the victim doesn’t notice due to its similarity. Techniques for this could include replacing letters with numbers, β€œi” with β€œL”, swapping letters around, etc. Examples include:

  • g00gle.com
  • googie.com
  • gooogle.com

Legitimate looking

Another potential technique is registering domains which don’t contain typos and aren’t designed to look like the target but a victim might think it genuine. This could include registering different top-level domains using the legitimate company name, or prepending/appending words to the target. Examples include:

  • googlesupport.com
  • google.net
  • google-discounts.com

What can I do if someone registers my domain?

So you have identified a list of similar domains to yours. You’ve investigated and found that one of the domains has mirrored your own website and is being used to launch phishing campaigns against your employees. What do you do now?

In the United States there are two avenues for legal action:

  • Internet Corporation of Assigned Names and Numbers (ICANN)
  • Anticybersquatting Consumer Protection Act (ACPA)

ICANN Procedure

ICANN has developed the Uniform Domain Name Dispute Resolution Policy (UDNDRP), to resolve disputes for domains which may potentially infringe on trademark claims. A person can bring an action by complaining that:

  • A domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; and
  • The domain has no rights or legitimate interests in respect of the domain name; and
  • The domain name has been registered and is being used in bad faith.

If the action is successful, the domain will either be cancelled or transferred to you.

Legal Action Under the ACPA

The Anticybersquatting Consumer Protection Act (ACPA) was enacted in 1999 in order to combat cybersquatting such as the case described in this article. A trademark owner may bring an action against a squatter who:

  • Has a bad faith intent to profit from the trademark
  • Registers, traffics in, or uses a domain name that is
    • Identical or confusingly similar to a distinctive trademark
    • Identical or confusingly similar to or dilutive of a famous trademark
    • Is a protected trademark

A UDNDRP proceeding is generally the more advised course of action to take, as they tend to be faster and cheaper.

User awareness and technical solutions

As these proceedings can be time consuming (or if your business is based outside of the United States), more immediate measures can be taken to at least protect a client’s own internal users. Making employees aware of a new phishing site is one of the quickest and easiest steps that can be taken to help them stay on the lookout and reduce the chance of success for the attacker.

In addition to this, email policies can be set up to block incoming emails from these potential phishing domains so that they never reach employees in the first place. Some determined attackers may attempt to get round this by contacting employees via another medium such as telephone, coercing victims to visit their site manually via a web browser. In these cases, networking solutions may be able to help to prevent users from connecting to these malicious domains at all by blocking them at the firewall level.

Conclusion

Cybersquatting is threat which is often overlooked, and many companies either don’t consider protection until they’ve been affected by it, or believe it’s something they aren’t able to proactively defend against. Nettitude are aiming to assist clients further in this area by developing the tools to allow domains to be continuously monitored for potentially suspicious permutations.

The post What is Cybersquatting? appeared first on Nettitude Labs.

Explaining Mass Assignment Vulnerabilities

Programming frameworks have gained popularity due to their ability to make software development easier than using the underlying language alone. However, when developers don’t fully understand how framework functionality can be abused by attackers, vulnerabilities are often introduced.

One commonly used framework feature is known as mass assignment, a technique designed to help match front end variables to their back end fields, for easy model updating.

Implementing mass assignment

We’ll be using PHP/Laravel as an example to demonstrate how mass assignment works via the Laravel framework. Let’s imagine you have a form which allows a user to update some of their profile details, and that form contains the following fields:

<form method="POST" action="/updateuser">
    <input type="text" name="name" />
    <input type="text" name="email" />
    <input type="text" name="address" />
    <input type="text" name="phone" />
    <button type="submit">Signup</button>
</form>

Within the Laravel controller, one way to update those fields would be as follows:

public function updateUser(Request $request)
{
    $user = Auth::user();
    $user->name = $request->post('name');
    $user->email = $request->post('email');
    $user->address = $request->post('address');
    $user->phone = $request->post('phone');
    $user->save();
}

An alternative way to do this would be to take advantage of mass assignment, which would look something like this:

publicΒ functionΒ updateUser(RequestΒ $request)
{
    $user = Auth::user();
    $user->update($request->all());
}

This code updates the User model with the values from the Request (in this case the HTML fields for name, email, address and phone) assuming that the input names match the models fields. This obviously saves superfluous lines of code, since all fields can be updated at once, instead of specifying individually.

The mass assignment vulnerability

So, how might an attacker exploit this?

As may be evident from the code above, the framework is taking all the input fields from the Request variable and updating the model without performing any kind of validation. Therefore, its trusting that all the fields provided are intended to be updateable.

Although the example currently only provides options for updating fields such as name and email, there are usually more columns in the User table which aren’t displayed on the front end. In this case, lets imagine that there is also a field named role, which determines the privilege of the user. The role field wasn’t displayed in the HTML form because the developers didn’t want users changing their own role.

However, with our understanding that the controller is simply trusting all input provided by the request to update the User model, an attacker can inject their own HTML into the page to add a field for role, simply by using built in browser tools. This can also be done by intercepting the request using a proxy and appending the field name and value, or by any other technique that allows client side modification.

<form method="POST" action="/updateuser">
    <input type="hidden" name="role" value="admin">
    <input type="text" name="name" />
    <input type="text" name="email" />
    <input type="text" name="address" />
    <input type="text" name="phone" />
    <button type="submit">Signup</button>
</form>

This time, when the controller is reached, the user model will be updated with the expected fields (name, email, address, phone) as well as the additional role field provided.Β  In this case, the vulnerability leads to privilege escalation.

This particular example demonstrates how mass assignment can be exploited to achieve privilege escalation, however it is often possible to bypass other controls using the same technique. For example, an application might prevent a username from being edited when updating profile information, to ensure integrity and accountability across audit trails. Using this attack, a user could perform malicious actions under the guise of one username before switching to another.

Countermeasures

There are several ways to protect against mass assignment attacks. Most frameworks provide defensive techniques such as those discussed in this section.

The general idea is to validate input before updating the model. The safest way to do this is to somewhat fall back to the original and more convoluted process of specifying each field individually. This also has the added benefit of providing the ability to add additional validation to each field beyond ensuring only expected fields are updated.

In Laravel, one way to do this would be as shown below; include some validation such as the maximum number of permissible characters for the name field, and then update the User model with the validated data. As the validate() function lists the exact fields expected, if the role field was appended as demonstrated in our previous sample attack, it would be ignored and have no effect.

public function updateUser(Request $request)
{
    $validatedData = $request->validate([
        'name' => ['required', 'max:255'],
        'email' => ['required', 'unique:users'],
        'address' => ['required'],
        'phone' => ['numeric']
    ]);
    $user = Auth::user();
    $user->update($validatedData);
}

An alternative method is to utilize allow lists and deny lists to explicitly state what fields can and cannot be mass assigned. In Laravel, this can be done by setting the $fillable property on the User model to state which fields may be updated in this way. The code below lists the four original fields from the HTML form, so if an attacker tried to append the role field, since its not in the $fillable allow list, it won’t be updated.

class User extends Model
{
    protected $fillable = [
        'name',
        'email',
        'address',
        'phone'
    ];
}

Similarly, deny lists can be used to specify which fields cannot be updated via mass assignment. In Laravel, this can be done using the $guarded property in the model instead. Using the following code would have the same effect as the above, since the role parameter has been deny listed.

class User extends Model
{
    protected $guarded = ['role'];
}

Conclusion

Mass assignment vulnerabilities are important issues to check for during software development and during penetration tests because they are often not picked up by automated tools, due to them often having a logic component. For example, a tool will not likely have the context to understand if a user has managed to escalate their privilege after a specially crafted request.

They are also often overlooked by developers, partly due to lack of awareness for how certain features can be exploited, but also due to pressure to complete projects since its faster to use mass assignment without performing input validation.

It’s important to understand that mass assignment vulnerabilities exist and can be exploited with high impact. A strong software development lifecycle and associated testing regime will reduce the likelihood of these vulnerabilities appearing in code.

The post Explaining Mass Assignment Vulnerabilities appeared first on Nettitude Labs.

❌