Category: Infosec

Security Awareness: A 5-step process to making your training program role based and relevant

Håkon Olsen1 Comment

Security awareness training is one of many strategies used by companies to reduce their security risks. It seems like an obvious thing to do, considering the fact that almost every attack contains some form of social engineering as the initial perimeter breach. In most cases it is a phishing e-mail.

Security awareness training is often cast as a mandatory training for all employees, with little customization or role based adaptation. As discussed previously, this can have detrimental effects on the effectiveness of training, on your employee’s motivation, and on the security culture as a whole. Only when we manage to deliver a message adapted to both skill level and motivation levels we can hope to be successful in our awareness training programs: When does cybersecurity awareness training actually work?

So, while many employees will need training about identification of malicious links in e-mails, or understanding that they should not use the same password on every user account, other employees may have a higher level of security understanding; typically an understanding that is linked to the role they have and the responsibilities they take. So, while the awareness training for your salesforce may look quite similar to the awareness training you give to your managers and to your customer service specialists, the security awareness discussions you need to have with your more technical teams may look completely different. They already know about password strength. They already understand how to spot shaky URL’s and strange domains. But what they may not understand (without having thought about it and trained for it) is how their work practices can make products and services less secure – forcing us to rely even more on awareness training for the less technically inclined coworkers, customers and suppliers. One example of a topic for a security conversation with developers is the use of authentication information during development and how this information is treated throughout the code evolution. Basically, how to avoid keeping your secrets where bad guys can find them because you never considered the fact that they are still there – more or less hidden in plain site. Like this example, with hardcoded passwords in old versions of a git repository: Avoid keeping sensitive info in a code repo – how to remove files from git version history

So, how can you plan your security conversations to target the audience in a good way? For this, you do need to do some up-front work, like any good teacher would tell you that you need to do for all students; people are different in terms of skills, knowledge, motivation for compliance, and motivation to learn. This means that tailoring your message to be as effective as possible is going to be very hard, and still very necessary to do.

The following 5-step process can be helpful in planning your content, delivery method and follow-up for a more effective awareness training session.

training_personal_targeting
A 5-step process for preparing your awareness training sessions. 

First you need to specify the roles in the organization that you want to convey your message to. What would be the expectations of the role holders of a good security awareness training? What are the responsibilities of these roles? Are the responsibilities well understood in the organization, both by the people holding these roles, and the organization as a whole? Clarity here will help but if the organizaiton is less mature, understanding this fact will help you target your training. A key objective of awareness training should here be to facilitate role clarification and identify expectations that are always exisiting but sometimes implicitly rather than explicitly.

When the role has been clarified, as well as the expectations they will have, you need to consider the skillsets they have. Are they experts in log analysis from your sys.admin department? Don’t insult them by stressing that it is important to log authentication attempts – this sort of thing kills motivation and makes key team members hostile to your security culture project. For technical specialists, use their own insights about deficiencies to target the training. Look also to external clues about technical skill levels and policy compliance – security audit reports and audit logs are great starting points in addition to talking to some of the key employees. But remember, always start with the people before you dive into technical artefacts. And don’t over-do it – you are trying to get a grasp of the general level of understanding in your audience, not evaluate them for a new job.

The next point should be to consider the atmosphere in the group you are talking to. Are they motivated to work with policies and stick with the program? Do they oppose the security rules of the company? If so, do you understand why? Make sure role models understand they are role models. Make sure policies do make sense, also for your more technical people. If there is a lack of leadership as an underlying reason for low motivation to get on board the security train, work with the senior leadership to address this. Get the leadership in place, and focus on motivation before extra skills – nobody will operationalize new skills if they do not agree with the need to do so, or at least understand why it makes sense for the company as a whole. You need both to get the whole leadership team on board, and you probably need to show quite some leadership yourself too to pull off a successful training event in a low motivation type of environment.

