Защита конфиденциальных данных и анонимность в инт

[Vinni]

раз уж пошли отчеты, то вот еще один - от Symantec http://eval.symantec.com/mktginfo/enterpri...-2008.en-us.pdf

 

Goods and services Percentage Range of prices

 

Bank accounts 22% $10-$1000

Credit cards 13% $0.40-$20

Full identities 9% $1-$15

eBay accounts 7% $1-$8

Scams 7% $2.5/week - $50/week for hosting.

$25 for design

Mailers 6% $1-$10

Email addresses 5% $0.83/MB-$10/MB

Email passwords 5% $4-$30

Drop (request or offer) 5% 10%-50% of total drop amount

Proxies 5% $1.50-$30

 

 

[Vinni]

а вот статья о том, как провайдеры следят (в целях более целенаправленной рекламы, конечно ;-)) как минимум за 100.000 американцами

 

_ttp://www.washingtonpost.com/wp-dyn/content/article/2008/04/03/AR2008040304052_pf.html

 

Every Click You Make

Internet Providers Quietly Test Expanded Tracking of Web Use to Target Advertising

 

By Peter Whoriskey

Washington Post Staff Writer

Friday, April 4, 2008; D01

 

The online behavior of a small but growing number of computer users in the United States is monitored by their Internet service providers, who have access to every click and keystroke that comes down the line.

 

The companies harvest the stream of data for clues to a person's interests, making money from advertisers who use the information to target their online pitches.

 

The practice represents a significant expansion in the ability to track a household's Web use because it taps into Internet connections, and critics liken it to a phone company listening in on conversations. But the companies involved say customers' privacy is protected because no personally identifying details are released.

 

The extent of the practice is difficult to gauge because some service providers involved have declined to discuss their practices. Many Web surfers, moreover, probably have little idea they are being monitored.

 

But at least 100,000 U.S. customers are tracked this way, and service providers have been testing it with as many as 10 percent of U.S. customers, according to tech companies involved in the data collection.

 

Although common tracking systems, known as cookies, have counted a consumer's visits to a network of sites, the new monitoring, known as "deep-packet inspection," enables a far wider view -- every Web page visited, every e-mail sent and every search entered. Every bit of data is divided into packets -- like electronic envelopes -- that the system can access and analyze for content.

 

"You don't want the phone company tapping your phone calls, and in the same way you don't want your ISP tapping your Web traffic," said Ari Schwartz of the Center for Democracy and Technology, an advocacy group. "There's a fear here that a user's ISP is going to betray them and turn their information over to a third party."

 

In fact, newly proposed Federal Trade Commission guidelines for behavioral advertising have been outpaced by the technology and do not address the practice directly. Privacy advocates are preparing to present to Congress their concerns that the practice is done without consumer consent and that too little is known about whether such systems adequately protect personal information.

 

Meanwhile, many online publishers say the next big growth in advertising will emerge from efforts to offer ads based not on the content of a Web page, but on knowing who is looking at it. That, of course, means gathering more information about consumers.

 

Advocates of deep-packet inspection see it as a boon for all involved. Advertisers can better target their pitches. Consumers will see more relevant ads. Service providers who hand over consumer data can share in advertising revenues. And Web sites can make more money from online advertising, a $20 billion industry that is growing rapidly.

 

With the service provider involved in collecting consumer data, "there is access to a broader spectrum of the Web traffic -- it's significantly more valuable," said Derek Maxson, chief technology officer of Front Porch, a company that collects such data from millions of users in Asia and is working with a number of U.S. service providers.

 

Consider, say, the Boston Celtics Web site. Based on its content, it posts ads for products a Celtics fan might be interested in: Adidas, a Boston hotel and so on.

 

With information about users from deep-packet inspection, however, advertisers might learn that the person looking at the Celtics Web site is also a potential car customer because he recently visited the Ford site and searched in Google for "best minivans." That means car companies might be interested in sending an ad to that user at the Celtics site, too.

 

