Tuesday, 25 March 2014

Detecting and Removing Trojan Horses



Detection – How to find a Trojan.


  • In this page you are going to learn about Detecting and Removing Trojan Horses. By their very nature Trojan horses are difficult to find. Unlike viruses they won’t corrupt files or delete things you might notice, they do their best to stay out of sight and avoid detection. That said, they are pieces of software and no software can run on any computer without leaving some trace of it’s existence. 
  • Below I’ll cover three basic tools that will uncover the presence of the majority of Trojan horses. None of these costs any money, in fact two of them are already installed on every windows computer!



The Task List


You may be familiar with the Task List that appears if you press CTRL+ALT+DEL within windows. This is supposed to be a list of all the programs running on your computer at the second you pressed those keys – it’s not. For reasons best known to themselves Microsoft hid a great many processes from display in the task list, possibly to avoid confusing novice users. In doing this, they gave trojan writers the perfect tool to hide their own creations from your view as well.

Less well known is the System Information Utility (msinfo32.exe) that hides in the

C:\program files\common\microsoft shared\msinfo

folder on your disk. This tool can uncover almost every process that’s running on any windows system, even those that are ‘hidden’ from the task list. Better yet, on windows 98 & ME the same tool provides an easy way to selectively disable any suspect processes at the next reboot. To use this when hunting for Trojans, look down the task listings for running tasks & services for any which you don’t recognize. Check the paths and file names. Check the file properties and run the executable or .dll through your virus scanner. If you find nothing but still aren't sure, use the Start up Programs editor in the tools menu to disable the process then reboot your machine (make a backup of your system files first!). If nothing complains, leave the process disabled for now and carry on looking at the others. Eventually you’ll have only those processes you really need running on your machine which will have the benefit of not only killing off any trojans but also making your PC seem more responsive and generally quicker to start up.


Netstat


  • All trojans need to communicate. If they don’t do that they are useless for their intended purpose. This is the second major weakness of most trojan horses, their communication leaves a trail you can follow.
  • The Netstat command lists all the open connections to and from your PC.
  • To use it, open a DOS box and enter the command netstat -an this will list all the open connections to and from your PC, along with the IP address of the machines on either side.
  •  If you see a connection you don’t recognise, you need to investigate it further and track down the process that’s using it. For this you need the third tool in the armoury, 



TCPView

  • TCPView is a free utility by Sysinternals which not only lists the IP addresses communicating with your computer, it tells you what program is using that connection. 
  • Armed with this information you can locate whatever program is sending data out of your machine and deal with it. 
  • I recommend renaming the offending file then rebooting – that way if you make a mistake you can put it right easily.


Removing a Trojan Horse

Trojans often modify the startup files of your computer, add or change lines in the system registry and even overwrite system files to make sure they are run every time you boot up. For that reason, removing them by hand takes time, patience and an understanding of what you are doing. It’s fraught with dangers, including trashing your registry or loosing the ability to run programs so it’s definatly not for everyone – even those who know exactly what they are doing often prefer to use automated tools when removing a trojan horse.
Each trojan has it’s own specific removal routine, see the Cleaners & Fixes pages for details on those. They do however all conform to the same basic patterns :
  • They usually insert a line in the run, run once or run services keys in the system registry. This is the principal startup method of most trojans including Back Orifice & Sub7. Removing the line from the registry and rebooting usually stops the trojan loading.
  • Some alter Win.ini, system.ini or plae themselves in the ‘Startup’ folder. Again, removing the offending line usually stops the trojan running.
  • Some alter or replace system files. These need careful handling and are best left to experts or automated tools.
  • One in particular can modify a certain setting in the registry, causing it to be executed before ANY program you run. removing this line stops you running ANYTHING! Again, this is best left to experts or automated tools to deal with.
The steps involved in removing a trojan are simple :
  1. Identify the trojan horse file on your hard disk.
  2. Find out how it is being started and take the necessary action to prevent it being restarted after a reboot.
  3. Reboot your machine and delete the trojan horse.
  4. See the Recovering from a System Compromise pages for more in-depth help on what else you may need to do.

Friday, 7 March 2014

"Girl killed herself" Facebook scam - be aware before you Share!

You know the saying about buses - you don't see one for ages, then three come along at once.
Facebook scams and hoaxes are a bit like that, except for the "you don't see one for ages" part.
But, judging by the most popular articles on Naked Security over the past couple of weeks, large-scale hoaxes and scams do sometimes come in threes.
A perfecta of long-running Facebook falsehoods has topped the charts recently.
Firstly, it was Talking Angela, the chat bot cat that was accused of all sorts ofdubious behavior - including behavior that isn't programmed into the software, couldn't have happened, yet was widely and regularly reported by people claiming "I saw it with my own eyes."
Secondly, it was the annual "Facebook will close from 29-31 February" hoax, circulated presumably as a joke but apparently taken seriously by some.
Now, it's the venerable "Girl killed herself video" bait-and-switch scam, already in its fifth year, that is making a reappearance.
→ Hoaxes and scams aren't the same, but they are similar in how they end up being shared over and over again. Generally, hoaxes are bogus warnings that spread because people forward them on the assumption that it's better to be safe than sorry. Scams are bogus links that spread because people forward them in return for some illusory benefit, such as access to an intriguing-sounding video.
We've written about the "Girl killed herself" video before, right back to 2010.
There are numerous variations on the theme, but the premise is often that a teenager committed suicide in shame after being caught out, perhaps by her own father, in some sort of inappropriate online activity.
There's a video, and you're invited to watch.
Here's how this sort of scam plays out, based on one of the versions circulating right now:
1. One of your friends Shares a link along the lines of "Girl killed herself live on cam."
2. It comes from a friend, so you click the link and arrive at a page that doesn't overtly claim to be affiliated with Facebook, but nevertheless uses visual clues to make it look more official than it is.
3. You're invited to Like the publisher's Facebook page, a request that seems routine and harmless enough:

