Home Made zero trust security?

I have a small office with some computers and servers and since I’m a fan of Zero Trust Security, I have firewall enabled even in local network. I’m especially concerned about my primary workstation, a Windows Machine where I have explicitly created firewall rules to block EVERY packet from another machine of the network.

I have backups, I have antivirus, but that machine is important and I do not want it to be compromised, working with a rule that block every contact from external code is nice and make it secure, but sometimes it is inconvenient.

Actually Zero Trust security can be complex, but for small offices it could be implemented with home made tools. In my scenario I’m pretty annoyed because there are some situation where I want to access my home network in VPN and then use my workstation in RDP, but since every port is closed, no RDP for me.

The alternative is to left RDP port opened always for all local machines, or for VPN ip subnet, but it is not a thing that I like. What about someone cracking my VPN? Once he is in VPN he can try to attack my RDP port, something that I want to prevent.

To solve this problem I’ve authored a really stupid program to manage hardening of my machine: https://github.com/alkampfergit/StupidFirewallManager This is a proof of concept, but basically it works with a simple concept: if I want to conditionally open TCP port based on a secret, I created a program that is listening on some UDP ports and if it receives a message with a specific secret it will open related TCP port, only for caller IP and only for a certain amount of time.

Here is a configuration:

  "Rules" : [
      "Name": "Rdp",
      "UdpPort": 23457,
      "TcpPort": 3389,
      "Secret": "this_is_a_secret"

This means that I want a rule called RDP that will listen on UDP port 23457 and when some other computer sends single UDP packet on that port with the expected secret, it will open 3389 TCP port for that IP for a couple of hours.

You can find the code on the above project, but you need to pay attention, because as soon as the program starts, it will add some rules to close all ports. Please be sure to use this POC only on computer where you have physical access.


Figure 1: All ports blocked upon program execution

In Figure 1  you can see that the tool added two rules to deny access to every ports that is not in the controlled range. This basically left only UDP port 23457 opened, and every TCP port except 3389 explicitly closed.

If I try to connect to my machine from another machine in my local network with RDP, I got no response.


Figure 2: Cannot access to my workstation with RDP

This happens because the tool explicitly deleted all rules about port 3389 and deny access to every other port. If I want to connect to that machine I need to fire up client and ask for port to open


Figure 3: Client program used to ask for port opening

Now if you got correctly both port and secret, a new rule was created.


Figure 4: New rule created upon correctly matching port and secret

The name of the rule is unique (it ends with a GUID) and contains in the name the expiration date in form of yyyyMMddHHmm, a timer in server part of the program check firewall rules each minutes to remove all of the rules that matches this pattern and remove them when they are expired.


Figure 5: New rule is created scoped for only the computer that sent correct UDP packet with correct secret.

If you look at the new rule it has a scope limited to caller computer

This simple POC allows me to remotely manage my firewall, opening only pre-determined port, for a predetermined amount of time, only for specific ip that knows a specific secret.

This is really only nothing more than a proof of concept, but if you want to apply Zero Trust Security in your environment and you have no commercial or enterprise ready solution, learning on how to manage local firewalls with your code is a good starting point to strongly limit the surface of attack on your local network. These kind of techniques strongly limit lateral movement on your network.

Gian Maria.

Check for Malware in a Azure DevOps Pipeline

In a previous post I’ve showed Credential Scanner, a special task part of Microsoft Security Code Analysis available in Azure, today I want to have a quick peek at Anti Malware scanner task.

First of all a simple consideration: I’ve been asked several times if there is any need to have an AntiVirus or AntiMalware tools in build machines, after all the code that is build is developed by own developer, so there should be no need of such tools, right? In my opinion this is a false assumption, here is some quick consideration on how a malware can be downloaded in your build machine

1) If you build open source code where others can contribute and if there is no constant analysis of code, it is simple for a malicious user to modify a script or yaml build to do something nasty to your build machine. Ok, this is a really an edge case, but think at an angry employee that got fired and want to damage the company….

2) Nuget, Npm and in general every package manager download stuff from internet, this should be enough to justify keeeping an AntiVirus on your build agent. Some npm package you are using can be hijacked to download everything, and, generally speaking, everything can go south if you download stuff from the internet. I know that npm and nuget probably does some check of packages, but there is no real formal approval process, so I think that noone can guarantee that everything that comes from nuget, npm or the like is safe.

3) Custom Task in azure devops are also downloaded from the server, but in this situation the risk can be mitigated, because Microsoft checks product that are in marketplace.

In my opinion, since a build agent will download stuff from internet and executes scripts made by humans, it is better to have a good security solution constantly monitoring Agent Working folder

