Stories and thoughts on IT Security

It’s not new the an AV surprises me, but it’s rare that they do in a pleasant way. So here is the story…

Let’s say you have a system that automatically processes emails and it also stores them as TXT files in a specific folder. Well, when I say TXT files, I really mean MSG files named as whatever.txt. I just found that Trend Micro Deep Security doesn’t just scan these files, but it “understands” that these are emails, so it treats them as emails. And there comes the magic.

Say, there is an alert that it detected and deleted a malware like this:

It doesn’t mean it deleted or did anything with the original file, but it deleted the malicious attachment from the “email”. So basically the TXT emails are always there, all Trend does is removing the malicious parts of the email.

If you check the TXT file, you can see Trend didn’t just delete the attachment, but it also put a placeholder there. Just like a AV on a mail gateway would do.

Honestly I was pretty surprised – this is kinda cool!

To double-check my theory I recovered the original file from Trend’s quarantine. As you can see in the original TXT file, there was a .7z attachment.

So Trend extracted the attachment – which was a VBS script btw – and detected it as malicious.

Just out of curiosity I did the legwork and extracted the VBS script and uploaded it to VirusTotal and also to Malwr. Below are the results – looks pretty bad.

Don’t get me wrong, I’m not impressed by the fact that it found a malicious file, but I’m kinda surprised by the fact that it didn’t just dumbly scanned the TXT files, but it detected them as e-mails.

We started to use Microsoft Advanced Threat Analytics (ATA) couple of months ago. It seems to be a pretty good toy honestly. I know what I used to be doing when pen testing internal networks and the alerts of this guy are pretty much aligned to those things. So ATA alerts have high priority on my list. However we started to receive bunch of them recently. Most of the alerts were either “Suspicion of identity theft based on abnormal behavior” or “Reconnaissance using directory services enumeration”. Let’s put the second one aside for a second – that’s a different story. The first though bugged me a lot. DISCLAIMER: this alert can be either a “High” or a “Medium” severity event. Everything in this post refers to the “Medium” alert. The highs are different and should be investigated!!

So let’s say you received a Medium alert of this identity theft thinggy. It should be something like this:

The alert from the ATA console

The first thing you want check is those “abnormal resources”. If you click on the link, you get the list of the accessed computers and the used protocols. If you are like me, you won’t find anything interesting among the computers. Except for the fact that in most cases there are a lots of them. As you can see on the screenshot above, we had 123 computers just for that single alert. Pay attention to that listing though! In every single case the remote host was accessed via CIFS (445/tcp).

Details of those “abnormal resources”

If you are familiar with pen testing and SMB auth probes, most probably this is the last thing you want to see. A lot of SMB connections from a single computer to several others. Someone might run SMB auth sweeps on the network. On the top of that such alert indicates successful connections. Getting worse and worse…

As bad it looked, something just didn’t match. We had bunch of these alerts from a lot of different source computers and we found nothing suspicious besides these ATA alerts. So I started to check the source computers. I didn’t now what I was looking for. My first though was that it’s an application doing some weird crap. So the plan was to collect all the computers and ask desktop support to help me find something in common. While I was collecting the computers I realized all of the were Windows 10. This was no surprise as we were rolling out Win10 like crazy. However I also knew that our other division was still on Windows 7 and they saw no such alerts. Okay… so maybe it’s something with Win10, right? After searching a bit, it hit me.. crap.. it was so obvious (after I found it :)). This is the new feature of Windows 10 called Delivery Optimization. If you are not familiar with this feature, it’s basically peer2peer Windows updates. Yep, your Windows 10 can download updates from other computers. You can find a short summary of this feature here: https://privacy.microsoft.com/en-us/windows-10-windows-update-delivery-optimization

As I understand Delivery Optimization Service (DoSvc) uses dedicated ports (TCP listener on port 7680 and a UDP receiver on port 3544), however the peer discovery method uses 445/tcp, which kinda makes sense. At least this is my best guess so far, still need to do some testing.

Recently we had a pretty weird experience with the Barracuda Web Filters we are using. We noticed that a site that should be blocked is accessible for some users. The domain was tr553.com.