4. If you take a look, the publisher's page was recently created and might best be described as uninspired and uninspiring, but it seems harmless enough, perhaps leading you into a false sense of safety. (Banality is a surprisingly good cover for scammers, when you think about it.)

5. You can skip past the Like popup, but before you watch the video, you are forced to Share it:
 6. And once you have shared it, you need to answer some questions as a sort of CAPTCHA - one of those tests to prove you're a person, in this case a person who's old enough to watch adult videos:
→ CAPTCHA stands for Completely Automated Procedure for Telling Computers and Humans Apart. CAPTCHAs are challenges that are meant to be reasonably easy for humans to work out, but tricky for computers to process accurately. Examples include reading fuzzy characters against a distracting background, or answering arithmetical questions written out longhand using words, not symbols.
Except that the questions to prove you are illegible are, in fact, pay-per-click surveys or special offer pages that clock up revenue for the scammers every time someone fills them in:

Saturday, 3 August 2013

5 Physical security tips for protecting your Devices





As we read earlier this week, the chances that one or more of your digital devices may get stolen are uncomfortably high. So what would happen if your mobile device falls into the wrong hands? Here are a few tips that will help minimize the damage if it happens to you.

1. Password-protect your computing devices.


While it sounds obvious, if anyone steals your device they will have to defeat your password to get at your data and accounts, which will significantly slow attackers. Although it is not impossible to defeat password protection on a digital device, it adds a useful layer of protection, buying you time to locate and recover the device.

2. Always backup your files.


Why? Even if you can’t recover a stolen device that does not mean you have to lose all your information and software. Regular backups are the ultimate defense against theft of your files. There are plenty of options for backup these days including online backup. (Here’s an example of an online backup service.)

My colleague David Harley has written about backup here on the blog and here is a link to Aryeh Goretsky’s white paper on the subject (.pdf). Taking the time to setup backup really pays off if a device is stolen, helping reduce the pain involved in re-creating the sensitive content.

3. Use tracking software to help get your stolen device back.


Why? Getting your stolen device back is not impossible, particularly if the device itself can tell you where it is and you can communicate with it using a sort of “remote control” via SMS or other methods. You may even be able to communicate with the person who has it. (Here’s an example of how one piece of anti-theft software for PCs.)

4. Don’t tempt thieves with unattended mobile devices, particularly in public places.


Why? Leaving your computer or mobile device unattended in a car, airport or restaurant is akin to asking for it to be stolen. In a recent survey we found that 1 in 5 stolen devices were taken from a car, 12% from an airport, train, bus, or other public transportation, and 11% from a restaurant or coffee shop. (Here’s an example of anti-theft software for Android devices.)

5. Encrypt sensitive data.


Why? Storing sensitive data in encrypted files prevents anyone exploiting your data if your computer is stolen. Note: File encryption is available free on recent version of both the Microsoft Windows and apple Mac OS X operating systems. This step is a lot easier than it used to be, so the pain level is low these days (unlike in years past).
Bonus tip. 

Think about removing sensitive data from your device.


Why? Your computer may interact with sensitive data but it does not need to store all of it right there in one place. Consider using encrypted removable media for sensitive data and carrying that separate from the computer. Maybe leave sensitive work files on the company network and access remotely over a secure connection. This way, if “bad things” happen, you’ll have much lower likelihood that the bad actors got off with critical information.

Tuesday, 30 July 2013

Fasrt secure Protocol


Aspera's fasp transfer technology is an innovative software that eliminates the fundamental bottlenecks of conventional file transfer technologies such as FTP, HTTP, and Windows CIFS, and dramatically speeds transfers over public and private IP networks.

The approach achieves perfect throughput efficiency, independent of the latency of the path and robust to packet losses. In addition, users have extra-ordinary control over individual transfer rates and bandwidth sharing, and full visibility into bandwidth utilization. File transfer times can be guaranteed, regardless of the distance of the endpoints or the dynamic conditions of the network, including even transfers over satellite, wireless, and inherently long distance and unreliable international links. Complete security is built-in, including secure endpoint authentication, on-the-fly data encryption, and integrity verification