Ok, point 2 is the real risk, to mitigate it, the only solution is to point to a private Nuget or Npm repositories, and double check every package that you allow from nuget.org or npm main repository. The goal is: before a new version of a library is allowed to be used, someone should check if there are no risks. Npm is especially annoying, because an NPM install usually automatically updates libraries, this is why on a build you should always prefer npm ci instead of npm install.

Generally speaking, in my opinion it is better to have an antivirus on your build machine, and be 100% sure that agent folder and agent folder is constantly monitored.

To add an extra level of security, I’d also like to have a report in my build that certify that output of the build is safe, welcome Microsoft Malware Scanner Analyzer. This is another task part of the Microsoft Security Code Analysis whose purpose is scanning a specific folder and report analysis in the build.

Task configuration is quite simple, you can usually leave all default configurations, and you are ready to go.


Figure 1: Configuration of Malware scanner Task

The only real parameter you want to configure is the path you want to scan, usually is the artifacts directory, so you are confident that the output of the build that will be uploaded to the service is Malware free. Having another AntiVirus as I told before gives you double security, because standard antivirus kicks in automatically, and this task will do another check and upload result on the build.


Figure 2: Output of Malware scanner in build output

Call me paranoid, but I really like having an assurance that my artifacts are secure. I perfectly know that this is no 100% assumption that everything is good, but it is a good part to start.

Another nice aspect of the tool is that the output of the scan is also included as an artifacts.


Figure 3: Anti malware scanner log uploaded as artifacts.

This allows for everyone that downloads artifacts for installation to check output of the scanner.

Remember, when it is time for security, having a double check is better than have a single check.

Gian Maria

BruteForcing login with Hydra

Without any doubt, Hydra is one of the best tool to bruteforce passwords. It has support for many protocols, but it can be used with standard web sites as well forcing a standard POST based login. The syntax is a little bit different from a normal scan, like SSH and is similar to this cmdline.

./hydra -l username -P x:\temp\rockyou.txt hostname –s port http-post-form “/loginpage-address:user=^USER^&password=^PASS^:Invalid password!”

Dissecting the parameters you have

-l: specify a username you want to try, you can also specify a file containing all the username you want to try
-P: specify a file with all the password you want to try, rockyou.txt is a notable standard
-s: service, it should be the port the site is listening to

After these three parameters it comes the part needed to select the site and the payload you want to sent to the site. You start with http-post-form to specify that you want POST request with form urlencoded, followed by a special string composed by three parts separated by semicolon.

The first part is the page that will be called, the second part is the payload, with ^USER^ and ^PASS^ placeholder that will be substituted by Hydra at each tentative, finally, the last part is the text that hydra should look to understand if access is denied. Once launched it will try to bruteforce the password with tremendous speed.


Figure 1: Hydra in action

As you can see it works perfectly also on Windows.

Gian Maria.

Security in 2019, still unprotected ElasticSearch instance exists

I’ve received today a notification from https://haveibeenpwned.com/ because one of my emails was present in a data breach.


Ok, it happens, but two things disturbed me, the first is that I really never heard of those guys (People Data Labs), this because they are one of the companies that harvest public data from online sources, aggregates them and re-sell as “Data enrichment”. This means that they probably have only public data on me. If you are interested you can read article by Troy Hunt https://www.troyhunt.com/data-enrichment-people-data-labs-and-another-622m-email-addresses/ on details about this breach.

But the second, and more disturbing issue is that, in 2019, still people left ElasticSearch open and unprotected in the wild. This demonstrates really low attention about security, especially in situation where you have Elasticsearch on server that have a public exposure. It is really sad to see that Security is still a second citizen in software development, if not, such trivial errors would not be done.

Leaving ElasticSearch unprotected binded to a public IP address is sign of zero attention to security.

If you have ElasticSearch in a server with public access (such as machines in the cloud) you should:

  • 1) Pay for Authentication Module so you can secure your instance or, at least, use some open source module for basic auth). No Elasticsearch that is installed in a machine with a public access can be left without auth.
  • 2) Bind ElasticSearch instance on private ip address only (the same used by all legitimate machine that should contact ES), be 100% sure that it does not listen on public address.
  • 3) add firewall rule to explicitly close port 9200 for public networks (in case someone messed with rule 2)
  • 4) Open port 9200 only for internal ip that are legitimate to access Elastic Search

Finally you should check with some automatic tool if, for any reason, your ES instance starts responding on port 9200 in public ip address, to verify if someone messed with the aforementioned rules.

Gian Maria.

Quick Peek at Microsoft Security Code Analysis: Credential Scanner

