Aetheric Research, Ltd.

SEO–”search engine optimization”–is a set of tools and practices used by both legitimate webmasters trying to jockey for position in the rankings of search engines and by spammers attempting to push up, temporarily or otherwise, fly-by-night domains selling dubious products.  In some less-served areas, SEO-promoted domains may outnumber legitimate domains by many to one; combine this with redirections, link farms, and the like, and it becomes much more difficult to determine a legitimate source for any products, services, or information that you might happen to need.

Traditionally, the way in which this has been dealt with by blog and forum owners is to filter or delete spam posts.  This particular blog is frequented by any number of spammers who attempt to skew ratings with contentless comments linked to suspicious domains hawking–apparently, as I’m not stupid enough to follow those links–anything from viagra to discount financial instruments to “discount” rolexes.

Another approach has become apparent, though, especially with the advent of certain attempts by search engines of note to restrict the efforts of these “blackhat SEO tactics”–an approach that can be labeled SEP, for Search Engine Pessimization.  

‘Traditional’ optimization techniques seek to raise the ranking of a page through exploiting the algorithms used to generate the pagerank–generally assumed to involve links from external pages, keywords in links pointing to the page, and several other factors; Google is, naturally, reticent about the exact specifications of their algorithms, especially given the amount of money people gain from trying to guess at them.

Blackhat SEO–those tactics which have been developed to exploit these rankings–take advantage of these techniques by exaggerating them, trying to imitate legitimate traffic through spamming fora with spurious links, farming keyworded domains and cross-linking them in giant link farms, etc.  Many of these techniques have been detected, and some have been well publicized by Google and other search engine companies as no longer effective because they are automatically detected and deprecated by the engine.

The attack venue here should be obvious: to pessimize an undesirable domain, promote it through the use of known-bad ‘optimization’ techniques. 

These techniques can be determined by looking through complaints filed about ‘arbitrary’ reductions in pagerank and the like; by determining the cause of the reduction, a list of methods and tactics can be quickly developed that will serve to indicate to the automated algorithms that a site is attempting to ‘game the system’ and gain unjust ranking, triggering the part of the algorithm that punishes those sites.

An interesting supplementary tactic is that of googlebombing.  Googlebombing is the practice of using certain SEO techniques to associate a given keyword–usually one with amusing connotations–with a particular page; one of the more publicized ones involved former president Bush and the word ‘failure’.  Associating unsavory words or those involving illegal activities with a domain could, in this day and age, result in the domain’s siezure by the authorities–a win-win situation, as every domain siezed for the wrong reasons weakens the case of this rather nonsensical practise, and it also neuters the spammers by disabling a venue by which they could potentially make money.

Maximum benefit, though, would likely result from linking in some way the domain to be pessimized with known-bad domains–those serving malware, those known to be scams, etc.–thus alerting the search engines’ spiders of a potentially harmful connection as soon as possible.  Using extensions to report spam is also effective.

There is always a race between those innovating ways to make search and the like more relevant to the user and those seeking to exploit it for their own reasons; manipulating search engines to punish spammers is one way in which anyone who dislikes spam can fight back.

The Register has an excellent (if somewhat snarky, though that is the milieu of the publication) article on some of the recent breaks to SSL’s effectiveness as a platform for secure communications.

The basic problem behind this round of vulnerabilities is the reliability of the certifying organizations.  After the recent breakin to Comodo that resulted in the issuance of several fraudulent certificates, more attention has been paid to this particular flaw in the way in which traffic is secured.

SSL works by means of PKI: public key infrastructure.  This means that a large string of data, known as a ‘key’, is sent out into the public for use by anyone wishing to communicate with the server.  The key has a certain mathematical relationship with another key stored on the server (known as the private key); when data is encrypted with one, it can be decrypted with the other if the proper mathematical steps are taken.

These keys are used to negotiate a secured connection to a server, which serves two purposes–first, it assures the person connecting to the server that they are connecting to the genuine article; the fact that the connection can be made successfully proves that the server has the requisite private information associated with the key.  Secondly, it allows the entire connection to be encrypted so that people between the computer and the server will be unable to determine the content of the transaction.

This only works, however, if the key is trusted–if anyone has access to the private key other than the server in question, then there is no assurance that the connection is being made to the correct server, and no assurance that someone in the middle is unable to eavesdrop.

