Vulnerabilities on Untrusted Network

Actively exploited open redirect in Google Web Light

Jan Kopriva — Mon, 26 Feb 2024 06:30:00 +0100

TL;DR: An open redirect vulnerability exists in the remains of Google Web Light service, which is being actively exploited in multiple phishing campaigns. Google decided not to fix it, so it might be advisable to block access to the Web Light domain in corporate environments…

If you are already aware of the principles behind “open redirect” vulnerabilities and want jump straight to the discussion of the Web Light vulnerability and its active exploitation, click here. If you are not, let’s first set the stage by discussing what open redirects are and how they may be used by threat actors…

Open redirect – or CWE-601 – is a type of software vulnerability, which affects web applications that redirect its visitors to URLs, that are dynamically created based on user-controlled input, if these applications don’t sufficiently validate whether these URLs are “trusted”. In basic terms, any such vulnerability allows for creation of links, which point to a vulnerable application and which cause it to automatically redirect the browser of a visitor to another (usually any specified) URL.

If the potential impact of such a vulnerability isn’t clear to you, imagine if a web application of a well-known bank running at “www.mybank.tld” redirected visitors to the domain “login.mybank.tld” using a dynamic redirection mechanism, which would accept the target URL through a “redirect_to” parameter. A URL used for this redirection might look like this.

https://www.mymybank.tld/?redirect_to=https://login.mybank.tld

You might wonder why someone would use the above-mentioned “dynamic” approach to redirection instead of using static links. The truth is that there may be certain benefits to doing so this way – probably the most important one being the ability to precisely track “clickthroughs” to different destinations (e.g., for marketing purposes).

In any case, if the redirection mechanism in our example allowed only for limited redirection to URLs within the second-level domain mybank.tld, it would most likely be quite alright from a security standpoint. However, if the mechanism lacked any sort of validation of the target URL, one could easily create a link, which would point to the trusted site of the bank, but which would result in a redirection to an untrusted (and potentially malicious) site… For example a literal “untrusted” site:

https://www.mymybank.tld/?redirect_to=https://untrustednetwork.net

You can probably see the issue – in such a case, any threat actor out there could create a link pointing to the legitimate website of the bank, which would – when opened – result in redirection to a malicious site of their choosing. This could be quite useful for phishing attacks. Since most people only check the beginning of a URL before opening it, if they saw that a link in an e-mail points to a valid domain of the bank, they might be much more willing to click it than if it pointed to a different/unknown domain. And, in fact, threat actors do actively exploit these vulnerabilities in just this way - by redirecting unsuspecting victims to phishing sites through legitimate domains…

As we can see, although open redirects are hardly the most dangerous type of vulnerabilities in existence, they do sometimes pose a not insignificant risk – especially if the affected application is hosted on a well-known and well-trusted domain. This viewpoint is well-supported by the fact that “Unvalidated Redirects and Forwards” were actually included in the 2010 version of OWASP Top 10 (i.e., they were considered by the security community at large to be one of the 10 most significant risks related to web applications at that time).

Nevertheless, since successful exploitation of these vulnerabilities is dependent on social engineering, and their impact is limited, many organizations consider them either very low risk, or non-issues. For some organizations and some domains, this may be understandable, while for others not so much…

One organization, which takes the overall viewpoint that “a small number of properly monitored redirectors offers fairly clear benefits and poses very little practical risk” is Google.

Source: Google

While I personally disagree with the “very little practical risk” part (especially in connection with any domain owned by Google) I completely understand the “clear benefits” portion of the sentence… Though it should be stressed that the “benefits” are not to users of Google services, but to Google itself, since – as we already mentioned – redirection mechanisms are quite useful for marketing-related tracking.

Although I don’t want to appear petty, it is also worth noting that my views on risks connected with open redirects on Google’s domains are shared by its own AI…

Source: Google Gemini

That is beside the point, however.

What is important is that even though Google sees “very little practical risk” in open redirection, it has implemented sufficient security measures for most of its services where open redirection is actually used. I.e., some Google services do allow for redirection to arbitrary URLs, however, if these services are linked to from an external source (e.g., an e-mail or a third-party site), then the user is first asked if the redirection should take place. You can see how this looks by opening either of the following links.