Here is why we believed it’s being blocked. On the Barracuda, you can check the categorization of a URL via the Content Filter Lookup functionality. As you can see the given domain was categorized as “Advertisements & Popups”.

On the Content Filter page, you can define whether a particular category is allowed or blocked. The advertisements category was clearly blocked on all devices.

But still, we could access the https://tr553.com site thru the proxy. Some of you may think, you must have had the SSL inspection turned off and that’s an HTTPS URL. Actually you are right. For various reasons (that will be another story) we have SSL inspection turned off on the web filters and that’s an HTTPS URL indeed. However, the Barracuda web filters are smart enough to enforce the content filter policies (actually all domain based restrictions) on HTTPS URLs even if you don’t have SSL inspection. And yes, usually it works just fine. But let’s go back to our little problem here. There is a pretty cool feature on the Barracuda, you can use its troubleshooting feature to test whether a particular user and/or client IP can access a page or not. As we did so with https://tr553.com, we got the following result.

That’s a deny!!! What Da FrozenCow?? So Barracuda says, “Hey, no worries I’m gonna block this site”, but in reality it ain’t block shit.

We tried one more thing, we visited http://533.com and guess what?! It was blocked! So if we didn’t use HTTPS, but HTTP, everything was good. I know what you’re thinking… it’s the SSL inspection. No, it’s not. Because a) I know from experience that the content filter blocks work perfectly with HTTPS sites and b) read further 🙂

This was the time when we started to test this on other devices – luckily we have a handful of Barracuda proxies :). There came the second surprise. On a different device (same settings), the request was blocked as it should have been.

We double checked everything, the two devices were identical in terms of configuration. My next idea was to remove the device from the rack and either burn it or sell it on eBay, then we realized the difference. We used the latest shinny firmware (version 12.whatever) on the first device, while we were still on v11 on the second device. Yes, the old firmware did its job perfectly, while the new one had a major bug.

Honestly I don’t understand this. Content filtering is a core (and basic) feature of a proxy server. How is it possible that a firmware is being released when it has a flaw in this core functionality. The only possible explanation is that these updates are tested properly. My problem is that we are talking about security products here!! In this example it was a advertisement site, so one could say “who cares?”, but the same functionality is used to block malicious sites or we have custom blacklists with plenty of domains.

What frustrates me is that the more I work on the defensive side, the more often I see things like this. It’s so disappointing.

Today’s story is about the side effects of turning Network Level Authentication on. I’d like to focus on a specific case namely the effects on end-users. There are two things being widely used in password policies. One is that the user needs to change his/her password after the first login if it was reset by IT. The other one is expiration. This latter one is being challenged nowadays, but let’s assume you still have password expiration.

What happens if you try to log in with an initial or expired password via RDP? You receive a warning message saying right after login you need to change the password and it takes you to a password change screen.

What happens if you try to do the same thing, but NLA is turned on? You got an error like this:

This particular error is not referring to an expired password, but for the fact that the “User must change password at first logon” . But trust me, you have a very similar one with expired accounts :).

Just to be clear, it’s not a bug or a configuration mistake of any kind. If you turn on NLA, this is what it is.

My intention with this post is not to grade or evaluate the solution described here. My only point is to be sure you are aware of the potential side effects of using this particular configuration. Also, as not being a subject-matter expert, this post only reflects what I learnt and understood after few hours of testing.

Background story

When you have a spam filter/mail gateway (of any kind), you want to use it to block “dangerous” attachments, right? You don’t want your users to receive executables for instance. I know, a simple Word file with a macro is as dangerous as an EXE, but unfortunately you can’t block Word files. So you just try doing your best.

Approach

We set up two types of blocking rules. One was blocking files based on their extension. Simple file name matching rules (e.g. *.jar, *.exe, *.bin). Yes, it can be bypassed by a 7-year old, I know that. However, a) it doesn’t hurt to turn this on (oh yeah.. it can hurt as we learnt) and b) if the bad guys need to rename their hack.exe to hack.ex_, we already gained some advantage. Nothing happens if the user double-click on the “hack.ex_” file, so it’s something 🙂