Microsoft Security Code Analysis contains a set of Tasks for Azure DevOps pipeline to automate some security checks during building of your software. Automatic security scanning tools are not a substitute in any way for human security analysis, remember: if you develop code ignoring security, no tool can save you.

Despite this fact, there are situation where static analysis can really give you benefit, because it can avoid you some simple and silly errors, that can lead to troubles. All Tasks in Microsoft Security Code Analysis package are designed to solve a particular problem and to prevent some common mistake.

Remember that security cannot be enforced only with automated tools; nevertheless they are useful to avoid some common mistakes and are not meant to replace security audit of your code.

The first task I suggest you to look at is Credential Scanner, a simple task that searches source code for potential credentials inside files.


Figure 1: Credential scanner task

Modern projects, especially those designed for the cloud, use tons of sensitive data that can be mistakenly stored in source code. The easiest mistake is storing credential for databases or other services inside configuration file, like web.config for ASP.Net projects or we can left some Token for Cloud resource or services, leaving that resource unprotected.

Including Credential Scanner in your azure pipeline can save you troubles, with minimal configuration you can have it scan your source code to find credentials. All you need to do is drop the task in the pipeline, use default configuration and you are ready to go. Full details on configuring the task could be found here.


Figure 2: Configuration pane for Credential Scanner

Credential scan will run in your pipeline and report problem found.


Figure 3: Credential scanner found a match.

If you look in Figure 3: Credential scanner found a match, but the task does not make the build fails (as you could expect). This is normal behvior, because all security tasks are meant to produce an output file with scan result, and it is duty of another dedicated task to analyze all results file and make the build fail if problems are found.

It is normal to have security related tasks not to fail the build immediately, a dedicated tasks is needed to analyze ALL log files and fail the build if needed

Post Analysis task is your friends here.


Figure 4: Add a Post Analysis task to have the build fails if some of the security related task failed

Actually this special task allows you to specify which of the security task you want to analyze and this is the reason why the build does not fails immediately when Credential Scanner found a problem. The goal here is running ALL security related tasks, then analyze all of them and have the build fails if problems where found.


Figure 5: Choose which analyzer you want to use to make the build fail.

After you added this task at the end of the build, your build fails if security problems are found.


Figure 6: Build fails because some of the analysis found some problems. In this specific situation we have credentials in code.

As you can see from Figure 6 Credential Scan task is green and is the Security Post Analysis Task that made the build fails. It also log some information in build errors page as you can see from Figure 7.


Figure 7: Build fails for issues in credential scanner

Now the final question is: where can I found the csv file generated by the tool? The answer is simple, there is another special task whose purpose is upload all logs as artifacts of the build.


Figure 8: Simply use the PublishSecurityAnalysisLog task to have all security related logs published as artifacts.

As you can see from Figure 9 all the logs are correctly uploaded as artifacts and divided by tool type.  In this example I’ve ran only the Credential Scanner Tool so it is the only output I have in my artifacts folder.


Figure 9: Credential Scanner output included as artifact build.

Downloading the file you can open it with excel (I usually use csv file output for Credential Scanner) and find what’s wrong.


Figure 10: Csv output contains the file with the error, the number of the line but everything else is redacted out for security

As I can verify from csv output, I’ve some problem at line 9 of config.json file, time to look at the code and find the problem.


Figure 11: Password included in a config file.

In CSV output file, Credential Scanner task only store file, row number and hash of the credential found, this is needed to avoid the credential leak from build output.

Now, this example was made for this post, so do not try that password against me, it will just not work :). If you think that you never fall for this silly mistake remember that noone is perfect. Even if I’m trying to avoid these kind of errors, I must admit that some years ago I was contacted by a nice guy that told me that I’ve left a valid token in one of my sample source. Shame on me, but this kind of errors could happen. Thanks to Credential Scanner you can really mitigate them.

If you wonder what kind of rules the task uses to identify password, the documentation states that

CredScan relies on a set of content searchers commonly defined in the buildsearchers.xml file. The file contains an array of XML serialized objects that represent a ContentSearcher object. The program is distributed with a set of searchers that have been well tested but it does allow you to implement your own custom searchers too.

So you can download the task, and examine the dll, but the nice aspect is that you can include your own searcher too.

If the tool find false positive and you are really sure that the match is really a false positive, you can use an exclude file as for the documentation.


Figure 12: Suppression rules for the task.

I must admit that Credential Scanner is really a powerful tool that should be included in every build, especially if you are developing open source code. Remember that there are lots of tools made to scavenge projects for this kind of vulnerabilities in code, so, if you publish some sensitive password or keys in open source project, it constitutes a big problem. Sooner or later this will bite you.

Gian Maria