https://www.google.com/url?sa=t&url=https://untrustednetwork.net https://www.youtube.com/redirect?q=https%3A%2F%2Fwww.untrustednetwork.net

While some aspects of the defensive mechanisms that are in place could potentially be improved upon, they generally provide adequate protection from the most common exploitation approaches and techniques. Problem is that not all Google services and domains are secured in this way.

One service, which does not have any similar protection mechanisms in place, is/was named Google Web Light.

It was first introduced in 2015 and provided a way to load web pages faster in Chrome on Android devices. In simple terms, Web Light served as a specialized proxy server, which “optimized” the transmitted content through compression and filtering in such a way, that according to Google, in their experiments, optimized pages loaded four times faster than the original pages and used 80% fewer bytes. For mobile devices of the time, which were connected to the internet through low-bandwidth links (i.e., over 2G), this undoubtedly made significant difference.

Google offered the service for several years (though only in selected countries) before officially retiring the Web Light crawler in December 2022, when it was decided that the service was no longer needed given the increase in general availability of fast mobile internet and more computationally powerful mobile devices.

However, the fact that the Web Light service as a whole was retired didn’t mean that all of its functions suddenly stopped working. In fact, to this day, the Web Light preview functionality is partially available… though it does not function in precisely the same way as it used to.

Source: Google

If one tries to use the preview functionality these days, it does not provide a preview of a web page through the Web Light crawler as it used to – it can’t since the crawler is no longer being used – but rather simply redirects the visitor to the provided target URL using HTTP 301 response… You can probably see where this is going.

Indeed, the redirection mechanism used on https://googleweblight.com/ appears to be completely open and unrestricted, and – unlike YouTube and Google search – does not display any warning that the browser is about to be redirected. You may try this yourself by opening the following link.

https://googleweblight.com/i?u=untrustednetwork.net

How big of a problem is this? Well, it depends on how trustworthy you consider the domain googleweblight.com to be… It certainly isn’t as bad as if the open redirect existed on google.com (though, by the way, there is at least one on that domain as well). Nevertheless, the fact that the domain name begins with “www.google…”, and that the domain is actually registered by Google lends it at least some level of credibility, both when it comes to people seeing a link to it, as well as when such a link is evaluated by automated security solutions.

Threat actors obviously think that is looks trustworthy too, since I have seen the open redirect on googleweblight.com used in two different phishing campaigns just last week…

As you may see, the links in the two phishing messages pointed to the following URLs:

hxxp[:]//googleweblight[.]com/i?u=hxxps[:]//bafybeicrejl4lniju4uumll6zph6fbntlgnarnd22kyijwfqmcltj2icba.ipfs.cf-ipfs[.]com/webmail.html#[e-mail address]

hxxps[:]//googleweblight[.]com/i?u=hxxps[:]//cloudflare-ipfs[.]com/ipfs/bafybeifrl56eni6oixqpdknl6n2fcatl23jvefr4knsrbaut7opquzcyry/#[e-mail address]

Both of these links still work at the time of writing and lead to generic credential-stealing phishing pages. Note that both of them are hosted on IPFS, even if they are accessed through different gateways…

This is far from the first time that the Google Web Light open redirect mechanism was used in a phishing campaign – analysts from Trustwave mentioned seeing it used in 2022, and I myself came across it in a phishing campaign in 2023. Nevertheless, the fact that even with the limited visibility I have, I came across two messages from different campaigns that exploit this vulnerability in a single week would seem to indicate that the use of this redirection mechanism by phishing authors might be becoming more of a mainstream technique, and thus might warrant some response.

I have therefore reported the fact that the open redirect on the Web Light domain exists and is under active exploitation to Google, along with a recommendation for implementing the same defenses there, as they have on their other services. They responded that the open redirect is intended behavior, and that their “position on open redirectors is described in greater detail in this article”. Since it therefore appears that Google’s “Web Light Open Redirection Service”, as I shall call it from now on, will stay with us for at least the foreseeable future, it might be worth thinking about what we may do about it ourselves.

