Recently we detected return of reflection from 1434 port. The attack manifests in the form of Microsoft SQL Server responses to a client query or request via abuse of the Microsoft SQL Server Resolution Protocol (MC-SQLR), which listens on UDP port 1434.

MC-SQLR lets clients identify the database instance with which they are attempting to communicate when connecting to a database server or cluster with multiple database instances. Each time a client needs to obtain information on configured MS SQL servers on the network, the SQL Resolution Protocol can be used. The server responds to the client with a list of instances.

Attackers abuse SQL servers by executing scripted requests and spoofing the source of the query with the IP address of the intended target. Depending on the number of instances present in the abused SQL server, the amplification factor varies.

The attack presents a specific payload signature, producing an amplification factor of nearly 25x. In this case, the attacker’s request totaled 29 bytes, including IP and UDP headers, and triggered a response of 719 bytes including headers. Some servers may produce a larger or smaller response depending on their configuration.

Verification

In this section, we show how to check a host for an openly accessible service. All tests are performed using tools commonly included with standard Linux/Unix distributions. To verify the service is openly accessible from the Internet, the test should not be run on the host itself or the local network but instead from a different node on the Internet, for example a host on a cable/DSL line. In all examples, replace 95.141.xx.xx with the IP address of the host to check.

To check if an MSSQL browser service is openly accessible from the Internet, connect to the MS-SQL server using ‘netcat’ as follows:

$ netcat -u 95.141.xx.xx 1434
Then, press followed by .

An openly accessible MSSQL browser service will return a response like this:

ServerName;S16362421;InstanceName;MSSQLSERVER2012; IsClustered;No;Version;11.0.2100.60;tcp;49511;np; \S16462341pipeMSSQL$MSSQLSERVER2012sqlquery;;
Otherwise, there will be no response.

Solution

If the MSSQL browser service is not needed, disable it. Otherwise, restrict access to trusted clients, for example by blocking incoming connections to port 1434/udp on the firewall.

Microsoft recommends:
“The SQL Server Browser service lets users connect to instances of the Database Engine that are not listening on port 1433, without knowing the port number. To use SQL Server Browser, you must open UDP port 1434. To promote the most secure environment, leave the SQL Server Browser service stopped, and configure clients to connect using the port number.”
(https://msdn.microsoft.com/library/ms175043.aspx)

SeFlow DDoS Mitigation

If you’re a victim of this amplification you need to contact your provider to get protected because is volumetric DDoS and your uplink maybe will not be enough to absorb it.

SeFlow Customers are already protected, we block this kind of attacks on our backbone and you will not receive packets.

Kind Regards