File: 1886.txt

package info (click to toggle)
snort 2.9.7.0-5
  • links: PTS, VCS
  • area: main
  • in suites: buster, stretch
  • size: 55,000 kB
  • ctags: 38,464
  • sloc: ansic: 266,667; sh: 12,508; makefile: 2,908; yacc: 497; perl: 496; lex: 261; sed: 14
file content (69 lines) | stat: -rw-r--r-- 1,616 bytes parent folder | download | duplicates (8)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
Rule:


--
Sid: 

1886

-- 
Summary: 
This rule has been placed in deleted.rules

-- 
Impact: 

attacker might have gained an ability to execute commands remotely on the system.

--
Detailed Information:

This signature triggers when a UNIX "id" command is used to confirm
the user name of the currently logged in user over any unencrypted
connection. Such connection can be either a legitimate telnet
connection or a result of spawning a shell on FTP, POP3, SMTP or other
port as a consequence of network exploit. The string "uid=" and
"(apache)" is an output of an "id" command indicating that the user
has "apache" account privileges, typically used by the web server
process.  Seeing such a response indicates that some user connected
over the network to a target web server and likely exploited the web
server to launch a shell.

--
Attack Scenarios: 

a buffer overflow exploit against the WWW server
results in "/bin/sh" being executed. An automated script performing an
attack, checks for the success of the exploit via an "id" command.

-- 
Ease of Attack: 

this post-attack behavior can accompany different attacks

-- 
False Positives: 

the signature will trigger if a legitimate system administrator executes the "id" command over the telnet connection which uses one of the web ports, as defined in snort.conf

--
False Negatives: 

not known

-- 
Corrective Action: 

investigate the server for signs of compromise, run
the integrity checking software, look for other IDS alerts involving
the same IP addresses.

--
Contributors: 

Anton Chuvakin <anton@chuvakin.org>

-- 
Additional References:

--