From: jbass@dmsd.com (John L. Bass)
Date: Sat, 30 Sep 95 12:09:27 PDT
To: www-security@ns2.rutgers.edu
Subject: A new tack on breaking SSL streams and NetScape servers
Message-ID: <9509301909.AA10965@dmsd.com>
MIME-Version: 1.0
Content-Type: text/plain


| From jbass Mon Sep 25 15:00:41 1995
| To: JohnCGreen@aol.com
| Subject: Re:  Netscape bug, RSA patent, hacker challenge
| Cc: rmiug-discuss@rmiug.org, isig@netf.org
| 
| On Thu, 21 Sep 1995 JohnCGreen@aol.com wrote:
| > Internet commerce is getting off to a slow start. One of the reasons is
| > nervousness on the part of the general public regarding the use of insecure
| > networks. I believe it is not in the industry's interest to have vendors
| > publicly pointing out flaws in competitors' products.
| [ ... part deleted ...]
| > I believe that as long as industry experts working for huge companies like
| > Sun and AT&T as well as executives of small companies like NetManage and
| > Community ConneXion continue to criticize publicly the security of
| > competitors' systems commerce will be very slow to develop.
| > - - -
| > Internet Marketing and Business Development Consultant
| > 21483 Old Mine Rd             Tel: (408)353-1870
| > Los Gatos CA 95030           Internet: JohnCGreen@aol.com
| 
| Most of us are employed directly or indirectly by somebody. The quotes
| involved were not derived from text under a press release letterhead
| by the employers of those involved.  The press is certainly free to use
| the persons educational and employment credentials in citing the source.
| Your objections here are with out merit, since the quotes were not
| officially released by the businesses involved and only serve to distract
| from the real problems.
| 
| Internet commerce is getting off to a slow start for good reason. Encryption
| or not, using the internet in it's current state for commerce is fundementally
| insecure, and the commercial internet providers have failed to address the
| primary problems. During a security discussion in the Colorado SuperNet
| users group mailing list last spring Brad Huntting, one of CSN's lead
| techinical specialists, made this remarkably clear in his posting on
| 13 Mar 1995 23:55:46 in response to my posting regarding minimal security
| expectations to do business on/over the internet.
| 
| A clear line of attack for any site dealing with credit cards or other
| valuable data would be to attack the authoritative name servers (and routes
| to/thru DNS servers) to reroute the target hosts traffic thru a filter host
| to skim off data transparently. Or more directly to watch /dev/nit somewhere
| on the network where www clients or servers are active with this data.
| 
| I am hardly an internet security expert, but also far from being a newbie
| at this game. I often have a more fundamental perspective on these problems,
| and in some cases very different levels of expectations. We are dealing with
| areas where there is no single right and wrong way to solve the security
| problem. But there are clearly certain technical flaws that MUST be addressed
| FIRST, before any solution will be viable.
| 
| [from my Mon, 13 Mar 95 21:43:46 -0700 posting to ug@csn.net]
| 
| I start with 4 expectations about providers which are seldom met:
| 
| 	1) ISP's manage internal and external back bones in a secure mode.
| 	   This means that nobody except critical internal staff can snoop
| 	   customer traffic or program routers - by network design.
| 
| 	2) ISP's manage the bridge/routers and subnets for network customers
| 	   (dedicated/slip/ppp) with advertised routes/domains/MX service
| 	   as secure too.
| 
| 	3) They firewall the billing systems, key servers, and monitor
| 	   the security for them very carefully.
| 
| 	4) They have a relatively insecure interactive environment on it's own
| 	   subnet behind a bridge/router/etherswitch to issolate it from the
| 	   internal backbone.
| 
| The CSN/Brad Huntting response was:
| 
| >I dont believe any ISP's do this. "As secure"?  This [...] is fantasy.
| 
| With this model we can make some assertions (not necessaryly true today):
| 
| 	A) Customer data between two full-time (#2 above) subscribers (of
| 	   atleast the same provider, and reasonably expected between major
| 	   providers) *SHOULD* be expected to be secure *AND* that they devote
| 	   the resources to insure that it remains secure. Without this
| 	   everyone using the internet to transact business is highly at risk.
| 
| 	B) Mail service between two full-time (#2 above) subscribers (of
| 	   atleast the same provider, and reasonably expected between major
| 	   providers) *SHOULD* be expected to be secure. This is clearly not
| 	   true today since some providers use interactive customer systems
| 	   for mail servers - so fall back delivery via MX records drop mail
| 	   into an insecure environment.
| 
| The CSN/Brad Huntting response was:
| 
| > E-Mail?  Secure?  You are high...
| 
| It's no wonder an increasing number of companies are all but disconnecting
| from the internet.
| 
| The interactive systems at providers sites are completely a different cow/pig
| ...  they are difficult to class as anything but unsecure/hostile since the
| user base has *NO* controls. Anybody that pays their startup fees can get an
| account and hack/crack for atleast a month. Running www, other clients or
| servers which transact business in this environment is fundementally insecure.
| Because of this, the home computer model over slip/ppp should be the only or
| prefered way to do internet business.
| 
| Any rational provider needs to firewall their "support" systems (routers,
| billing systems, and key servers) from this interactive zoo, slip/ppp/dedicated
| customers, and the rest of the internet. The Kevin Mitnick attack was pure
| stupidity ... he left a trail to his apartment. The providers involved didn't
| do enough to firewall their support systems. Dozens/hundreds of other hackers
| and crackers are atleast smart enough to loop their telnet/rlogins thru foreign
| sites that *WILL NOT* provide call/route trace data to the Feds and then loop
| the service such that packet correlation within a provider can not be done.
| Had Mitnick done this he would still be reaping havoc. Other probably are
| still at it, untraceable.
| 
| I have several friends that have been running mail order businesses via
| WEB servers ... you can order audio CD's, Video's, software, Adult toys,
| and other interesting things from them. They are also cracker targets since
| they do business via credit cards from their systems. Unless somebody can
| start making the core part of the network secure and drive the cracker
| havens from the net, I would not be suprised if the credit card companies
| start withdrawing authorization from these businesses. Some of the non-credit
| card companies, like Pizza Hut will also get tired of the internet when
| some SOB floods them with prank orders day in and day out ...
| 
| Current "secure protocols" are hardly secure in an insecure environment, they
| require atleast a certain trusted agent/transport domain to work.  If we are
| going to "cleanup the net", it is going to be with providers and users taking
| responsiblity for securing the primary backbones and provider resources, then
| removing the hostile users and havens from the net.
| 
| Having safe-havens on the net where hackers from around the world can safely
| telnet thru has to stop ... before business on the internet is practical.
| Getting the ISP's to accept basic route/data security as part of their service
| offering is manditory for any sucessful encryption scheme. NetScape's current
| problems are just the tip of the iceberg.
| 
| -----------
| John Bass
| UNIX Consultant                     Development, Porting, Performance by Design
| 
| 
| From jbass Mon Sep 25 16:48:29 1995
| To: isig@netf.org, rmiug-discuss@rmiug.org
| Subject: encryption in an insecure environment
| Status: O
| 
| Since several Public Key and PGP supporters don't understand the basics
| of their own offerings ... I'll provide the rebuttal publicly for the
| rest of you who may have been confused by my last posting.
| 
| Encryption security is only as good as the security of the "key(s)" involved.
| How keys are transmitted is the weak link for network based encryption
| security systems.
| 
| First Public Key encryption is far better than "pretty good" as long as
| you know the sending party *IS* using *YOUR* key. The problem is that
| when one or more messengers are in the loop, they can keep the receipents
| key and provide the sender with their own key. When they get the senders
| message they can decode the text, then re-encode it with the key obtained
| from the receipent before passing it along to the receipent.
| 
| Using Public Key encryption over the internet therefore requires that the
| messengers (ISP's and the commerical internet backbones) are trustworthy
| in delivering keys and limiting data access. If any point in the network
| allows a hacker to substitute keys and reencrypt messages, then communication
| between the customer and vendor is insecure. Routers, bridges, and Domain
| Name Servers become key targets and must be trusted and secure. This is not
| true today.
| 
| John Bass
| UNIX Consultant                     Development, Porting, Performance by Design
| 
| From jbass Tue Sep 26 20:46:01 1995
| To: rmiug-discuss@rmiug.org, isig@netf.org
| Subject: DNS role in an insecure network environment
| Status: O
| 
| Since some folks here may not understand why Domain Name Servers
| and the routes to/from them must be secure I'll provide a short
| description of why attacking them, or their routing, can be used
| to attack a vendors server system.
| 
| Domain Name Service (DNS) has several critical roles in regard
| to supporting internet security. This opens the door for several
| interesting attacks.
| 
| It is critical that the mapping of host.domain a client system results
| in the internet address of the server host requested - and not that of
| some substituted server intercepting traffic for it.
| 
| If an attacker can convince a client system to resolve requests for
| server.vendor.domain to the substituted server, then the attacker can
| forward the clients requests to the real server while skimming the
| data involved. There are several ways to do this ranging from directly
| attacking the DNS system to injecting subsituted DNS replys into the
| network. Doing this on an ISP's interactive system simply requires
| gaining enough privilege to either edit/replace host name tables or
| forcing an entry into the network kernel cache. Since DNS entries are
| cached, the substituted server address can have a fairly long life. The
| substituted server can be any machine in the world ... either in a safe
| haven zone or another compromised site to protect the hackers identity.
| 
| Authentication often requires that given some client/server address
| that you can trust DNS services to map it to the correct host.domain
| name which is then compared with an access control list.  Many network
| servers can be attacked by subsituting a trusted sites name given the
| attackers address.
| 
| The reliance on DNS creates a house of cards out of internet security,
| particulary since the ISP's internal network and internet backbone
| is managed without explict attention to data/routing/DNS security. The
| ISP's seem think it's the users problem ... without any viable solution.
| 
| John
| 
| From jbass Thu Sep 28 08:14:26 1995
| To: Steve Hultquist <ssh@rmii.com>
| Subject: Re: DNS role in an insecure network environment
| Cc: rmiug-discuss@rmiug.org, isig@netf.org
| Status: O
| 
| Steve,
| 
| Let's recap this in brief. In the first three postings I formed a strong
| argument that a collection of technologies in current use and percieved
| as secure, have in fact several lines of attack related to the messenger
| problem of distributing public keys. Nobody has offered a rebuttal to
| this method of attack showing the assertions invalid.
| 
| This assertion directly implies that current practice of using Public
| Key encryption with inband keys is flawed, independent of the merits
| of the encryption algorithm, key algorithm or key length.
| 
| Independent of the merits of any encryption or authentication algorithm,
| accepted solutions to the the messenger attack require the existance of
| either an out-of-band key or a secure communications channel. How secure
| the channel must be depends on several factors. At minimum it must have
| routing integrity, which is not currently the case, to prevent a third
| party from inserting a filter (messenger) into the data path. Preferably
| the data path would not be clear text at all.
| 
| There are millions of customers and a large number of vendors accepting
| the current technology without the knowledge of it's flaws.
| 
| You jump in with two postings which attempt to discredit my assertions
| purely with the force of your reputation saying it ain't so, and offer
| your signature lines as proof. And then get highly personal and offended
| when I question your weak attack.
| 
| There are solutions to the problem, but they are not in widespread use
| on the internet to protect WWW commerce. CrypoCards are neat, but they
| are not the solution for the WWW. Third party systems still have the
| messenger problem unless an out-of-band key exists or the communication
| channel is secure to start with.
| 
| My business cards just say "consultant" ... I also have a few left that
| say "janitor" (for cleaning up other engineers messes, and empting the
| trash after my employees). I also have a few that simply say "owner",
| but I have never thought it quite right to run my 1-10 man shop with
| the title president, CEO, or whatever titles that are used by those
| with the real resposibility for running multi-million/billion dollar
| companies with hundreds/thousangds of peoples jobs/lives at stake.
| 
| 
| You say:
| 
| 	I think the technology is well-understood and has to do with
| 	key escrow by trusted servers.
| 
| and I say fine, but that doesn't help today's customers. The messenger
| problem still exists with dynamic in-band registration, an out-of-band
| key is still needed..
| 	
| 	Yes, it takes a little time to set up third-party
| 	key servers, but it's not *that* difficult.  And, fortunately, it has
| 	nothing to do with major changes to things as fundamental as DNS.
| 
| and I say fine, but that doesn't help today's customers. Nor did I advocate
| changes to DNS ... just cleaning up the security of the channels it operates
| over.
| 	
| 	I don't think [out-of-band] key management is that difficult.
| 
| I don't think it is either, *IF* done by the ISP for the ISP's protection
| domain *AND* the ISP's implement and extended protection domain to cover
| the backbone and all ISP's. But's that's not here today either
| 	
| 	Are you familiar with the current IETF working groups?  Would you
| 	like to provide us with an assessment of the various approaches, including
| 	IPv6 (which, by the way, we are demonstrating here at Networld+Interop this
| 	week: http://www.interop.net)?
| 
| As I stated in my original post I don't claim to be an internet security expert.
| You do.
| 
| The real point is that none of this protects todays customers and vendors.
| I am not going to beat my chest and hope some group can change the risks
| for www customers in the next year either. (But it would be nice)
| 	
| 	>Since current systems depend on messengers, they are flawed from
| 	>a security standpoint no matter how many million may be in use.
| 	>The NetScape encryption that was just broken what widely in use
| 	>and success by your definition ... by mine it was a failure due
| 	>to it's flaws ... exploited or not.
| 	
| 	Hogwash.  Netscape was broken because they screwed up their randomization
| 	routine.  It has nothing to do with the inherent security of the design,
| 	other than the flawed randomization.  These are the rumors I was talking about.
| 
| (grin) then prove it. Disprove the messenger attack. This is not a complex
| theory or algorithm we are talking about. The thousand or so readers of
| these lists will sleep a lot better if you can.
| 	
| 	>And there in lies the cruz of the problem, trusting people with your title
| 	>for security who claim to be experts, yet just stick their head in the sand ...
| 	
| 	You know, John, you are one of the most caustic people I have ever conversed
| 	with.  You don't know me, other than our e-mail conversations, yet you
| 	continue to denigrate me in public.  I won't talk about my background,
| 	except to say that none of my security implementations have been
| 	compromised, my clients recommend me to others, and I am well aware of those
| 	times I need to enlist other experts.
| 	
| 	Unlike you, John, I'm not perfect, and can use the assistance of others at
| 	times.
| 
| Gee ... for somebody that doesn't know me either you bring a lot of personel
| stabs into this. "stick their head in the sand" is pretty meek compared to
| your full on attack.
| 	
| 	>please explain to the rest of how your CryptoCard can be used
| 	>to solve the problem for the rest of us that would like to wander
| 	>the Web and shop without physically registering our card
| 	>with each store.
| 	
| 	You'd only need to register it with a key server.  But, you won't be
| 	convinced, will you, John?
| 
| and serveral million readers installed on every PC, and several million more cards
| with unique ID's manufactured and distributed to users world wide, and the
| coding whould have to have a trap door for the NSA and law enforcement which
| would soon become widely known by all cyber crooks and econo terrorists.
| (or copies of the servers database should some employee decide that a new
| name and foreign home and retirement plan was worth the price of walking out
| the front door with some extra in their pocket) Not every problem has
| a technical solution ... not even for technical secrets.
| 	
| 	>dream on and sleep well ...
| 	
| 	I sleep well almost every night.  And so do my clients.
| 	
| 	It makes me wonder about yours.  If you have any.
| 	
| cheap shot ... sleep on. (but I wonder about your ...)
| 
| 	Cheers,
| 	ssh
| 	--
| 	Steve Hultquist                   Distributed Systems and Internet Engineering
| 	President, Worldwide Solutions, Inc.                         Boulder, Colorado
| 
| John Bass
| Janitor, DMS Design		;-))
| 
| From jbass Fri Sep 29 01:28:26 1995
| To: isig@netf.org, rmiug-discuss@rmiug.org
| Subject: How to get rich from this ...
| Status: R
| 
| 
| Security flaws for the most part are just fun toys. With WWW & credit cards
| we can really let our fingers to the walking. Thru the internet backbone
| travels thousands of credit cards with authorization data every day/hour/minute.
| Or you can be a little more selective and pick a state, city, or smaller
| geograhical area by choosing which pipe to plug into.
| 
| Where good old phone banks with people and the net differ - is a single
| electronicly readable pipe of treasure outside the normal EFT security
| channels. This centralization of data is what makes it attractive *IF*
| you find a way to turn it into cash without getting caught or the risk of
| getting caught can be out wieghed by the gains.
| 
| How much can 5,000 credit cards be worth ... 1,000-3,000 each to the tune
| of say 10 million if you are thinking small. On a little bit more grand
| scale 10X or 100X is possible with some planning on how to get the money
| into a usable place. We are talking more money than can be obtained from
| even the biggest of bank or collectable roberies. I think that makes it
| a goal of atleast somebody out there ... if not an unknown cyber crook,
| organized crime, revolutionaries, some third world government.
| 
| Some planning is in order - how to plug into the pipe, how to get the
| money out. This is the fun part ;-)
| 
| We could probably afford to give say $50K to some college kid working for
| the regional ISP to find out a router passwd or two and share them with us.
| Maybe we are a little more discrete and simply put in a job application with
| them for the summer, or we by a few dozen very expensive routers and sell
| them cheap after installing a trap door in their firmware. Maybe we just
| do it the old fashion way and crack the root passwd on the interactive server
| and leave a background process watching /dev/nit for router passwds around
| the time we know they are going to do some reconfiguration.
| 
| Getting the money out is the real creative part.  Certainly running down
| and taking out cash advances is out of the question - or at least boring.
| We could do it the simple way - for each card in a targeted city, binary
| search it's limit by ordering various non-traceable comodities like Pentium
| CPU's, memory, jewlry, gold/silver coins for the card owners shipped to
| their homes - then hijack the FedX and UPS regional delivery trucks first
| thing in the morning. Since the goods are prepaid, it will probably take
| several days before they can figure out the magnitude of the deal. Probably
| time to do it a couple more times. Certainly doing say 50 at the same time
| could yield a diversified retirement income.
| 
| With out the glamour is more tried and true ways - hire a few hundred
| college kids to start a chain of computer software stores. Build volume
| by selling exactly at operating costs - undercutting everybody. When the
| bank gets used to the credit card rate, hold a few loss leader sales to
| create some greate peaks ... then dump the entire stolen credit card list
| spread out against all the stores over a week period - slamming the cash
| into places difficult to find and run like heck. With luck you may be able
| to shield your identity and be faceless after the fallout.
| 
| Take a large portion of the earnings to the track, powerball offices,
| and your local bookie ... REALLY HIDE the rest. If you get caught nobody
| will have the foggiest idea of how much is in your retirement fund
| after writing a best selling crime series in the slammer. Hopefully
| they will allow notebook computers and ISDN lines in cells by then.
| 
| Find your body double and do everything in their name and town -- that's
| FYI on the SLY of course ....
| 
| Unlike others, I have a strong dislike for centralized key databases, they
| make too big a target for traditional sorts of penitration - the data is
| worth thousands times more than you are likely to pay for it under the table.
| 
| I am a strong supporter of Public Key for both private and commerical data
| protection ... but you must be fully aware to protect the initial key. As
| used by most applications, the messenger attack is possible.
| 
| have fun, hope you enjoyed this series.
| 
| The Janitor :)