RPC over HTTP

[Jon-Erik]

I do a lot of work (unfortunately) with Windows 2003 servers. I've noticed that nmap returns ports 6000, 6002, and 6004 as X server ports, which, of course, they are on nix systems. But, on a 2k3 server the pattern of these three ports being open means an Exchange server has implemented RPC over HTTP, which is allegedly a safer way of having Outlook "just work" remotely.



Without any specific knowledge, I imagine this is a source of many potential vulnerabilities and so anyone hardening a 2k3 server will need to check for it, and, also, it's a pretty clear pattern in terms of OS detection.



Has that been addressed yet? (I'm new to the list)



_______________________________________________
No banners. No pop-ups. No kidding.
Make My Way your home on the Web - http://www.myway.com

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Martin Mačok]

Post by Jon-Erik
I do a lot of work (unfortunately) with Windows 2003 servers. I've
noticed that nmap returns ports 6000, 6002, and 6004 as X server
ports

Have you tried version scan (-sV) or just a pure portscan?

Martin Mačok
ICT Security Consultant

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Jon-Erik]

Here's the behind-the-firewall output from a -sV scan from version 3.81 on FreeBSD3.81



*SNIP*

2105/tcp open msrpc Microsoft Windows msrpc

3052/tcp open msrpc Microsoft Windows msrpc

3268/tcp open ldap Microsoft LDAP server

3269/tcp open ssl/ldap Microsoft LDAP server

3389/tcp open microsoft-rdp Microsoft Terminal Service (Windows 2000 Server)

5000/tcp open msrpc Microsoft Windows msrpc

5002/tcp open msrpc Microsoft Windows msrpc

6001/tcp open X11:1?

6002/tcp open X11:2?

6004/tcp open X11:4?

*SNIP*



Now, keep in mind there are about 100 open Microsoft ports on this that nmap identified that I didn't include. I don't know how the code is set up; whether it can adjust depending on what else pops up... anyway the above is defeinitely a 2k3 server.



Also, port 4125 is special for SBS--it's for a terminal server proxy that isn't apparently looked for.

Post by Martin Mačok

Post by Jon-Erik
I do a lot of work (unfortunately) with Windows 2003 servers. I've
noticed that nmap returns ports 6000, 6002, and 6004 as X server
ports

Have you tried version scan (-sV) or just a pure portscan?
Martin Ma�ok
ICT Security Consultant

_______________________________________________
No banners. No pop-ups. No kidding.
Make My Way your home on the Web - http://www.myway.com

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Martin Mačok]

Post by Jon-Erik
Here's the behind-the-firewall output from a -sV scan from version 3.81 on FreeBSD3.81
3389/tcp open microsoft-rdp Microsoft Terminal Service (Windows 2000 Server)

Could you run
$ grep "Microsoft Terminal Service" /usr/share/nmap/nmap-service-probes'
?

It seems to me that you have different copy of that file than the one
from nmap-3.81 distribution (I can't explain the "(Windows 2000
Server)" string otherwise).

Post by Jon-Erik
6001/tcp open X11:1?
6002/tcp open X11:2?
6004/tcp open X11:4?

When the version scan failes to identify the service then it can't do
much more than displaying the name of the well known port service which
is X11 for the 600x/tcp case (and not RPC). Take it as a *blind*
guess, or a hint if you want.

Could you post the SF: lines from the end of the output? Is it ncacn_*
service? If so, the attached patch should make the output a bit more
useful. Writing and contributing specialized DCE/RPC probes
for better identification would be nice too (hint!) ;-)

Martin Maèok
ICT Security Consultant

[Jon-Erik]

I was going to work on something if it hadn't been already addressed, so I just wanted to make sure that was correct. As for the build, I built it today from the source distro on insecure.org, v. 3.81. I'll post the full output below.



More information about RPC over HTTP can be found at http://www.msexchange.org/tutorials/outlookrpchttp.html



