7

If you install wireshark on a web server sitting in the DMZ, is there a hack that can be used to get backdoor entrace to that server even when RDP is disblaed? I'm trying to monitor the wire on the DMZ web server but getting pushback from the DMZ team that it opens up a back door hack without a lot of details

chmeee
  • 7,370
  • 3
  • 30
  • 43
G33kKahuna
  • 289
  • 1
  • 4
  • 10

6 Answers6

12

A proper DMZ will isolate hosts on the DMZ from each-other in addition to managing access between the hosts and the internet / internal network. The DMZ environment provides for a single choke-point to enforce security and access policies, and provides one single point to monitor traffic into, out of, and within the DMZ.

A DMZ isn't just a network that has access to the internet and the internal network. That's called a security risk and poor planning.

There are potential buffer overruns and security risks with any application that is taking data from uncontrolled sources, especially if the application is running with root / superuser privileges. This is true of wireshark, this is true of sendmail, IIS, true of anything.

To my knowledge, there aren't any "RDP back doors" in wireshark.

My point is "So what if it does open a back-door?"

A proper DMZ should

  1. prevent that compromised system from interacting with anything else except in the predefined manner (DNS to the DNS server, ftp to the FTP server, http to the http server, but no ssh to anything, no rdp from anything to anything, etc)
  2. Identify that improper traffic is attempting to take place (I just got an alert that the SQL server is getting RDP / VNC traffic from the FTP server!)
  3. Be easy to use for everyone else in the enterprise. If the DMZ properly enforces security, it is safer to put "dangerous" things there than in the enterprise network. Would the DMZ team rather have a back-door into the enterprise network or into the DMZ? The answer should be "DMZ, because we monitor and restrict traffic into and out of the DMZ."
chris
  • 11,944
  • 6
  • 42
  • 51
  • 1
    +1 for explaining the true essence of a DMZ which is grossly overlooked in practice – squillman Jun 12 '10 at 14:47
  • 1
    +1 - I'm in total agreement with squillman re: common DMZ practices. I've run into a goodly number of DMZs that fit the bill of "a routed IP subnet separate from the LAN, but with unrestricted access to the LAN and the Internet, hanging off a dedicated interface on a firewall". >sigh – Evan Anderson Jun 12 '10 at 14:51
  • @chris: I disagree with definition of DMZ here. Generally, the DMZ (De-Militarized Zone) is a subnet with UNFILTERED access to/from the INTERNET. Hence the term. Traffic from DMZ to internal network would be filtered. That doesn't mean to/from the Internet wouldn't be monitored, just not filtered. Hosts on a DMZ are typically hardened because they need to defend themselves. The scenario you are describing (protecting each DMZ host from every other DMZ host) is NOT what I'd expect in the typical DMZ. Sounds more like access control between VLANs to me. – oz10 Jun 17 '10 at 15:13
  • @Evan Anderson: DMZ should not have unfiltered access to the secure internal network... all traffic in the secure internal network should be filtered coming and going according to the principle of least privilege. – oz10 Jun 17 '10 at 15:15
  • @ceretullis: I was expressing my frustration at how many DMZ networks have unfiltered access to the secure LAN, like squillnan observed. Too many DMZ's are really just little secure LAN subnets hanging off of a dedicated firewall interface instead of actually having good filtering rules. FWIW, I would still filter access from / to the Internet into a DMZ. Another layer of security doesn't hurt. – Evan Anderson Jun 17 '10 at 18:12
  • @Evan Anderson: by definition, a DMZ has no filtering to/from the Internet. You can have subnets that are isolated from the secure internal network and have filtered internet access (a good and useful thing), but it is not technically correct (IMHO) to call them DMZs. – oz10 Jun 18 '10 at 15:23
  • @ceretullis: By *your* definition. Sure-- let's argue semantics, then. Can you give me an RFC on your definition? I don't think putting some filtering rules on a DMZ subnet makes it "not a DMZ" if it's otherwise fulfilling the purposes of being a DMZ. Personally, I don't think *any* production hosts in corporate networks should be connected to the Internet except behind a dedicated firewall performing egress filtering and stateful packet inspection. I don't want my "DMZ" subnet being a launching point for attacks against other networks, and filtering outbound traffic helps prevent that. – Evan Anderson Jun 18 '10 at 17:37
  • @Evan Anderson: "... I don't think any production hosts in corporate networks should be connected to the Internet except behind a dedicated firewall performing egress filtering and stateful packet inspection." I never suggested you *should* put production hosts in a DMZ. Indeed I think they should be in an isolated LAN with ingress/egress filtering from internal LAN & Internet. The only thing I've ever deployed to a DMZ is a hardened bastion host used for penetration testing clients' networks. Traditionally DMZ has meant the perimeter network between your border router and your firewall. – oz10 Jun 21 '10 at 19:57
