Vulnerability on Untrusted Network

SANS ISC Diary - How quickly do we patch? A quick look from the global viewpoint

Jan Kopriva — Mon, 21 Jul 2025 13:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at how quickly do we – as a global society – patch actively-exploited vulnerabilities when it comes to our internet-facing systems…

SANS ISC Diary - Another day, another phishing campaign abusing google.com open redirects

Jan Kopriva — Wed, 14 May 2025 12:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at an actively exploited open redirect vulnerability in Google Travel service that enables threat actors to craft links pointing to www.google.com which cause redirection to an arbitrary URL…

SANS ISC Diary - The xz-utils backdoor in security advisories by national CSIRTs

Jan Kopriva — Mon, 01 Apr 2024 13:55:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of security advisories published by national and governmental CSIRTs in connection with the backdoor in xz-utils…

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.

SANS ISC Diary - Kazakhstan - the world's last SSLv2 superpower... and a country with potentially vulnerable last-mile internet infrastructure

Jan Kopriva — Wed, 28 Jun 2023 08:30:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a surprisingly high number of old network devices in Kazakhstan, which still support SSL version 2.0…

SANS ISC Diary - Passive detection of internet-connected systems affected by vulnerabilities from the CISA KEV catalog

Jan Kopriva — Wed, 11 Jan 2023 12:00:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at a new function of my TriOp tool and its use for passive identification of systems affected by vulnerabilities listed in the CISA KEV Catalog…

TriOp update - version 1.5

Jan Kopriva — Wed, 11 Jan 2023 11:50:00 +0100

I’ve published version 1.5 of TriOp today. Besides the addition of several CVEs into the internal list of vulnerabilities, a new feature was also introduced, which enables automatic generation of Shodan queries for the current list of vulnerabilities from the CISA Known Exploited Vulnerabilities (KEV) Catalog.

As alway, you may download the latest version of TriOp from my GitHub.

Presentations from 67th TF-CSIRT meeting - Threat modeling with ATT&CK and How quickly do we patch?

Jan Kopriva — Sat, 01 Oct 2022 10:40:00 +0100

67th meeting of the TF-CSIRT community took place this week and I’ve had a chance to contribute to it with two presentations - one discussing the speed with which we apply patches (from a global standpoint), and another one, in which we looked at a basic approach to threat modeling using MITRE ATT&CK. If you would like to take a look at the slides, you may find them here - even if you didn’t have a chance to attend the event, I believe they might be useful.

SANS ISC Diary - EternalBlue 5 years after WannaCry and NotPetya

Jan Kopriva — Tue, 05 Jul 2022 10:35:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of internet-exposed systems that are still vulnerable to the EternalBlue exploit…

Log4shell Lightning talk - 2022 TF-CSIRT Meeting & FIRST Regional Symposium Europe

Jan Kopriva — Mon, 14 Mar 2022 09:00:00 +0100

Few weeks ago, I attended the 2022 TF-CSIRT Meeting & FIRST Regional Symposium Europe and gave a lighting talk there discussing couple of interesting trends seen in Log4shell exploitation attempts and the possibility to create a simple generic defense agains similar attacks in the future. Recordings of all the talks are now available on YouTube and you may find my lightning talk in the video under this paragraph or on this link. Lightning talks were supposed to be only 5 minutes long and I went significantly over the allocated time, but I hope that most attendees didn’t mind it too much…

SANS ISC Diary - Over 20 thousand servers have their iLO interfaces exposed to the internet, many with outdated and vulnerable versions of FW

Jan Kopriva — Wed, 26 Jan 2022 12:20:00 +0100

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the high number of HP servers that have their out-of-band configuration interface exposed to the internet…

SANS ISC Diary - ProxyShell - how many Exchange servers are affected and where are they?

Jan Kopriva — Mon, 09 Aug 2021 12:25:00 +0200

A new Diary of mine was published today on the SANS Internet Storm Center website. In this one, we’ll take a look at the number of Exchange serveres vulnerable to the ProxyShell attack…

TriOp update - version 1.1

Jan Kopriva — Mon, 08 Mar 2021 11:00:00 +0100