In this digital world, fast and reliable movement of digital data, including massive sizes over global distances, is becoming vital business success across virtually every industry. The Transmission Control Protocol(TCP) that has traditionally been the engine of this data movement, however has inherent bottlenecks in performance(fig 1), especially for networks with high round-trip time and packet loss, and most pronounced on high-bandwidth networks. It is well understood that these inherent “soft” bottlenecks are caused by TCP’s Additive. Increase Multiplicative Decrease(AIMD) congestion avoidance algorithm, which slowly probes the available bandwidth of the network, increasing the transmission rate until packet loss is detected and then exponentially reducing the transmission rate.

However, it is less understood that other sources of packet losses due to physical network media, not associated with network congestion equally reduce the transmission rate. In fact, TCP AIMD itself creates losses, and equally contributes to the bottleneck. In ramping up the transmission rate until loss occurs, AIMD inherently overdrives the available bandwidth. In some cases, this self-induced loss actually surpasses loss from other causes (E.g. Physical media) and turns a loss free communication “channel” into an unreliable “channel” with an unpredictable loss ratio. The loss-based congestion control in TCP AIMD has a deadly impact on throughput: Every packet loss leads to retransmission, and stalls the delivery of data to the receiving application until retransmission occurs. This can slow the performance of any network application but is fundamentally flawed for reliable transmission of large “bulk” data, for example file transfer, which does not require in-order (byte-stream delivery).

Shortcomings of TCP Transfer



Transferring large data sets—big files, big collections of files—via inexpensive IP networks, instead of shipping tapes, discs, or film, promises to change fundamentally the economics of content production, distribution, and management. Under ideal conditions, data may be moved quickly and inexpensively using ordinary file transfer methods such as FTP, HTTP, and Windows CIFS copy. However, on real wide-area and high-speed network paths these methods' throughput collapses, failing to use more than a small fraction of available capacity. This is a consequence of the design of TCP, the underlying protocol they all rely on. New TCP stacks and new network acceleration devices are marketed to help, but they fail to fully utilize many typical wide-area network paths. Consequently, conventional FTP, and even new "acceleration" solutions, cannot provide the speed and predictability needed for global file transfers.

 

The TCP bottleneck in file transfer


The transmission control protocol (TCP) that provides reliable data delivery for conventional file transfer protocols has an inherent throughput bottleneck that becomes more severe with increased packet loss and latency. The bar graph shows the maximum throughput achievable under various packet loss and network latency conditions on an OC-3 (155 Mbps) link for file transfer technologies that use TCP (shown in yellow). Transmission rates are defined by rate of the bitstream of the digital signal and are designated by hyphenation of the acronym OC and an integer value of the multiple of the basic unit of rate, e.g., OC-48. The base unit is 51.84 Mbit/s. Thus, the speed of optical-carrier-classified lines labeled as OC-n is n × 51.84 Mbit/s. The throughput has a hard theoretical limit that depends only on the network round-trip time (RTT) and the packet loss. Note that adding more bandwidth does not change the effective throughput. File transfer speeds do not improve and expensive bandwidth is underutilized. OC-3 is a network line with transmission speed of up to 155.52 Mbit/s (payload: 148.608 Mbit/s; overhead: 6.912 Mbit/s, including path overhead) using fiber optics. Depending on the system OC-3 is also known as STS-3 (electrical level) and STM-1 (SDH).

Consequences

TCP file transfers are slow and bandwidth utilization of single file transfers is poor. In local or campus area networks, where packet loss and latency are small but non-negligible (0.1%/10ms), the maximum TCP throughput is 50 Mbps. Typical file transfer rates are lower, 20-40 Mbps (with TCP stack tuning on the endpoints) on gigabit ethernet. Because standard TCP halves its throughput in response to a single packet loss event, at high speeds, even a low loss percentage significantly lowers TCP throughput. Even with an abundance of bandwidth, transfer times are disappointing and expensive bandwidth is underutilized. The bandwidth utilization problem compounds on wide area links where increased network latency combines with packet loss.

A typical FTP transfer across the United States has a maximum theoretical limit of 1.7 megabits per second (Mbps), the maximum throughput of a single TCP stream for 90ms latency and 1% loss, independent of link bandwidth. On typical intercontinental links or satellite networks, the effective file transfer throughput may be as low as 0.1% to 10% of available bandwidth. On a typical global link (3%/150ms), maximum TCP throughput degrades to 500-600 kilobits per second, 5% of a 10 Mbps link. Sometimes network engineers attempt to improve the throughput by "tuning" the operating system parameters used by the TCP networking stack on the file transfer endpoints or applying a TCP acceleration device.

While this technique boosts throughput on clean networks, the improvement vanishes when real packet loss due to channel characteristics or network congestion increases. TCP file transfers over difficult networks (with high packet loss or variable latency) are extremely slow and unreliable. TCP does not distinguish packet losses due to network congestion from normal latency variations or bit errors on some physical channels such as satellite links and wireless LANs, and severely self-throttles. FTP throughput over good satellite conditions is 100 kbps and degrades by more than half during high error periods such as rain fade. Large transfers can be extremely slow and may not complete. TCP file transfer rates and times are unpredictable. As a window-based protocol, TCP can only determine its optimal rate through feedback from the network.