5

I'm not completely in agreement with the DMZ descriptions described above. The security professionals who operate the DMZ probably have "paranoid" in their job descriptions and the DMZ is a "production" space, so see it from their point.

Many of the vulnerabilities cited occur due to flaws in packet dissectors, which are only used during the interactive rendering of traces. This interactive access does not require the same elevated privileges required for packet capture.

Since what you seem to need this for is analyzing local packet capture from the web server, why not separate the functions? Run packet capture on one host, and do the analysis (keeping the dissectors up to date, etc) from another, more restricted, non-production segment after retrieving the trace files.

See

Wireshark Security: http://wiki.wireshark.org/Security

Platform-Specific information about capture privileges: http://wiki.wireshark.org/CaptureSetup/CapturePrivileges

and implement the practices described there.

medina
  • 1,970
  • 10
  • 7
3

Wireshark doesn't offer any networking service and doesn't open any port on the system it's running on, so this just doesn't make sense. Having it installed on a system doesn't pose any security threat on its own.

The only potential risk here is, if someone manages to take control of that server, he can use Wireshark to examine network traffic in the DMZ. But, if someone takes full control of your server, he could also install any program he wants on it... so not having it installed wouldn't stop him from installing it, if he wants to.

I really can't see any problem in installing it on a server.

Massimo
  • 70,200
  • 57
  • 200
  • 323
1

Wireshark has suffered from its fair share of remote compromise vulnerabilities [CVE-2010-1455, CVE-2010-0304, CVE-2009-4377 + 8, CVE-2009-4376] (CVE lists hundreds). As anyone whose gone to Defcon or the Blackhat security conventions knows, Running any sort of packet sniffing software is wildly dangerous if you're in a secure environment. I'd guess that practically every Security Metrics book published in the last few years would strongly recommend against it.

That said, a proper DMZ would prevent an attacker from gaining any leverage anyway, however, you need to weigh the potential of your IDS or routing control software of choice to be compromised with the usefulness of running WS.

zetavolt
  • 1,352
  • 1
  • 8
  • 12
  • Zephyr, thanks. Most of the CVE lists buffer overruns and DOS, which happens even with IIS/ apache running in the DMZ. I've researched some of the CVE's and they dont list any back door just DOS due to buffer overruns. I have to agree with Massimo below wireshark listens to a service but doesn't have a service to allow access to a specific port. As a test I stopped IIS running on port 80 while wireshark running listening to port 80, launched an online port scanner to scan for port 80. It returned as blocked. I'm letting the scanner run on all ports just in case – G33kKahuna Jun 12 '10 at 18:07
  • Any buffer overrun type attack that causes a program to crash may also possibly be exploited to give access to the system. It isn't easy, or always possible, but if you can cause a program to crash, beware that someone else can probably cause the program to run a program you don't want it to run. – chris Jun 12 '10 at 23:28
  • Keep in mind, Due to the nature of Wireshark, many of the dangerous bugs are not buffer overflows (Which are fairly easily mitigated in the modern world), but are rather parsing errors like use-after-free attacks or Invalid pointers exploitable through heap spraying (Of course instead of spraying the heap with Javascript as you would with other client side attacks like web browsers, You would do so with network traffic) – zetavolt Jun 12 '10 at 23:51
1

First up, I'm of the opinion that anything extraneous installed on any machine in the DMZ is a potential security risk. I work on the principle that anything in the DMZ is a target and has been placed there to try and minimise risk through isolation. Such machine should be treated as if it can be expected to be compromised.

Despite the foregoing, while Wireshark could potentially be used to watch the traffic in the DMZ the reality is that in order to use it the machine must already be compsomised, which means the perpetrator could just as easily install it themselves if they wanted to. By having it already installed you might at worst be saving them a few seconds of time.

John Gardeniers
  • 27,458
  • 12
  • 55
  • 109
1

Wireshark has had plenty of vulnerabilities in the past, and will likely continue to have more discovered in the future. They usually lie in the protocol analyzers. If an attacker sends specially crafted packets, wireshark could have a buffer overflow while analyzing those packets and execute arbitrary code. (So RDP is irrelevant). Try using a simpler sniffer like tcpdump and just analyze the pcap files elsewhere. (Why do you really need Wireshark's GUI anyway if you're not RDPing into the box?) Another thing to keep in mind is that depending on what this webserver does, sniffing the traffic may reveal info you're not supposed to have.

PopularIsn'tRight
  • 141
  • 3