I’ve published version 1.1 of TriOp today. I’ve added CVEs for the recent Exchange vulnerabilities to the vulnerability search list, since Shodan is now capable of detecting systems affected by them. In response to a request from the CSIRT community, I’ve also added the option for use of arbitrary filter along with a list of parameters.
In version 1.0, it was only possible to generate composite searches based on list of countries, however in version 1.1, one may specify any filter (i.e. not just “country”) for use with the list of parameters.
Previously, one could specify a list of searches (-s/-S) and a list of countries (-c/-C) and TriOp would run each search for each specified country and even potentially output results for each country into a specific file (–country_names).
In the updated version, one may specify an arbitrary filter (–filter) and a list of parameters for that filter (-p/-P) along with a list of searches (-s/-S) and the result will be the same. The “one output file per parameter” option is available as well (–filter_names).
What I assume will be of most useful when it comes to this feature, will be the filter “net” – the following example shows how a command using it might look:

triop.py -s "port:80,port:443" --filter net -p "200.0.0.0/16,200.1.0.0/16"

in which case, the output might look similar to:

Current IP count for query port:80 net:"200.0.0.0/16" is 1643
Current IP count for query port:443 net:"200.0.0.0/16" is 1474
Current IP count for query port:80 net:"200.1.0.0/16" is 819
Current IP count for query port:443 net:"200.1.0.0/16" is 798

A country search could be done in the following manner:

triop.py -s "port:22,port:23" --filter country -p "CZ,DE"

and the output would be the same as with the use of the -c option:

Current IP count for query port:22 country:"CZ" is 83007
Current IP count for query port:23 country:"CZ" is 21143
Current IP count for query port:22 country:"DE" is 1467418
Current IP count for query port:23 country:"DE" is 31595

The original “country” options are still present but will be removed in future versions.

You may download the latest version of TriOp from my GitHub.

SANS ISC Diary - TriOp - tool for gathering (not just) security-related data from Shodan.io

Jan Kopriva — Wed, 27 Jan 2021 11:00:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at TriOp - my recently published tool, which enables anyone to periodically gather interesting data from Shodan.

SANS ISC Diary - Want to know what's in a folder you don't have a permission to access? Try asking your AV solution...

Jan Kopriva — Tue, 29 Dec 2020 15:20:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look a small issue present in many anti-malware tools, which may be used to bypass file system level folder listing permissions.

SANS ISC Diary - A slightly optimistic tale of how patching went for CVE-2019-19781

Jan Kopriva — Fri, 18 Dec 2020 10:00:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at how many publicly accessible systems are still vulnerable to CVE-2019-19781, AKA Shitrix.

Most common vulnerabilities based on Shodan scans

Jan Kopriva — Wed, 18 Nov 2020 21:00:00 +0100

My recent post on the Internet Storm Center website about the surprisingly high number of systems still affected by critical vulnerabilities, which have been patched for a long time, received quite a positive feedback. I have consequently decided to take a look at the issue in a more comprehensive manner and since I didn’t know, which vulnerabilities Shodan was able to detect, I’ve used my TriOp tool to gather data for all of the approximately 190k CVEs ever published. After couple of days the script took to run, I have the results and they are quite interesting…

Before we get to them though, let’s take a quick look at how many vulnerabilities is Shodan capable of detecting. The magic number seems to currently be 2246. Or, rather, that is the number of CVEs, for which Shodan detected at least one affected IP address. Since for each of 40 different CVEs it detected only 1 vulnerable IP and for 99 more CVEs it detected only between 2 and 10 affected IPs, it is quite possible that Shodan is capable of identifying other vulnerabilities as well, but it didn’t find them on any of the systems it scanned in the past few days or weeks.

On the other hand, as you may see from the following chart, there are a significant number of CVEs for which Shodan detected over 1 million affected IP addresses – 145, to be specific.

We won’t, for obvious reasons, discuss all of them but I thought that a closer look at the top 15 CVEs detected most often might be worth it, since all of these had more than 4 million detections.

As the chart above shows, we have couple of sets of vulnerabilities with similar numbers of detections. This is mostly due to them affecting the same version of a specific system, which corresponds with the similar (and sometimes nearly sequential) CVE numbers.