The other thing we did was MIME-Type blocking. We were blocking MIME-Types that may indicate dangerous files – among others we had “application/octet-stream” in the list.

Lessons learnt

We learnt three important lessons within 2 hours :). Needless to say we blocked hundreds of e-mails in the first hour which was more than suspicious.

When we checked the console we saw lots of e-mails being blocked by our mime-type rule: application/octet-stream. Checking the e-mails showed that they contained PDFs, GIF images, that sort of things. As you know a PDF should be application/pdf while GIF is image/gif. Well.. in theory. In reality sometimes they’re sent as application/octet-stream.

As you can see the attachment was a PDF, however it was sent with the mime-type of application/octet-stream. Ergo, it was blocked.

So you can’t really block application/octet-stream because of the huge number of the false positive hits. Sad… really sad.

If you turn on the inspection of the archive containers, it’ll extract EVERYTHING it can. As it’s well known, the new Office file formats (xslx, docx, pptx etc.) are archives. So the mail gateway can and will extract those files. It’s a good question whether it’s the expected behavior or not, but it’s a fact. The only problem you may face (if you want to filter the *.bin extension) is that these Office files may contain *.bin files. For instance, most of them has a “printerSettings1.bin”.

This means, you can’t really block the *.bin files without blocking most of the MS Office files as well.

Of course you could set up exceptions. Yes, you could, if you’re lucky enough to have a mail gateway supporting such nice features 🙂

The last lesson – never trust the “Delivery status” column of your mail log. So here is the thing, let’s say you blocked couple of hundreds of e-mails by accident, so you have to release them manually. This is not a problem, every mail filter has this functionality.

The following two pictures show the status of a blocked e-mail before and after it was delivered.

If you can’t find the difference, you’re right… there is no difference!! So you can’t be sure whether the e-mail was really delivered to the recipient or not after you clicked on the “Deliver” button. And believe me, when you’re in the middle of fixing the mess you’ve created, you really want to know the delivery status. Actually, this is the only thing you care about!

I think the take away here is what we already know. It’s easy to write security recommendations and guidelines, but the road of implementation is full of bumps and roadblocks. And sometimes even the simplest things are impossible to do.

I’m just an average eBay customer having my PayPal account linked. No matter why, but recently I changed my PayPal account. Few days ago I realized my eBay and PayPal accounts were not synced as eBay had my prior PayPal account. So I just unlinked them and tried to link my new PayPal account. Theoretically it’s easy. Here is the official guide:

Click My eBay at the top of most eBay pages.

Click the Account tab.

Click the “PayPal Account” link on the left side of the page.

Click the Link My PayPal Account button.

You’ll be asked to log into PayPal to finish linking your accounts.

Step 5 can be tricky though. When you enter your username and password (first factor) you are redirected to a page on which you can click on the “SEND” button so you receive the second factor code via text message. You enter the code and magic SHOULD happen. Magic means you should be redirected back to eBay. In reality you’re redirected to the PayPal login page again (username and password). I repeated these steps at least 5 times and got the same result.

Yes – I tried all the classics: logout from eBay and PayPal, clear the browser cache, private browsing, new browser, google the problem … nothing worked.

I suspected it’s not a real issue. If it would be a bug, the Internet would be full of it. eBay and PayPal are big players, if the integration breaks between these two that’s a big thing, right? So I fired up Burp to see what’s going on and what I found was a kind of shocking. No surprise, when you click on the “Link My PayPal” account link on eBay a lot of things happen. There are approx. 10 calls within the eBay domain, but I was not interested in those. Of course at some point in time you are redirected to paypal.com. The key is the last eBay URL before you leave the site.

I tried to color-code the URL – it’s URL-encoded, but you can spot the point, I believe. This call defines the “return URLs” to which you should be redirected back after the PayPal authentication. If you’ve ever coded / pen tested / used a site which was integrated with another one, you’ve seen such things.