TCP overdrives the network until packets are dropped by intervening routers, and in the best case, oscillates around its optimal rate, causing instabilities in the network for file transfer and other applications. Over commodity Internet links where traffic loads vary, file transfer rates may vary widely with network load. File transfers slow down and may exceed the allotted time window,. TCP acceleration devices may improve throughput and smooth the transfer rate when links are clean, but are also window-based and subject to unpredictable back off.


Complete Security

The fasp protocol provides complete built-in security without compromising transfer speed. The security model, based solely on open standards cryptography, consists of secure authentication of the transfer endpoints using the standard secure shell (SSH), on-the-fly data encryption using strong cryptography (AES-128) for privacy of the transferred data, and an integrity verification per data block, to safeguard against man-in-the-middle and anonymous UDP attacks. The transfer preserves the native file system access control attributes between all supported operating systems, and is highly efficient: With encryption enabled, fasp achieves WAN file transfers of 40-80 Mbps on a laptop computer; 100-150 Mbps on a P4 or equivalent single processor machine; and 200-400 Mbps+ on dual-processor or duo-core workstations.

 Secure endpoint authentication


Each transfer session begins with the transfer endpoints performing a mutual authentication over a secure, encrypted channel, using SSH ("standard secure shell"). SSH authentication provides both interactive password login and public-key modes. Once SSH authentication has completed, the fasp transfer endpoints generate random cryptographic keys to use for bulk data encryption, and exchange them over the secure SSH channel. These keys are not written to disk, and are discarded at the end of the transfer session.

On-the-fly data encryption.


Using the exchanged keys, each data block is encrypted on-the-fly before it goes on the wire. fasp uses a 128-bit AES cipher, re-initialized throughout the duration of the transfer using a standard CFB (cipher feedback) mode with a unique, secret nonce (or "initialization vector") for each block. CFB protects against all standard attacks based on sampling of encrypted data during long-running transfers.

Integrity verification.


fasp accumulates a cryptographic hashed checksum, also using 128-bit AES, for each datagram. The resulting message digest is appended to the secure datagram before it goes on the wire, and checked at the receiver to verify message integrity. This protects against both man-in-the-middle and re-play attacks, and also against anonymous UDP denial-of-service attacks.

 

fasp vs. FTP on gigabit metropolitan and wide area networks


Conventional TCP file transfer technologies such as FTP dramatically reduce the data rate in response to any packet loss, and cannot maintain long-term throughputs at the capacity of high-speed links. For example, the maximum theoretical throughput for TCP-based file transfer under metropolitan area network conditions (0.1% packet loss and 10 ms RTT) is 50 megabits per second (Mbps), regardless of bandwidth. The effective FTP throughput is even less (22 Mbps). In contrast, fasp achieves 100% utilization of high-speed links with a single transfer stream.

Monday, 29 July 2013

Google File System


The great success of Google Inc. is attributed not only to its efficient search algorithm, but also to the underlying commodity hardware and, thus the file system.

As the number of applications run by Google increased massively, Google’s goal became to build a vast storage network out of inexpensive commodity hardware. Google created its own file system, named as Google File System.

Google File System was innovatively created by Google engineers and ready for production in record time in a span of one year in 2003, which speeded Google’s market thereafter. Google File system is the largest file system in operation.

Formally, Google File System (GFS) is a scalable distributed file system for large distributed data intensive applications. In the design phase of GFS, points which were given stress includes component failures are the norm rather than the exception, files are huge in the order of MB & TB and files are mutated by appending data. The entire file system is organized hierarchically in directories and identified by pathnames.

The architecture comprises of a single master, multiple chunk servers and multiple clients. Files are divided into chunks, which is the key design parameter. Google File System also uses leases and mutation order in their design to achieve consistency and atomicity. As of fault tolerance, GFS is highly available, replicas of chunk servers and master exists.


Assumptions


In designing a file system for Google’s needs, they have been guided by assumptions that offer both challenges and opportunities.

• The system is built from many inexpensive commodity components that often fail. It must constantly monitor itself and detect, tolerate, and recover promptly from component failures on a routine basis.

• The system stores a modest number of large files. Usually a few million files, each typically 100 MB or larger in size. Multi-GB files are the common case and should be managed efficiently. Small files must be supported, but need not optimize for them.

• The workloads primarily consist of two kinds of reads: large streaming reads and small random reads. In large streaming reads, individual operations typically read hundreds of KBs, more commonly 1 MB or more. Successive operations from the same client often read through a contiguous region of a file. A small random read typically reads a few KBs at some arbitrary offset. Performance-conscious applications often batch and sort their small reads to advance steadily through the file rather than go back and forth.

• The workloads also have many large, sequential writes that append data to files. Typical operation sizes are similar to those for reads. Once written, files are seldom modified again. Small writes at arbitrary positions in a file are supported but do not have to be efficient.

• The system must efficiently implement well-defined semantics for multiple clients that concurrently append to the same file. The files are often used as producer consumer queues or for many-way merging. Hundreds of producers, running one per machine, will concurrently append to a file. Atomicity with minimal synchronization overhead is essential. The file may be read later, or a consumer may be reading through the file simultaneously.

• High sustained bandwidth is more important than low latency. Most of the target applications place a premium on processing data in bulk at a high rate, while few have stringent response time requirements for an individual read or write


Google File System Architecture