The most common vulnerability seems to be CVE-2017-15906, which affects OpenSSH and luckily isn’t too critical. That unfortunately can’t be said about some of the other ones, as three vulnerabilities (two in Apache and one in PHP), which have made it into the top 15, have CVSSv3 score 9.8. You may take a find details for all of the most commonly detected vulnerabilities in the following table.

CVE	Number of affected IP addresses	CVSSv3
CVE-2017-15906	7,551,378	5.3
CVE-2018-1312	6,936,210	9.8
CVE-2019-0220	5,687,693	5.3
CVE-2017-7679	5,581,571	9.8
CVE-2018-17199	5,392,949	7.5
CVE-2018-15919	5,299,655	5.3
CVE-2016-8612	5,267,545	4.3
CVE-2016-4975	5,051,548	6.1
CVE-2018-1283	4,971,245	5.3
CVE-2017-15715	4,971,235	8.1
CVE-2017-15710	4,971,199	7.5
CVE-2019-9641	4,149,029	9.8
CVE-2019-9639	4,149,025	7.5
CVE-2019-9638	4,149,024	7.5
CVE-2019-9637	4,149,015	7.5

As we see, the vulnerabilities we discussed in the ISC post may all have high impact, but would seem not to be the most common ones.

Although it’s not too probable, let’s hope that the number of systems affected by the CVEs mentioned above start falling soon, as otherwise they might quite quickly become dangerous not just for their users but to others as well, since public exploits for some of the vulnerabilities are freely available…

SANS ISC Diary - Vulnerabilities don’t disappear just because we don’t talk about them anymore

Jan Kopriva — Mon, 16 Nov 2020 11:08:20 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at couple of pre-2020 high-impact vulnerabilities, which still affect surprising number of publicly accessible systems.

SANS ISC Diary - SMBGhost - the critical vulnerability many seem to have forgotten to patch

Jan Kopriva — Wed, 28 Oct 2020 11:00:00 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the concerning number of machines connected to the internet, that are still not patched for the critical SMBGhost vulnerability.

SANS ISC Diary - Crashing explorer.exe with(out) a click

Jan Kopriva — Mon, 30 Mar 2020 07:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a vulnerability in the way Windows handles self-referential links, which makes it possible to use specially crafted URL and LNK files to crash Explorer.

CrisisCon - Breaking Windows

Jan Kopriva — Sat, 28 Mar 2020 09:15:00 +0100

Videos of all presentations from last weeks CrisisCon are now accessible on Youtube. Among them is my own talk on known unpatched vulnerabilities and weaknesses in Windows.

If you couldn’t make it to the online conference, I recommend you at least go through some of the recordings as couple of the talks were quite interesting.

SANS ISC Diary - Desktop.ini as a post-exploitation tool

Jan Kopriva — Mon, 16 Mar 2020 07:55:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at a vulnerability in the way Windows handles desktop.ini files, which makes it possible to use them as an interesting post-exploitation tool.

UPDATE 27. 5. 2020: I put together a shor video demonstrating the vulnerabiltiy while preparing materials for SANSFIRE 2020. You may find it here.

SANS ISC Diary - Discovering contents of folders in Windows without permissions

Jan Kopriva — Tue, 18 Feb 2020 07:18:21 +0100

A Diary of mine was published today on the SANS Internet Storm Center. This one deals with a strange side effect of the way in which Windows deals with file permissions, which enables any user, regardless of permissions, to brute-force contents of any local folder.

UPDATE 20. 5. 2020: I put together a shor video demonstrating the weakness/vulnerability while preparing materials for SANSFIRE 2020. You may find it here.

SANS ISC Diary - Open Redirect: A Small But Very Common Vulnerability

Jan Kopriva — Wed, 28 Aug 2019 14:27:02 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. In this one, I discuss open redirect vulnerabilities and how to find them. If you’ve never heard of open redirects, this might be a useful introductory text.

Where are all the machines affected by BlueKeep hiding - part 2

Jan Kopriva — Sat, 10 Aug 2019 10:11:50 +0200

Last week, we took a look at Shodan results to try to determine which countries are the “richest” in the world when it comes to machines vulnerable to BlueKeep visible from the internet. Since the number of vulnerable machines Shodan detects grows every day (see the following chart), I thought it might be interesting to have another look at the numbers. But in a way which is a little different.