What’s the problem then? Well, PayPal fails to propagate these URLs (via the 2FA pages). I’m not sure whether the 2FA is the problem here, because I couldn’t turn 2FA off (!!) for testing purposes. This option just disappeared from the security settings!! Anyway.. what happens is that during the PayPal login process it starts using its own “returnUri” parameter. This parameter of course doesn’t point back to eBay. So here is the problem:

You click on the “Link my PayPal” link (eBay)

You are redirected to the PayPal login page (PayPal)

You enter your username and password (PayPal)

You request a secondary code to your phone (PayPal)

You enter the code (PayPal)

You are redirected back to the login page (PayPal)

You never hit eBay again!

Once I saw this flow, the solution was obvious. All I needed to do was to “manually redirect” myself back to eBay by entering one of the return URLs to my browser’s address bar (after some decoding of course). Then eBay greeted and told me I’m just one step away from finishing the process. So I just clicked on a button and it’s over.

What bugs me is that turning on a security feature (2FA) breaks the eBay and PayPal integration. I don’t know if it’s just me or others might be affected as well? Maybe there was some other circumstances that ended up in this mess. I will never understand these IT things I believe 🙂

My intention with this post is not to grade or evaluate the solution described here. My only point is to be sure you are aware of the potential side effects of using this particular configuration. Also, as not being a subject-matter expert, this post only reflects what I learnt and understood after few hours of testing.

UPDATE: other security products have the same authentication option, so please do not focus on the given product, but also check yours.

Background story

Suppose you have a Barracuda Web Security Gateway operating in inline mode (1) and you also have the SSO option configured and enabled (2). Note that (1) and (2) conditions are important.
In such case the appliance can see two types of users – authenticated and unauthenticated. Barracuda offers you to have different policy settings for these two groups.

Phenomenon

You connect a laptop (not domain member) to the network running whatever OS you like – in this case it was OSX if you are interested, but doesn’t matter really ;). As the proxy is operating in inline mode you can start browsing the internet. Let’s log in to the Barracuda and check the logs related to the IP address of this laptop. There are two options:

You see the newcomer as an unauthenticated user – no surprise here

You see him as an authenticated user and a “random” (ok, it’s not random, see below) username is being associated with him. Long story short: with a home laptop without providing any credentials you may become an authenticated user.

Explanation

The first thing that bugged me is the authentication (especially the SSO) itself. If the device is in inline mode there must be a trick, right? And there is. Barracuda’s DC Agent comes to rescue. Here is the description straight from the official site (https://techlib.barracuda.com/BWF/DCAgentOverview):

You can install the Barracuda DC Agent either on the domain controller or on a dedicated Windows PC on the office network. The Barracuda DC Agent periodically checks the domain controller for login events and to obtain a record of authenticated users. The IP addresses of authenticated users are mapped to their username and group context. The list of authenticated users is provided to the Barracuda Session Manager on your Barracuda Networks product, allowing true single sign-on capabilities.

So what’s going on here? When the appliance synchronises the login data, it binds the usernames to IP addresses. As a result, the appliance identifies (and authenticates – according to the terminology) the users based on their IP addresses.

In one hand, it makes sense as this is the only information the appliance can see in inline mode. It has no “direct contact” with the clients, the traffic just “get routed” via the appliance. Ok, I know there are other ways…

On the flipside though, you must be aware of that in such configuration your proxy is going to authenticate your users based on their IP addresses only. Needless to say changing the IP address is not a brain puzzle. It may lead to user impersonation in the proxy context. Consider the following scenario, Bob plugs in his laptop, logs in to the domain and does some work. Then Bob needs to leave for a meeting, he unplugs the laptop, so his IP is free to use. Eve may configure this IP or the IP is assigned to her via DHCP (after a given period of time). Anyway as soon as Eve has the IP, she becomes to Bob – at least for the proxy.

One thing you can use is the “Cache groups for” option of the DC Agent. This is the amount of time (in minutes) to allow the DC Agent to rely on cached login information (the default is 480 minutes). However it’s not a real solution.

I guess the best you can do (if you need authentication) is using the device in forward proxy mode with NTLM Domain User Authentication or with the Kerberos Authentication.