Your organization hopefully has articulated security objectives. For a more in-depth discussion on objectives, see this post on ISO 27001. Planning in-depth security awareness training without having a clear picture of the objectives the organization is hoping to achieve is like starting an expedition without knowing where you are trying to end up. It is going to be painful, time-consuming, costly and probably not very useful. When you do have the objectives in place – assess how the roles in question are going to support the objectives. What are the activities and outcomes expected? What are the skillsets required? Why are these skillsets required, and are they achievale based on the starting point? When you are able to ask these questions you are starting to get a grip not only on the right curriculum but also on the depth level you should aim for.

When you have gone through this whole planning excercise to boil down the necessary curriculum and at what level of detail you should be talking about it, you are ready to state the learning goals for your training sessions. Learning goals are written expressions of what your students should gain from the training, in terms of abilities they acquire. These goals makes it easier for you to develop the material using the thinking of “backwards course design“, and it makes it easier to evaluate the effectiveness of your training approach.

Finally, remember that the training outcomes do not come from coursework, e-learning or reading scientific papers. It comes from practice, operationalization of the ideas discussed in training, and it comes from culture, when practice is so second nature that it becomes “the way we do things around here”.

To achieve that you need training, you need leadership, and you need people with the right skills and attitudes for their jobs. That means that in order to succeed with security the whole organizaiton must pull the load together – which makes security not only IT’s responsibility but everybody’s. And perhaps most of all, it is the responsibility of the CEO and the board of directors. In many cases, lack of awareness in the trenches in the form of no secure dev practices, bad authentication routines, insufficient testing stems from a lack of security prioritization by the board.

Want more? Get free updates by joining the Safecontrols e-mail list!

 

Avoid keeping sensitive info in a code repo – how to remove files from git version history

Håkon Olsen1 Comment

One of the vulnerabilities that are really easy to exploit is when people leave super-sensitive information in source code – and you get your hands on this source code. In early prototyping a lot of people will hardcode passwords and certificate keys in their code, and remove it later when moving to production code. Sometimes it is not even removed from production. But even in the case where you do remove it, this sensitive information can linger in your version history. What if your app is an open source app where you are sharing the code on github? You probably don’t want to share your passwords…

Key on keyboard
Don’t let bad guys get the key to your databases and other valuable files by searching old versions of your code in the repository.

Getting this sensitive info out of your repository is not as easy as deleting the file from the repo and adding it to the .gitignore file – because this does not touch your version history. What you need to do is this:

  • Merge any remote changes into your local repo, to make sure you don’t remove the work of your team if they have commited after your own last merge/commit
  • Remove the file history for your sensitive files from your local repo using the filter-branch command:

git filter-branch –force –index-filter \
‘git rm –cached –ignore-unmatch \
PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA‘ cat — –all

Although the command above looks somewhat scary it is not that hard to dig out – you can find in the the Github doc files. When that’s done, there’s only a few more things to do:

  • Add the files in question to your .gitignore file
  • Force write to the repo (git push origin –force –all)
  • Tell all your collaborator to clone the repo as a fresh start to avoid them merging in the sensitive files again

Also, if you have actually pushed sensitive info to a remote repository, particularly if it is an open source publicly available one, make sure you change all passwords and certificates that were included previously – this info should be considered compromised.

Like what you read? Sign up for free updates!

Cybercrime one of 5 top organized crime threats to Europe according to EUROPOL

Håkon Olsen1 Comment

Europol has recently released its 2017 report on organized (SOCTA) crime in the EU. In this report they identify 5 key threats to Europe from organized crime groups. In addition to cybercrime itself, the report pulls forward illicit drugs crimes, migrant smuggling, organized property crime and labor market crime. Cybercriminal activities are often integral to or supporting also the other key operations of organized crime groups.

090515_1236_Managinginf1.jpg
Organized crime groups are highly adaptable, and cybercrime is not an enabler of much of their more traditional criminal businesses. Threat intelligence becomes a key part of any defense strategy when the adversary is a powerful and diverse organization. 

Key tools of organized crime groups are

  • Corruption
  • Counterintelligence against law enforcement
  • Money laundering
  • Document fraud
  • Online trade
  • Technology
  • Violence and extortion