Cerifying Authorities such as Comodo, VeriSign, and others are supposed to guarantee that they issue certificates only to the organizations that they identify.  However, this is not always the case; especially in the case of their licensees–companies that issue certificates under license from the CA houses, and whose certificates are intended to be just as trusted–the requisite identification of the certificate request is not always accomplished properly, resulting in certificates being issued to incorrect persons.

One particular certificate that has been mentioned is one for ‘localhost’–that is, one’s own computer.  While most articles on this subject have noted that this is an essentially frivolous certificate and have paid much more attention to the ‘exchange’ domain certificates that could be used for intercepting corporate email, it’s worth noting that a live ‘localhost’ certificate along with a maliciously-installed local proxy could intercept all internet traffic that a user attempts, thus providing no overt sign (unless the user was very security-conscious and checked carefully the certificates of all the sites that they connected to) to the user that they were being compromised and, for instance, their bank account details were being stolen.

Certain alternatives to the SSL system have been proposed, but as yet they all suffer from the difficulties of limited adoption.  Until a significant movement arises–or at least some of the ‘big players’ get involved–eCommerce and the like will likely continue to be only partly secured.

(On a side note, a service that actively tracks and validates certificates issued by all authorities–like the automated one run by Google on page 3 of the article linked–could be made very profitable)

Social Engineering: The Art of Human Hacking

Christopher Hadnagy

The review that I’d read on Slashdot fairly glowed with praise, describing Social Engineering as being the “definitive text” on the subject.  I’m going to have to modify that statement, as I have some fairly severe reservations about the book.

Available in both dead-tree and ebook formats, the book’s electronic edition is, at least, well put together and mostly* professional looking, with table of contents and an index–no glossary, however, which this book might benefit from like other introductory texts.

And it is an introductory text–the language is obviously aimed at the novice, someone for whom ‘social engineering’ is a buzzword they may have heard once.  Much of the first part of the book, before he gets into the ‘meat’ of the subject, is spent trying to make the case for why you should read the rest of the book.  

When he does get though his spiel of trying to both concern and reassure the reader–that social engineering is a real and dangerous phenomenon that is so all-pervasive that you may not be aware it’s happened and that there are ways to be able to tell, respectively–and gets into the subject the book is nominally about, the content improves significantly.

The book is laid out according to his ‘system’–that’s really what he’s selling, here: a way to organize and categorize social engineering as a teachable system–where he outlines various ways to pursue an ultimate goal of finding out information that the target wishes to keep hidden.

There’s a broad sketch of information gathering techniques–a couple of software packages are namedropped as a means to organize and collate information–followed up with sketches of elicitation (more or less congruent with other standard resources on the subject; links are provided therein to government pamphlets and the like), reading body language (mostly concerned with facial microexpressions–almost nothing on other body language interpretation) and an overview of building pretexts (mostly concerned with selecting the correct one).

The section on causing “buffer overruns” in humans is fairly interesting and well put together, but he either doesn’t recognize or purposely deemphasizes the general case (that of distracting the conscious mind in order to plant suggestions or issue short commands that will be followed without immediate objection) for several specific method-driven cases.

There are some other bits and pieces which might be useful to the budding social engineer–recommendations on how to bypass physical security, for instance, and methods for seeding exploits into locations where the target might conceivably run them.

At the end, there are some case studies–discussing a couple of cases from Mitnick’s book on the subject; a couple of his own cases; and a couple of cases that, dramatically, are hightly obfuscated as “top secret” and intimated to be about “high profile” companies and the like.  If you’ve actually read the book up to this point, you’ll likely realize that the language chosen to introduce that section in particular is more than a little loaded.

As an introduction to the concepts and processes of social engineering, it’s not a bad book.  It does cover most of the bases of social engineering and some related concepts, but there are a few rather large holes.

If I were to take Mr. Hadnagy at his word–which, given the context of the book, would be a rather foolish thing to do–pretty much everything he does is elicit enough of an opening to introduce spyware onto a corporate system using a PDF exploit.  It’s always the same methodology in every case that he describes his personal involvement in, and it reads like a particularly bad spy thriller when he does so.  I get this impression of inexperience in the field, as well–he takes a sort of “gee whiz, ain’t that cool!” tone with the exploits of others that he describes, who have little to recommend them beyond their audacity in taking on the targets they did and their talent at maintaining their pretext.  

He also continually refers to his “mentor” in such a way that makes me question whether the Master knows the Apprentice is writing and marketing books based on work they may have done.  