It should be mentioned that the rise in the number of affected machines is most likely due to Shodan scanning previously unscanned IP ranges and not because there are actually more vulnerable machines out there. In fact it is quite probable that a not insignificant percentage of machines shown by Shodan as vulnerable have either been assigned different IP addresses since the detection (and could therefore have even been counted multiple times) of have been patched since the detection. If you’d like to see something closer to an actual “real-time” look at the number of machines which are still vulnerable to BlueKeep and accessible from the internet, Shadowserver will probably be a better place to look then Shodan.
But that doesn’t mean that Shodan can’t still give us something quite interesting in this area.

Since very little has changed in terms of positions of different countries (see the previous post if you are interested who still has the dubious honor of belonging to the “BlueKeep Top 10 Club of Countries” as there were no changes in the first 10 places), I believe it might be more interesting to explore another aspect of the numbers, namely what percentage of machines which are accessible on the usual RDP ports (3388 and 3389) in the different countries are actually vulnerable. I quite like the idea since it could give us at least some idea of how large a percentage of all affected machines are potentially still unpatched in the countries in question.

It is true that machines directly accessible from the internet are not the best sample for “all the machines out there”, however some lose correlation between patch levels of servers accessible from the internet and patch levels of all the other machines certainly exists. One could even realistically expect that servers directly connected to the internet should be patched more often than other servers/machines so using what Shodan sees as a sample isn’t that inappropriate.
Although, since we’re listing weaknesses of this approach, we should mention that we’re completely skipping over identifying operating systems of machines behind the RDP ports and we’re counting anything with any service accessible on 3388 or 3389 as either vulnerable or patched. I.e. the following results are interesting but take them with a grain of salt.

Based on Shodan detections, of the 30 countries with highest numbers of affected machines, Hong Kong, South Korea, Argentina, China and Ukraine seem to be worse off when it comes to the percentages of machines with open RDP ports that are vulnerable to BlueKeep.
I’ve left the chart ordered by number of detected vulnerable machines in different countries so you can draw your own conclusions. The percentages themselves are in a table at the end of the post.
What seems most interesting is that although the US is second overall in the number of vulnerable machines detected (over 109k machines on the day of writing), it appears that the local patching culture is much better than in the rest of the “Top 30” BlueKeep countries as this number represents less than 3.7% of all systems with open RDP ports in the US.
This well illustrates the fact number of vulnerable systems in a certain country often doesn’t give us the whole story…

Position	Country	Vulnerable machines	Percentage of vulnerable machines
1	China	355449	24.34%
2	United States	109011	3.67%
3	South Korea	32300	29.07%
4	Brazil	29137	19.66%
5	Russian Federation	28432	20.12%
6	Hong Kong	25015	30.67%
7	Germany	13971	6.58%
8	Taiwan	13394	22.36%
9	Japan	12444	10.15%
10	United Kingdom	11691	8.75%
11	France	10413	7.74%
12	Canada	10086	9.78%
13	Italy	9585	16.99%
14	Spain	9428	17.13%
15	India	7732	11.00%
16	Mexico	7361	16.50%
17	Netherlands	6941	4.48%
18	Argentina	6826	27.86%
19	Ukraine	6516	22.41%
20	Australia	5555	8.69%
21	Viet Nam	5455	13.07%
22	Singapore	5226	6.45%
23	Turkey	4915	10.92%
24	Thailand	4522	15.52%
25	Poland	4241	14.01%
26	South Africa	4175	13.95%
27	Colombia	2962	14.59%
28	Czech Republic	2890	10.40%
29	Iran	2822	14.14%
30	Malaysia	2725	17.82%

Where are all the machines affected by BlueKeep hiding?

Jan Kopriva — Thu, 01 Aug 2019 11:23:55 +0200

EDIT 8/5/2019: Wrong CVE - CVE-2019-0709 was mentioned instead of CVE-2019-0708…

We’ve all read about the hundereds of thousands of machines affected by BlueKeep connected to the internet, but where are they hiding? With the help of Shodan, we can try to figure it out.