A GFS cluster consists of a single master and multiple chunkservers and is accessed by multiple clients. The basic analogy of GFS is master maintains the metadata; client contacts the master and retrieves the metadata about chunks that are stored in chunkservers; next time, client directly contacts the chunkservers. Figure 1 describes these steps more clearly.



Each of these is typically a commodity Linux machine running a user-level server process. Files are divided into fixed-size chunks. Each chunk is identified by an immutable and globally unique 64 bit chunk handle assigned by the master at the time of chunk creation. Chunkservers store chunks on local disks as Linux files and read or write chunk data specified by a chunk handle and byte range. For reliability, each chunk is replicated on multiple chunkservers. By default, three replicas are stored, though users can designate different replication levels for different regions of the file namespace. The master maintains all file system metadata. This includes the namespace, access control information, the mapping from files to chunks, and the current locations of chunks. It also controls system-wide activities such as chunk lease management, garbage collection of orphaned chunks, and chunk migration between chunkservers.

The master periodically communicates with each chunkserver in HeartBeat messages to give it instructions and collect its state. GFS client code linked into each application implements the file system API and communicates with the master and chunkservers to read or write data on behalf of the application. Clients interact with the master for metadata operations, but all data-bearing communication goes directly to the chunkservers. Neither the client nor the chunkserver caches file data. Client caches offer little benefit because most applications stream through huge files or have working sets too large to be cached.

Not having them simplifies the client and the overall system by eliminating cache coherence issues. (Clients do cache metadata, however.) Chunkservers need not cache file data because chunks are stored as local files and so Linux’s buffer cache already keeps frequently accessed data in memory. Before going into basic distributed file system operations like read, write, we will discuss the concept of chunks, metadata, master, and will also describe how master and chunkservers communicates.

Leases and Mutation:

mutation is an operation that changes the contents or metadata of a chunk such as a write or an append operation. Each mutation is performed at all the chunk’s replicas. Leases are used to maintain a consistent mutation order across replicas. The master grants a chunk lease to one of the replicas, which we call the primary. The primary picks a serial order for all mutations to the chunk. All replicas follow this order when applying mutations. Thus, the global mutation order is defined first by the lease grant order chosen by the master, and within a lease by the serial numbers assigned by the primary.

The lease mechanism is designed to minimize management overhead at the master. A lease has an initial timeout of 60 seconds. However, as long as the chunk is being mutated, the primary can request and typically receive extensions from the master indefinitely. These extension requests and grants are piggybacked on the HeartBeat messages regularly exchanged between the master and all chunkservers. The master may sometimes try to revoke a lease before it expires (e.g., when the master wants to disable mutations on a file that is being renamed). Even if the master loses communication with a primary, it can safely grant a new lease to another replica after the old lease expires.

Write algorithm is similar to Read algorithm, in terms of contacts between client, master, and chunkservers. Google keeps at least three replicas of each chunks, so in Read, we just read from one of the chunkservers, but in case of Write, it has to write in all three chunkservers, this is the main difference between read and write.

Following is the algorithm with related figures for the Write operation.

1. Application originates the request

2. GFS client translates request from (filename, data) -> (filename, chunk index), and sends it to master

3. Master responds with chunk handle and (primary + secondary) replica locations

4. Client pushes write data to all locations. Data is stored in chunkservers’ internal buffers

Conclusion

data processing workloads on commodity hardware. While some design decisions are specific to the unique setting, many may apply to data processing tasks of a similar magnitude and cost consciousness. Google started work on GFS by reexamining traditional file system assumptions in light of current and anticipated application workloads and technological environment. We treat component failures as the norm rather than the exception, optimize for huge files that are mostly appended to (perhaps concurrently) and then read (usually sequentially), and both extend and relax the standard file system interface to improve the overall system.

The system provides fault tolerance by constant monitoring, replicating crucial data, and fast and automatic recovery. Chunk replication allows us to tolerate chunkserver failures. The frequency of these failures motivated a novel online repair mechanism that regularly and transparently repairs the damage and compensates for lost replicas as soon as possible. Additionally, check summing is used to detect data corruption at the disk or IDE subsystem level, which becomes all too common given the number of disks in the system. The design delivers high aggregate throughput to many concurrent readers and writers performing a variety of tasks.

This is achieved by separating file system control, which passes through the master, from data transfer, which passes directly between chunkservers and clients. Master involvement in common operations is minimized by a large chunk size and by chunk leases, which delegates authority to primary replicas in data mutations. This makes possible a simple, centralized master that does not become a bottleneck. GFS has successfully met the storage needs and is widely used within Google as the storage platform for research and development as well as production data processing. It is an important tool that enables Google to continue to innovate and attack problems on the scale of the entire web.

Browser Security



The initial design of internet and web protocols assumed an environment where servers, clients, and routers cooperate and follow standard protocols except for unintentional errors.

However, as the amount sensitivity of usage increased, concerns about security, fraud and attacks became important. In particular, since currently internet access is widely available, it is very easy for attackers to obtain many client (and even host) connections and addresses, and use them to launch different attacks, both on the networking itself and on other hosts and clients.