If you’re entirely unaware of social engineering–if you’ve never seen a spy movie, or a heist movie, or read about Frank Abignale or any other famous con-men; if you’ve never considered ways in which people would be able to steal your information or convince you to take an action that you would not otherwise take–then feel free to read this book.  If you’re after a more serious education as to how social engineering works and how to present yourself in a certain way to gain another’s sympathy, then take an acting class–you’ll get a lot farther.

*One does not make one’s source citations in-line.  One makes one’s citations in footnotes like a civilized person.  Mr. Hadnagy should take note.

A tool as powerful as the Native Client promises to be will have equally powerful misuses.  As discussed yesterday, NaCl is an extension of the functionality of Chrome, allowing it to act as something closer to a general hypervisor than ‘just’ a browser.  To understand the security implications of running generalized code in such a manner, it may be instructive to look at the Java VM.

The Java language was invented originally as a means of providing additional functionality to cellphones–before smartphones existed.  It spent much of the late ’90s being pushed as a ‘platform independent’ programming language–any platform that could run the Java Virtual Machine could run any Java program without issues.  This independence was at a much lower cost to speed than that of competitor interpreted languages; Java had a hybrid approach that rendered human-readable program instructions into an intermediate state between the human-readable instructions and the machine-readable code that compiled programs end up in–something called ‘bytecode’.

These bytecodes execute inside a sandbox environment set up by the JVM; much like the NaCl, the JVM seeks to isolate running code from touching parts of the machine other than what it is authorized to access–though unlike the JVM, the NaCl leverages the thread isolation offered by the Chrome environment to prevent inter-thread communications to (if I analyze this correctly) a greater extent than the JVM does.  

This sandboxing model is fairly safe as-is, though like all systems it is exploitable.  In the case of the JVM, exploits appear to focus on memory corruption, attempting to cause the virtual machine to execute instructions that will cause information to be written outside the authorized memory stack, and thence to execute instructions that have not been approved for execution by the trusted environment.

The exploit can be handled in various ways; one paper gives the possibility of loading a specially crafted program and waiting for a memory-corruption event to allow for the code execution to happen.  Existing vulnerabilities (that have been patched in the past) include corrupted image files and overflowing calendar modules.

The same vectors of attack are likely to happen inside NaCl, with similar effectiveness–that is, fairly ineffective unless some fault in the vetting of the code to be executed can be found.  With open-sourced projects, such faults are unlikely to persist, given the number of eyes (especially those with a vested interest in ensuring the project’s success) examining the code, as well as the well-publicized monetary rewards posted as bounties for bug reporting by Google.  Still, it would be a mistake to assume safety–as always, the basic rules will still apply, and a new vulnerability in the process could be found at any time.  

The ChromeOS (and by extension the chromium browser) is to include the NaCl–the Native Client.  Condiment puns abound, given that NaCl is also the chemical formula for table salt.  NaCl is an implementation of a means to run machine code inside the framework of the browser, granting webapps a significant performance boost.

The Chrome paradigm is one of multithreaded sandboxing: each thread (more or less synonymous with “browser tab”) has its own area of memory and its own slice of processor time to work with.  In this model, the browser tabs are like very limited virtual machines, and the parent browser process much like a hypervisor–individual meltdowns of machines are (at least in theory) irrelevant to the operation of the other threads, and can be cleaned up and removed by the parent process should it become necessary.

NaCl takes this a little bit closer to a real VM setup, in that it offers a way to run code on the ‘bare metal’–that is, using the native hardware of the user’s machine, rather than working via a javascript implementation like current HTML5 apps.  

The sandboxing requirement is still maintained, in that the Native Client only (theoretically) allows code to run that will respect the limits of the sandboxing system–this is important, given that running code directly allows for a great deal more leeway and leveraging of resources than execution inside a javascript interpreter.  The NaCl executables are, for all intents and purposes, the same kind of machine code that you would run directly on your computer, and have all the associated advantages (speed, especially) and disadvantages (ability to cause harm) that this entails.

One intended use for the NaCl framework is for cloud apps to export a portion of the processing load to the client systems, to enable a better user experience.  Games, especially, will benefit from the Native Client, given that the graphical rendering calculations are rather more intensive than those required for standard web apps.  Statistical and rendering applications may also see a benefit from the increased performance available under this model.

Another is for webapps to extend parts of their functionality to the client machine in order to limit the amount of data required to be sent and received–an important consideration for people who may be on slow or capped internet connections.  In this model, the NaCl app could be downloaded once, and thereafter traffic to and from the hosting server would be limited to user provided or requested data–all the processing and rendering of the information could happen locally.

