| 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 :)