This is a realtively new thing, and, since it requires Outlook 2003 SP1, it may not be widely deployed. Yet. But since it is a form of RPC and it provides full MAPI access, and...er, it's from Microsoft, something tells me we'll be hearing about this sooner or later in a not so good way.





Beware: long text follows



------------------------------------------------------------

***@vidar.hrith.com:[ /usr/share ]18:12:22 > nmap -sV -v -v -O 24.180.0.170



Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-03-04 18:13 PST

Initiating SYN Stealth Scan against odin.hrith.com (24.180.0.170) [1663 ports] at 18:13

Discovered open port 443/tcp on 24.180.0.170

Discovered open port 636/tcp on 24.180.0.170

Discovered open port 3389/tcp on 24.180.0.170

Discovered open port 21/tcp on 24.180.0.170

Discovered open port 53/tcp on 24.180.0.170

Discovered open port 80/tcp on 24.180.0.170

Discovered open port 25/tcp on 24.180.0.170

Discovered open port 389/tcp on 24.180.0.170

Discovered open port 2105/tcp on 24.180.0.170

Discovered open port 1026/tcp on 24.180.0.170

Discovered open port 5000/tcp on 24.180.0.170

Discovered open port 593/tcp on 24.180.0.170

Discovered open port 9/tcp on 24.180.0.170

Discovered open port 3269/tcp on 24.180.0.170

Discovered open port 445/tcp on 24.180.0.170

Discovered open port 19/tcp on 24.180.0.170

Discovered open port 88/tcp on 24.180.0.170

Discovered open port 17/tcp on 24.180.0.170

Discovered open port 1025/tcp on 24.180.0.170

Discovered open port 3268/tcp on 24.180.0.170

Discovered open port 135/tcp on 24.180.0.170

Discovered open port 464/tcp on 24.180.0.170

Discovered open port 13/tcp on 24.180.0.170

Discovered open port 6004/tcp on 24.180.0.170

Discovered open port 6001/tcp on 24.180.0.170

Discovered open port 3052/tcp on 24.180.0.170

Discovered open port 6002/tcp on 24.180.0.170

Discovered open port 5002/tcp on 24.180.0.170

Discovered open port 139/tcp on 24.180.0.170

Discovered open port 7/tcp on 24.180.0.170

The SYN Stealth Scan took 3.22s to scan 1663 total ports.

Initiating service scan against 30 services on odin.hrith.com (24.180.0.170) at 18:13

Service scan Timing: About 60.00% done; ETC: 18:14 (0:00:30 remaining)

The service scan took 125.86s to scan 30 services on 1 host.

For OSScan assuming port 7 is open, 1 is closed, and neither are firewalled

For OSScan assuming port 7 is open, 1 is closed, and neither are firewalled

For OSScan assuming port 7 is open, 1 is closed, and neither are firewalled

Host odin.hrith.com (24.180.0.170) appears to be up ... good.

Interesting ports on odin.hrith.com (24.180.0.170):

(The 1631 ports scanned but not shown below are in state: closed)

PORT STATE SERVICE VERSION

7/tcp open echo

9/tcp open discard?

13/tcp open daytime Microsoft Windows USA daytime

17/tcp open qotd Windows qotd

19/tcp open chargen

21/tcp open ftp Microsoft ftpd

25/tcp open smtp Microsoft ESMTP 6.0.3790.211

53/tcp open domain Microsoft DNS

80/tcp open http Microsoft IIS webserver 6.0

88/tcp open kerberos-sec Microsoft Windows kerberos-sec

135/tcp open msrpc?

139/tcp open netbios-ssn

389/tcp open ldap Microsoft LDAP server

443/tcp open ssl/http Microsoft IIS webserver 6.0

445/tcp open microsoft-ds Microsoft Windows 2003 microsoft-ds

464/tcp open kpasswd5?

593/tcp open http-rpc-epmap?

636/tcp open ssl/ldap Microsoft LDAP server

1025/tcp open msrpc Microsoft Windows msrpc