One usage that has not appeared in the official documentation, at least as far as I’ve seen, but seems as though it would be appropriate would be an implementation of the BOINC client–being able to run folding@home, seti@home or any of the other distributed computing projects inside a browser tab could result in significantly increased uptake.  Given that the format of the NaCl executables is fairly close to that of an existing BOINC implementation, a comparatively limited amount of development would be required to adapt it to this platform.

NaCl offers significant opportunities to developers; much can be done with native machine code that cannot be effectively done with javascript or other interpreted languages.  It also offers significant dangers–of which the developers appear very much aware.  On the whole, though, NaCl appears likely to be able to provide a much improved user experience, with the potential for significant improvements for developers–with NaCl, much like Java before it, they’ll be able to write one program and run it on any platform, rather than having to target a specific OS.  Unlike Java, which handled sandboxing by implementing a sort of virtual machine and compiling code into a special format to run on top of it, NaCl allows the execution to be handled directly by the processor–this should allow NaCl applications to run much faster than the equivalent Java apps.  

Native Client is still very much experimental, but can be enabled for users of the Chromium browser by going to the about:flags page, clicking the ‘Enable’ button under the Native Client option, and restarting your browser.  You can test out some of the functionality with the examples found in the Gallery page.

As Monday was about basic online safety and Tuesday was about safe Email use, today’s Security 101 will focus on web surfing specifically.  Web surfing is one of the more common uses of online time, as it’s the way to access much of the generally available information (rather than the special-purpose non-”web” internet archives–those are a special case).  Accordingly:

• Make sure that you have applied all the updates available for your computer, your browser, and any antivirus program that you might run.  The vast majority of infections by hostile software come about as a result of unpatched security updates.
• If you use Windows, do not use Internet Explorer.  IE is still tightly integrated into the operating system; as such, any vulnerability in IE that is not patched–either because Microsoft has not released a patch or because you ignored the previous bullet–is a vulnerability in Windows as a whole.  Using any other browser (such as Chrome, Firefox, or Opera) will introduce another layer for hostile software to have to go through before it can affect your computer.  Additionally, both Chrome and Firefox have numerous plugins (or add-ons or extensions or whatever the browsers are calling them these days) available specifically to make your browsing experience safer.  Some of those for Chrome have been discussed here; those available for Firefox are just as easy to find.
• Consider blocking most advertisements.  There have been several cases where advertisement servers have been compromised and have ended up serving ads containing hostile software.  Text ads are, by their nature, immune to this–though it is still adviseable to be very careful before considering clicking them, as many ads do point to sites of dubious provenance.  
• Hover before you click.  Especially on sites where users submit links, hover your pointer over the link and look at the address that appears at the bottom when you do so.  If you have any doubts about the domain that the link goes to, don’t follow it.
• When in doubt, close the browser.  A website can’t hurt you if you don’t have a browser open to it.
• If shopping, or any time that you might enter personal information, make sure that the form has SSL–a technology to keep your information encrypted in transmission–enabled.  Most modern browsers have a specific, clear indicator that the page has been encrypted with SSL; for instance, the Chrome browser will turn the address bar green.  SSL addresses always start with “https” rather than “http”–double-check to make sure, and don’t put in any personal information unless that’s there.
• Do not give out any personal information other than the bare minimum required.  If a site wants more information from you than you feel comfortable providing–especially if, like the Gawker family, they have poor security–consider alternatives instead.
• Avoid downloading any files unless you are sure of the source.  Anything more complicated than a basic text file can contain hostile software that can harm your computer, and this risk goes up with the complexity of the file.  
• If a website suddenly looks different than what you’re used to–especially if it’s one where you manage your financial information–doublecheck the spelling of the address.  There have been many instances of what is referred to as “typosquatting,” where an address only a couple letters off from the official one is bought by someone unrelated to the official website and used for fraudulent purposes.  If in doubt, close the browser window or tab and try again.
• If some kind of web content “requires” a plugin to view, do not follow the link from the page.  Instead, check to see if you have the plugin installed, and if not, look for the manufacturer’s webpage to find it.  Flash, for instance, comes from Adobe; any other source cannot be trusted.

As before, all the other general recommendations still apply:  think before you click, and if you’re not sure of a situation, find someone who does this for a living and ask them nicely.  Merely keeping “tips” in mind will not keep you safe–only a deep and abiding commitment to safety, and careful use of safe browsing practises, will do that.