For all its promise, however, the service providers exploring and testing such services have largely kept quiet -- "for fear of customer revolt," according to one executive involved.

 

It is only through the companies that design the data collection systems -- companies such as NebuAd, Phorm and Front Porch -- that it is possible to gauge the technology's spread. Front Porch collects detailed Web-use data from more than 100,000 U.S. customers through their service providers, Maxson said. NebuAd has agreements with providers covering 10 percent of U.S. broadband customers, chief executive Bob Dykes said.

 

In England, Phorm is expected in the coming weeks to launch its monitoring service with BT, Britain's largest Internet broadband provider.

 

NebuAd and Front Porch declined to name the U.S. service providers they are working with, saying it's up to the providers to announce how they deal with consumer data.

 

Some service providers, such as Embarq and Wide Open West, or WOW, have altered their customer-service agreements to permit the monitoring.

 

Embarq describes the monitoring as a "preference advertising service." Wide Open West tells customers it is working with a third-party advertising network and names NebuAd as its partner.

 

Officials at WOW and Embarq declined to talk about any monitoring that has been done.

 

Each company allows users to opt out of the monitoring, though that permission is buried in customer service documents. The opt-out systems work by planting a "cookie," or a small file left on a user's computer. Each uses a cookie created by NebuAd.

 

Officials at another service provider, Knology, said it was working with NebuAd and is conducting a test of deep-packet inspection on "several hundred" customers in a service area it declined to identify.

 

"I don't view it as violating any privacy data at all," said Anthony Palermo, vice present of marketing at Knology. "My understanding is that all these companies go through great pains to hash out information that is specific to the consumer."

 

One central issue, of course, is how well the companies protect consumer data.

 

NebuAd promises to protect users' privacy in a couple of ways.

 

First, every user in the NebuAd system is identified by a number that the company assigns rather than an Internet address, which in theory could be traced to a person. The number NebuAd assigns cannot be tracked to a specific address. That way, if the company's data is stolen or leaked, no one could identify customers or the Web sites they've visited, Dykes said.

 

Nor does NebuAd record a user's visits to pornography or gaming sites or a user's interests in sensitive subjects -- such as bankruptcy or a medical condition such as AIDS. The company said it processes but does not look into packets of information that include e-mail or pictures.

 

What it does do is categorize users into dozens of targeted consumer types, such as a potential car buyer or someone interested in digital cameras.

 

Dykes noted that by a couple of measures, their system may protect privacy more than such well-known companies as Google. Google stores a user's Internet address along with the searches made from that address. And while Google's mail system processes e-mail and serves ads based on keywords it finds in their text, NebuAd handles e-mail packets but does not look to them for advertising leads.

 

Such privacy measures aside, however, consumer advocates questioned whether monitored users are properly informed about the practice.

 

Knology customers, for example, cull the company's 27-page customer service agreement or its terms and condition for service to find a vague reference to its tracking system.

 

"They're buried in agreements -- who reads them?" said David Hallerman, a senior analyst at eMarketer. "The industry is setting itself up by not being totally transparent. . . . The perception is you're being tracked and targeted."

[Vinni]

а вот детальная техническая информация о том, как это устроено - http://www.cl.cam.ac.uk/~rnc1/080404phorm.pdf

 

...

A Inspecting trac

1. The basic concept behind the Phorm architecture is that they wish to take a copy of the

trac that passes between an end-user and a website. This enables their systems to inspect

what requests were made to the website and to determine what content came back from

that website. An understanding of the types of websites visited is used to target adverts

at particular users.

2. The actual mechanics of taking the copy diers from ISP to ISP, but one can view it

as a \Layer 7 switch", implemented using Policy Based Routing (PBR) or Deep Packet

Inspection (DPI). This switch is capable of providing a view of the web session to out-of-

band machines. By \out-of-band" I mean the original session is not aected by the act of

making a copy, and neither end is capable of directly determining that a copy has been

made.

3. The \Layer 7 switch" only inspects trac on port 80, the conventional port used for web