Today's attackers are more likely to host their malicious files on the web. They may even update those files constantly using automated tools. When you are surfing the Internet, it is easy to visit sites you think are safe but are not. These sites can introduce malware when you click the site itself, when you download a file from the site manually and install it, or worse,

when you are conned into believing the site you are visiting is a real site, but in fact is nothing more than a fake used to garner your personal information. From a network security perspective, a browser is essentially a somewhat controlled hole in your organization’s firewall that leads to the heart of

what it is you are trying to protect.

While browser designers do try to limit what attackers can do from within a browser, much of the security relies far too heavily on the browser user, who often has other interests besides security. There are limits to what a browser developer can compensate for, and browser users will not always accept the constraints of security that a browser establishes.


Open Browser Engineering Issues


Other than the general design of HTTP, HTML, and related mechanisms discussed previously, a handful of browser engineering decisions tend to contribute to a disproportional of day-to-day security woes.

Understanding these properties is sometimes important for properly assessing the likelihood and maximum impact of security breaches, and hence determining the safety of user data. Some of the pivotal, open-ended issues include:


 Relatively unsafe core programming languages:
C++ is used for a majority of code in Internet Explorer, Firefox, Safari, Opera, and Chrome; C is used in certain highperformance or low-level areas, such as image manipulation libraries.

The choice of C and C++ means that browsers are regularly plagued by memory management and integer overflow problems, despite considerable ongoing audit efforts.

 No security compartmentalization:
once control of the process is seized due to common implementation flaws, most browsers provide essentially unconstrained access to the user context they are running in. This means that browser bugs - historically, very common - easily lead to total system integrity loss.

 Inconsistent and haphazard data storage practices:
browsers use a mix of random storage methods to keep temporary files, downloads, configuration data, and sensitive records such as passwords, browsing history, saved cookies, or cache entries. These methods include system registry, database container files, drop-off directories, text-based configs (CSV, INI, tab-delimited, XML), and proprietary binary files.

The data may be stored in user home directories, system-wide temporary directories, or global program installation folders. Controlling the permissions on all these resources and manipulating them securely is relatively difficult, contributing to many problems, particularly in multi-user systems, or when multiple browsers are used by the same user.

 Web technologies are used in browser chrome:
JavaScript, HTML, and XML are all used to a varying degree to implement some browser internals and various diagnostic and error pages in most browsers. This choice contributes to an elevated risk of HTML injection flaws that permit web content to gain elevated chrome privileges, which - depending on the browser - may carry the permission to read or write files, access arbitrary sites on the Internet, or alter browser settings. The problem is particularly pronounced for Firefox, which implements much of its user interface in this manner.

 Inconsistent and overly complex security UIs:
a vast majority of browsers employ highly inconsistent UI elements and security messaging, including several styles of modal prompts, interstitials, icons, color codes, and messages that pop up either on the bottom or on the top of the document window. Usability studies consistently show that at least some of these features are easily misidentified, misunderstood, or trivial to spoof (this is particularly the case for interstitials and notification bars that are not anchored in browser UI). Although a gradual improvement may be observed in certain aspects, further coordinated work in this area seems to be necessary.



Phishing Techniques


 Link manipulation :
Most methods of phishing use some form of technical deception designed to make a link in an e-mail (and the spoofed website it leads to) appear to belong to the spoofed organization. Misspelled URLs or the use of subdomains are common tricks used by phishers. In the following example URL, http://www.yourbank.example.com/, it appears as though the URL will take you to the example section of the yourbank website; actually this URL points to the "yourbank" (i.e. phishing) section of the example website.

Another common trick is to make the anchor text for a link appear to be valid, when the link actually goes to the phishers' site. The following example link, http://en.wikipedia.org/wiki/Genuine, appears to take you to an article entitled "Genuine"; clicking on it will in fact take you to the article entitled "Deception". In the lower left hand corner of most browsers you can preview and verify where the link is going to take you.

 Filter evasion:
Phishers have used images instead of text to make it harder for antiphishing filters to detect text commonly used in phishing e-mails.

 Phone phishing: Not all phishing attacks require a fake website. Messages that claimed to be from a bank told users to dial a phone number regarding problems with their bank accounts. Once the phone number (owned by the phisher, and provided by a Voice over IP service) was dialed, prompts told users to enter their account numbers and PIN.

Vishing (voice phishing) sometimes uses fake caller-ID data to give the appearance that calls come from a trusted organization.

 Website forgery:
Once a victim visits the phishing website the deception is not over. Some phishing scams use JavaScript commands in order to alter the address bar. This is done either by placing a picture of a legitimate URL over the address bar, or by closing the original address bar and opening a new one with the legitimate URL.
How Do We Know?

 Phishers, pretending to be legitimate companies, may use email to request personal information and direct recipients to respond through malicious web sites
/
 Phishers tend to use emotional language using scare tactics or urgent requests to entice recipients
to respond

 The phish sites can look remarkably like legitimate sites because they tend to use the copyrighted images from legitimate sites

 Requests for confidential information via email or Instant Message tend to not be legitimate

 Fraudulent messages are often not personalized and may share similar properties like details in the header and footer

What a Browser Designer should do?