1026/tcp open msrpc Microsoft Windows msrpc

1755/tcp filtered wms

2105/tcp open msrpc Microsoft Windows msrpc

3052/tcp open msrpc Microsoft Windows msrpc

3268/tcp open ldap Microsoft LDAP server

3269/tcp open ssl/ldap Microsoft LDAP server

3389/tcp open microsoft-rdp Microsoft Terminal Service

5000/tcp open msrpc Microsoft Windows msrpc

5002/tcp open msrpc Microsoft Windows msrpc

6001/tcp open X11:1?

6002/tcp open X11:2?

6004/tcp open X11:4?

7070/tcp filtered realserver

4 services unrecognized despite returning data. If you know the service/version, please submit the following fingerprints at http://www.insecure.org/cgi-bin/servicefp-submit.cgi :

==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============

SF-Port593-TCP:V=3.81%D=3/4%Time=422915C8%P=i386-unknown-freebsd5.3%r(NULL

SF:,E,"ncacn_http/1\.0")%r(GenericLines,E,"ncacn_http/1\.0")%r(GetRequest,

SF:E,"ncacn_http/1\.0")%r(HTTPOptions,E,"ncacn_http/1\.0")%r(RTSPRequest,E

SF:,"ncacn_http/1\.0")%r(RPCCheck,E,"ncacn_http/1\.0")%r(DNSVersionBindReq

SF:,E,"ncacn_http/1\.0")%r(DNSStatusRequest,E,"ncacn_http/1\.0")%r(Help,E,

SF:"ncacn_http/1\.0")%r(SSLSessionReq,E,"ncacn_http/1\.0")%r(SMBProgNeg,26

SF:,"ncacn_http/1\.0\x05\0\r\x03\x10\0\0\0\x18\0\0\0\0\x08\x01@\x04\0\x01\

SF:x05\0\0\0\0")%r(X11Probe,E,"ncacn_http/1\.0")%r(LPDString,E,"ncacn_http

SF:/1\.0")%r(LDAPBindReq,E,"ncacn_http/1\.0")%r(LANDesk-RC,E,"ncacn_http/1

SF:\.0")%r(TerminalServer,E,"ncacn_http/1\.0")%r(NCP,E,"ncacn_http/1\.0")%

SF:r(NotesRPC,E,"ncacn_http/1\.0")%r(WMSRequest,E,"ncacn_http/1\.0")%r(ora

SF:cle-tns,E,"ncacn_http/1\.0");

==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============

SF-Port6001-TCP:V=3.81%D=3/4%Time=422915F0%P=i386-unknown-freebsd5.3%r(NUL

SF:L,E,"ncacn_http/1\.0")%r(X11Probe,E,"ncacn_http/1\.0")%r(GenericLines,E

SF:,"ncacn_http/1\.0")%r(GetRequest,E,"ncacn_http/1\.0")%r(HTTPOptions,E,"

SF:ncacn_http/1\.0")%r(RTSPRequest,E,"ncacn_http/1\.0")%r(RPCCheck,E,"ncac

SF:n_http/1\.0")%r(DNSVersionBindReq,E,"ncacn_http/1\.0")%r(DNSStatusReque

SF:st,E,"ncacn_http/1\.0")%r(Help,E,"ncacn_http/1\.0")%r(SSLSessionReq,E,"

SF:ncacn_http/1\.0")%r(SMBProgNeg,26,"ncacn_http/1\.0\x05\0\r\x03\x10\0\0\

SF:0\x18\0\0\0\0\x08\x01@\x04\0\x01\x05\0\0\0\0")%r(LPDString,E,"ncacn_htt

SF:p/1\.0")%r(LDAPBindReq,E,"ncacn_http/1\.0")%r(LANDesk-RC,E,"ncacn_http/

SF:1\.0")%r(TerminalServer,E,"ncacn_http/1\.0")%r(NCP,E,"ncacn_http/1\.0")

SF:%r(NotesRPC,E,"ncacn_http/1\.0")%r(WMSRequest,E,"ncacn_http/1\.0")%r(or

SF:acle-tns,E,"ncacn_http/1\.0");

==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============

SF-Port6002-TCP:V=3.81%D=3/4%Time=422915F0%P=i386-unknown-freebsd5.3%r(NUL

SF:L,E,"ncacn_http/1\.0")%r(X11Probe,E,"ncacn_http/1\.0")%r(GenericLines,E

SF:,"ncacn_http/1\.0")%r(GetRequest,E,"ncacn_http/1\.0")%r(HTTPOptions,E,"

SF:ncacn_http/1\.0")%r(RTSPRequest,E,"ncacn_http/1\.0")%r(RPCCheck,E,"ncac

SF:n_http/1\.0")%r(DNSVersionBindReq,E,"ncacn_http/1\.0")%r(DNSStatusReque

SF:st,E,"ncacn_http/1\.0")%r(Help,E,"ncacn_http/1\.0")%r(SSLSessionReq,E,"

SF:ncacn_http/1\.0")%r(SMBProgNeg,26,"ncacn_http/1\.0\x05\0\r\x03\x10\0\0\

SF:0\x18\0\0\0\0\x08\x01@\x04\0\x01\x05\0\0\0\0")%r(LPDString,E,"ncacn_htt

SF:p/1\.0")%r(LDAPBindReq,E,"ncacn_http/1\.0")%r(LANDesk-RC,E,"ncacn_http/

SF:1\.0")%r(TerminalServer,E,"ncacn_http/1\.0")%r(NCP,E,"ncacn_http/1\.0")

SF:%r(NotesRPC,E,"ncacn_http/1\.0")%r(WMSRequest,E,"ncacn_http/1\.0")%r(or

SF:acle-tns,E,"ncacn_http/1\.0");

==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============

SF-Port6004-TCP:V=3.81%D=3/4%Time=422915F1%P=i386-unknown-freebsd5.3%r(NUL

SF:L,E,"ncacn_http/1\.0")%r(X11Probe,E,"ncacn_http/1\.0")%r(GenericLines,E

SF:,"ncacn_http/1\.0")%r(GetRequest,E,"ncacn_http/1\.0")%r(HTTPOptions,E,"

SF:ncacn_http/1\.0")%r(RTSPRequest,E,"ncacn_http/1\.0")%r(RPCCheck,E,"ncac

SF:n_http/1\.0")%r(DNSVersionBindReq,E,"ncacn_http/1\.0")%r(DNSStatusReque

SF:st,E,"ncacn_http/1\.0")%r(Help,E,"ncacn_http/1\.0")%r(SSLSessionReq,E,"

SF:ncacn_http/1\.0")%r(SMBProgNeg,26,"ncacn_http/1\.0\x05\0\r\x03\x10\0\0\

SF:0\x18\0\0\0\0\x08\x01@\x04\0\x01\x05\0\0\0\0")%r(LPDString,E,"ncacn_htt

SF:p/1\.0")%r(LDAPBindReq,E,"ncacn_http/1\.0")%r(LANDesk-RC,E,"ncacn_http/

SF:1\.0")%r(TerminalServer,E,"ncacn_http/1\.0")%r(NCP,E,"ncacn_http/1\.0")

SF:%r(NotesRPC,E,"ncacn_http/1\.0")%r(WMSRequest,E,"ncacn_http/1\.0")%r(or

SF:acle-tns,E,"ncacn_http/1\.0");

MAC Address: 00:11:95:1E:E0:6F (Alpha Networks)

No exact OS matches for host (If you know what OS is running on it, see http://www.insecure.org/cgi-bin/nmap-submit.cgi).

TCP/IP fingerprint:

SInfo(V=3.81%P=i386-unknown-freebsd5.3%D=3/4%Tm=42291649%O=7%C=1%M=001195)

TSeq(Class=TR%IPID=I%TS=0)

T1(Resp=Y%DF=N%W=4000%ACK=S++%Flags=AS%Ops=MNWNNT)

T2(Resp=N)

T3(Resp=N)

T4(Resp=N)

T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=)

T6(Resp=N)

T7(Resp=N)

PU(Resp=Y%DF=N%TOS=0%IPLEN=B0%RIPTL=148%RID=E%RIPCK=E%UCK=E%ULEN=134%DAT=E)





TCP Sequence Prediction: Class=truly random

Difficulty=9999999 (Good luck!)

TCP ISN Seq. Numbers: 8093B5CF 935EC84D 2CBFA739 44C2AECA 1420983D 84BEB014

IPID Sequence Generation: Incremental



Nmap finished: 1 IP address (1 host up) scanned in 143.060 seconds

Raw packets sent: 1728 (70.2KB) | Rcvd: 1691 (78.5KB)

***@vidar.hrith.com:[ /usr/share ]18:15:37 >



_______________________________________________
No banners. No pop-ups. No kidding.
Make My Way your home on the Web - http://www.myway.com

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Martin Mačok]

Post by Jon-Erik
More information about RPC over HTTP can be found at
http://www.msexchange.org/tutorials/outlookrpchttp.html

Not much of use from a developer's point of view. However, getting the
protocol spec is not the problem here, it is the time to read it and
implement it for version scan use :-)

Anyway, take a look at dcetest.nasl (GPLv2) Nessus plugin or the
original dcetest (GPL) from Dave Aitel ...

(By the way, the whole concept of RPC over HTTP seems rather silly to me
- first we realize that Microsoft's RPC protocols are insecure so we
set up our firewalls to block them in and out of our house ...
then Microsoft realizes we are blocking them so they start
tunneling it through http so they can traverse the net again - and
they even call it "security"! It also reminds me of the
virus/antivirus culture ;-)

Post by Jon-Erik
This is a realtively new thing

This MAPI might be new but the RPC over HTTP procol itself is not that
hot ...

Post by Jon-Erik
and, since it requires Outlook 2003 SP1, it may not be widely
deployed. Yet. But since it is a form of RPC and it provides full
MAPI access, and...er, it's from Microsoft, something tells me we'll
be hearing about this sooner or later in a not so good way.

I agree. However, the chance is there might also be even worse things
around by that time :-)

Post by Jon-Erik
3389/tcp open microsoft-rdp Microsoft Terminal Service

OK, this is correct now.

Post by Jon-Erik
==============NEXT SERVICE FINGERPRINT (SUBMIT INDIVIDUALLY)==============
SF-Port593-TCP:V=3.81%D=3/4%Time=422915C8%P=i386-unknown-freebsd5.3%r(NULL
SF:,E,"ncacn_http/1\.0")%r(GenericLines,E,"ncacn_http/1\.0")%r(GetRequest,
SF:E,"ncacn_http/1\.0")%r(HTTPOptions,E,"ncacn_http/1\.0")%r(RTSPRequest,E
SF:,"ncacn_http/1\.0")%r(RPCCheck,E,"ncacn_http/1\.0")%r(DNSVersionBindReq
SF:,E,"ncacn_http/1\.0")%r(DNSStatusRequest,E,"ncacn_http/1\.0")%r(Help,E,
SF:"ncacn_http/1\.0")%r(SSLSessionReq,E,"ncacn_http/1\.0")%r(SMBProgNeg,26
SF:x05\0\0\0\0")%r(X11Probe,E,"ncacn_http/1\.0")%r(LPDString,E,"ncacn_http
SF:/1\.0")%r(LDAPBindReq,E,"ncacn_http/1\.0")%r(LANDesk-RC,E,"ncacn_http/1
SF:\.0")%r(TerminalServer,E,"ncacn_http/1\.0")%r(NCP,E,"ncacn_http/1\.0")%
SF:r(NotesRPC,E,"ncacn_http/1\.0")%r(WMSRequest,E,"ncacn_http/1\.0")%r(ora
SF:cle-tns,E,"ncacn_http/1\.0");

[and so on]

As you can see, the current set of probes couldn't get anything more
than "ncacn_http/1.0" reponse so we can't tell which service is behind
it. You could use the patch I've sent previously to get at least
ncacn_http Microsoft Network Computing Architecture Connection-Oriented RPC Protocol
recognition (or something shorter if you prefer) before someone
implements something better.

Cheers,

Martin Mačok
ICT Security Consultant

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Alan Jones]

Post by Martin Mačok
(By the way, the whole concept of RPC over HTTP seems rather silly to me
- first we realize that Microsoft's RPC protocols are insecure so we
set up our firewalls to block them in and out of our house ...
then Microsoft realizes we are blocking them so they start
tunneling it through http so they can traverse the net again - and
they even call it "security"! It also reminds me of the
virus/antivirus culture ;-)

/>> This is a realtively new thing /

Post by Martin Mačok
This MAPI might be new but the RPC over HTTP procol itself is not that
hot ...

Ok I am confused about this. Are you saying that RPC over HTTP is not
really being pushed and implemented? Every MS Exchange person I talk to
these days has that as something they have recently done or are wanting
to do as soon as they get to Exchange 2003 and Outlook 2003 rolled out.

The Microsoft Reps also push RPC over HTTP as a way to get around
problems. "No more having to mess with VPN issues and teaching you end
users how to connect to the VPN just for e-mail".

This is not just where I work, but other places. People that claim to
be interested in security say it is a "filtered" when it goes though
HTTP so no worries. I am not sure I buy this, but don't have any
knowledge one way or another.

From a security perspective I really questioned RPC over HTTP when they
implemented it where I work. They challenged me to find any strong
information security issues with it. At the time of my search the only
articles of concern I could find all talked about theory and were before
Exchange 2003 was released so that did not really help much.

I think there could be some advantages detecting RPC over HTTP from both
a version detection perspective. You know the OS is Windows 2003 and the
Mail Server is Exchange 2003 or greater. It would be a much stronger
version number then saying it could be any Windows server all the way
back to NT. This would also be helpful from a scanning perspective if
there were some firm security holes in RPC over HTTP discovered so that
one could scan a range and say hey you need to fix this.

just my random rant after dealing with this in my own organization.

Alan






---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Martin Mačok]