They carry out crimes through currency counterfeiting, various cybercrimes including child exploitation, payment fraud, data trade and malware campaigns. Also sports corruption is a major area for organized criminals, drawing profits from the gambling markets.

Document fraud is increasing and is a significant threat to Europe. It is an enabler of types of criminal activities, including terorrism. These documents are increasingly traded online.

Document fraud is one of the key drivers of identity theft. Document fraud can be necessary to facilitate other criminal activities, and cyberattacks may be used to steal credentials used to obtain documents.

Trade in illicit goods is increasing, and a lot of this trade is conducted on darknet sites. Key products are drugs, illegal firearms and malware. Other Crime-as-a-service segments are also of interest, like botnets for hire, ransomeware-as-a service, exploit coding. Europol sees Crime-as-a-Service as a growing threat to society, according to the SOCTA 2017 report. In particular the growth in ransomeware (#fiction #usecase) targeting not only individuals but also public and private organizations is worrying.

Geopolitical events are driving changes in organized crime in Europe. Conflicts close to European borders are influencing crime through migration, need for illicit goods, as well as European targets being picked by non-European fighters performing terrorist acts in Europe. Cybercrime is one source of funding for such terror groups, in addition to cybercrime being an enabler of the organized crime groups that support the needs of terrorism through illicit firearms trade, trade in drugs and narcotics and human trafficking.

Pulling EUROPOL’s intelligence into your cybersecurity threat context

What does this mean for European businesses? Depending on your exposure, technology base and value chain, this may affect the threat landscape for your organization.

  • Increasing the direct threat level, e.g. ransomeware and payment frauds
  • Supply chain effects, including money laundering schemes
  • Threats to your intellectual property
  • Corruption affecting your markets, including partners, owners, suppliers and customers
  • Potential investments from money laundering schemes into your infrastructure

If growth in the activities of organized crime groups affects your threat landscape, it may also mean that you need to rethink your cybersecurity defense priorities. Is availability still the main threat, or are confidentiality issues coming to the forefront?

 

Hashtag bots spreading spam and malicious links

Håkon OlsenLeave a comment

Automation is a part of social media today. They can help locate, aggregate and share interesting content. They can also be used to spread spam and malicious links. 

Try any popular hashtag and it is quite likely a bot will retweet you. Some of these bots have lots of followers – potentially reaching a lot of possible fraud victims. Here’s one example; the Twitter account @thehackerbot intends to retweet hacker news. Be of its triggers is the hashtag #hacked. 

The hacker bot

It does retweet a lot of hacker news. But then we also have this..

From Russia with love – spam retweeted by a bot

So, if you want to create a retweet bot, it is a great opportunity to work on your machine learning and AI skills – teach your bot to filter out spam. 

Is complexity better than length when it comes to passwords?

Håkon OlsenLeave a comment

Most organizations have password policies that require users to change their passwords every XX days, and that they use a minimum (or sometimes fixed!) length, and a combination of capital and small letters, numbers and special symbols. But what exactly makes a password “strong” or difficult to guess?

Entropy can be used to measure the complexity of an information string – or the number of possible combinations within the given “rule” for constructing a string if you want. To calculate the information entropy of your password, use this formule:

ENTROPY = LOG (Characters in set you make password from) / LOG (2) x (Length of password)

So, comparing a password using only lower case letters, and one with a combination of upper case and lower case, we get that the entropy in the first case is 37, and in the latter case it is 45. This means the latter case is harder to crack using brute-force attacks – but how much so? (Higher entropy is better). Open security research has made a calculator for brute force time that we can use to estimate that. The estimate is based on benchmarks for common cracking tools on a regular consumer grade PC. Assuming a SHA-encrypted salted password we get about 7 hours to crack the first but 2000 hours to crack the latter – entropy is obviously a big deal. As we see form the formula above, increasing the character set length is one way to increase entropy, the other one is increasing the length of the password itself. Note that in terms of cracking – using some symbols or characters not normally found in words is necessary to avoid dictionary based attacks – these brute force times are “worst-case times” seen from the attacker perspective – the time it takes to exhaust the entire character space.

What is better – more characters or longer passwords?

Turning to some basic maths, we can use the formula for entropy to look at the effects of increasing character set size versus password length. The entropy is proportional to the logarithm of the character set size – that means entropy growth rate with character set size c is 1/c. When c is large, the derivative approaches zero; increasing the set size is efficient for small set sizes but the value of doing so becomes smaller as the set size grows larger.

charset_entropy
The effect of increasing character set size on entropy is best when the charset is still small. 

The effect of increasing password length however, is linear, and remains the same for a given charset size for each length of the password. What does this mean in practice?

  • Add complextiy up to a certain level – that also takes away dictionary attacks as an efficient way to brute-force the password
  • Increase length after that instead of including more complexity

Using the brute force time calculator, we estimate the following exhaustion times:

  • Lower case letters, 8-character password: 7 hours to crack
  • Lower case and upper case letters, 8-character password: 2000 hours to crack
  • Lower case letters, 16-character password: 189 million years to crack
  • Lower and upper case letters, 16-character password: 12 trillion years to crack

Logical conclusion: use passphrases with some added complexity. This makes a brute-force attack on your password extremely difficult.

Top of the iceberg: politicians’ private email accounts and shadow IT

Håkon OlsenLeave a comment

In CISO circles the term “shadow IT” is commonly used for when employees use private accounts, devices and networks to conduct work outside of the company’s IT policies. People often do this because they feel they don’t have the freedom to get the job done within the rules.

071615_1406_Treatyourpe1.jpg
If you deny your people a well-stacked toolbox, they will bring their own. That may not be the best solution for your security. 

This is not only for low-level clerks and helpdesk ninjas: top level managers are known to do this a lot, including politicians. Hillary Clinton probably lost the presidential election at least partially due to her poor security awareness. Now VP Mike Pence has also been outed as “private email wielding pubic servant” – and he was hacked too. Why do people do this?

Reasons why people do their business in the IT shadows

I’ll nominate 3 main reasons why people tend to use private and unauthorized tools and services in companies and public service. Then let’s look at what we can do about it, because this is a serious expansion of the organization’s attack surface! And we don’t want that, do we?

I believe (based on experience) the 3 main reasons are:

  1. The tools they are provided with are hard to use, impractical or not available
  2. They do not understand the security implications and have not internalized what secure behaviors really are
  3. The always-on culture is making the distinction between “work” and “personal” foggy; people don’t see that risks they are willing to take in their personal lives are also affecting their organizations that typically will have a completely different risk context

How to avoid the shadow IT rabbit hole of vulnerabilities

First of all, don’t treat your employees and co-workers are idiots. IT security is very often about locking everything down and hardening machines and services. If you go too far in this direction you make it very hard for people to do their jobs, and you can end of driving them into the far riskier practices of inventing their own workarounds using unauthorized solutions – like private email accounts. Make sure controls are balanced, and don’t forget that security is there to protect productivity – not as the key product of most organizations. Therefore, your risk governance must ensure:

  • Select risk-based controls – don’t lock everything down by default
  • Provide your employees with the solutions they need to do their jobs
  • Remember that no matter how much you harden your servers, the human factor still remains.

Second, make people your most important security assets. Build a security aware culture. This has to be done by training, by leadership and by grassroots engagement in your organization.

Third, and for now last, disconnect. Allow people to disconnect. Encourage it. Introduce separations between the private and what is work or for your organization. This is important because the threat contexts of the private sphere and the organizational sphere are in most cases very different. This is also the most difficult part of the management equation: allowing flexible work but ensuring there is a divide between “work” and “life”. This is what work-life balance means for security; it allows people to maintain different contexts for different parts of their lives.

 

Hijacking existing email threads: taking phishing to a new level

Håkon OlsenLeave a comment

Phishing e-mails is the most common way for a hacker to breach the initial attack surface. Filters and blacklisting technologies have been less than effective in stopping such threats, and it is up to the cybersecurity training and awareness of the user to ensure safe choices are made. Now phishermen have new ideas about making their bait more trustworthy; hijacking existing mail threads, piggybacking on existing interpersonal trust. A received an e-mail sent me from a contact who told me he realized he’d fallen for a scam the second he submitted his username and password to the phoney login site he was led to. Here’s (a somewhat edited) excerpt of the e-mail thread leading him into the phisherman’s trap.

From: Jim Salesman
To: Danny Customer

Subject: Re: confirm order details

Dear Danny,

thank you for your purchase. Please download and check these documents.

clickphish

With best regards,
Jim

From: Danny Customer
To: Jim Salesman

Subject: Re: confirm order deetails

Dear Danny,

I agree to the conditions as you have suggested. Make sure the part serial numbers are indicated correctly on the labels.

With best regards,
Danny

——- (after multiple e-mails back and forth)

Where does the link lead to?

The link does not lead to a Google page, despite claiming to be a Google Docs file. Also the lack of Google branding in the download section could be an indicator. The URL is “ehbd-dot-ml/hbdesigns/gibberish/” and is rendered over http – no security. It displays a selection of “login credentials” to choose from.

phishinglogin

OK, so here are several well-known brand names.

So, who owns the domain ehbd-ml? A whois search shows the domain is registered to Mali Divi. B.V. in the Netherlands.This firm has been active since 2012 and owns a number of free domains. It has a VAT number and one employee, according to this site: https://www.opencompanies.nl/elektrotechniek-mali-dili-bv-amsterdam-56155794.

Why submitting your info is dangerous

My friend realized the mistake the moment he hit “submit”. He then called his company’s IT department, and was told to change his passwords and run a virus scan. That was the right thing to do. But why is this dangerous?

Giving hackers access to your e-mail makes it easy for them to:

  • your e-mails and attachments
  • they can impersonate you by sending e-mails as you
  • they can hijack other accounts where your email is used to reset your password

Lessons learned

Phishing scammers are skilled at exploiting established trust between you and your contacts. Always be suspicous about links in e-mails, even from people you know. Before clicking, always check:

  • Does the URL look reasonable?
  • Does the branding (logos etc.) look right for the contents?
  • Is the site it leads to secured when you would expect it to be? All major service providers will only serve https – not http
  • Is the domain name strange? The .ml top domain is the national domain for Mali in Africa. Google Docs does not use that as the default login site domain.

 

 

Cybersecurity for boards – the short story

Håkon OlsenLeave a comment

A few days ago I wrote a post on the lack of cybersecurity skills in corporate boards, and how to fix that. This became one of the most popular posts on the blog. That’s why I created this short summary video – that you can easily share with your top management and board members.

The take-aways are:

  • Build an information security management system with the most important policies, guidelines, procedures, change mangement and monitoring processes in place
  • Select reporting metrics that make sense in terms of the company strategy. Relate impact to financial, customer, organnization and learning, and internal process perspectives.
  • Use compliance to drive board focus: regulatory compliance is already central in goverannce work.
  • Focus on people when communicating – build a positive security culture by combining bottom-up and top-down approaches.

Thanks to Kenneth Holley and eForensics Magazine for sharing the board post! Great accounts to follow on Twitter!

IEC 61511 Security – getting the right detail level

Håkon OlsenLeave a comment

When performing the risk and vulnerability assessment required by the new IEC 61511 standard, make sure the level of detail is just right for your application. Normally the system integrator is operating at the architectural level, meaning signal validation in software components should probably already have been dealt with. On the other hand, upgrading and maintaining the system during the entire lifecycle has to be looked into. Just enough detail can be hard to aim for but digging too deep is costly, and being too shallow doesn’t help your decision making. Therefore, planning the security assessment depth level already from the beginning should be a priority!

Starting with the context – having the end in mind

The purpose of including cybersecurity requirements in a safety instrumented system design is to make sure the reliability of the system is not threatened by security incidents. That reliability requires each safety instrumented function (SIF) to perform its intended task at the right moment; we are concerned with the availability and the integrity of the system.

 

072115_1313_Uncertainty1.png
The probability of failure on demand for a safety critical function usually depends on random error distributions and testing regimes. How can hacker threats be included in the thinking around reliability engineering? The goal is to remain confident in the reliability calculations, so that quantitative risk calculations are still meaningful.

 

In order to understand the threats to your system you need to start with the company and its place in the world, and in the supply chain. What does the company do? Consider an oil producer active in a global upstream market – producing offshore, onshore, as well as from unconventional sources such as tar-sands, arctic fields and shale oil. The company is also investing heavily in Iraq, including areas recently captured from ISIS. Furthermore, on the owner side of this company you find a Russian oligarch, who is known to be close to the Kremlin, as a majority stock holder. The firm is listed on the Hong Kong stock Market. Its key suppliers are Chinese engineering firms and steel producers, and its top customers are also Chinese government-backed companies. How does all of this affect the threat landscape as it applies to this firm?

The firm is interfering with causes that may trigger the interest of hacktivists:

  • Unconventional oil production
  • Arctic oil production

It also operates in an area that can make them a target for terrorist groups, in one of the most politically unstable regions in the world, where the world’s largest military powers also have to some degree opposing interests. This could potentially draw the interest of both terrorist groups and of nation state hackers. It is also worth noting that the company is on good terms with both the Russian and Chinese governments, two countries often accused of using state sponsored hackers to target companies in the west. The largest nation state threat to this oil company may thus be from western countries, including the one headed by Donald Trump. He has been quite silent on cybersecurity after taking office but issued statements during his campaign in 2016 hinting at more aggressive build-ups of offensive capacities. So, the company itself should at least expect the interest of script kiddies, hacktivists, cybercriminals, terrorists, nation states and insiders. These groups have quite varying capacities and the SIS is typically hard to get at due to multiple firewalls and network segregations. Our main focus should thus be of hacktivists, terrorists and nation states – with cybercriminals and insiders acting as proxies (knowingly or not).

The end in mind: keeping safety-critical systems reliable also under attack, or at least make it an insignificant contribution to unreliability.

Granularity of security assessment

Our goal of this discussion was to find the right depth level for risk and vulnerability assessments under IEC 61511. If we start with the threat actors and their capabilities, we observe some interesting issues:

  • Nation states: capable of injecting unknown features into firmware and application software at the production stage, including human infiltration of engineering teams. This can also be “features” sanctioned by the producer in some countries. Actual operations can include cyberphysical incursions with real asset destruction.
  • Terrorists: infiltration of vendors less likely. Typical capabilities are ATP’s using phishing to break the attack surface, and availability attacks through DDoS provided the SIS can be reached. Physical attack is also highly likely.
  • Cybercriminals: similar to terrorists, but may also have more advanced capabilities. Can also act out of own interest, e.g. through extortion schemes.
  • Hacktivists: unlikely to threaten firmware and software integrity. Not likely to desire asset damage as that can easily lead to pollution, which is in conflict with their likely motivations. DDoS attacks can be expected, SIS usually not exposed.

Some of these actors have serious capabilities, and it is possible that they will be used if the political climate warrants this. As we are most likely relying on procured systems form established vendors, using limited variability languages for the SIS, we have little influence over the low-level software engineering. Configurations, choice of blocks and any inclusion of custom-designed software blocks is another story. Regarding our assessment we should thus, at least, include the following aspects:

  • Procurement – setting security requirements and general information security requirements, and managing the follow-up process and cross-organizational competence management.
  • Software components – criticality assessment. Extra testing requirements to vendors. Risk assessment including configuration items.
  • Architectural security – network segregation, attack surface exposure, monitoring, security technologies, responsible organizations and network operations
  • Hardware – tampering risk, exposure to physical attacks, ports and access points, network access points including wireless (VSAT, microwave, GSM, WiFi)
  • Organizational security risks: project organization, operations organization. Review of roles and responsibilities, criticality of key personnel, workload aspects, contractual interfaces, third-party personnel.

Summary

This post does not give a general procedure for depth of analysis decisions but it does outline important factors. Always start with the context to judge both impact and expected actions from threat actors. Use this to determine capabilities of the main threat actors. This will help you decide the granularity level of your assessment. The things that are outside of your control should also not be neglected by considered an uncertainty point that may influence the necessary security controls you need to put in place.

 

granularity
A sketch of key factors to include when deciding on the granularity for a cybersecurity risk assessment under IEC 61511

 

 

 

How can you defend your assets against distributed reflective attacks via DNS?

Håkon OlsenLeave a comment

DNS servers are necessary for finding resources on the internet. They are also a source of vulnerabilities, and are often poorly defended. The DNS protocol listens on port 53, and this port is therefore open in most firewalls. This combination of an open listening service and little security focus makes the protocol interesting to hackers; especially if they want to perform denial-of-service attacks, because they can use some of the features of DNS to amplify their attack vectors.

How DNS works

DNS servers are used on the internet to translate between human friendly domain names and IP addresses. DNS stands for Domain Name System, and is a database of IP addresses. For an overview of how DNS works, see this Microsoft Technet article: https://technet.microsoft.com/en-us/library/cc958978.aspx.

DNS usually receive a recursive name query from a web browser. One specific DNS server can only hold a limited amount of information. When a query is recursive it will query other DNS servers on the internet for the correct address lookup before returning the IP address to the client. The way this works is that when the web browser queries the DNS and the DNS doesn’t have the right information it gives a referral back as the result; the address of a DNS server further down the namespace tree.

Illustration of a recursive DNS lookup. The resolver queries the DNS server with a request.The DNS server cannot find the infromation requested in its cache or zone, and queries the root server. It is then referred to the domain DNS server, which again points to the Example domain DNS server.

Attacking through Recursive Open DNS

Using recursive DNS servers to flood a target with traffic is effective for attackers because the request package sent to the DNS server is very small compared with the response (hence the term “amplified” attack). All the attacker has to do, is to spoof the sender address of the DNS request package, and submit the spoofed package to open recursive DNS servers from a large number of machines under his or her control, and voila – a DoS condition occurs for the target because the DNS server will direct all those responses to the spoofed IP. So what you need to perform this attack is:

  • A list of open recursive DNS servers
  • A spoofed UDP request package to the DNS server
  • A botnet under your control

The first point of the list is easy enough – go to https://duckduckgo.com and search for ‘public dns’ and it will give you a list as an instant answer.

Spoofing the IP can be done using any library that can write IP headers (or you can craft the header manually…). Here’s an example using scapy, a Python module for low level network operations:

from scapy.all import *

spoofed_packet = IP(src='spoofed_ip', dst='the dns you are trying to reach') \
	/ TCP(sport=sourceport, dport=53) / payload

So, then you only need a botnet. You can go ahead and create one by spreading malware to thousands of victims, or you can hire a botnet on the dark web – both are equally illegal and immoral, but the bad guys do this.

Defending against this mess

Using an old-fashioned IP tables firewall won’t do the job because you cannot drop traffic on port 53 (this is your DNS traffic). The DNS server can be configured to mitigate some of these attacks – but the open public ones are outside of your control. Some of them have rate control, limiting the frequency with which they can be queried for the same target, as well as per source IP.

So what can you do locally to protect against this type of attacks?

  1. Ensure you have sufficient capacity to take peak traffic loads. It is probably infeasible to build capacity for very large DDoS attacks (~ 300 Gbps) but many attacks are much smaller than this and can be absorbed by high bandwidth capacity
  2. Filter your traffic – especially unexpected traffic types. Filter out all DNS traffic for all equipment not dependent on sending DNS requests. Filter out IP’s from identified botnets and use a robust threat intelligence solution to obtain information on botnets.
  3. Use anomaly detection and use dynamic throttling of traffic from name servers. If there are sudden spikes in traffic from unusual resolvers, it may be a sign of a reflective amplification attack.
  4. For key resources, build in redundancy to redirect traffic when necessary and allowing the service to remain operational. Potentially contract with a very-high-bandwidth provider to act as a buffer to large DDoS floods.