Proactive and reactive developers can generate an endless series of software updates. As a responsible defender, your dilemma is that allowing these updates in to your users without testing may break applications or even introduce security holes, but not allowing them may leave your enterprise open to even more serious attacks. Distributed management provides some help in this area, but all major browsers are weaker than many defenders would like them to be. Microsoft provides the free Internet Explorer Administration Kit, which sets the bar for enterprise browser deployment and management tools, but that bar is lower than many would care for.


FirefoxADM, an open source project for managing collections of Firefox browsers, is far more limited but a step in the right direction. FrontMotion provides a Webbased tool that allows a defender to create packages with approved software, configuration, and plug-ins for Firefox. All are available for Windows platforms only. Firefox and Google's Chrome browser have implemented sandboxes, in which the browser runs code (such as JavaScript or Flash) in a compartmentalized area of the  Program that provides only limited resources for the program and whose design is heavily scrutinized for security flaws. Internet Explorer uses a zone-based security model, in which security features are enabled or disabled depending on the site being accessed.


Under Vista, Internet Explorer runs in what is known as Protected Mode, which limits the operating-system privileges the browser program can exercise. Open source developers especially must be very careful about designing and implementing sandbox systems, because their sandbox source code is available to the attacker for study and testing. This is, of course, no surprise to the sandbox developers and one reason why open source sandboxes tend to improve quickly.
Conclusion
Browsers are at the heart of the Internet experience, and as such they are also at the heart of many of the security problems that plague users and developers alike. As the sensitivity of internet usage increased concerns about security, fraud and attacks became important. There are limits to what a browser developer can compensate for, and browser users will not always accept the constraints of security that a browser establishes. Attack and defense strategies are coevolving, as are the use and threat models. As always, anybody can break into anything if they have sufficient skill, motivation and opportunity. The job of browser developers, network administrators, and browser users is to modulate those three quantities to minimize the number of successful attacks.




























































Mind Reader Computer



Definition of Mind-Reading Computer

Drawing inspiration from psychology, computer vision and machine learning, the team in the Computer Laboratory at the University of Cambridge has developed mind-reading machines - computers that implement a computational model of mind-reading to infer mental states of people from their facial signals.

The goal is to enhance human-computer interaction through empathic responses, to improve the productivity of the user and to enable applications to initiate interactions with and on behalf of the user, without waiting for explicit input from that user. There are difficult challenges:

Using a digital video camera, the mind-reading computer ppt system analyzes a person's facial expressions in real time and infers that person's underlying mental state, such as whether he or she is agreeing or disagreeing, interested or bored, thinking or confused.

Prior knowledge of how particular mental states are expressed in the face is combined with analysis of facial expressions and head gestures occurring in real time. The model represents these at different granularities, starting with face and head movements and building those in time and in space to form a clearer model of what mental state is being represented.

Software from Nevenvision identifies 24 feature points on the face and tracks them in real time. Movement, shape and colour are then analyzed to identify gestures like a smile or eyebrows being raised. Combinations of these occurring over time indicate mental states. For example, a combination of a head nod, with a smile and eyebrows raised might mean interest.

The relationship between observable head and facial displays and the corresponding hidden mental states over time is modeled using Dynamic Bayesian Networks.


Why mind reading?

The mind-reading computer system presents information about your mental state as easily as a keyboard and mouse present text and commands. Imagine a future where we are surrounded with mobile phones, cars and online services that can read our minds and react to our moods.

How would that change our use of technology and our lives? We are working with a major car manufacturer to implement this system in cars to detect driver mental states such as drowsiness, distraction and anger.

Current projects in Cambridge are considering further inputs such as body posture and gestures to improve the inference. We can then use the same models to control the animation of cartoon avatars.

We are also looking at the use of mind-reading to support on-line shopping and learning systems.
The mind-reading computer system may also be used to monitor and suggest improvements in human- human interaction.

The Affective Computing Group at the MIT Media Laboratory is developing an emotional-social intelligence prosthesis that explores new technologies to augment and improve people's social interactions and communication skills.

How does it work?
Futuristic headband

The mind reading actually involves measuring the volume and oxygen level of the blood around the subject's brain, using technology called functional near-infrared spectroscopy (fNIRS).

The user wears a sort of futuristic headband that sends light in that spectrum into the tissues of the head where it is absorbed by active, blood-filled tissues. The headband then measures how much light was not absorbed, letting the computer gauge the metabolic demands that the brain is making.


The results are often compared to an MRI, but can be gathered with lightweight, non-invasive equipment .


Wearing the fNIRS sensor, experimental subjects were asked to count the number of squares on a rotating onscreen cube and to perform other tasks. The subjects were then asked to rate the difficulty of the tasks, and their ratings agreed with the work intensity detected by the fNIRS system up to 83 percent of the time.

Mobile Jammer



Definition of GSM 900 Mobile Jammer
A GSM Jammer or cell phone jammer is a device that transmit signal on the same frequency at which the GSM system operates, the jamming success when the mobile phones in the area where the jammer is located are disabled.

Communication jamming devices were first developed and used by military. Where tactical commanders use RF communications to exercise control of their forces, an enemy has interest in those communications. This interest comes from the fundamental area of denying the successful transport of the information from the sender to the receiver.