browsing using the HTTP protocol. Trac on other ports will be entirely ignored by the

Phorm system.

4. Since the device is a Layer 7 switch, it understands the HTTP protocol itself, and can pick

apart the requests and responses that are being made. If the trac does not appear to be

HTTP (it is another protocol using port 80, or perhaps it is encrypted) then the trac

will be ignored by the Phorm system.

5. The \Layer 7 switch" is also capable of redirecting trac so that it does not reach the

\true destination" but instead is serviced by a machine within the ISP's network that,

for example, does some sleight-of-hand to check whether the user has opted-out of the

system, and if not, to determine the Unique Identier (UID) by which they are known to

the Phorm system.

6. The various ISPs who will implement the Phorm system may operate their own opt-in or

opt-out systems, these are not considered further.

7. In the meeting, Phorm stated their preference for an opt-out system, indicating that they

believed this would lead to higher overall usage.

B Cookies

8. A quick review of \cookie" handling is order. . . more details can be found in RFC2695

and the original Netscape specication.

9. Along with requested content, a website can return a text string called a \cookie" which

will be automatically stored by the user's browser. Any further requests to the same

website will be automatically accompanied by the cookie, and hence the website will be

able to link requests together { perhaps to record progress through a procedure, or to keep

track of visitor preferences.

10. It is a key design aspect of cookies that they are linked to a particular domain and are

only returned to a website within that domain { which means that a given website will

never receive a cookie that is associated with a completely dierent website.

2

11. However, cookies can be supplied by a website with the name of another website within

them. This is often associated with banner ads, served from a dierent domain. This form

of cookie is called a \third party" cookie and modern browsers will disable them (viz: the

cookies are not stored or returned) if the user requests this.

12. Further discussion will be solely about \rst party" cookies which are only set by and

returned to a particular domain. These cookies can also be disabled on user request either

for a particular site or for all sites, although in practice many sites do not work well without

cookies being enabled.

13. Turning now to the Phorm system. Consider the rst web request made by a user, for, let

us say, http://www.cnn.com/index.html. This will take the form of a GET request for

index.html with a HOST header of www.cnn.com.

14. The Layer 7 switch will see that the request does not contain a Phorm \cookie" and

will direct the request to a machine located within the ISP network that will pretend to

be www.cnn.com and will return a \307" response which says, in eect, \you want that

page over there". The page that will be directed to is webwise.net/bind/?<parameters>

where the parameters record the original URL that was wanted.

15. The user's browser will now wish to visit the webwise.net page it has been redirected to,

and will issue an appropriate GET request for this page. If the user already has a cookie

for webwise.net then this will, as is standard, accompany the request.

16. The Layer 7 switch will again direct the request to a special machine (within the ISP's

network for performance reasons if nothing else). This special machine, which is now acting

as webwise.net, will inspect any existing cookie to establish the current UID associated

with the user. If there is no cookie then a new UID will be issued instead.

17. The response from webwise.net will be a 307 response redirecting the user to a special

URL on www.cnn.com. The response will also contain a cookie (in the webwise.net

domain) which contains the UID that is used to track the user. The special URL will also

contain a copy of this UID, along with the original request that the user made.

18. The special URL on www.cnn.com will now be fetched by the user's browser, and the

Layer 7 switch will recognise the request (from its form) as once again to be redirected to

the special machine, which will once again pretend to be www.cnn.com.

19. The special machine will return a third and nal 307 redirection, and this time the desti-

nation URL will be the www.cnn.com/index.html page that the user has been waiting to

visit all along.

20. The response in paragraph 19 will also set a special \webwise" labelled cookie within

the www.cnn.com domain { which it will expect to be accepted because the machine is

pretending to be www.cnn.com. This cookie will contain the user's UID.

21. Finally the user's browser will re-issue the original request for www.cnn.com/index.html

but this time it will be accompanied by the webwise cookie that has just been set in the

www.cnn.com domain, and so the Layer 7 switch will permit it to pass through to the real

CNN site.

22. The specious cookie (from the point of view of www.cnn.com) will be removed as the

request passes through the Layer 7 switch.

3

23. The cookie has a lifetime of three days.

24. If, later on, the www.cnn.com website was to be visited via another ISP that was not using

a Phorm system (or if subsequent accesses were made using the \https" protocol) then

the cookie would reach www.cnn.com.

25. Phorm believe that by placing their name (webwise) within the cookie they place within

the www.cnn.com domain, no clash { or other bad eects { can occur.

26. Further requests for www.cnn.com pages (and all the other bits and pieces that make

up a modern web page, such as images, pop-ups, cascading style sheets and so on) will

automatically contain the webwise cookie, and so there will be no need to redirect any of

these. The behaviour at this stage underlies the claim made by Phorm that their system

does not slow down browsing.

27. If the user has disabled cookies for CNN (viz: they don't record their values and don't

supply them with further requests), then there is potential for an innite loop { repeating

all the 307 responses forever. The Layer 7 switch recognises this situation and records

that future trac (at least for a while) from the particular IP address to the particular

(CNN) domain is not to be redirected.

28. If the user has set a cookie within the webwise.net domain indicating that they do not

wish to be tracked, then this preference is passed to the Layer 7 switch during the process in

paragraph 16 above. The details on how this is done were not explained by Phorm. . . but

it is presumably related to the mechanism described in the previous paragraph.

29. If the user does not accept any cookies in the webwise.net domain then they will always

be allocated a new identier for every website they visit. This situation is detected by the

Layer 7 switch and the IP address is \blacklisted" and future trac is not redirected.

30. Note that the blacklisting of IP addresses by the Layer 7 switch (as described in the

three previous paragraphs), whether general, or for particular domains, will apply to all

of the users who are sharing a particular IP address, not just users with a particular UID.

However, because the \blacklisting" will time out eventually, the exact behaviour will

depend upon the mixture of requests made by dierent users who have dierent browser

settings.

31. Phorm told us that the UID which is allocated to the user is a 16 byte value chosen at

random. That is to say it is just a number. It is not, for example, an encryption of some

data that might later be decrypted. The actual value sent on the wire will be base-64

encoded, so it will be seen by humans as a 22 character string.

32. If, for whatever reason, the user discards cookies for other websites, such as www.cnn.com,

then { provided that they have not discarded their webwise.net cookie { they will retain

their existing UID.

33. If the user discards their webwise.net cookie then they will be continue to be tracked

under their old identity for up to three days whilst visiting sites that they have visited

before (because of the cookie in that website's domain). They will however acquire a new

UID for all new websites. Phorm have no way of linking the old UID and the new UID

together, so the user in eect gets a fresh new identity.

 

...

[Vinni]

для тех, кто хочет узнать, о чем "стучат" на него по SSL те или иные веб-сайты или программы (например, Google Desktop Search) можно воспользоваться программой Charles proxy, которая позволяет вклиниваться в SSL-сессии.

Для этого он динамически сам генерирует фиктивные сертификаты для посещаемых сайтов (у него свой CA и можно для удобства сделать его доверенным). IE7 ругается, но позволяет зайти, например, на Gmail и посмотреть тело всех запросов и ответов, отправляемых в ходе сеанса....

 

Можно узнать много интересного... ;-)

 

 

 

[Vinni]

оказывается не все так плохо с анонимностью :smile1:

Вот сообщение SANS, в котором обсуждается пример ситуации, когда для скрытия настоящих адресов злоумышленники использовали платный сервис анонимизации. В пиндостане его быстро прикрыли, а вот в Швеции будут проблемы даже с тем, чтобы получить логи этого сервиса :smile3:

 

_ttp://isc.sans.org/diary.html?n&storyid=5065

 

Data exfiltration and the use of anonymity providers

 

Crime analysts take particular care in identifying how a culprit removes stolen goods from the crime scene. This process can reveal how thoroughly the theft was planned, and how well resourced the attacker was. Tracking some digital data theft incidents, we’ve noticed an interesting switch in the modus operandi of a number of threat agents.

 

In the past, stolen data was usually moved from the compromised network onto networks under different legal jurisdiction, often in East Asia. As of May of this year, however, we noticed these gradually swapping out for networks within the EU and the US. This seemed a bit awkward.

 

Certain hosts started tunneling data to the network of an Indiana based provider of anonymity services, SecureIX. This provider allows users to set up a PPTP VPN connection to its servers, then hiding all their traffic behind a SecureIX IP address. The service is intended for well-meaning users who wish to remain anonymous while surfing. However, the for-a-fee SecureIX service also allows users to run services through such IP address. Hosts compromised by the attackers were configured to ship data to a specific port on a SecureIX IP, from where it was tunneled back to the attacker.

 

 

Diagram of a data exfiltration setup using anonimity providers

 

 

It’s important to understand that organizations such as SecureIX are not rogue service providers. As is the case with dynamic dns services, their services can however be abused by various criminal elements. However, their Terms of Service state:

 

* You remain solely responsible for your actions, and you agree to indemnify and hold harmless SecureIX, and any related businesses.


* You agree to only engage in lawful activities. Our service provides security, not immunity from local, state or federal laws.


* You understand that your privacy, although very important to us, can not be guaranteed.

 

This implies that the goal of the attackers is mainly to make analysts’ life more difficult. In the case of a prosecution, SecureIX would disclose the data it has on them. While it is still operational, on June 8th, the proprietors of SecureIX announced their service was now for sale.

 

Only two weeks after this announcement, something interesting happened. All hostnames previously pointing to SecureIX, suddenly resolved to the IP address space of Relakks. Relakks provides the same services, but from Sweden.

 

This organization was founded in collaboration with Sweden’s Pirate Party, and allows users to anonymously surf the internet. They provide identical service to SecureIX, but the legal implications are somewhat different, as they mention on their website:

 



”For Swedish authorities to force RELAKKS to hand over traffic data including your RELAKKS IP at a specific point in time, they will have to prove a case with the minimum sentence of two years imprisonment. Regarding inquires from other parties than Swedish authorities RELAKKS will never hand over any kind of information.”

 



While I am not a lawyer, this appears accurate under Swedish legislation.

 

Knowing that these attacks most likely originate from outside the country, there is some potential to investigate through means of the recent wiretapping laws that will be active in the country as of 2009. While this law is somewhat convoluted, it seems that in certain cases, it would potentially be possible for Swedish authorities to intercept traffic originating from abroad towards RELAKKS, and originating from RELAKKS towards foreign IP addresses.

 

Theoretically, this could allow for traffic pattern (not content, as traffic to and from the provider would likely carry different ciphertext) analysis and as such the identification of a ”loop” through Swedish IP space. It’s unlikely such extensive investigation would be undertaken for cases such as this, where damages are difficult to identify, let alone prove.

 

So, this makes law enforcement’s life somewhat harder. On the other hand, for network administrators this may be an asset. Each of the attacks connected out from the compromised corporate network onto the following ranges:

 

66.175.214/24 (SecureIX)

66.175.215

66.175.216


 

83.233.180/24 (Relakks)

83.233.181 


83.233.182

83.233.183

83.233.168

83.233.169

 

These are relatively small networks, and I would recommend any organization that has been affected by targeted attacks in the past to carefully review egress connections towards these networks.

 

Note that we are not advertising this as a blocklist: these services have very legitimate purposes, and many people use them for exactly what they are intended for: to browse the internet anonymously. While it’s completely benign for a client to use one of these services to connect to your corporate web service, a host on your network should probably not be initiating connections to the above.

 

"Is Troy Burning", a presentation on targeted attacks I gave at SANSFire covers to some degree the various DNS configurations similar threat agents use to maintain stealthy access to networks. If you see anything of interest regarding this modus operandi, we would be very interested in hearing from you.

 

--

Maarten Van Horenbeeck

maarten at daemon.be