Since the googleweblight.com domain is connected with a retired service and will therefore hardly be used for anything business-relevant in the near future, the most straightforward approach would seem to be to filter out/quarantine any e-mails with links that point to it and/or to completely block access to it. Although the domain will probably never make it to any commercial or publicly available blocklist, since it is registered by Google, and no content hosted on it is actually malicious, nothing is stopping us from manually adding it to any internal blocklists we may be using within our own organizations…

While we’re on the subject, it might be worthwhile to do the same thing with all public IPFS gateways as well. Since IPFS currently has very low (if any) business relevance for most organization, and threat actors use it quite heavily to host phishing pages, this simple step might help us significantly reduce risk connected with untargeted phishing… But we’ll discuss that in more detail another time.

Do automated tools really detect only 45% of all vulnerabilities?

Jan Kopriva — Sat, 19 Oct 2019 18:50:15 +0200

If you’ve dealt with IT security for any length of time, chances are that you’ve come across a claim that research has shown that automated tools can only detect 45% of vulnerabilities. It is often cited to illustrate the need for participation of human experts in security and penetration tests. However is the claim really true?

You may find it in, among many other places, the latest OWASP Testing Guide.

Source: OWASP Testing Guide v4, page 22

Given this source in particular, one might reasonably expect the claim to be correct…but, as you may have guessed, that is not the case. Or rather not entirely. Some other sources cite the original research, where the number 45% originated, more or less correctly, as tools are capable of detecting 45% of types of vulnerabilities. This version may be found (again, among many other places) in several OWASP presentations.

Source: OWASP - Embed within SDLC, slide 42

Many have cited these presentations. For example Mitnick Security, company of the world renowned Kevin Mitnick, cites OWASP almost word for word on their website. However, as a closer look at the text of their site shows, even they, when coming from exact citation of OWASP, managed to interpret the conclusions of the original research to mean “automated tools detect only 45% of vulnerabilities” in some cases.

Source: mitnicksecurity.com

Leaving misunderstanding/misquoting of the original conclusions to one side, even in cases when the conclusions are cited correctly, many seem to gloss over the fact that the research, which resulted in the “45%” result, was limited in scope to only certain types of tools and took place all the way back in 2007 so its results don’t necessarily describe the current state of affairs… But we’re getting ahead of ourselves. First, let’s take a look at where the number actually came from.

OWASP Testing Guide is one of the few places where we may find an attribution (although the reference in OTG should point to [21], not [22]), which leads us to a presentation from BlackHat DC 2007 by a team (Robert A. Martin, Sean Barnum and Steve Christey) from MITRE/Cigital.

Unfortunately, by itself, the slide from the presentation which is cited in OTG doesn’t give us much information. We may deduce from it that 55% of CWEs were found not to be covered by - presumably - some tested or analyzed tools, but that is about it.

Source: MITRE, Being Explicit About Weaknesses, Slide 30, Coverage of CWE

Since the other slides in the presentation don’t give us any more information regarding the presumed 45% detection rate, we need to dig a bit deeper. After a while of Googling, one might find couple of articles from the same authors on MITRE website (one which probably served as a basis for the BlackHat talk and one from CrossTalk magazine), which are both titled the same as the presentation. Neither of them, unfortunately, sheds any light on the issue of detection rate among automated tools.

I have to admit that this was the point, where my Google-Fu failed me as I was unable to find anything more exact with regards to the original research. I was, however, able to find e-mail contacts for all three authors of the original paper/presentation from BlackHat DC 2007 and one of them - Bob Martin - was kind enough to reply to my message and explain what their work was based on. Following paragraphs are contents of the e-mail I received, unedited except for the use of bold font for what I believe are the most important parts.

The source of that statistic is the MITRE CWE Team's compilation of the knowledge-bases from the static analysis tools that provided us with the details of weaknesses so we could build out CWE.

While we don't have a specific list of those who donated content, the list of organization on the CWE Community page is close, if you limit yourself to tool and researcher organizations.

The 2007 Black Hat talk does a pretty good job covering what went into the creation of CWE.

So when we combined all of these different knowledge-sources we found that there was only a very slight intersections between the tools knowledge-bases.

Now a days, the best way to recreate this would be to use the COVERAGE CLAIMS that most of the CWE Compatible tools and services provide.