Nowadays the mobile jammer devices or cell phone jammer software are becoming civilian products rather than electronic warfare devices, since with the increasing number of the mobile phone users the need to disable mobile phones in specific places where the ringing of cell phone would be disruptive has increased. These places include worship places, university lecture rooms, libraries, concert halls, meeting rooms, and other places where silence is appreciated


Introduction of GSM 900 Mobile Jammer

Jamming devices
overpower the cell phone by transmitting a signal on the same frequency as the cell phone and at a high enough power that the two signals collide and cancel each other out. Cell phones are designed to add power if they experience low-level interference, so the jammer must recognize and match the power increase from the phone. Cell phones are full-duplex devices, which mean they use two separate frequencies, one for talking and one for listening simultaneously. Some jammers block only one of the frequencies used by cell phones, which has the effect of blocking both. The phone is tricked into thinking there is no service because it can receive only one of the frequencies.

Less complex devices block only one group of frequencies, while sophisticated jammers can block several types of networks at once to head off dual-mode or tri-mode phones that automatically switch among different network types to find an open signal. Some of the high-end devices block all frequencies at once and others can be tuned to specific frequencies.

To jam a cell phone, all you need is a device that broadcasts on the correct frequencies. Although different cellular systems process signals differently, all cell-phone networks use radio signals that can be interrupted. GSM, used in digital cellular and PCS-based systems, operates in the 900-MHz and 1800-MHz bands in Europe and Asia and in the 1900-MHz (sometimes referred to as 1.9-GHz) band in the United States. Jammers can broadcast on any frequency and are effective against AMPS, CDMA, TDMA, GSM, PCS, DCS, iDEN and Nextel systems. Old-fashioned analog cell phones and today's digital devices are equally susceptible to jamming. Disrupting a cell phone is the same as jamming any other type of radio communication. A cell phone works by communicating with its service network through a cell tower or base station. Cell towers divide a city into small areas, or cells. As a cell phone user drives down the street, the signal is handed from tower to tower

 
A jamming device transmits on the same radio frequencies as the cell phone, disrupting the communication between the phone and the cell-phone base station in the town
It's a called a denial-of-service attack .

The jammer denies service of the radio spectrum to the cell-phone users within range of the jamming device. Older jammers sometimes were
limited to working on phones using only analog or older digital mobile phone standards. Newer models such as the double and triple band jammers can block all widely used systems (AMPS, iDEN, GSM, etc) and are even very effective against newer phones which hop to different frequencies and systems when interfered with. As the dominant network technology and frequencies used for mobile phones vary worldwide, some work only in specific regions such as Europe or North America.

The power of the jammer's effect can vary widely based on factors such as proximity to towers, indoor and outdoor settings, presence of buildings and landscape, even temperature and humidity play a role. There are concerns that crudely designed jammers may disrupt the functioning of medical devices such as pacemakers. However, like cell phones, most of the devices in common use operate at low enough power output (<1W) to avoid causing any problems


Type "A" Device: JAMMERS
:

In this device we overpower cell phone's signal with a stronger signal, This type of device comes equipped with several independent oscillators transmitting 'jamming signals' capable of blocking frequencies used by paging devices as well as those used by cellular/PCS systems' control channels for call establishment. When active in a designated area, such devices will (by means of RF interference) prevent all pagers and mobile phones located in that area from receiving and transmitting calls.

This type of device transmits only a jamming signal and has very poor frequency selectivity, which leads to interference with a larger amount of communication spectrum than it was originally intended to target. Technologist Jim Mahan said, "There are two types. One is called brute force jamming, which just blocks everything. The problem is, it's like power-washing the airwaves and it bleeds over into the public broadcast area. The other puts out a small amount of interference, and you could potentially confine it within a single cell block. You could use lots of little pockets of small jamming to keep a facility under control."


Type "B" Device: INTELLIGENT CELLULAR DISABLERS

Unlike jammers, Type "B" devices do not transmit an interfering signal on the control channels. The device, when located in a designated 'quiet' area, functions as a 'detector'. It has a unique identification number for communicating with the cellular base station. When a Type "B" device detects the presence of a mobile phone in the quiet room; the 'filtering' (i.e. the prevention of authorization of call establishment) is done by the software at the base station.

When the base station sends the signaling transmission to a target user, the device after detecting simultaneously the presence of that signal and the presence of the target user, signals the base station that the target user is in a 'quiet' room; therefore, do not establish the communication. Messages can be routed to the user's voice- mail box, if the user subscribes to a voice-mail service. This process of detection and interruption of call establishment is done during the interval normally reserved for signaling and handshaking. For 'emergency users', the intelligent detector device makes provisions for designated users who have emergency status. These users must per-register their phone numbers with the service providers.

When an incoming call arrives, the detector recognizes that number and the call are established for a specified maximum duration, say two minutes. The emergency users are also allowed to make out going calls. Similarly, the system is capable of recognizing and allowing all emergency calls routed to "911".

It should be noted that the Type "B" detector device being an integral part of the cellular/PCS systems, would need to be provisioned by the cellular/PCS service providers or provisioned by a third-party working cooperatively with full support of the cellular/PCS service providers.