Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Moving sideward from the specific case of Microsoft's RPC-over-HTTPS to the
case of XML-over-HTTPS used for Web Services, here are some thoughts from
the "Web Services Security" world:
I find that people start from a standpoint of thinking "firewalls are
oblivious to XML" but then realize that a far more frightening issue is that
"firewalls are oblivious to any encrypted data that's being sent over
HTTPS", i.e. exactly what's being discussed here. And the SSL issue must be
addressed before you look for threats inside the XML. The knee-jerk solution
is usually to terminate the SSL at an "XML Firewall" and then ignore the
security from the "XML Firewall" to the endpoint which is consuming the XML.
This creates a "last mile" problem and obviously does not block an attacker
who simply who do not go through the "XML Firewall". It also means storing
policies out in the DMZ, and synching them up between many "XML Firewall"
instances, if you have more than one.
As I see it, there are two architectural solutions to this problem.
Option One is to terminate the SSL at the "XML Firewall" and then, following
authentication and content-inspection of the XML, to insert a security token
into the XML which identifies the client which you've just authenticated.
The XML, plus the embedded security token identifying the authenticated
client, is then passed to the endpoint. SAML and WS-Security are perfect for
this, or else you can put the client identity (e.g. Distinguished Name) into
a HTTP header as many load-balancers/SSL-terminators do today. SSL is then
used to encrypt the connection from the "XML Firewall" to the "Web Service"
endpoint itself. At the endpoint, you can the native capabilities of the Web
Services platform to consume the security token, or you can embed an "Agent"
in there to validate (check the integrity) and verify (check the trust) the
security token against a central "Security Server" that acts as a Policy
Decision Point (as in RFC 2753).
Option Two is to not put an "XML Firewall" in place and to just embed the
"Agent" after the SSL terminator takes place at the Web Services endpoint
itself. In this case, you are relying on your existing network firewall to
detect and block traditional "flooding" DoS attacks from reaching the Web
Services endpoint, and the "Agent" is taking care of the XML validation (is
it the right format and does it contain threats?) and verification (do we
trust the sender?) by connecting to a central "Security Server" which does
the policy decision making (RFC 2753 again). The "Agents" may be on machines
which are in the line of fire in the DMZ, but the Security Server should not
be, and should be on a non-routable subnet behind NAT.
I've written about this in this Java Pro article ("Architecting Security for
Web Services")
http://www.ftponline.com/javapro/2003_08/magazine/features/moneill/
And in this book ("Web Services Security")
http://www.amazon.com/exec/obidos/tg/detail/-/0072224711
A bit of full-disclosure now: I'm from a vendor (Vordel) which has software
which implements the above functionality (XML Firewall and XML Security
Server with Agents) but I hope that the principles are generic enough to
apply outside of our own customers.
-Mark
Mark O'Neill
CTO, Vordel
www.vordel.com
weblog: http://radio.weblogs.com/0111797/
- Entrust adds Vordel XML security products to its portfolio
http://www.vordel.com/news/press/04_09_02.html
- Vordel and RSA Security partner for XML security
http://www.vordel.com/news/press/04_07_20.html
On Tue, 26 Oct 2004 16:47:21 +0100, Airey, John <[EMAIL PROTECTED]>
wrote:
> Therefore my point still stands that if someone does possess a
mathematical solution
to the above, then all bets are off.
> (Whoever it was who disagreed about my statements on encryption, please
remember the
context of the thread is about SSL security, not one-time keys).
Agreed. Current SSL standards rely on public key encryption methods
which obtain their strength from the difficulty of the factoring
problem.
> Getting back to the original question, you can't discover if someone is
sending
RPC over https unless you have a solution to the RSA hard problem above. Nor
is it a major
security issue if someone is using RPC over https either, unless there are
flaws in the
implementation of SSL or RPC that could be exploited by someone else.
Yes -- however, there are workarounds.
If you control one end point or the other, then you can take steps to
permit examination of the contents of SSL sessions.
Server:
If you control the server, you can of course load the keys into the
sniffer (risky, but not unheard of, see
http://www.radware.com/content/products/ct100/default.asp)) or
terminate the SSL session on a device under your control. (For an
RPC-over-HTTP example, see this document:
http://www.msexchange.org/pages/article_p.asp?id=613)
Client:
If you control the client (say a corporate desktop PC), you have
another option -- you can modify the clients list o
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
On Tue, 26 Oct 2004 16:47:21 +0100, Airey, John <[EMAIL PROTECTED]> wrote: > Therefore my point still stands that if someone does possess a mathematical solution > to the above, then all bets are off. > (Whoever it was who disagreed about my statements on encryption, please remember the > context of the thread is about SSL security, not one-time keys). Agreed. Current SSL standards rely on public key encryption methods which obtain their strength from the difficulty of the factoring problem. > Getting back to the original question, you can't discover if someone is sending RPC > over https unless you have a solution to the RSA hard problem above. Nor is it a > major security issue if someone is using RPC over https either, unless there are > flaws in the implementation of SSL or RPC that could be exploited by someone else. Yes -- however, there are workarounds. If you control one end point or the other, then you can take steps to permit examination of the contents of SSL sessions. Server: If you control the server, you can of course load the keys into the sniffer (risky, but not unheard of, see http://www.radware.com/content/products/ct100/default.asp)) or terminate the SSL session on a device under your control. (For an RPC-over-HTTP example, see this document: http://www.msexchange.org/pages/article_p.asp?id=613) Client: If you control the client (say a corporate desktop PC), you have another option -- you can modify the clients list of trusted CAs, and force the client to establish the SSL session to your proxy server. This gives the proxy an opportunity to inspect/log/modify the cleartext contents of the session. The proxy establishes it's own SSL session to the remote server normally neither the client or server would be aware of the MITM. A freeware implementation of this MITM approach was "Achilles", I have also seen at least one commercial product offering this functionality to permit content-scanning of outbound HTTPS browser traffic. Kevin Kadow ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
> -Original Message- > From: Kyle Maxwell [mailto:[EMAIL PROTECTED] > Sent: 25 October 2004 04:30 > To: Airey, John > Cc: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Possibly a stupid question RPC > over HTTP > >[snip] > > You're talking about solving a problem that DOESN'T EXIST BY > DEFINITION. Re-read my response -- this time without being stupid -- > and you'll see that I was trying to explain to you that the problem is > the general factoring of large numbers (into primes for what should be > obvious reasons). This is NOT the same as factoring large primes as > that's a solved problem. If this is still difficult to understand, any > handy grade-school maths book should provide additional explanation. > Testing for primality, which is a related but different problem, is > solved, but proving that a number is composite is unfortunately not > the same as knowing its factors. > > > As to the question of whether this is a solved problem: we may have to > agree to disagree; if it were the NSA, given their past interactions > with the crypto community, I think it likely that they'd have over > time moved to another type of cryptography. BTW, brute forcing a key > does not break the system -- and as others have shown in this thread, > it's impossible to precompute all the keys unless you've broken every > single PRNG out there, and that's even less likely. What is it with this list that people can't reply without being rude? Is it the phase of the moon or something? OK, so we can rule out brute force, as storing every prime that's possible with 512bit keys isn't possible in this universe. Anyway, to quote RSA Laboratories: "The RSA algorithm works as follows: take two large primes, p and q, and compute their product n = pq; n is called the modulus. Choose a number, e, less than n and relatively prime to (p-1)(q-1), which means e and (p-1)(q-1) have no common factors except 1. Find another number d such that (ed - 1) is divisible by (p-1)(q-1). The values e and d are called the public and private exponents, respectively. The public key is the pair (n, e); the private key is (n, d). The factors p and q may be destroyed or kept with the private key. It is currently difficult to obtain the private key d from the public key (n, e). However if one could factor n into p and q, then one could obtain the private key d. Thus the security of the RSA system is based on the assumption that factoring is difficult" (http://www.rsasecurity.com/rsalabs/node.asp?id=2214) Therefore my point still stands that if someone does possess a mathematical solution to the above, then all bets are off. (Whoever it was who disagreed about my statements on encryption, please remember the context of the thread is about SSL security, not one-time keys). Getting back to the original question, you can't discover if someone is sending RPC over https unless you have a solution to the RSA hard problem above. Nor is it a major security issue if someone is using RPC over https either, unless there are flaws in the implementation of SSL or RPC that could be exploited by someone else. This is my last post on the matter which is solely for the purpose of making at least one post in this thread sensible and useful for future readers of the archive. All future abusive emails on my mathematical abilities will be deleted without response. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Tag line temporarily removed due to several people being unable and/or unwilling to comprehend what I'm talking about. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
On Fri, 22 Oct 2004 14:50:23 +0100, Airey, John <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Kyle Maxwell [mailto:[EMAIL PROTECTED] ] > > I think you may mean something slightly differently; given any large > > prime p, I can factor it completely extremely quickly: > > > > p = 1 * p > > > > There are no other factors; this *is* the prime factorization. :) Bill > > Oh no, the whole security of computing has just fallen over, since you've shown that > primes don't exist. What next, proving that black is white and getting run over on a > zebra crossing? > > A prime is defined as being divisible by itself and 1 only, so for the purpose of > the definition, 1 is not a factor. I was trying to give you the benefit of the doubt in my explanation, but your response makes it clear that you're not thinking straight. By your (almost correct) definition of prime, the factorization is trivial! And yes, 1 is a factor. If you can break the prime into ANY other factors, then it's NOT a prime. You're talking about solving a problem that DOESN'T EXIST BY DEFINITION. Re-read my response -- this time without being stupid -- and you'll see that I was trying to explain to you that the problem is the general factoring of large numbers (into primes for what should be obvious reasons). This is NOT the same as factoring large primes as that's a solved problem. If this is still difficult to understand, any handy grade-school maths book should provide additional explanation. Testing for primality, which is a related but different problem, is solved, but proving that a number is composite is unfortunately not the same as knowing its factors. As to the question of whether this is a solved problem: we may have to agree to disagree; if it were the NSA, given their past interactions with the crypto community, I think it likely that they'd have over time moved to another type of cryptography. BTW, brute forcing a key does not break the system -- and as others have shown in this thread, it's impossible to precompute all the keys unless you've broken every single PRNG out there, and that's even less likely. -- Kyle Maxwell [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
On 22 Oct 2004, at 06:50, Airey, John wrote: On Thu, 21 Oct 2004 13:21:10 +0100, Airey, John <[EMAIL PROTECTED]> wrote: This gives you two options. One, use brute force to break the SSL encryption. Two (and it's entirely possible that the security services have this already) come up with a mathematical way to factor large primes rapidly. I think you may mean something slightly differently; given any large prime p, I can factor it completely extremely quickly: p = 1 * p There are no other factors; this *is* the prime factorization. :) Bill Gates made the same mistake in his book _The Road Ahead_. Factoring large primes is trivial; the prime factorization of large numbers is hard, and I guess that's what you meant. The whole security of encryption rests on the belief that prime factorization isn't possible in a reasonable time, and it may well have been solved. Need we tell you again? READ THE DEFINITION OF A PRIME NUMBER. Here's a site with a good definition: http://mathworld.wolfram.com/PrimeNumber.html A prime number, BY DEFINITION, cannot be factored. Factoring products of large primes - for example, 8732977253934620914004266951938806186093326019599 - is believed to be a Hard problem, and that's what RSA is based on. (The factorization is at the bottom of this message.) Why would any government admit that it had cracked RSA security and its derivates? It wouldn't. Partially because: - Governments use RSA too. - Businesses use RSA as well. Declaring RSA broken would kill e-commerce overnight. I realise that we are getting into the realms of conspiracy theories now, however history shows that the UK did not wish it to be made public during the war that it had cracked the Enigma code. Why should it be any different now? Because we aren't at war with Rivest, Shamir, and Adleman? A prime is defined as being divisible by itself and 1 only, so for the purpose of the definition, 1 is not a factor. Okay, so you do remember your elementary school math. So explain how "prime factorization" is possible, then. Even if Embryonic Stem Cell Research yielded medical treatments, how could enough eggs be obtained to make them viable? We can't even get enough organs for transplant donation. Easily. Eggs are much easier to obtain than organs. Since you scrolled down to see it: Mathematica factors 8732977253934620914004266951938806186093326019599 to 2925219829459042790944067 * 2985408879697632628675397 in about 2 minutes. PGP.sig Description: This is a digitally signed message part
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
> -Original Message- > From: Kyle Maxwell [mailto:[EMAIL PROTECTED] > Sent: 21 October 2004 17:57 > To: Airey, John > Cc: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Possibly a stupid question RPC > over HTTP > > > On Thu, 21 Oct 2004 13:21:10 +0100, Airey, John > <[EMAIL PROTECTED]> wrote: > > This gives you two options. One, use brute force to break > the SSL encryption. Two (and it's entirely possible that the > security services have this already) come up with a > mathematical way to factor large primes rapidly. > > I think you may mean something slightly differently; given any large > prime p, I can factor it completely extremely quickly: > > p = 1 * p > > There are no other factors; this *is* the prime factorization. :) Bill > Gates made the same mistake in his book _The Road Ahead_. Factoring > large primes is trivial; the prime factorization of large numbers is > hard, and I guess that's what you meant. > > And if the problem of factoring large numbers into primes was indeed > solved (this is probably what you meant), I think you'd very quickly > see a complete replacement of crypto systems in use today by the > governments with such security services. > -- > Kyle Maxwell > [EMAIL PROTECTED] > Oh no, the whole security of computing has just fallen over, since you've shown that primes don't exist. What next, proving that black is white and getting run over on a zebra crossing? The whole security of encryption rests on the belief that prime factorization isn't possible in a reasonable time, and it may well have been solved. Why would any government admit that it had cracked RSA security and its derivates? I realise that we are getting into the realms of conspiracy theories now, however history shows that the UK did not wish it to be made public during the war that it had cracked the Enigma code. Why should it be any different now? A prime is defined as being divisible by itself and 1 only, so for the purpose of the definition, 1 is not a factor. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Even if Embryonic Stem Cell Research yielded medical treatments, how could enough eggs be obtained to make them viable? We can't even get enough organs for transplant donation. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
On Thu, 21 Oct 2004 13:21:10 +0100, Airey, John <[EMAIL PROTECTED]> wrote: > This gives you two options. One, use brute force to break the SSL encryption. Two > (and it's entirely possible that the security services have this already) come up > with a mathematical way to factor large primes rapidly. I think you may mean something slightly differently; given any large prime p, I can factor it completely extremely quickly: p = 1 * p There are no other factors; this *is* the prime factorization. :) Bill Gates made the same mistake in his book _The Road Ahead_. Factoring large primes is trivial; the prime factorization of large numbers is hard, and I guess that's what you meant. And if the problem of factoring large numbers into primes was indeed solved (this is probably what you meant), I think you'd very quickly see a complete replacement of crypto systems in use today by the governments with such security services. -- Kyle Maxwell [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Burnes, > James > Sent: 14 October 2004 17:42 > To: ASB; [EMAIL PROTECTED] > Subject: RE: [Full-Disclosure] Possibly a stupid question RPC > over HTTP > > > Welcome the wonderful wide world of "web services". The gleeful > tunneling through https and http of non REST information. > This has been > an issue for, how many years now? > > Get yourself a SOAP/XML sniffer. I believe one of the XML firewall > suppliers gives this out for free. > Time to end the ignorant suggestions. First of all, yes it would be possible to block RPC over http. However, if the traffic is going out through https, you can't. Before ANY data is exchanged over https, a handshake takes place to determine what level of encryption is used. Now I know that lots of browsers don't show the padlock before you send a username and password to an SSL protected site, but that data is still encrypted (hint - if you have any sites that are private to your company that your users need to access from outside, protect with SSL and password prompt first. If it's hacked you can demonstrate it was a private system). Once a connection is established via SSL to any site, all you can see is encrypted packets between you and that site. Blocking individual sites is always a possibility. This gives you two options. One, use brute force to break the SSL encryption. Two (and it's entirely possible that the security services have this already) come up with a mathematical way to factor large primes rapidly. I cannot believe that no-one has pointed this out yet. -- John Airey, BSc (Jt Hons), CNA, RHCE Internet systems support officer, ITCSD, Royal National Institute of the Blind, Bakewell Road, Peterborough PE2 6XU, Tel.: +44 (0) 1733 375299 Fax: +44 (0) 1733 370848 [EMAIL PROTECTED] Even if Embryonic Stem Cell Research yielded medical treatments, how could enough eggs be obtained to make them viable? We can't even get enough organs for transplant donation. -- DISCLAIMER: NOTICE: The information contained in this email and any attachments is confidential and may be privileged. If you are not the intended recipient you should not use, disclose, distribute or copy any of the content of it or of any attachment; you are requested to notify the sender immediately of your receipt of the email and then to delete it and any attachments from your system. RNIB endeavours to ensure that emails and any attachments generated by its staff are free from viruses or other contaminants. However, it cannot accept any responsibility for any such which are transmitted. We therefore recommend you scan all attachments. Please note that the statements and views expressed in this email and any attachments are those of the author and do not necessarily represent those of RNIB. RNIB Registered Charity Number: 226227 Website: http://www.rnib.org.uk ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Welcome the wonderful wide world of "web services". The gleeful tunneling through https and http of non REST information. This has been an issue for, how many years now? Get yourself a SOAP/XML sniffer. I believe one of the XML firewall suppliers gives this out for free. jb -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ASB Sent: Wednesday, October 13, 2004 2:45 PM To: [EMAIL PROTECTED] Subject: Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP You need protocol level inspection (i.e. beyond SPI) if you're going to monitor that kind of traffic. Also, the support for RPC over HTTP (should really be HTTPS) is not as open ended as you might fear. Look at the following: http://www.google.com/search?q=RPC%20over%20HTTPS%20implement - ASB Cheap, Fast, Secure -- Pick Any TWO. http://www.ultratech-llc.com/KB/ On Tue, 12 Oct 2004 12:41:56 -0700, Daniel Sichel <[EMAIL PROTECTED]> wrote: > This may just reflect my ignorance, but I read (and found hard to > believe) that Microsoft has implemented RPC over HTTP. Is this not a > HUGE security hole? If I understand it correctly it means that good old > HTML or XML can invoke a process using standard web traffic (port 80)? > Is there any permission checking done? what things can be invoked by RPC > over HTTP? Jeeze, to me it looks like the barn door is now wide open. Am > I right, and if so, how can I detect RPCs in web traffic to block this > junk? Can ANY stateful packet filter see this stuff or is the pattern > too broad in allowed RPCs? > > Again, I hope this is not a stupid question or inappropriate format for > this, as somebody else recently said, there is already enough noise on > this list. I would hate to see this list degenerate, it has been REALLY > valuable to me as a network engineer on occaison. > > Thanks all, > Dan Sichel > Ponderosa telephone > [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Barry Fitzgerald wrote: > Daniel H. Renner wrote: > >> Daniel, >> >> Could you please point out where you read this data? I would like to >> see this one... >> >> > > I seem to remember that this was one of the caveats with regard to > MSBlast and RPC/DCOM vulnerabilities last year. > > In certain configurations, it was theoretically possible (I'd never > personally seen any PoC code or worms that exploited it, though) that > some RPC calls could be made via RPC over HTML. According to the more than theoretically posibly... u can chek that with the DCE/RPC endpoint dumper program that is part of the impacket python package: http://oss.coresecurity.com/projects/impacket.html http://oss.coresecurity.com/impacket/rpcdump.py ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
I recall Todd from bindview talking about this in one of his advisories...that it was possible in IIS, but had to be explicitly switched on. And also in one of the blackhat (rm) archive methinks. http://www.securityfocus.com/archive/1/329668 > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Rodrigo Barbosa > Sent: Thursday, 14 October 2004 6:05 AM > To: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Possibly a stupid question RPC > over HTTP > > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > This is called, in my experience, XML-RPC (google search with lots > of results). Reference: http://www.xmlrpc.com/spec > > Yes, it is a Remote Procedure Calling implementation. No, it is not > the same things that the good old udp based RPC used for things > like NIS and NFS. References: RFC 1057 and RFC 1831. > > That can be the source of confusion. Akin names. > > On Wed, Oct 13, 2004 at 11:37:12AM -0400, Daniel H. Renner wrote: > > Daniel, > > > > Could you please point out where you read this data? I > would like to > > see this one... > > > This may just reflect my ignorance, but I read (and found hard to > > > believe) that Microsoft has implemented RPC over HTTP. Is > this not a > > > HUGE security hole? If I understand it correctly it means > that good old > > > HTML or XML can invoke a process using standard web > traffic (port 80)? > > > Is there any permission checking done? what things can be > invoked by RPC > > > over HTTP? Jeeze, to me it looks like the barn door is > now wide open. Am > > > I right, and if so, how can I detect RPCs in web traffic > to block this > > > junk? Can ANY stateful packet filter see this stuff or is > the pattern > > > too broad in allowed RPCs? > > > > > > Again, I hope this is not a stupid question or > inappropriate format for > > > this, as somebody else recently said, there is already > enough noise on > > > this list. I would hate to see this list degenerate, it > has been REALLY > > > valuable to me as a network engineer on occaison. > > - -- > Rodrigo Barbosa <[EMAIL PROTECTED]> > "Quid quid Latine dictum sit, altum viditur" > "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.2.3 (GNU/Linux) > > iD8DBQFBbYoGpdyWzQ5b5ckRAsMMAJ0bg5ygvKOa1Du66mbW9+gkYfTqVACfewf0 > PPz66l4bre4Gtn1J4dYl6AQ= > =ZAmy > -END PGP SIGNATURE- > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
The doc (http://support.microsoft.com/?id=833401) lists the salient points: 1. Verify that your server computer and your client computer meet the requirements to use RPC over HTTP. 2. Consider important items and recommendations that are described in this article. 3. Configure Exchange to use RPC over HTTP. 4. Configure the RPC virtual directory in Internet Information Services. 5. Configure the RPC proxy server to use specific ports. 6. Configure your client computers to use RPC over HTTP. And this glorious tidbit: "The RPC client establishes the Internet connection by tunneling the RPC traffic through the HTTP protocol. Typical RPC communication is not designed for use on the Internet. RPC communication does not work reliably through a firewall that is on the perimeter network. RPC over HTTP helps make it possible to use an RPC client with firewalls that are on the perimeter network. If the RPC client can make an HTTP connection to a remote computer that is running Microsoft Internet Information Services (IIS), that RPC client can connect to any server on the remote network." This doesn't sound like XML-RPC to me, it sounds like, too literally, someone figured that, in theory, encryption and entity/service identification of whatever sort can be performed reliably and quickly; perfectly so in fact! So, what you effectively have is a medium/technique/? of communication that is easy to deal with and known fairly well by a fair number of people (http), already cross platform and architecture independant (http and it's text basis, and heck that XDR layer that hangs out with RPC), seems to take hacks well (whatever session management and auth stuff you can cram on either), plays nice with most firewalling, and sheeit, golly gee lets try and do oldschool RPC, DCOM, DCE-RPC (or whatever it is, can't remember exactly at the moment) and see if it'll quack! It's easier than doing it the right way (notice that I have not suggested one, that's my right as a con-MS bigot ;) and it's here now! Not that I wouldn't giggle at MS binary protocols, encryption intrinsic, designed explicitly for peoples emails getting shuffled over the internet, and I think even they know how well that would go over. Problem is a medium like that doesn't exist, and the world doesn't correspond 1:1 with computer science theory. In any case, I gotta grab a cold Orangina and ponder whether I misappropriated copywritten content in this email. Feh. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
On Wed, 13 Oct 2004 15:33:13 -0700 (PDT), S G Masood <[EMAIL PROTECTED]> wrote: > Yeah, it certainly is a security risk in several ways. > Decoding and inspecting HTTPS traffic at the perimeter > before it reaches the server becomes an absolute > necessity if RPC over HTTPS is implemented. Same with > RPC over HTTP. There was a Microsoft employee on-site for a few days this summer, and I noticed one day that he was reading MS email messages in Outlook 2003 (not OWA) from his laptop while connected to *our* private LAN. Any smart enterprise blocks all POP/IMAP/MAPI protocols both inbound and outbound, so this made me more than a bit suspicious... When I checked the proxy traffic from the DHCP address assigned to his laptop, I saw normal-lookup HTTP requests followed by additional RPC headers. Turns out the employee he was working with helpfully gave him the information to use the outbound proxy, and after configuring proxy settings in the control panel, it "just worked". Our visitor went back to Redmond before I could get approval from management to modify the firewall configuration to explicitly block RPC-over-HTTP :( Kevin ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Yeah, it certainly is a security risk in several ways. Decoding and inspecting HTTPS traffic at the perimeter before it reaches the server becomes an absolute necessity if RPC over HTTPS is implemented. Same with RPC over HTTP. -- S.G.Masood --- ASB <[EMAIL PROTECTED]> wrote: > You need protocol level inspection (i.e. beyond SPI) > if you're going > to monitor that kind of traffic. > > Also, the support for RPC over HTTP (should really > be HTTPS) is not as > open ended as you might fear. > > Look at the following: > http://www.google.com/search?q=RPC%20over%20HTTPS%20implement > > > - ASB > Cheap, Fast, Secure -- Pick Any TWO. > http://www.ultratech-llc.com/KB/ > > > > > On Tue, 12 Oct 2004 12:41:56 -0700, Daniel Sichel > <[EMAIL PROTECTED]> wrote: > > This may just reflect my ignorance, but I read > (and found hard to > > believe) that Microsoft has implemented RPC over > HTTP. Is this not a > > HUGE security hole? If I understand it correctly > it means that good old > > HTML or XML can invoke a process using standard > web traffic (port 80)? > > Is there any permission checking done? what things > can be invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn > door is now wide open. Am > > I right, and if so, how can I detect RPCs in web > traffic to block this > > junk? Can ANY stateful packet filter see this > stuff or is the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or > inappropriate format for > > this, as somebody else recently said, there is > already enough noise on > > this list. I would hate to see this list > degenerate, it has been REALLY > > valuable to me as a network engineer on occaison. > > > > Thanks all, > > Dan Sichel > > Ponderosa telephone > > [EMAIL PROTECTED] > > ___ > Full-Disclosure - We believe in it. > Charter: > http://lists.netsys.com/full-disclosure-charter.html > ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Yeah, it certainly is a security risk in several ways. Decoding and inspecting HTTPS traffic at the perimeter before it reaches the server becomes an absolute necessity if RPC over HTTPS is implemented. Same with RPC over HTTP. -- S.G.Masood --- ASB <[EMAIL PROTECTED]> wrote: > You need protocol level inspection (i.e. beyond SPI) > if you're going > to monitor that kind of traffic. > > Also, the support for RPC over HTTP (should really > be HTTPS) is not as > open ended as you might fear. > > Look at the following: > http://www.google.com/search?q=RPC%20over%20HTTPS%20implement > > > - ASB > Cheap, Fast, Secure -- Pick Any TWO. > http://www.ultratech-llc.com/KB/ > > > > > On Tue, 12 Oct 2004 12:41:56 -0700, Daniel Sichel > <[EMAIL PROTECTED]> wrote: > > This may just reflect my ignorance, but I read > (and found hard to > > believe) that Microsoft has implemented RPC over > HTTP. Is this not a > > HUGE security hole? If I understand it correctly > it means that good old > > HTML or XML can invoke a process using standard > web traffic (port 80)? > > Is there any permission checking done? what things > can be invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn > door is now wide open. Am > > I right, and if so, how can I detect RPCs in web > traffic to block this > > junk? Can ANY stateful packet filter see this > stuff or is the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or > inappropriate format for > > this, as somebody else recently said, there is > already enough noise on > > this list. I would hate to see this list > degenerate, it has been REALLY > > valuable to me as a network engineer on occaison. > > > > Thanks all, > > Dan Sichel > > Ponderosa telephone > > [EMAIL PROTECTED] > > ___ > Full-Disclosure - We believe in it. > Charter: > http://lists.netsys.com/full-disclosure-charter.html > ___ Do you Yahoo!? Declare Yourself - Register online to vote today! http://vote.yahoo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Yeah, it certainly is a security risk in several ways. Decoding and inspecting HTTPS traffic at the perimeter before it reaches the server becomes an absolute necessity if RPC over HTTPS is implemented. Same with RPC over HTTP. -- S.G.Masood --- ASB <[EMAIL PROTECTED]> wrote: > You need protocol level inspection (i.e. beyond SPI) > if you're going > to monitor that kind of traffic. > > Also, the support for RPC over HTTP (should really > be HTTPS) is not as > open ended as you might fear. > > Look at the following: > http://www.google.com/search?q=RPC%20over%20HTTPS%20implement > > > - ASB > Cheap, Fast, Secure -- Pick Any TWO. > http://www.ultratech-llc.com/KB/ > > > > > On Tue, 12 Oct 2004 12:41:56 -0700, Daniel Sichel > <[EMAIL PROTECTED]> wrote: > > This may just reflect my ignorance, but I read > (and found hard to > > believe) that Microsoft has implemented RPC over > HTTP. Is this not a > > HUGE security hole? If I understand it correctly > it means that good old > > HTML or XML can invoke a process using standard > web traffic (port 80)? > > Is there any permission checking done? what things > can be invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn > door is now wide open. Am > > I right, and if so, how can I detect RPCs in web > traffic to block this > > junk? Can ANY stateful packet filter see this > stuff or is the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or > inappropriate format for > > this, as somebody else recently said, there is > already enough noise on > > this list. I would hate to see this list > degenerate, it has been REALLY > > valuable to me as a network engineer on occaison. > > > > Thanks all, > > Dan Sichel > > Ponderosa telephone > > [EMAIL PROTECTED] > > ___ > Full-Disclosure - We believe in it. > Charter: > http://lists.netsys.com/full-disclosure-charter.html > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
You need protocol level inspection (i.e. beyond SPI) if you're going to monitor that kind of traffic. Also, the support for RPC over HTTP (should really be HTTPS) is not as open ended as you might fear. Look at the following: http://www.google.com/search?q=RPC%20over%20HTTPS%20implement - ASB Cheap, Fast, Secure -- Pick Any TWO. http://www.ultratech-llc.com/KB/ On Tue, 12 Oct 2004 12:41:56 -0700, Daniel Sichel <[EMAIL PROTECTED]> wrote: > This may just reflect my ignorance, but I read (and found hard to > believe) that Microsoft has implemented RPC over HTTP. Is this not a > HUGE security hole? If I understand it correctly it means that good old > HTML or XML can invoke a process using standard web traffic (port 80)? > Is there any permission checking done? what things can be invoked by RPC > over HTTP? Jeeze, to me it looks like the barn door is now wide open. Am > I right, and if so, how can I detect RPCs in web traffic to block this > junk? Can ANY stateful packet filter see this stuff or is the pattern > too broad in allowed RPCs? > > Again, I hope this is not a stupid question or inappropriate format for > this, as somebody else recently said, there is already enough noise on > this list. I would hate to see this list degenerate, it has been REALLY > valuable to me as a network engineer on occaison. > > Thanks all, > Dan Sichel > Ponderosa telephone > [EMAIL PROTECTED] ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Hi Daniel & Daniel I agree this can lead to security holes. There are ways to make it "more secure" (if you can call it secure), here are some links about this subject : (sorry for wrapped urls) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/remote_procedure_calls_using_rpc_over_http.asp http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/rpc_over_http_security.asp http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx http://www.scripting.com/98/04/stories/bobAtkinsonOnHttpPost.html http://www.winnetmag.com/MicrosoftExchangeOutlook/Article/ArticleID/40018/MicrosoftExchangeOutlook_40018.html http://www.sanx.org/tipShow.asp?articleRef=117 http://www.kb.cert.org/vuls/id/698564 http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0807 http://searchexchange.techtarget.com/originalContent/0,289142,sid43_gci963557,00.html Have a nice day Maxime Ducharme Programmeur / Spécialiste en sécurité réseau - Original Message - From: "Daniel H. Renner" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, October 13, 2004 11:37 AM Subject: Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP > Daniel, > > Could you please point out where you read this data? I would like to > see this one... > -- > Daniel H. Renner <[EMAIL PROTECTED]> > Los Angeles Computerhelp > > > On Tue, 2004-10-12 at 20:54, [EMAIL PROTECTED] > wrote: > > Message: 18 > > Date: Tue, 12 Oct 2004 12:41:56 -0700 > > From: "Daniel Sichel" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Subject: [Full-Disclosure] Possibly a stupid question RPC over HTTP > > > > This may just reflect my ignorance, but I read (and found hard to > > believe) that Microsoft has implemented RPC over HTTP. Is this not a > > HUGE security hole? If I understand it correctly it means that good old > > HTML or XML can invoke a process using standard web traffic (port 80)? > > Is there any permission checking done? what things can be invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn door is now wide open. Am > > I right, and if so, how can I detect RPCs in web traffic to block this > > junk? Can ANY stateful packet filter see this stuff or is the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or inappropriate format for > > this, as somebody else recently said, there is already enough noise on > > this list. I would hate to see this list degenerate, it has been REALLY > > valuable to me as a network engineer on occaison. > > > > Thanks all, > > Dan Sichel > > Ponderosa telephone > > [EMAIL PROTECTED] > > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
It looks like they have.. (url may wrap) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/remote_procedure_calls_using_rpc_over_http.asp -- Regards, Sean Milheim iDREUS Corporation --- Begin Message --- I have heard the same thing and I have the same concern. The latest and greatest (?) MS Exchange 2003 uses it for Outlook Web Access and Outlook 2003 may connect to Exchange through it also without needing a VPN. http://support.microsoft.com/?id=833401 Daniel H. Renner wrote: Daniel, Could you please point out where you read this data? I would like to see this one... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html -- This message was scanned for spam and viruses by BitDefender For more information please visit http://www.idreus.com/index.php?page=product&product_id=8 --- End Message --- -- This message was scanned for spam and viruses by BitDefender For more information please visit http://www.idreus.com/index.php?page=product&product_id=8
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is called, in my experience, XML-RPC (google search with lots of results). Reference: http://www.xmlrpc.com/spec Yes, it is a Remote Procedure Calling implementation. No, it is not the same things that the good old udp based RPC used for things like NIS and NFS. References: RFC 1057 and RFC 1831. That can be the source of confusion. Akin names. On Wed, Oct 13, 2004 at 11:37:12AM -0400, Daniel H. Renner wrote: > Daniel, > > Could you please point out where you read this data? I would like to > see this one... > > This may just reflect my ignorance, but I read (and found hard to > > believe) that Microsoft has implemented RPC over HTTP. Is this not a > > HUGE security hole? If I understand it correctly it means that good old > > HTML or XML can invoke a process using standard web traffic (port 80)? > > Is there any permission checking done? what things can be invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn door is now wide open. Am > > I right, and if so, how can I detect RPCs in web traffic to block this > > junk? Can ANY stateful packet filter see this stuff or is the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or inappropriate format for > > this, as somebody else recently said, there is already enough noise on > > this list. I would hate to see this list degenerate, it has been REALLY > > valuable to me as a network engineer on occaison. - -- Rodrigo Barbosa <[EMAIL PROTECTED]> "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFBbYoGpdyWzQ5b5ckRAsMMAJ0bg5ygvKOa1Du66mbW9+gkYfTqVACfewf0 PPz66l4bre4Gtn1J4dYl6AQ= =ZAmy -END PGP SIGNATURE- ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Look for documentation on SOAP. Thanks, Ron DuFresne On Wed, 13 Oct 2004, Daniel H. Renner wrote: > Daniel, > > Could you please point out where you read this data? I would like to > see this one... > -- ~~ "Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation." -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
RE: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Are you talking about the BITS change? Where it does BITS over HTTP? > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Daniel H. Renner > Sent: Wednesday, October 13, 2004 10:37 AM > To: [EMAIL PROTECTED] > Subject: Re: [Full-Disclosure] Possibly a stupid question RPC > over HTTP > > Daniel, > > Could you please point out where you read this data? I would > like to see this one... > -- > Daniel H. Renner <[EMAIL PROTECTED]> Los Angeles > Computerhelp > > > On Tue, 2004-10-12 at 20:54, [EMAIL PROTECTED] > wrote: > > Message: 18 > > Date: Tue, 12 Oct 2004 12:41:56 -0700 > > From: "Daniel Sichel" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Subject: [Full-Disclosure] Possibly a stupid question RPC over HTTP > > > > This may just reflect my ignorance, but I read (and found hard to > > believe) that Microsoft has implemented RPC over HTTP. Is this not a > > HUGE security hole? If I understand it correctly it means > that good old > > HTML or XML can invoke a process using standard web traffic > (port 80)? > > Is there any permission checking done? what things can be > invoked by RPC > > over HTTP? Jeeze, to me it looks like the barn door is now > wide open. Am > > I right, and if so, how can I detect RPCs in web traffic to > block this > > junk? Can ANY stateful packet filter see this stuff or is > the pattern > > too broad in allowed RPCs? > > > > Again, I hope this is not a stupid question or > inappropriate format for > > this, as somebody else recently said, there is already > enough noise on > > this list. I would hate to see this list degenerate, it has > been REALLY > > valuable to me as a network engineer on occaison. > > > > Thanks all, > > Dan Sichel > > Ponderosa telephone > > [EMAIL PROTECTED] > > > > > ___ > Full-Disclosure - We believe in it. > Charter: http://lists.netsys.com/full-disclosure-charter.html > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Daniel H. Renner wrote: Daniel, Could you please point out where you read this data? I would like to see this one... I seem to remember that this was one of the caveats with regard to MSBlast and RPC/DCOM vulnerabilities last year. In certain configurations, it was theoretically possible (I'd never personally seen any PoC code or worms that exploited it, though) that some RPC calls could be made via RPC over HTML. According to the security bulletin for MS03-026, the service that provides RPC over HTML is COM Internet Services (CIS). From what I recall, it was discussed at the time as a potential infection vector, though CIS is not installed by default on IIS installs. There were, at the time, very few sites that utilized it. Feel free to correct me if I'm wrong, though. Please see the MS03-026 bulletin for some more points: http://www.microsoft.com/technet/security/bulletin/MS03-026.mspx Go down to the "Frequently asked Questions" section, expand it, and look at the section that discusses CIS for more information. I'm sure that this will give you enough information to do some more searching for further information on current versions of CIS and determining whether they're installed. -Barry ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
I remember reading this too. So after a little investigation I've found the following resources: http://www.msexchange.org/tutorials/outlookrpchttp.html http://www.microsoft.com/office/ork/2003/three/ch8/OutC07.htm http://www.winnetmag.com/MicrosoftExchangeOutlook/Article/ArticleID/40018/MicrosoftExchangeOutlook_40018.html It looks to be primarily an Exchange "feature", but Server 2003 supports it. http://www.sanx.org/tipShow.asp?articleRef=117 http://support.microsoft.com/default.aspx?kbid=826382 Shannon Johnston On Wed, 2004-10-13 at 09:37, Daniel H. Renner wrote: > Daniel, > > Could you please point out where you read this data? I would like to > see this one... -- Shannon Johnston <[EMAIL PROTECTED]> Cavion Plus signature.asc Description: This is a digitally signed message part
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
"Daniel H. Renner" <[EMAIL PROTECTED]> 10/13/2004 8:37:12 AM: > Daniel, > > Could you please point out where you read this data? I would like to > see this one... Ye god, it's true. And it's recommended by Microsoft as well. One example: http://www.microsoft.com/downloads/details.aspx?FamilyID=77B6D819-C7B3-42D1-8FBB-FE6339FFA1ED&displaylang=en This is the Exchange Server 2003 deployment guide. Self-extracting ZIP. Contains the guide, nothing else. Page 154: - - - - - 8< - - - - - Configuring RPC over HTTP for Outlook 2003 When you deploy RPC over HTTP in your corporate environment, you have two deployment options that are based on where you locate your RPC Proxy server: * Option 1 (recommended) Deploy an advanced firewall server such as Internet Security and Acceleration (ISA) Server in the perimeter network, and position your RPC Proxy server within the corporate network. Note When you use ISA Server as your advanced firewall server, you have several deployment options. For information about how to install ISA Server as an advanced firewall server, see the guide Using Microsoft Exchange 2000 Front-End Servers (http://go.microsoft.com/fwlink/?linkid=14575). * Option 2 Position the Exchange 2003 front-end server acting as an RPC Proxy server in the perimeter network. - - - - - 8< - - - - - Matt ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
I have heard the same thing and I have the same concern. The latest and greatest (?) MS Exchange 2003 uses it for Outlook Web Access and Outlook 2003 may connect to Exchange through it also without needing a VPN. http://support.microsoft.com/?id=833401 Daniel H. Renner wrote: Daniel, Could you please point out where you read this data? I would like to see this one... ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Re: [Full-Disclosure] Possibly a stupid question RPC over HTTP
Daniel, Could you please point out where you read this data? I would like to see this one... -- Daniel H. Renner <[EMAIL PROTECTED]> Los Angeles Computerhelp On Tue, 2004-10-12 at 20:54, [EMAIL PROTECTED] wrote: > Message: 18 > Date: Tue, 12 Oct 2004 12:41:56 -0700 > From: "Daniel Sichel" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Subject: [Full-Disclosure] Possibly a stupid question RPC over HTTP > > This may just reflect my ignorance, but I read (and found hard to > believe) that Microsoft has implemented RPC over HTTP. Is this not a > HUGE security hole? If I understand it correctly it means that good old > HTML or XML can invoke a process using standard web traffic (port 80)? > Is there any permission checking done? what things can be invoked by RPC > over HTTP? Jeeze, to me it looks like the barn door is now wide open. Am > I right, and if so, how can I detect RPCs in web traffic to block this > junk? Can ANY stateful packet filter see this stuff or is the pattern > too broad in allowed RPCs? > > Again, I hope this is not a stupid question or inappropriate format for > this, as somebody else recently said, there is already enough noise on > this list. I would hate to see this list degenerate, it has been REALLY > valuable to me as a network engineer on occaison. > > Thanks all, > Dan Sichel > Ponderosa telephone > [EMAIL PROTECTED] > ___ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
