Community discussions

MikroTik App
 
m4rk
newbie
Topic Author
Posts: 30
Joined: Fri Dec 15, 2017 8:02 pm

DNS resolution vulnerability

Tue Feb 05, 2019 11:34 am

Hi,

I'm contacting you because I've found a very big vulnerability with the lastest version of Mikrotik.
Practically I've seen that thousands of DNS requests were sent from my Mikrotik to the same domain "USADF.GOV".
Analyzing the issue, I've noticed that seems like the port 53 UDP (DNS Service) was open for the world, in this way every people are able to use my Public IP to resolve names, like a Public DNS Service.
I've found this problem also from other Customers.
The problem seems tied to the latest version of Mikrotik, have you already seen that issue?
Do you have a solution?

Waiting your reply I wish you a good day,

With best regards,
Marco
 
User avatar
Steveocee
Forum Guru
Forum Guru
Posts: 1120
Joined: Tue Jul 21, 2015 10:09 pm
Location: UK
Contact:

Re: DNS resolution vulnerability

Tue Feb 05, 2019 11:35 am

This just sounds like you didn't set up your firewall properly. Not a vulnerability.

If you enable DNS cacheing then the router will do it regardless, it is up to you then as the user to ensure that only requests you want answered are responded to. Usually a dro pUDP-53 rule from the WAN interface is enough.
 
User avatar
baragoon
Member Candidate
Member Candidate
Posts: 295
Joined: Thu Jan 05, 2017 10:38 am
Location: Kyiv, UA
Contact:

Re: DNS resolution vulnerability

Tue Feb 05, 2019 11:50 am

Do you have a solution?
lol
yes, close tcp and udp 53 from WAN side.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: DNS resolution vulnerability

Tue Feb 05, 2019 11:59 am

I'm contacting you because I've found a very big vulnerability with the lastest version of Mikrotik.
Practically I've seen that thousands of DNS requests were sent from my Mikrotik to the same domain "USADF.GOV".
Analyzing the issue, I've noticed that seems like the port 53 UDP (DNS Service) was open for the world, in this way every people are able to use my Public IP to resolve names, like a Public DNS Service.
I've found this problem also from other Customers.
The problem seems tied to the latest version of Mikrotik, have you already seen that issue?
It is a problem that you or a fellow admin have created yourself!
The default configuration of MikroTik routers does NOT have this problem.
However, when you have removed the firewall or made incorrect changes to it, it can happen (as with ANY router!).
When you have used very old RouterOS versions and have updated all the time without resetting the configuration, and especially when you use PPPoE to connect to internet, it is a good idea to reset to defaults because the default firewall is now more resistant to making incorrect changes.
However, it is very important that you use real information about how the firewall works when configuring it, NOT view some video on YouTube as a source of information!
Many videos there are made by beginners who just unpacked their first MikroTik and proudly announce how they did something, and are completely incorrect.
 
m4rk
newbie
Topic Author
Posts: 30
Joined: Fri Dec 15, 2017 8:02 pm

Re: DNS resolution vulnerability

Tue Feb 05, 2019 12:25 pm

Hi,

Thanks for your quick answers.

We have a lot of Customers that are using Mikrotik and we've found that issue only in the last months before that all worked properly and we've changed nothing.
We work also with a lot of Dealers in the world and they are Mikrotik programmers and they've still experienced that issues recently, without having made changes.

I'll check the rules and I'll ask them to do the same and I'll update you.

In the meanwhile thanks a lot for your help.
With best regards,

Marco
 
User avatar
sebastia
Forum Guru
Forum Guru
Posts: 1782
Joined: Tue Oct 12, 2010 3:23 am
Location: Antwerp, BE

Re: DNS resolution vulnerability

Tue Feb 05, 2019 12:33 pm

Which version of software are they running? There were some vulnerabilities published last year It's possible that these routers got exploited and opened to wide world.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10186
Joined: Mon Jun 08, 2015 12:09 pm

Re: DNS resolution vulnerability

Tue Feb 05, 2019 12:36 pm

We have a lot of Customers that are using Mikrotik and we've found that issue only in the last months before that all worked properly and we've changed nothing.
Are those routers managed by you or by the customers?
Can you show a /export of the configuration of one of them?
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: DNS resolution vulnerability

Tue Feb 05, 2019 6:35 pm

Concur, the logical conclusion is

a. current config is leaky and needs to be fixed.
b. current config is fine but leaky which leads one to conclude a potentially compromised firmware from past poorly done configs (and net install was not used to fix the issue).

Either way Marco, you have serious issues to deal with and not deflect.
 
alfred998
Frequent Visitor
Frequent Visitor
Posts: 76
Joined: Fri Apr 27, 2018 4:58 pm

Re: DNS resolution vulnerability