Examples of Publicly Available CWE Coverage Claims:
----------------------------------------------------------------------
https://www.synopsys.com/content/dam/synopsys/sig-assets/datasheets/coverity-cwe-sanstop25.pdf
https://www.grammatech.com/software-assurance/certifications-compliance/cwe
https://docs.sonarqube.org/latest/user-guide/security-rules/
https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/o5xpvFVymSUGcFJ492HXEg
http://docs.klocwork.com/Insight-10.0/CWE_IDs_mapped_to_Klocwork_C_and_C%2B%2B_checkers
http://docs.klocwork.com/Insight-10.0/2011_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/2010_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/CWE_IDs_mapped_to_Klocwork_Java_checkers
http://docs.klocwork.com/Insight-10.0/2011_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
http://docs.klocwork.com/Insight-10.0/2010_CWE-SANS_Top_25_Most_Dangerous_Software_Errors_mapped_to_Klocwork_checkers
https://access.redhat.com/articles/171613
https://dwheeler.com/flawfinder/flawfinder.pdf
https://vulncat.fortify.com/en/weakness

On the last one, we'd like to get Fortify to offer their coverage indexed by CWE Ids but so far this is what we have from them.

That being said, the statistic we did in 2007 was only for static analysis tools, since at that time they were the only one really documenting the flaws they found and talking about how to fix them.

Similar static analysis studies were done by the Center for Assured Software (CAS) out of NSA. Here's links to their 2010 and 2011 reports:

http://cps-vo.org/file/1152/download/30152
https://samate.nist.gov/docs/CAS_2011_SA_Tool_Method.pdf

On slides 21 & 22 of the first one, and on page 25 of the second one they show the overlap in findings between tools.

Today you'd want to include DAST and Binary analysis, along with any other tool/technique that can uncover weaknesses in software architecture, software design, software code, and the deployment of software into operations.

You would also want include more of the quality issues that only indirectly make it easier to introduce a vulnerability and/or make the vulnerability more difficult to detect or mitigate, like reliability, performance, and maintainability, similar to the expansion undergone by CWE itself in January https://cwe.mitre.org/news/index.html#jan032019_CWE_Version_3.2_Now_Available.

Within CWE these are captured in the CWE-1128 view (CISQ Quality Measures (2016)) and the "quality" slice (CWE-1040, Quality Weaknesses with Indirect Security Impacts), which includes not-automatically-detectable quality issues.

CISQ recently published an update to their work which we are still capturing as a CWE view.

Leveraging the CAS work, NIST has been holding Software Assurance Tool Evaluation (SATE) efforts, where NIST is working with the community, both private industry, academia, and government, to get a better handle on what weaknesses tools find and how well they find them. They have annual workshops and share test programs (Juliet).

Finally, tools can not find many architecture or design weakness https://cwe.mitre.org/data/definitions/1008.html. If the development effort using model-based software engineering tools they theoretically can find some of these - which is the focus of a new MBSE Working Group in the Consortium of Information and Security Quality (CISQ).

___

As we may see - among many other information for which I’m very grateful to Bob Martin - the original research only covered static analysis tools (SAST). Even if the research wasn’t as old as it is, this fact alone shows its results should not be interpreted and presented in the way they very often are.

Don’t get me wrong - I don’t claim that tools alone can find every type of vulnerability out there. They can’t - automated scanners and other tools are great at finding certain types of vulnerabilities, but for others, they are either unable to find them at all or don’t come even close to what an experienced penetration tester, analyst or auditor may discover. I don’t even claim that tools are currently capable of finding more than 45% of all vulnerability types - I don’t know whether or not they are and as far as I can tell, no one else does either.

And that is the point - although we might like to have hard numbers to back up why human factor is indispensable when it comes to finding vulnerabilities, citing results of a study from 2007 as current, or using misquoted version of its conclusions in marketing materials in order to convince customers that they really need our experienced pentesters in order to be secure, is something we should try very hard to avoid.

Half-open redirect vulnerability in Youtube

Jan Kopriva — Mon, 22 Jul 2019 19:33:43 +0200