At the time of writing, Shodan returns 667243 results for CVE-2019-0708. In the leading place is China with 291686 results, followed by United States (88625 results), Korea (26578 results), Brazil (23756 results) and Russia (22682).

Top 49 countries are each the home of more than 1000 vulnerable servers (the Czech Republic has 2327 results and is in 29th place) and each of the top 97 countries has at least 100 detections.

For those of you who would like to take a look at all the countries (though it is possible I missed some of them) where there was at least one vulnerable machine, you may take a look at the following chart.

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

Looking back at September 2015

Jan Kopriva — Sun, 18 Oct 2015 16:13:47 +0100

Information concerning number of devices vulnerable to Heartbleed vulnerability has appeared in the news during September. Given that the existence of Heartbleed was made public almost a year and a half ago it may be surprising that the number of vulnerable devices exceeds 200.000.
Affair concerning the Stagefright vulnerability (which was mentioned in the last Looking back) continued in September when Zimperium – the company which discovered Stagefright – released a proof-of-concept code which exploits the vulnerability.
A stealth malware hidden in modified Cisco IOS images and named SYNful knock has been discovered on tens of Cisco routers around the world. The malware functions as a backdoor and besides the (persistent) IOS-embedded main component uses tens of modules which provide further functionality which it loads into volatile memory.
It should be mentioned that Google, Microsoft and Mozzila made a press release announcing that their browsers will stop supporting the RC4 encryption algorithm early next year.
One final piece of interesting news we will mention has been the discovery of a malware targeted at online poker players. The trojan horse is named Odlanor and captures screenshots of applications used for playing poker online and then sends them to the attacker.

Looking back at August 2015

Jan Kopriva — Tue, 08 Sep 2015 17:06:42 +0100

One of the most important information related to cyber security pertains to August release of a patch for the Stagefright vulnerability, to which almost all versions of the Android OS from versions 2.2 to version 5.1 are vulnerable. The existence of Stagefright had been made public at the end of July and it is estimated that vulnerable device number in hundreds of millions. The vulnerability enables the attacker to cause arbitrary code execution by sending a specially crafted MMS. The released patch has unfortunately been shown to be incomplete, the result of which is that even updated devices are still vulnerable.
Another interesting vulnerability which also affects a mobile platform (in this case iOS) is called Ins0mnia. The vulnerability enables malicious applications to circumvent OS security controls and run in the background without users knowledge (and – for example – collect sensitive information). Ins0mnia affects even non-jailbroken devices and has been patched in the iOS 8.4.1 update.
One further August news story has been connected to Apple products – creation of the Thunderstrike 2.0 proof-of-concept worm which is able to infect firmware of Macs. Given the location of infected memory, it is highly problematic to detect the infection from the OS and removal of the worm requires firmware to be re-flashed.
Another newly discovered (however 18 years old) attack vector also exploits vulnerability connected to computer hardware. A vulnerability in Intel x86 processors enables an attacker to install rootkit into memory location used by SMM (System Management Mode – a privileged mode used outside of normal OS execution).
One final interesting news comes from the Czech Republic and concerns signing of a sectoral agreement about cyber security education between commercial and governmental entities.

Looking back at July 2015

Jan Kopriva — Wed, 05 Aug 2015 10:27:36 +0100

The most important IT security-related news in July has definitely been the affair surrounding a theft of data from the Hacking Team – company, which develops commercial spyware intended for use by police departments and other security agencies. More than 400 GB of stolen data were made public and afterwards analyzed by IT security specialists, leading to discovery of a large number (still growing) of zero-day vulnerabilities which were used in Hacking Team’s products.
An interesting news appeared also in connection with vehicle security. Two researchers managed to leverage a vulnerability in a wirelessly accessible on-board entertainment system of a Jeep Cherokee which enabled them to remotely control some of the vehicle’s functions and components, including transmission. Fiat Chrysler has responded to publication of the vulnerability by a recall of 1.4 million of affected vehicles. Similar action in connection with software bugs/vulnerabilities was also taken by Land Rover and Ford.
A mention should be made of a press release by Europol, made in the middle of the month, regarding a successful operation to take down the Darkode cybercriminal forum. Although 28 users and administrators were arrested in, the forum resumed its operation only two weeks later.
Another vulnerability has also been discovered in OpenSSL, which enables an attacker to potentially use invalid certificate as a valid one. A fix for the vulnerability was released only few days after its publication.
An interesting new attack which could lead to extraction of data from an air-gapped system has also been made public. It is based on transmitting a radio signal generated by the computer using a video card bus as an antenna and received by a nearby mobile phone.