Fri Jul 31, 2020 3:35 am

Sorry but i have to concur with marko. Default config with drop 53 added :
0    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked 

 1    ;;; drop udp 53
      chain=input action=drop protocol=udp in-interface-list=WAN dst-port=53 

 2    ;;; drop tcp 53
      chain=input action=drop protocol=tcp in-interface-list=WAN dst-port=53
      
allow-remote-requests: no

nmap :
Discovered open port 53/udp on xx.xx.xx.xx
Discovered open|filtered port 53/udp on xxx-xx4.xxx-xx.org (xx.xx.xx.xx) is actually open
 
martinclaro
Frequent Visitor
Frequent Visitor
Posts: 95
Joined: Sat Sep 28, 2013 6:08 am
Location: Buenos Aires, Argentina
Contact:

Re: DNS resolution vulnerability

Fri Jul 31, 2020 4:55 am

Can you share an export of firewall settings (both filter and nat rules)? Maybe you are dst-nating dns queries from the wan side at nat rules, and allowing dstnated packets on the filter rules.

Is your wan interface added to the WAN interface-list?
Last edited by martinclaro on Fri Jul 31, 2020 5:09 am, edited 1 time in total.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 18958
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: DNS resolution vulnerability

Fri Jul 31, 2020 5:00 am

wrong bucko!
The default rules include this rule which stops that BS cold.
More likely the routers were compromised for other reasons and the above issue were just symptoms.

/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment=\
"defconf: accept to local loopback (for CAPsMAN)" dst-address=127.0.0.1
add action=drop chain=input comment="defconf: drop all not coming from LAN" \
in-interface-list=!LAN

add action=accept chain=forward comment="defconf: accept in ipsec policy" \
ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" \
ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" \
connection-state=established,related
add action=accept chain=forward comment=\
"defconf: accept established,related, untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=drop chain=forward comment=\
"defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat \
connection-state=new in-interface-list=WAN
 
User avatar
vecernik87
Forum Veteran
Forum Veteran
Posts: 882
Joined: Fri Nov 10, 2017 8:19 am

Re: DNS resolution vulnerability

Fri Jul 31, 2020 6:30 am

Sorry but i have to concur with marko. Default config with drop 53 added :
Default config contains universal drop rule. You shouldn't need those individual drop rules. If you need them, you are clearly missing some important part. (you or someone else likely deleted that)

To confirm original, unmodified defconf, please run
/system default-configuration print
Among many other lines, you should see following (exported from 6.47.1):
/ip firewall {
   filter add chain=input action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
   filter add chain=input action=drop connection-state=invalid comment="defconf: drop invalid"
   filter add chain=input action=accept protocol=icmp comment="defconf: accept ICMP"
   filter add chain=input action=accept dst-address=127.0.0.1 comment="defconf: accept to local loopback (for CAPsMAN)"
   filter add chain=input action=drop in-interface-list=!LAN comment="defconf: drop all not coming from LAN"
   filter add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
   filter add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
   filter add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack"
   filter add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related, untracked"
   filter add chain=forward action=drop connection-state=invalid comment="defconf: drop invalid"
   filter add chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN comment="defconf: drop all from WAN not DSTNATed"
 }
As you can see, on the 6th line (5th/last "input" rule), it drops everything from not-LAN. Afaik, this rule was always there.

If your default-configuration does not contain this, please post the WHOLE result of the command. Not just part of it.
If your default-configuration contains this, it is a proof that the critical rule got somehow removed from your running config. In that case I would strongly recommend to properly secure the router, or even completely reinstall it from scratch.
 
User avatar
Jotne
Forum Guru
Forum Guru
Posts: 3279
Joined: Sat Dec 24, 2016 11:17 am
Location: Magrathean

Re: DNS resolution vulnerability

Fri Jul 31, 2020 7:42 am

To all. Look at the date of the thread. For some reason alfred998 responded to a thread that is 1 1/2 year old. Where m4rk did not post his config. I guess he did see that and left the thread.
 
User avatar
vecernik87
Forum Veteran
Forum Veteran
Posts: 882
Joined: Fri Nov 10, 2017 8:19 am

Re: DNS resolution vulnerability

Fri Jul 31, 2020 8:27 am

*facepalm* silly me :D Always forget to check gravediggers
 
User avatar
jprietove
Trainer
Trainer
Posts: 212
Joined: Fri Jun 03, 2016 3:00 pm
Location: Cádiz, Spain
Contact:

Re: DNS resolution vulnerability

Fri Jul 31, 2020 11:09 am

I think you should read https://wiki.mikrotik.com/wiki/Manual:S ... our_Router

Specially DNS Caché Section. It explains everything you should consider before exposing your router to Internet.

Who is online

Users browsing this forum: Bing [Bot], holvoetn, karlisi and 85 guests