If you open any Youtube video, which has in its description a link to an external URL, you may notice that the link points to a Youtube redirection mechanism (https://www.youtube.com/redirect?…), with the target URL being passed to it as a parameter, rather than to the target URL itself. In such a case, the link has the following structure:

https://www.youtube.com/redirect?q=[target_URL]&redir_token=[token]&event=video_description&v=[video_ID]

Since there is a redir_token parameter in the URL, one might assume that the redirect mechanism isn’t open, i.e. that can’t be used for redirection to an arbitrary URL. One would, however, be only half-right.

The value of the token seems to be connected with the current Youtube session (though there isn’t any obvious corelation between values of relevant cookies and the token). And while parameters event and v are optional, if you try to use the redirection mechanism without the redir_token parameter - or with an invalid value of this parameter - you will be greeted with the following message:

You may try this out for yourself yourself using this link. So far everything seems to be in order.

A problem - if only a small one - however, starts to become obvious when we try to use a valid token along with another URL (i.e. we copy a valid link, perhaps delete the optional parameters, and change the value of the parameter q). In this case, a browser will indeed be redirected (using HTTP code 303) to the new URL, because the tokens are in no way dependent on the value of q.

This means that if you can get a valid redirect link from a user, who has an active Youtube session established, you could modify it in such a way, that - if this user opened it - it would redirect his/her browser to the URL of your choice. As the tokens seem to last (although I tried to determine the maximum age for a token on only one ocasion so don’t quote me on it) for approximately 24 hours, one could hypotetically use this (it should probably be called “partially-missing input validation”, but “half-open redirect” will do) vulnerability in a real world scenario. Although it is almost completely useless for malicious phishing campaigns, it could be used quite effectively against - for example - one’s coleagues and/or friends (e.g. “Jack, could you please send me the link under this video? Thank you. Now, here is a link to a video you’re going to love…"). Plus, it might be a good example of dangers of clicking on seemingly safe links in e-mail for any security awareness classes out there.

Since Google replied to me that they don’t intend to fix this small vulnerability and don’t mind if I publish it, use it (ethically, please) as you see fit.

It should be added that there seems to be some regularity to the values of tokens being generated (e.g. when a site is refreshed), but at first glance there doesn’t seem to be any obvious way to use this regularity to craft valid tokens, although I didn’t spend much time on verifying that.

How big of a problem is the 'open redirect' in Babel?

Jan Kopriva — Sat, 02 Mar 2019 12:35:00 +0100

During a recent research into prevalence of open redirection vulnerabilities within the ccTLD .CZ we’ve done with my colleagues from ALEF CSIRT (description of its results in Czech may be foud here), I’ve noticed that many of the vulnerable sites seemed to be using CMS Made Simple with Babel multi-language module. This seemed to warrant a closer investigation…

Before we go further, let’s briefly describe what „open redirection“ (CWE-601) weakness/vulnerability actually is. The term is usually used to describe a mechanism which – when present on a certain website and queried in a specific way (usually by passing a specific parameter to it) - automatically redirects visiting browser to a different (arbitrary) domain/URL. What this means in practical terms is that it is possible to create a link to the website in question, which redirects user to any other - pontentially malicious or untrusted - site.
This behaviour might be intentionally present on certain websites, but in most cases, it is considered a vulnerability and/or bad practice since may be quite easily misused. Imagine, for example, how easy it would be to create a successful phishing campaign targeting clients of a bank which has open redirection vulnerability on its website.

An example of a site with intentional open redirection functionality, which will enable us to demonstrate the principle in practice, is 1gr.cz – a logger which counts clickthroughs for ad and marketing purposes. A link to 1gr.cz which automatically redirects visitors to untrustednetwork.net could be crafted in the following way:

http://1gr.cz/log/redir.aspx?url=https://www.untrustednetwork.net/

Now, let us dive right into the interesting details regarding CMS Made Simple and Bable.
CMS Made Simple (CMSMS) is one of the lesser known CMS platforms out there. Although it is not too widely used, vulnerabilities in the CMSMS core or in its plugins or modules may still affect thousands of websites. This appears to be the case with the vulnerability I found in Babel – a module which brings multilingual functionality to CMSMS sites.
The full write up of the vulnerability may be found here, but in simple terms, Babel in all its versions translates content by redirecting user to different pages based on their language preferences. This is not a bad idea per se, however in Babel, the same mechanism enables anyone to create a link to the CMSMS-enabled site, which redirects to an arbitrary URL.
Babel – when installed – uses the path domain.root/modules/babel to hold all its PHP files. Among these is redirect.php, a file containing PHP script through which the translation is handled. The relevant code looks like this:

if(!isset($_GET["newurl"]) ){
	/*code not important for our purposes removed here*/
}else{
	/*code not important for our purposes removed here*/
	header("location: ".$_GET["newurl"]);
}

What it basically means is that if the “newurl” parameter is set, browser will be redirected to the URL contained therein. Since there are no checks or limits regarding the target URL, the fact that there is an “open” redirection vulnerability should be obvious.

So how big of a problem is this vulnerability? Well, not too big. As has been said before, open redirection is mainly useful for phishing and not that many sites interesting to phishers use the Babel module… But with approximately 3.700 URLs affected before the disclosure was published it is not insignificant either. That number is based on relevant Google search results (so take it with a grain of salt - in terms of affected sites, it was probably a lot less…although the latest version of the vulnerable module was downloaded from the CMS website more than 5.700 times, so who knows) from February 14th 2019.

I was interested in the distribution of vulnerable sites/URLs around different TLDs, so I’ve done a search for each of the 20 most used TLDs and a serach for each of the ccTLDs of European countries. The “Top 10” results are:

TLD	Count
========	========
COM	1590
BE	448
FR	408
NL	227
PT	226
CH	207
DE	142
CZ	96
LV	78
AT	46

That covers most of what seems to be out there, but if you want to see the results for all top level domains with at least one relevant search result, they are summarized in the following chart.

As you may see, a number of the vulnerable websites are hosted on domains within ccTLDs belonging to different European countries. What’s more, based on a quick look at the .COM results, it seems that most of those domains are also registered by European citizens and companies. I’m not sure whether CMSMS as a whole or just Babel have mostly Euro-centric user base, but this regional disparity seemes quite interesting either way.

Open Redirection Vulnerability in Babel

Jan Kopriva — Wed, 20 Feb 2019 20:36:35 +0100

Bellow you may find description of a vulnerability I found in Babel - a CMSMS module - when searching for sites affected by Open Redirection vulnerabilities (writeup on the research in Czech may be found here). Further discussion of this vulnerability be found here.

Basic Information

Affected Software: Babel: Multilingual Site module for CMS Made Simple
Affected Version: 0.4.1 and earlier
Patched Version: None - project is no longer under development
CVE Identifier: CVE-2019-1010290
Vulnerability type: CWE-601: URL Redirection to Untrusted Site (‘Open Redirect’)
Severity Rating: CVSS v3 Base Score: 6.1 (AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N)

Summary

The Babel multi-language module for CMSMS contains an open redirection vulnerability in a script within the redirect.php file. The script takes an argument specifying a URL to which a browser should be redirected. This URL may be completely arbitrary. It is therefore possible to craft a link to a Babel-enabled site which causes redirection to any URL specified, even outside the originating domain. This is especially useful for phishing attacks, when attacker creates a link to a safe site, which, without the knowledge of a user, redirects him or her to a fake/malicious site. All CMSMS sites with Babel module installed are affected, since redirect.php is always publically accessible.

Detailed Description

The Babel module provides CMSMS sites with the capacity to easily switch between multiple translations of web page content. Desired translation may be chosen by sending a GET request to vulnerable.site/modules/babel/redirect.php. Under normal conditions, this PHP script takes two arguments - “newlang” and “newurl”. The first argument sets the desired language for the translation and the second one sets URL which should be displayed in selected language.
A non-working example of what the URL might look like is:

https://www.vulnerable.site/modules/babel/redirect.php?newlang=en_US&newurl=https://www.vulnerable.site/about

The vulnerability is caused by the absence of any filtering when the parameter “newurl” is processed (the parametr “newlang” is - for our purposes - optional and may be omitted).

Proof of Concept

https://www.vulnerable.site/modules/babel/redirect.php?newurl=https://www.malicious.site/

Recommendation

Removal of the Babel module from any affected site.

Disclosure Timeline

Developer Contacted: 2. 2. 2019
Developer Responded: 11. 2. 2019 (project abandoned, no new versions are to be expected)
Disclosure to CSIRT network: 14. 2. 2019
Public Disclosure: 20. 2. 2019