Post by Alan Jones
Ok I am confused about this. Are you saying that RPC over HTTP is
not really being pushed and implemented?

No, I meant that while this MAPI might be a new thing, the ncacn_http
protocol itself is not so new. We surely agree on that it is being
widely deployed recently and that it might be another can of worms
waiting to be open (like my colleague said about MS RPC years before
we had troubles with RPC DCOM worms...)

Martin Mačok
ICT Security Consultant

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org

[Jon-Erik]

Ok I am confused about this. Are you saying that RPC over HTTP is not
really being pushed and implemented? Every MS Exchange person I talk to
these days has that as something they have recently done or are wanting
to do as soon as they get to Exchange 2003 and Outlook 2003 rolled out.

I don't know if you were responding to me or to a subsequent post, because it only shows me being quoted, but... For my part, I agree with this. They are pushing it hard, and the only reason it's not "hot" is because, as we've said, you have to have everyone up with Outlook 2003. But it will be.



You didn't have to mess with VPN issues in the past. I know they say that, but it's not true. There were a couple of ways to "publish" the MAPI and RPC services (ISA server being one of them) without using RPC over HTTP.



Anyway, I'm sure of two things. (1) There are plenty of people on this list who know way more than I do, but (2) there will come a point where this will be something that needs to be checked for, because I can almost guarantee a vulnerability will be found in it.



I'm happy to help to work on an addition for nmap. (=







_______________________________________________
No banners. No pop-ups. No kidding.
Make My Way your home on the Web - http://www.myway.com

---------------------------------------------------------------------
For help using this (nmap-dev) mailing list, send a blank email to
nmap-dev-***@insecure.org . List archive: http://seclists.org