Looking back at June 2015

Jan Kopriva — Sat, 18 Jul 2015 17:29:33 +0100

Probably the most interesting of security-related news in June has been an announcement by OPM (Office of Personnel Management of United States), organization which is responsible for HR services and administration of US federal employees, about an attack which exposed records for approximately four million current and past employees. The breach has apparently been active for some time before it was discovered using a special IDS called Einstein. Anonymous US officials attributed the attack to China.
Information about a similar attack in Japan has been made available in June. Personal information about approximately 1.25 million citizens was stolen during the attack. Primary attack vector appears to have been a malicious e-mail attachment.
For owners and users of Apple products might be interesting news about discovery of a vulnerability, which enables attacker to rewrite FW in older (devices shipped before the second half of 2014) Macs. The vulnerability enables the attacker to make changes in BIOS when the device is waking up from sleep (when the FLOCKDN protection which should ensure that some parts of the system are accesible in read-only mode is disabled) which may be used to gain root privileges.

Looking back at May 2015

Jan Kopriva — Fri, 05 Jun 2015 00:00:57 +0100

May has been at least as rich on cybersecurity incidents and events as any of the previous months of the year. Some of the more important are described in the following text.
The VENOM (Virtual Environment Neglected Operations Manipulation) vulnerability may be considered to be a very significant one. VENOM is a vulnerability in the code of a virtual floppy drive which is used by some of the virtualization platforms (QEMU, KVM, Xen). It enables the attacker to access underlying hypervisor from a virtualized OS using a buffer overflow attack. Since the vulnerability is non OS specific its impact is fairly high.
A mention should also be made of another of the TLS/SSL protocol implementation vulnerabilities, the so-called Logjam. Using Logjam, a downgrade of encryption is possible in man in the middle attacks on connections which use Diffie Hellman key exchange algorithm and support its export version.
Finally, it is noteworthy that the government has ratified an Action plan for National Cyber Security Strategy 2015 – 2020. Further information (in Czech) may be found here.

Rowhammer - an attack which uses a weakness in DDR3 memory

Jan Kopriva — Tue, 10 Mar 2015 13:57:46 +0100

Researchers from Google’s Project Zero have released information about a new attack based on flipping bits in DDR3 memory. The attack uses approach called Rowhammer which was devised last year by a team from Carnegie Mellon University and Intel Labs. It is based on repeated writing to and reading from a part of memory in a very short time which causes flipping values of bits in adjacent memory (the flipping is made possible by interaction between adjacent memory cells caused by their close proximity).
Using the described principle, researchers from Project Zero created two exploits which they used to successfully elevate user privileges on a x86-64 Linux system where they achieved unrestricted access to the entire physical memory by flipping bits in page table entries (PTEs). In their announcement, they reported that the described approach was successfully used on machines with DDR3 memory without ECC (error correcting code). Flipping of bits has not been seen on machines with ECC memories. Source codes for the test program used to determine if a machine is vulnerable to Rowhammering have been released by the authors and may be found here.

FREAK - a high impact vulnerability in TLS/SSL

Jan Kopriva — Wed, 04 Mar 2015 10:06:49 +0100

An international research team has devised attack called FREAK (Factoring attack on RSA Export Keys) with which it is possible to lower the level of encryption used in SSL connections. Attack is based on forcing server and client to use legacy (the vulnerability has been present for a long time) weak cryptographic suites which are still supported by some of the mainstream browsers (Safari and OpenSSL-based Android browser among others) and servers. After a key has been factored a man-in-the-middle attack may be launched by attacker against encrypted connection between a server and a browser. The aformentioned legacy cryptographic suites have been added to SSL implementations at a time when export regulations for cryptographic material were in effect in USA and only specific (weak) cryptographic suites were legally allowed to be exported. A link to a page containing further information about potentially vulnerable sites and a test for vulnerability on the client side may be found here.