Virtualization

Virtualization, in computing, is a term that refers to the various techniques, methods or approaches of creating a virtual (rather than actual) version of something, such as a virtual hardware platform, operating system (OS), storage device, or network resources. Hardware virtualization or platform virtualization refers to the creation of a virtual machine that acts like […]

Virtualization, in computing, is a term that refers to the various techniques, methods or approaches of creating a virtual (rather than actual) version of something, such as a virtual hardware platform, operating system (OS), storage device, or network resources.

Hardware virtualization or platform virtualization refers to the creation of a virtual machine that acts like a real computer with an operating system. Software executed on these virtual machines is separated from the underlying hardware resources. For example, a computer that is running Microsoft Windows may host a virtual machine that looks like a computer with the Ubuntu Linux operating system; Ubuntu-based software can be run on the virtual machine.[1][2]

In hardware virtualization, the host machine is the actual machine on which the virtualization takes place, and the guest machine is the virtual machine. The words host and guest are used to distinguish the software that runs on the physical machine from the software that runs on the virtual machine. The software or firmware that creates a virtual machine on the host hardware is called a hypervisor or Virtual Machine Manager.

Different types of hardware virtualization include:

  1. Full virtualization: Almost complete simulation of the actual hardware to allow software, which typically consists of a guest operating system, to run unmodified.
  2. Partial virtualization: Some but not all of the target environment is simulated. Some guest programs, therefore, may need modifications to run in this virtual environment.
  3. Paravirtualization: A hardware environment is not simulated; however, the guest programs are executed in their own isolated domains, as if they are running on a separate system. Guest programs need to be specifically modified to run in this environment.

Hardware-assisted virtualization is a way of improving the efficiency of hardware virtualization. It involves employing specially designed CPUs and hardware components that help improve the performance of a guest environment.

Hardware virtualization can be viewed as part of an overall trend in enterprise IT that includes autonomic computing, a scenario in which the IT environment will be able to manage itself based on perceived activity, and utility computing, in which computer processing power is seen as a utility that clients can pay for only as needed. The usual goal of virtualization is to centralize administrative tasks while improving scalability and overall hardware-resource utilization. With virtualization, several operating systems can be run in parallel on a single central processing unit (CPU). This parallelism tends to reduce overhead costs and differs from multitasking, which involves running several programs on the same OS. Using virtualization, an enterprise can better manage updates and rapid changes to the operating system and applications without disrupting the user. “Ultimately, virtualization dramatically improves the efficiency and availability of resources and applications in an organization. Instead of relying on the old model of “one server, one application” that leads to under utilized resource, virtual resources are dynamically applied to meet business needs without any excess fat” (ConsonusTech).

Hardware virtualization is not the same as hardware emulation. In hardware emulation, a piece of hardware imitates another, while in hardware virtualization, a hypervisor (a piece of software) imitates a particular piece of computer hardware or the entire computer. Furthermore, a hypervisor is not the same as an emulator; both are computer programs that imitate hardware, but their domain of use in language differs.

VirtualBox is a general-purpose full virtualizer for x86 hardware, targeted at server, desktop and embedded use.

For a thorough introduction to virtualization and VirtualBox, please refer to the online version of the VirtualBox User Manual’s first chapter.



Why does HP recommend that I keep Hardware Virtualization off?

There are several attack vectors from bad drivers that can utilize VT extensions to do potentially bad things. that’s why the setting is usually in the “security” section of your BIOS UI.

additionally the smaller your instruction set, the more efficient the CPU runs at a very very low level (hence last decades interest in RISC chips). having it disabled allows the CPU to cache fewer instructions and search the cache faster.

http://en.wikipedia.org/wiki/Blue_Pill_%28software%29

So is there a security risk to enabling AMD-V? – Rocket Hazmat Feb 1 at 16:21
yes. Installing drivers and other very-low-level software is always risky, so its probably no more risky that grabbing a driver off a non-official download site. the big difference is that a blue-pill exploit could allow a guest to affect the host and vice-verse, which should really never be true. – Frank Thomas Feb 1 at 16:37
I disagree saying there is a security risk by enabling AMD-V. Doing a quick search on “AMD-V security” results in NO results on the first page about a security vulnerability that says a great deal. – Ramhound Feb 1 at 16:46
So, it’s off by default, because there are rootkits that pretend to by hypervisors? Guess I just gotta be careful what I download! :-) – Rocket Hazmat Feb 1 at 16:49

Blue Pill is the codename for a rootkit based on x86 virtualization. Blue Pill originally required AMD-V (Pacifica) virtualization support, but was later ported to support Intel VT-x (Vanderpool) as well. It was designed by Joanna Rutkowska and originally demonstrated at the Black Hat Briefings on August 3, 2006, with a reference implementation for the Microsoft Windows Vista kernel.

Digital Forensics

What is odessa? It’s an acronym for “Open Digital Evidence Search and Seizure Architecture” The intent of this project is to provide a completely open and extensible suite of tools for performing digital evidence analysis as well as a means of generating a usable report detailing the analysis and any findings. The odessa tool suite […]

What is odessa?

It’s an acronym for “Open Digital Evidence Search and Seizure Architecture”
The intent of this project is to provide a completely open and extensible suite of tools for performing digital evidence analysis as well as a means of generating a usable report detailing the analysis and any findings. The odessa tool suite currently represents more than 7 man years of labor, and consists of 3 highly modular cross-platform tools for the acquisition, analysis, and documentation of digital evidence.

In addition to the odessa tool suite, the project hosts other applications and information related to digital forensics. At this time, the list of additional tools includes a set of whitepapers and utilities authored by Keith J. Jones including Galleta, a tool for analyzing Internet Explorer cookies, Pasco, a tool for analyzing the Microsoft Windows index.dat file, and Rifiuti, a tool for investigating the Microsoft Windows recycle bin info2 file.

CAINE (Computer Aided INvestigative Environment) is an Italian GNU/Linux live distribution created as a project of Digital Forensics
Currently the project manager is Nanni Bassetti.
CAINE offers a complete forensic environment that is organized to integrate existing software tools as software modules and to provide a friendly graphical interface.
The main design objectives that CAINE aims to guarantee are the following:

  • an interoperable environment that supports the digital investigator during the four phases of the digital investigation
  • a user friendly graphical interface
  • a semi-automated compilation of the final report

We recommend you to read the page on the CAINE policies carefully.
CAINE represents fully the spirit of the Open Source philosophy, because the project is completely open, everyone could take the legacy of the previous developer or project manager. The distro is open source, the Windows side (Wintaylor) is open source and, the last but not the least, the distro is installable, so giving the opportunity to rebuild it in a new brand version, so giving a long life to this project ….

http://linuxzoo.net/page/tut_caine_lab1.html

Information Systems Security

The Open Source Security Testing Methodology http://www.isecom.org/mirror/OSSTMM.3.pdf The Information Systems Security Assessment Framework (ISSAF) seeks to integrate the following management tools and internal control checklists: Evaluate the organizations information security policies & processes to report on their compliance with IT industry standards, and applicable laws and regulatory requirements Identify and assess the business dependencies on […]


The Open Source Security Testing Methodology

http://www.isecom.org/mirror/OSSTMM.3.pdf


The Information Systems Security Assessment Framework (ISSAF) seeks to integrate the following management tools and internal control checklists:

Evaluate the organizations information security policies & processes to report on their compliance with IT industry standards, and applicable laws and regulatory requirements
Identify and assess the business dependencies on infrastructure services provided by IT
Conduct vulnerability assessments & penetration tests to highlight system vulnerabilities that could result in potential risks to information assets
Specify evaluation models by security domains to :
Find mis-configurations and rectify them
Identifying risks related to technologies and addressing them
Identifying risks within people or business processes and addressing them
Strengthening existing processes and technologies
Provide best practices and procedures to support business continuity initiatives

Business Benefits of ISSAF

The ISSAF is intended to comprehensively report on the implementation of existing controls to support IEC/ISO 27001:2005(BS7799), Sarbanes Oxley SOX404, CoBIT, SAS70 and COSO, thus adding value to the operational aspects of IT related business transformation programmes.
Its primary value will derive from the fact that it provides a tested resource for security practitioners thus freeing them up from commensurate investment in commercial resources or extensive internal research to address their information security needs.
It is designed from the ground up to evolve into a comprehensive body of knowledge for organizations seeking independence and neutrality in their security assessment efforts.

It is the first framework to provide validation for bottom up security strategies such as penetration testing as well as top down approaches such as the standardization of an audit checklist for information policies.


The Open Web Application Security Project (OWASP) is an open-source application security project. The OWASP community includes corporations, educational organizations, and individuals from around the world. This community works to create freely-available articles, methodologies, documentation, tools, and technologies. The OWASP Foundation is a 501(c)(3)charitable organization that supports and manages OWASP projects and infrastructure. It is also a registered non profit in Europe since June 2011.

OWASP is not affiliated with any technology company, although it supports the informed use of security technology. OWASP has avoided affiliation as it believes freedom from organizational pressures may make it easier for it to provide unbiased, practical, cost-effective information about application security.[citation needed] OWASP advocates approaching application security by considering the people, process, and technology dimensions.

OWASP’s most successful documents include the book-length OWASP Guide,[1] the OWASP Code Review Guide OWASP Guide [2] and the widely adopted Top 10 awareness document.[3][citation needed] The most widely used OWASP tools include their training environment,[4] their penetration testing proxy WebScarab,[5] and their .NET tools.[6] OWASP includes roughly 190 local chapters [7] around the world and thousands of participants on the project mailing lists. OWASP has organized the AppSec [8] series of conferences to further build the application security community.

OWASP is also an emerging standards body, with the publication of its first standard in December 2008, the OWASP Application Security Verification Standard (ASVS).[9] The primary aim of the OWASP ASVS Project is to normalize the range of coverage and level of rigor available in the market when it comes to performing application-level security verification. The goal is to create a set of commercially workable open standards that are tailored to specific web-based technologies. A Web Application Edition has been published. A Web Service Edition is under development.

the OWASP Top Ten Project – if you’re looking for the OWASP Top 10 Mobile Click Here
The Release Candidate for the OWASP Top 10 for 2013 is now available here: OWASP Top 10 – 2013 – Release Candidate

The OWASP Top 10 – 2013 Release Candidate includes the following changes as compared to the 2010 edition:

  • A1 Injection
  • A2 Broken Authentication and Session Management (was formerly A3)
  • A3 Cross-Site Scripting (XSS) (was formerly A2)
  • A4 Insecure Direct Object References
  • A5 Security Misconfiguration (was formerly A6)
  • A6 Sensitive Data Exposure (merged from former A7 Insecure Cryptographic Storage and former A9 Insufficient Transport Layer Protection)
  • A7 Missing Function Level Access Control (renamed/broadened from former A8 Failure to Restrict URL Access)
  • A8 Cross-Site Request Forgery (CSRF) (was formerly A5)
  • A9 Using Known Vulnerable Components (new but was part of former A6 – Security Misconfiguration)
  • A10 Unvalidated Redirects and Forwards

Please review this release candidate and provide comments to dave.wichers@owasp.org or to the OWASP Top 10 mailing list (which you must be subscribed to). The comment period is open from Feb 16 through March 30, 2013 and a final version will be released in May 2013.

If you are interested, the methodology for how the Top 10 is produced is now documented here: OWASP Top 10 Development Methodology

OWASP Appsec Tutorial Series

Uploaded on Jan 30, 2011
The first episode in the OWASP Appsec Tutorial Series. This episode describes what the series is going to cover, why it is vital to learn about application security, and what to expect in upcoming episodes.

Uploaded on Feb 8, 2011
The second episode in the OWASP Appsec Tutorial Series. This episode describes the #1 attack on the OWASP top 10 – injection attacks. This episode illustrates SQL Injection, discusses other injection attacks, covers basic fixes, and then recommends resources for further learning.

Uploaded on Jul 11, 2011
The third episode in the OWASP Appsec Tutorial Series. This episode describes the #2 attack on the OWASP top 10 – Cross-Site Scripting (XSS). This episode illustrates three version of an XSS attack: high level, detailed with the script tag, and detailed with no script tag, and then recommends resources for further learning.

Published on Sep 24, 2012
The forth episode in the OWASP Appsec Tutorial Series. This episode describes the importance of using HTTPS for all sensitive communication, and how the HTTP Strict Transport Security header can be used to ensure greater security, by transforming all HTTP links to HTTPS automatically in the browser.


DEFT 7 is based on the new Kernel 3 (Linux side) and the DART (Digital Advanced Response Toolkit) with the best freeware Windows Computer Forensic tools. It’s a new concept of Computer Forensic system that use LXDE as desktop environment and WINE for execute Windows tools under Linux and mount manager as tool for device management.

It is a very professional and stable system that includes an excellent hardware detection and the best free and open source applications dedicated to Incident Response, Cyber Intelligence and Computer Forensics.

DEFT is meant to be used by:

Military
Police
Investigators
IT Auditors
Individuals

DEFT is 100% made in Italy

anonimized run

The Amnesic Incognito Live System or Tails is a Debian based Linux distribution aimed at preserving privacy and anonymity.[1] Actually, it is the next iteration of development on the previous Gentoo based Incognito Linux distribution.[2] All its outgoing connections are forced to go through Tor,[3] and direct (non-anonymous) connections are blocked. The system is designed […]

The Amnesic Incognito Live System or Tails is a Debian based Linux distribution aimed at preserving privacy and anonymity.[1] Actually, it is the next iteration of development on the previous Gentoo based Incognito Linux distribution.[2] All its outgoing connections are forced to go through Tor,[3] and direct (non-anonymous) connections are blocked. The system is designed to be booted as a live CD or USB, and leaves no trace on the machine unless explicitly told to do so. The Tor Project has provided most of the financial support for development.[4]

Tails is a live system that aims at preserving your privacy and anonymity. It helps you to use the Internet anonymously almost anywhere you go and on any computer but leave no trace using unless you ask it explicitly.

It is a complete operating-system designed to be used from a DVD or a USB stick independently of the computer’s original operating system. It is Free Software and based on Debian GNU/Linux.

Tails comes with several built-in applications pre-configured with security in mind: web browser, instant messaging client, email client, office suite, image and sound editor, etc.

Read about how you can help improving Tails documentation.

General information

Get Tails

First steps with Tails

Connect to the Internet anonymously

Encryption & privacy

Work on sensitive documents

Advanced topics

quantOS, based on Linux Mint 11, is a hardened Linux distro for secure daily use. quantOS leverages AppArmor application security profiles, Arkose Desktop Application Sandboxing and Vidalia for creating secure Tor connections for enhanced privacy.


The DemocraKey was invented by Kirk, in response to government snooping and censorship in China and the United States. Six months later, he started DemocraKey.com to promote the DemocraKey and get help with his project.
Read more here.

kaos.theory’s Anonym.OS LiveCD is a bootable live cd based on OpenBSD that provides a hardened operating environment whereby all ingress traffic is denied and all egress traffic is automatically and transparently encrypted and/or anonymized.

Liberté Linux is a secure, lightweight, and easy to use Gentoo-based Linux distribution intended as a communication aid in hostile environments. Liberté installs on a USB key, and boots on any computer or laptop.

Gentoo Linux, a special flavor of Linux that can be automatically optimized and customized for just about any application or need. Extreme performance, configurability and a top-notch user and developer community are all hallmarks of the Gentoo experience. To learn more, read our about page.
Continue reading “anonimized run”

cracking password hashes

Forgot your Windows admin password? Reinstall? Oh no… But not any more… This is a utility to reset the password of any user that has a valid local account on your Windows system. Supports all Windows from NT3.5 to Win7, also 64 bit and also the Server versions (like 2003 and 2008) You do not […]

Forgot your Windows admin password?

Reinstall? Oh no… But not any more…


  • This is a utility to reset the password of any user that has a valid local account on your Windows system.
  • Supports all Windows from NT3.5 to Win7, also 64 bit and also the Server versions (like 2003 and 2008)
  • You do not need to know the old password to set a new one.
  • It works offline, that is, you have to shutdown your computer and boot off a CD or USB disk to do the password reset.
  • Will detect and offer to unlock locked or disabled out user accounts!
  • There is also a registry editor and other registry utilities that works under linux/unix, and can be used for other things than password editing.

Windows stores its user information, including crypted versions of the passwords, in a file called ‘sam’, usually found in windowssystem32config. This file is a part of the registry, in a binary format previously undocumented, and not easily accessible. But thanks to a German(?) named B.D, I’ve now made a program that understands the registry.

This site provides CD and floppy images for end users to easily edit their forgotten passwords. But it also provides full source code and binary builds of the tools to allow others to use as they like for other purposes. Registry format documentation also available.

Latest release is 110511 (2011-05-11)

The following is available for download and information:

2011-05-11

  • Some major! new features for people using the registry utilites, but not much changes to password reset.

2009-12-01

  • New site, official URL is now: http://pogostick.net/~pnh/ntpasswd/
  • All releases still contains old mail address, please note NEW mailaddress is pnh@pogostick.net. Old mailaddress vil be invalid after January 1st 2010.
  • No new release, 2008-08-02 is still newest. Hope to release new early 2010.

A rainbow table is a precomputed table for reversing cryptographic hash functions, usually for cracking password hashes. Tables are usually used in recovering the plaintext password, up to a certain length consisting of a limited set of characters. It is a practical example of a space/time trade-off, using more computer processing time at the cost of less storage when calculating a hash on every attempt, or less processing time and more storage when compared to a simple lookup table with one entry per hash. Use of a key derivation function that employ a salt makes this attack infeasible.

Rainbow tables are an application of an earlier, simpler algorithm by Martin Hellman.[1]

Hash Sets are used in a data analysis technique called Hash Analysis, which uses the MD5, SHA1 and SHA256 hash of files to verify the files on a storage device. A hash uniquely identifies the contents of a file, regardless of filename and can be used to identify the presence of malicious, contraband, or incriminating files such as bootleg software, pornography and viruses. See this video of hash sets in use in OSForensics.

Rainbow tables are available for free from http://www.freerainbowtables.com/, approximately a 2.5TB (2500 GB) download.

The hash sets are available for free from the National Software Reference Library, approximately a 1.7GB download, and there is a OSForensics tutorial on how to convert them for use within OSForensics. Please note that conversion may take several days.

The hash sets and rainbow tables created by PassMark are also available from the OSForensics Download page.  We are not selling the tables, only the service of copying them onto a 3TB hard drive and shipping.

Any computer system that requires password authentication must contain a database of passwords, either hashed or in plaintext, and various methods of password storage exist. Because the tables are vulnerable to theft, storing the plaintext password is dangerous. Most databases therefore store a cryptographic hash of a user’s password in the database. In such a system, no one — including the authentication system — can determine what a user’s password is, simply by looking at the value stored in the database. Instead, when a user enters his or her password for authentication, it is hashed and that output is compared to the stored entry for that user (which was hashed before being stored). If the two hashes match, access is granted.

A thief who steals the (hashed) password table cannot merely enter the user’s (hashed) database entry to gain access since the authentication system would hash that a second time, producing a result which does not match the stored value, which was hashed only once. In order to learn a user’s password, the thief must reverse the hash to find a password which produces the hashed value. A good authentication system will make this process as difficult as possible by using a one-way hash function, that has a high ratio for the time to invert the function compared to the time to compute the function.

Rainbow tables are one tool that has been developed in an effort to derive a password by looking only at a hashed value.

Rainbow tables are not always needed, for there are simpler methods of hash reversal available. Brute-force attacks and dictionary attacks are the simplest methods available, however these are not adequate for systems that use large passwords, because of the difficulty of storing all the options available and searching through such a large database to perform a reverse-lookup of a hash.

To address this issue of scale, reverse lookup tables were generated that stored only a smaller selection of hashes that when reversed could generate long chains of passwords. Although the reverse lookup of a hash in a chained table takes more computational time, the lookup table itself can be much smaller, so hashes of longer passwords can be stored. Rainbow tables are a refinement of this chaining technique and provide a solution to a problem called chain collisions.

Ophcrack is a free Windows password cracker based on rainbow tables. It is a very efficient implementation of rainbow tables done by the inventors of the method. It comes with a Graphical User Interface and runs on multiple platforms.

The multi-platform password cracker Ophcrack is incredibly fast. How fast? It can crack the password “Fgpyyih804423″ in 160 seconds. Most people would consider that password fairly secure. The Microsoft password strength checker rates it “strong”. The Geekwisdom password strength meter rates it “mediocre”.

Why is Ophcrack so fast? Because it uses Rainbow Tables.

Features:

  • » Runs on Windows, Linux/Unix, Mac OS X, …
  • » Cracks LM and NTLM hashes.
  • » Free tables available for Windows XP and Vista/7.
  • » Brute-force module for simple passwords.
  • » Audit mode and CSV export.
  • » Real-time graphs to analyze the passwords.
  • » LiveCD available to simplify the cracking.
  • » Dumps and loads hashes from encrypted SAM recovered from a Windows partition.
  • » Free and open source software (GPL).

Note that all rainbow tables have specific lengths and character sets they work in. Passwords that are too long, or contain a character not in the table’s character set, are completely immune to attack from that rainbow table.

Unfortunately, Windows servers are particularly vulnerable to rainbow table attack, due to unforgivably weak legacy Lan Manager hashes. I’m stunned that the legacy Lan Manager support “feature” is still enabled by default in Windows Server 2003. It’s highly advisable that you disable Lan Manager hashes, particularly on Windows servers which happen to store domain credentials for every single user. It’d be an awful shame to inconvenience all your Windows 98 users, but I think the increase in security is worth it.

I read that Windows Server 2008 will finally kill off LM hashes when it’s released next year. Windows Vista already removed support for these obsolete hashes on the desktop.

The Ophcrack tool isn’t very flexible. It doesn’t allow you to generate your own rainbow tables. For that, you’ll need to use the Project Rainbow Crack tools, which can be used to attack almost any character set and any hashing algorithm. But beware. There’s a reason rainbow table attacks have only emerged recently, as the price of 2 to 4 gigabytes of memory in a desktop machine have approached realistic levels. When I said massive, I meant it. Here are some generated rainbow table sizes for the more secure NT hash:

Character Set Length Table Size
ABCDEFGHIJKLMNOPQRSTUVWXYZ 14 0.6 GB
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789 14 3 GB
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+= 14 24 GB
ABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789!@#$%^&*()-_+=~`[]{}|:;"'<>,.?/ 14 64 GB

A rainbow table attack is usually overkill for a desktop machine. If hackers have physical access to the machine, security is irrelevant. That’s rule number 3 in the 10 Immutable Laws of Computer Security. There are any number of tools that can reset passwords given physical access to the machine.

But when a remote hacker obtains a large list of hashed passwords from a server or database, we’re in trouble. There’s significant risk from a rainbow table attack. That’s why you should never rely on hashes alone– always add some salt to your hash so the resulting hash values are unique. Salting a hash sounds complicated (and vaguely delicious), but it’s quite simple. You prefix a unique value to the password before hashing it:

hash = md5('deliciously-salty-' + password)

If you’ve salted your password hashes, an attacker can’t use a rainbow table attack against you– the hash results from “password” and “deliciously-salty-password” won’t match. Unless your hacker somehow knows that all your hashes are “delicously-salty-” ones. Even then, he or she would have to generate a custom rainbow table specifically for you.

To begin, password storage 101: servers don’t usually store actual passwords. Instead, they hash the password, store the hash, and discard the password. The hash can verify a password from a login page, but can’t be reversed back to the text of the password. So when you inevitably lose your SQL password table, you haven’t exposed all the passwords; just the crappy ones.

Now let’s re-explain rainbow tables:

  1. take a “dictionary” —- say, of all combinations of alphanumerics less than 15 characters
  2. hash all of them
  3. burn the results onto a DVD.

You now have several hundred billion hash values that you can reverse back to text —- a “rainbow table”. To use,

  1. take your stolen table of hashes
  2. for each hash
  3. find it in the rainbow table.

If it’s there, you cracked it.

 

.

Here’s what you need to know about rainbow tables: no modern password scheme is vulnerable to them.

Rainbow tables are easy to beat. For each password, generate a random number (a nonce). Hash the password with the nonce, and store both the hash and the nonce. The server has enough information to verify passwords (the nonce is stored in the clear). But even with a small random value, say, 16 bits, rainbow tables are infeasible: there are now 65,536 “variants” of each hash, and instead of 300 billion rainbow table entries, you need quadrillions. The nonce in this scheme is called a “salt”.

Cool, huh? Yeah, and Unix crypt —- almost the lowest common denominator in security systems —- has had this feature since 1976. If this is news to you, you shouldn’t be designing password systems. Use someone else’s good one.

 

.

No, really. Use someone else’s password system. Don’t build your own.

Most of the industry’s worst security problems (like the famously bad LANMAN hash) happened because smart developers approached security code the same way they did the rest of their code. The difference between security code and application code is, when application code fails, you find out right away. When security code fails, you find out 4 years from now, when a DVD with all your customer’s credit card and CVV2 information starts circulating in Estonia.

 

.

Here’s a “state of the art” scheme from a recent blog post on rainbow tables and salts:

hash = md5('deliciously-salty-' + password)

There are at least two problems with this code. Yeah, the author doesn’t know what a salt is; “deliciously-salty-” is not a nonce (also, Jeff, your computer really doesn’t care if you seperate the password from the nonce with a dash; it’s a computer, not a 2nd grade teacher).

But there’s a much bigger problem with this code: the letters “md5”.

Two reasons.

1.

You’re expecting me to go off on a rant about how there is no redeeming quality to justify using MD5 in 2007. That’s true (MD5 is broken; it’s too slow to use as a general purpose hash; etc). But that’s not the problem.

2.

The problem is that MD5 is fast. So are its modern competitors, like SHA1 and SHA256. Speed is a design goal of a modern secure hash, because hashes are a building block of almost every cryptosystem, and usually get demand-executed on a per-packet or per-message basis.

Speed is exactly what you don’t want in a password hash function.

Modern password schemes are attacked with incremental password crackers.

Incremental crackers don’t precalculate all possible cracked passwords. They consider each password hash individually, and they feed their dictionary through the password hash function the same way your PHP login page would. Rainbow table crackers like Ophcrack use space to attack passwords; incremental crackers like John the Ripper, Crack, and LC5 work with time: statistics and compute.

The password attack game is scored in time taken to crack password X. With rainbow tables, that time depends on how big your table needs to be and how fast you can search it. With incremental crackers, the time depends on how fast you can make the password hash function run.

The better you can optimize your password hash function, the faster your password hash function gets, the weaker your scheme is. MD5 and SHA1, even conventional block ciphers like DES, are designed to be fast. MD5, SHA1, and DES are weak password hashes. On modern CPUs, raw crypto building blocks like DES and MD5 can be bitsliced, vectorized, and parallelized to make password searches lightning fast. Game-over FPGA implementations cost only hundreds of dollars.

Using raw hash functions to authenticate passwords is as naive as using unsalted hash functions. Don’t.

 

.

What is the state of the art here?

1.

First, what your operating system already gives you: a password scheme “optimized” to be computationally expensive. The most famous of these is PHK’s FreeBSD MD5 scheme.

The difference between PHK’s scheme and the one you were about to use for your social shopping cart 2.0 application is simple. You were just going to run MD5 on a salt and a password and store the hash. PHK runs MD5 for thousands of iterations. That’s called “stretching”.

PHK’s MD5 scheme is straightforward to code and comes with Linux and BSD operating systems. If you have to choose between the PHP code you have now and PHK’s scheme, you choose PHK’s scheme or you fail your PCI audit. [â??]

2.

The best simple answer is “adaptive hashing”, which Neils Provos and David Mazieres invented for OpenBSD in 1999. Their original scheme is called “bcrypt”, but the idea is more important than the algorithm.

There are three big differences between Provos-Mazieres and PHK’s scheme:

  1. Bcrypt was invented by two smart guys and PHK’s was only invented by one smart guy. That’s literally twice the smart.
  2. Bcrypt uses Blowfish instead of MD5. Blowfish is a block cipher with a notoriously expensive setup time. To optimize Blowfish to run much faster, you’d have to contribute a major advance to cryptography. We security practioners are all “betting people”, and we usually like to place our bets on the side that “demands major advances in cryptography”.
  3. Provos and Mazieres extended Blowfish. They call theirs “Eksblowfish”. Eksblowfish is pessimized: the setup time takes even longer than Blowfish. How long? Your call. You can make a single password trial take milliseconds, or you can make it take hours.

Why is bcrypt such a huge win? Think of the problem from two perspectives: the server, and the attacker.

First, the server: you get tens of thousands of logins per hour, or tens per second. Compared to the database hits and page refreshes and IO, the password check is negligable. You don’t care if password tests take twice as long, or even ten times as long, because password hashes aren’t in the 80/20 hot spot.

Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long.

Get it?

The major advantage of adaptive hashing is that you get to tune it. As computers get faster, the same block of code continues to produce passwords that are hard to crack.

3.

Finally, as your attorney in this matter, I am required to inform you about SRP.

SRP is the Stanford Secure Remote Password protocol. It is a public key cryptosystem designed to securely store and validate passwords without storing them in the clear or transmitting them in the clear.

That design goal is cooler than it sounds, because there’s usually a tradeoff in designing password systems:

  1. You can store a hash of the password. Now if you lose the password database, you haven’t exposed the good passwords. However, you also don’t know the password cleartext, which means that to validate passwords, your customers need to send them to you in the clear.
  2. You can use a challenge-response scheme, where both sides use a math problem to prove to each other that they know the password, but neither side sends the password over the wire. These schemes are great, but they don’t work unless both sides have access to the cleartext password —- in other words, the server has to store them in the clear.

Most practitioners will select the hashing scheme. Both attacks —- stolen databases and phished passwords —- happen all the time. But stolen databases compromise more passwords.

SRP resolves the tradeoff. It’s an extension of Diffie-Hellman. The salient detail for this post: instead of storing a salted password hash, you store a “verifier”, which is a number raised to the (obviously very large) power of the password hash modulo N.

If you understand DH, SRP is just going to make sense to you. If you don’t, the Wikipedia will do a better job explaining it than I will. For the test next Wednesday, you need to know:

  • SRP is related to Diffie-Hellman.
  • SRP is a challenge-response protocol that lets a server prove you know your password without your password ever hitting the wire.
  • SRP doesn’t require you to store plaintext passwords; you store non-reversable cryptographic verifiers.
  • “Cracking” SRP verifiers quickly would involve a significant advancement to cryptography.
  • SRP is simple enough to run out of browser Javascript.

Awesome! Why aren’t you using SRP right now? I’ll give you three reasons:

  • SRP is patented.
  • To make it work securely in a browser, you have to feed the login page over SSL; otherwise, like Meebo, you wind up with a scheme that can be beaten by anyone who can phish a web page.
  • SRP is easy to fuck up, so the first N mainstream Rails or PHP or Pylons SRP implementations are going to be trivially bypassable for at least the first year after they’re deployed.

 

.

What have we learned?
We learned that if it’s 1975, you can set the ARPANet on fire with rainbow table attacks. If it’s 2007, and rainbow table attacks set you on fire, we learned that you should go back to 1975 and wait 30 years before trying to design a password hashing scheme.

We learned that if we had learned anything from this blog post, we should be consulting our friends and neighbors in the security field for help with our password schemes, because nobody is going to find the game-over bugs in our MD5 schemes until after my Mom’s credit card number is being traded out of a curbside stall in Tallinn, Estonia.

We learned that in a password hashing scheme, speed is the enemy. We learned that MD5 was designed for speed. So, we learned that MD5 is the enemy. Also Jeff Atwood and Richard Skrenta.

Finally, we learned that if we want to store passwords securely we have three reasonable options: PHK’s MD5 scheme, Provos-Maziere’s Bcrypt scheme, and SRP. We learned that the correct choice is Bcrypt.

The Rainbow Table Is Dead

Well ok, not really.  But you should not be securing hashes against rainbow tables anymore, you need to secure them against brute forcing.  Rainbow tables are still very effective for simple hashes (md5($password)), but just because an algorithm is hard to use for a rainbow table doesn’t mean that it is safe, because the rainbow table is dead…

What Is A Rainbow Table?

Generically, a rainbow table is nothing more than a time-storage trade-off.  Instead of recomputing a function every time you want to attack it, a rainbow table is generated by pre-computing a large number of input permutations to that function.  Then, given a result, it should be easy to look-up the result in a table to determine which input(s) generate it.  That way, you can effectively reverse a non-reversible function…

Applied to hashing (and in this particular context, password hashing), a rainbow table is generated by generating a large number of candidate passwords (typically random, but may be dictionary based as well), and storing the password->hash mapping in a database or data file.  Then simply look-up the hash that you have to get the plain text password that may have generated it.

The First Problem: Storage Space

For a rainbow table to be effective, it must have a lot of candidate passwords in it.  Let’s take a look at an MD5 rainbow table, and see how much storage space it will require.  Let’s also assume that it will be stored in MySQL with a char(10) column for the password, and binary(16) column for the hash (storing it in a binary format).  So each row will have approximately 26 bytes of data (not including any overhead).  And lets look at source passwords of all printable non-control ASCII characters (there are 77 of them).

Length Of Password Number Of Possibilities Size Of Table
4 characters 35,153,041 913 MB
5 characters 2,706,784,157 70 GB
6 characters 208,422,380,089 5.4 TB
7 characters 16,048,523,266,853 417 TB
8 characters 1,235,736,291,547,681 32 PB (PetaBytes, 10^15)

As you can see, the number of possibilities goes up quite fast as you support longer passwords. So that means for a rainbow table to be effective, it must actually reduce the number of possible candidates that it stores.  After all, who would want to download 32 Petabytes to crack a hash?  Sure, you could use a dictionary and permutations on the words to try to reduce the search space significantly without cutting down on effectiveness much (statistically speaking).  But that also means a much greater resistance to strong-but-short passwords.

The Second Problem: Hash Algorithms

Hash algorithms are designed with two things in mind: security and speed.  Their typical role is to create a MAC (message authentication code) for a document.  So by hashing the document, you can tell if the original document is the same as long as the generated hashes match.  So since they need to process a lot of data (potentially gigabytes or more), a key requirement is speed.  In fact, most modern “secure” algorithms are even faster than their predecessors on modern hardware (for example, sha256 is several times faster than md5 which is much older).

The faster the hash function is, the less reason there is to use a rainbow table.  After all, the rainbow table is just a time-storage trade-off (you’re reducing time by using more storage).  So since hash functions are only getting faster, the benefit of a rainbow table is diminished.

The Third Problem: Salts

Salts are a random token (usually used only once) that is combined with the password before hashing.  They are specifically used to prevent the use of a rainbow table.  Note that using a salt doesn’t directly prevent a rainbow table from being used, it just reduces its effectiveness.  It artificially increases the length of a password in the rainbow table (so to crack a 4 character password with a 4 character salt, you’d need to generate an 8 character rainbow table).  In practice, most usual lengths of salts are too big to generate a universal rainbow table (for a 32 character salt and 8 character password, the rainbow table would need to be 2.8*10^75 bytes).  So another method that attackers use is to steal the salt along with the hash, and then generate a new rainbow table for each salt.  That’s why it’s so important to use a unique salt for each stored password (it reduces the return on investment that the new rainbow table will provide).

Why Were They Popular?

Rainbow tables were popular for one key reason: Up until very recently, disk was significantly cheaper than CPU time.  It was easier to pre-compute the rainbow table (which can take a very long time) than to do hashes as needed.

The Reality Today

I know what you’re thinking…  ”Isn’t disk space even cheaper today than it was a few years ago?”…  Yes it is.  But CPU time is even cheaper by several orders of magnitude.  In 2000, the cost of a hard drive was about $13 per gigabyte.  Today, the cost of a hard drive is about $0.10 per gigabyte.  That’s 2 orders of magnitude!  But if we look at a Pentium 3, it could achieve about 300 mflops (millions of floating point operations per second) for $825, for an average of $2.75 per mflop.  A modern Intel i7 can do about 107,000 mflops for $999, averaging about $0.0093 per mflop.  That’s a 4 order or magnitude difference!

But wait; we have a reasonably new contender!  Enter, the GPU.  A single Radeon HD 6990M can achieve approximately 1,600,000 mflops for about $700.  Computed down, that’s a whopping $0.00043 per mflop.  That’s about an order of magnitude less than the Intel i7, and 5 orders of magnitude less than the P3.  Not to mention the raw performance is 4 orders of magnitude greater!

How Many Hashes Per Second?

Well, there’s a password cracking tool called John the Ripper.  Currently, it can hash up to 514 million (DES crypt()) hashes per second (abbreviated mhps from here out) on a modern 4 core CPU (Intel x7550).  When using a more modern algorithm such as sha256, John the Ripper can do a rather measly 200,000 hashes per second.  At that rate it would take 3 minutes to generate a 4 character rainbow table.  Fast, but not fast enough for our purposes.

Now, let’s look at what a GPU can do.  Bitcoin currently uses 2 internal sha256 rounds to compute a single “hash”.  So when we look at the performance numbers they are reporting, we need to realize that’s for 2 sha256 hashes.  If we look at the fastest single card setup (an ATI 5970), it does over 860 million bitcoin hashes per second.  That’s over 1.720 billion sha256 hashes per second!  And a 3 card setup can hit almost 4.2 billion sha256 hashes per second.  So let’s take a look at our chart again, this time for a salted sha256 password:

Length Of Password Number Of Possibilities CPU GPU
4 characters 35,153,041 3 minutes 0.0083 seconds
5 characters 2,706,784,157 3.75 hours 0.64 seconds
6 characters 208,422,380,089 12 days 49 seconds
7 characters 16,048,523,266,853 2.5 years 1.06 hours
8 characters 1,235,736,291,547,681 195 years 3.4 days

So, for about $2100, we can have a set of 3 GPUs that can brute force any printable 8 character password possible in about 3.4 days. And that’s at the absolute worst case possible.  If we started to do intelligence things such as using a dictionary as the base for our search, we could likely find that password much, much faster.

The Other Benefit To Brute Forcing

The other benefit to brute forcing, is you invest practically nothing in the algorithm.  For a rainbow table you need to provide both cpu time to generate (a lot of it) and storage space (a lot of it). Not to mention thinks like disk seek time.  An average high end hard drive has a seek time of around 4ms.  So to merely read the data stored in a rainbow table for a 4 character password, you’re spending about 1/2 the time taken by the gpu just seeking in the database file.  Then, the computer needs to do a full scan of all of the data to search for the hash value.  So in the end, for a 4 character password, it’s likely cheaper in all accounts just to brute force it on a GPU than it is to generate a rainbow table.

A Word On Entropy

All of the numbers that I’ve used in this article are based off the assumption that password choice is fully random.  That’s the worst case situation.  That means that given n bits of data, it would take on average 2^(n-1) tries to have a 50% chance of guessing it.  So for a pure random 8 character password (printable characters), you’d need on average about 1.7 days on a GPU to brute force it.  Each character in our pure random password has about 6.26 bits of entropy (due to the 77 possible characters, instead of 256).  So an 8 character password has about 50 bits of entropy (and this is true, since 2^50 is about 10^15, which is what we calculated above).

But that’s not the way of the world.  The vast majority of passwords are user generated.  And user generated passwords tend to have significantly less entropy.  In fact, according to NIST (Appendix A), a 8 character password with symbols and numbers would only have about 18 bits of entropy.  It could be 24 bits if there existed both upper-case and lower-case characters.  But 2^24 is only about 16 million.  So notice that our 4 character random password is actually on average twice as strong as a user-selected 8 character password.  In the worst case, it would take the full 2^50 tries to guess a user selected 8 character password, so that’s the same.  But the 50% chance occurs much sooner at 2^23 than the random password at 2^49.

Speaking of entropy, we’re going to revisit the concept in another post soon (specifically about what a recent web-comic pontificated)…

Finally

The overall point is simple.  A rainbow table is a useful tool.  But it’s also an outdated tool that doesn’t mean nearly as much as it used to.  In the era of the cheap GPU, brute forcing is more than a possibility, it’s a fact.  Using an algorithm because it’s resistant to a rainbow table is not only obsolete, it bypasses the bigger problem.  You need to hash your passwords so that they are hard to brute force.  If they are hard to brute force, they will be hard to rainbow table as well.

Presently, there are about 3 algorithms for PHP that will provide adequate defense against brute forcing. BCrypt (called Blowfish in PHP’s docs), PBKDF2 and PHPASS‘s internal function (in order from strongest to weakest).  It’s worth noting that projects such as Drupal, PHPBB and WordPress have all implemented either PHPASS or a derivative thereof.  All of the algorithms accept a “work factor” which controls how much CPU time the algorithm takes.  By artificially slowing down the hash, brute forcing is made significantly harder (but not impossible).

Use an algorithm that has protections against brute forcing, as protecting against rainbow tables alone is a lost battle…

Posted by Anthony Ferrara at 8/16/2011 10:00:00 AM

 

El bueno, malo, y bonito

javascript esta en un estado límbico. Por un lado permite trucos de manejo de pantallas tipo Ajax y por otro es un riesgo de seguridad. ¿Qué influencia será más fuerte? Firefox flaws raise Mozilla security doubts

javascript esta en un estado límbico. Por un lado permite trucos de manejo de pantallas tipo Ajax y por otro es un riesgo de seguridad. ¿Qué influencia será más fuerte?

Firefox flaws raise Mozilla security doubts

ASP.Net Security

Make sure you are very familiar with the following terms: Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers. Authorization. Defining what authenticated clients are allowed to see and do within the application. Secure Communications. Ensuring that messages remain private and unaltered as they cross networks. Impersonation. This […]

tecnologias ASP.NetMake sure you are very familiar with the following terms:

  • Authentication. Positively identifying the clients of your application; clients might include end-users, services, processes or computers.
  • Authorization. Defining what authenticated clients are allowed to see and do within the application.
  • Secure Communications. Ensuring that messages remain private and unaltered as they cross networks.
  • Impersonation. This is the technique used by a server application to access resources on behalf of a client. The client’s security context is used for access checks performed by the server.
  • Delegation. An extended form of impersonation that allows a server process that is performing work on behalf of a client, to access resources on a remote computer. This capability is natively provided by Kerberos on Microsoft® Windows® 2000 and later operating systems. Conventional impersonation (for example, that provided by NTLM) allows only a single network hop. When NTLM impersonation is used, the one hop is used between the client and server computers, restricting the server to local resource access while impersonating.
  • Security Context. Security context is a generic term used to refer to the collection of security settings that affect the security-related behavior of a process or thread. The attributes from a process’ logon session and access token combine to form the security context of the process.
  • Identity. Identity refers to a characteristic of a user or service that can uniquely identify it. For example, this is often a display name, which often takes the form authority/user name.

Principles

There are a number of overarching principles that apply to the guidance. The following summarizes these principles:

  • Adopt the principle of least privilege. Processes that run script or execute code should run under a least privileged account to limit the potential damage that can be done if the process is compromised. If a malicious user manages to inject code into a server process, the privileges granted to that process determine to a large degree the types of operations the user is able to perform. Code that requires additional trust (and raised privileges) should be isolated within separate processes.The ASP.NET team made a conscious decision to run the ASP.NET account with least privileges.
  • Use defense in depth. Place check points within each of the layers and subsystems within your application. The check points are the gatekeepers that ensure that only authenticated and authorized users are able to access the next downstream layer.
  • Don’t trust user input. Applications should thoroughly validate all user input before performing operations with that input. The validation may include filtering out special characters. This preventive measure protects the application against accidental misuse or deliberate attacks by people who are attempting to inject malicious commands into the system. Common examples include SQL injection attacks, cross-site scripting attacks, and buffer overflow.
  • Use secure defaults. A common practice among developers is to use reduced security settings, simply to make an application work. If your application demands features that force you to reduce or change default security settings, test the effects and understand the implications before making the change.
  • Don’t rely on security by obscurity. Trying to hide secrets by using misleading variable names or storing them in odd file locations does not provide security. In a game of hide-and-seek, it’s better to use platform features or proven techniques for securing your data.
  • Check at the gate. You don’t always need to flow a user’s security context to the back end for authorization checks. Often, in a distributed system, this is not the best choice. Checking the client at the gate refers to authorizing the user at the first point of authentication (for example, within the Web application on the Web server), and determining which resources and operations (potentially provided by downstream services) the user should be allowed to access.If you design solid authentication and authorization strategies at the gate, you can circumvent the need to delegate the original caller’s security context all the way through to your application’s data tier.
  • Assume external systems are insecure. If you don’t own it, don’t assume security is taken care of for you.
  • Reduce surface area. Avoid exposing information that is not required. By doing so, you are potentially opening doors that can lead to additional vulnerabilities. Also, handle errors gracefully; don’t expose any more information than is required when returning an error message to the end user.
  • Fail to a secure mode. If your application fails, make sure it does not leave sensitive data unprotected. Also, do not provide too much detail in error messages; meaning don’t include details that could help an attacker exploit a vulnerability in your application. Write detailed error information to the Windows event log.
  • Remember you are only as secure as your weakest link. Security is a concern across all of your application tiers.
  • If you don’t use it, disable it. You can remove potential points of attack by disabling modules and components that your application does not require. For example, if your application doesn’t use output caching, then you should disable the ASP.NET output cache module. If a future security vulnerability is found in the module, your application is not threatened.

The following steps identify a process that will help you develop an authentication and authorization strategy for your application:

  1. Identify resources
  2. Choose an authorization strategy
  3. Choose the identities used for resource access
  4. Consider identity flow
  5. Choose an authentication approach
  6. Decide how to flow identity

Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

Natas; Crónica del virus mexicano

Tomado de http://vx.netlux.org/lib/agm00.html En 1992 Little Loc se registro en Prodigy para buscar información sobre virii. Little Loc, alias James Gentile, a los 16 años habí­a escrito un virus mutante que se dispersaba rápidamente. El virus, Satan Bug, estaba escrito de manera que el proceso mismo de rastrear un disco en busca de infección infectaba […]

Tomado de http://vx.netlux.org/lib/agm00.html

En 1992 Little Loc se registro en Prodigy para buscar información sobre virii. Little Loc, alias James Gentile, a los 16 años habí­a escrito un virus mutante que se dispersaba rápidamente. El virus, Satan Bug, estaba escrito de manera que el proceso mismo de rastrear un disco en busca de infección infectaba todos los ejecutables en el mismo.

Satan Bug era el nombre de una teleserie de los 70s. ((Aunque Little Loc nunca vio la serie, vio el nombre en el TVguí­a y le gusto. )) El icono que inspiro la creación de Satan Bug fue el trabajo de Dark Avenger, ((un programador búlgaro de virus y su virus Eddie o Dark Avenger. Eddie usaba los mecanismos de rastreo de antivirus para infectar una maquina y gradualmente corrompí­a el disco duro del anfitrión. Una muerta lenta y dolorosa bajo las cuchillas del vengador tenebroso.))

Little Loc tenía talento natural para escribir virii, un arte que aprendió sin maestro directo ni entrenamiento formal en programación. ((Siguiendo el modelo de Eddie, Satan Bug atacaba el command shell al instalarse en memoria.)) Adicionalmente a los poderes del vengador tenebroso, Satan bug estaba encriptado y se escondí­a en la memoria del computador. Las características de encriptación estaban basadas en la ballena, un virus alemán. La ballena era una pesada navaja suiza de trucos para esconderse de los antivirus.

Little Loc publico el código fuente de Satan Bug en un boletín de noticias y se dedico activamente a diseminar su código. ((Su motivación era ser reconocido por su habilidad técnica.)) Eventualmente, en 1993, Satan Bug infecto las maquinas del servicio secreto en Washington D.C. y las saco de servicio por 3 dí­as. El servicio secreto siguió una línea de investigación con la hipótesis de que el virus era un esfuerzo deliberado para atacar maquinas del gobierno de Estados Unidos.

Little Loc cambió su nombre por Priest y escribió Jackal. ((Jackal fue escrito como un contraataque contra TBClean, un antivirus producido por la compañí­a holandesa Thunderbyte, del investigador de virus Frans Veldman.)) Un derivado de Jackal fue el Natas. En su espí­ritu de medida retaliatoria, Natas formatea el disco duro cuando detecta la presencia de TBClean.

Los mecanismos de detección de programas antivirus de Jackal los incluyo Priest en Natas (Satan al revés), que llego a la ciudad de México en la primavera de 1994.

De acuerdo a la tradición, un consultor que vendía servicios antivirus en la ciudad de México se encargo de propagarlo vigorosamente. Debido a ignorancia e incompetencia, adicionada con entusiasmo empresarial y poder de convocatoria, este pendejo con iniciativa logro difundir Natas en México tan rápido que la leyendo urbana lo ubica como un software de origen mexicano. Un script tragicómico digno del mejor guionista.

El consultor, al visitar los boletines de noticias dedicados a virii, contamino un diskette con Natas. ((El software que usaba detectaba el virus en programas, pero no en el sector MBR (Master Boot Record) del disco duro.)) El consultor iba con sus clientes, corrí­a su software de rastreo de su diskette infectado y detectaba la infección de Natas que el mismo provocaba. Alarmado corría a la siguiente maquina y repetía el proceso, infectando todas las maquinas del lugar. Inmediatamente iba a visitar a sus mejores clientes con la noticia de que había una epidemia de Natas y que más les valía rastrear sus maquinas, con el software que el traí­a, que podía detectar al Natas. Entonces procedía a infectar todas las maquinas y a continuar el proceso con el vecino de al lado. Seguramente penso que eso de Satan iba ne sero cuando despues de formatar las maquinas el virus resurguía de la nada. Espeluznante!

Natas llego a México del sur de California. El consultor era visitante frecuente de BBS en Santa Clarita que tenían el Natas y su código fuente en la revista 40Hex. El buen cuate bajo el virus sin entender que al diablo le puedes vender el alma, pero no pedirla de regreso. En mayo de 1994, un mes después, desesperadamente el consultor buscaba ayuda en los boletines de noticias.

Natas era un programa tí­pico de Priest. Estando en memoria, hace parecer que programas infectados no lo estaban. Copia una copia limpia de MBR y se la muestra al usuario para fintarlo de que todo estaba bien si lo revisa. Natas infectaba diskettes y utiliza el rastreo del antivirus para diseminarse.

Yo en lo personal tuve una experiencia similar a la del cuento. Tenia una Compaq Presario que me estaba dando problemas y solicite la vista de un técnico de Compaq para que revisara la maquina. El técnico se tuvo que retirar sin dar le servicio porque todos sus diskettes con utilerías de diagnostico estaban infectados con un virus.

Ubuntu root

Con un enfoque paternalista Ubuntu de entrada no da acceso a la cuenta de  root, sino que los comandos privilegiados se deben ejecutar usando sudo. Since most Ubuntu documentation asks you to use sudo even with graphical applications, Why recommend gksudo or kdesudo for graphical applications instead of sudo. For example, a lot of guides […]

Con un enfoque paternalista Ubuntu de entrada no da acceso a la cuenta de  root, sino que los comandos privilegiados se deben ejecutar usando sudo. Since most Ubuntu documentation asks you to use sudo even with graphical applications, Why recommend gksudo or kdesudo for graphical applications instead of sudo.

For example, a lot of guides (including the first book ever published about Ubuntu) will ask you to type this sort of command:

sudo gedit /etc/apt/sources.list

I will always recommend, however, that people use instead this sort of command:

gksudo gedit /etc/apt/sources.list

And reserve sudo for command-line applications, like so:

sudo nano /etc/apt/sources.list

Why is it an issue?
Well, to be perfectly honest, most of the time it isn’t. For a lot of applications, you can run them the improper way—using sudo for graphical applications and see no adverse side effects.

1. There are other times, though, when side effects can be as mild as Firefox extensions not sticking or as extreme as as not being able to log in any more because the permissions on your .ICEauthority changed. You can read a full discussion on the issue here.

These errors occur because sometimes when sudo launches an application, it launches with root privileges but uses the user’s configuration file.

Referencias

the Interceptor

the Interceptor What is the Interceptor? The Interceptor is a wireless wired network tap. Basically, a network tap is a way to listen in to network traffic as it flows past. I haven’t done extensive research but all the ones I found when looking passed the copy of the traffic onto a specified wired interface […]

the Interceptor

What is the Interceptor?

The Interceptor is a wireless wired network tap. Basically, a network tap is a way to listen in to network traffic as it flows past. I haven’t done extensive research but all the ones I found when looking passed the copy of the traffic onto a specified wired interface which was then plugged into a machine to allow a user to monitor the traffic. The problem with this is that you have to be able to route the data from that wired port to your monitoring machine either through a direct cable or through an existing network. The direct cable method means your monitor has to be near by the location you want to tap, the network routing means you have to somehow encapsulate the data to get it across the network without it being affected on route.

The Interceptor does away with the wired monitor port and instead spits out the traffic over wireless meaning the listener can be anywhere they can make a wireless connection to the device. As the data is encrypted (actually, double encrypted, see how it works) the person placing the tap doesn’t have to worry about unauthorized users seeing the traffic.

See here for more information on how it works.

What Hardware Is Required

This project has been built and tested on a Fon+ but should in theory work on any device which will run OpenWrt and has at least a pair of wired interfaces and a wireless one.

OpenWrt is an operating system primarily used on embedded devices to route network traffic. The main components are the Linux kernel, uClibc and BusyBox. All components have been optimized for size, to be small enough to fit the limited storage and memory available in home routers.

OpenWrt is configured using a command-line interface (ash), or a web interface (LuCI). There are about 3500 optional software packages available for install via the opkg package management system.

OpenWrt can be run on CPE routers, residential gateways, smartphones (e.g. Neo FreeRunner), pocket computers (e.g. Ben NanoNote), and small laptops (e.g. One Laptop per Child (OLPC)). But it is also possible to run on ordinary computers (e.g. x86). Many patches are being included upstream in the Linux mainline kernel.

Possible Uses

This isn’t intended to be a permanent, in-situ device. It is designed for short term trouble shooting or information gathering on low usage networks, as such, it will work well between a printer and a switch but not between a switch and a router. Here are some possible situations for use:

  • Penetration testing – If you can gain physical access to a targets office drop the device between the office printer and switch then sit in the carpark and collect a copy of all documents printed. Or, get an appointment to see a boss and when he leaves the room to get you a drink, drop it on his computer. The relative low cost of the Fon+ means the device can almost be considered disposable and if branded with the right stickers most users wouldn’t think about an extra small box on the network.
  • Troubleshooting – For sys-admins who want to monitor an area of network from the comfort of their desks, just put it in place and fire up your wireless.
  • IDS – If you want to see what traffic is being generated from a PC without interfering with the PC simply add the Interceptor and sit back and watch. As the traffic is cloned to a virtual interface on your monitoring machine you can use any existing tools to scan the data.

I’m sure there are plenty more uses, if you come up with any good ones, let me know.

Download

The Interceptor comes as a single tarball which can be downloaded from here.

It also requires a number of extra packages to be installed on a base OpenWrt install, they can be found on the OpenWrt download page.

Install Notes

There are two sets of install notes, a basic set and a detailed walk-through set. The basic set is the standard set of notes that comes with most packages, the detailed set is a full walk through from flashing the Fon+, installing dependencies, installing Interceptor, starting up and monitoring traffic and finally shutting it down. Most people should find the basic set sufficient but the detailed set are useful if you have any problems.

Limitations

The main limitation is bandwidth, the wired network can get up to 100Mb/s but the top speed of the wireless is 54Mb/s, add on to that the overhead of encryption and that rate drops down further. This is why the Interceptor won’t work well on high traffic parts of the network.

From tests I’ve done, under high load the network seems to stay up and stable but not all traffic ends up on the monitor interface. I haven’t done any research to find out where the traffic is being dropped, it could be DaemonLogger, the AP or at the VPN. This is good as it means the device doesn’t affect the smooth running of the network but obviously means you may miss some important data. Be aware of this when working with the device.

The software has no fail safe in case of problems. If the hardware or software fails the network connection being tapped will probably be lost. Don’t use the Interceptor in situations where uptime is critical without knowing what you are doing.

Support

If you have any problems or questions you can either drop me an email or visit the Hak5 forums.

Licence

The Interceptor is released under a Creative Commons licence, view the terms for more information.

 

the fonosfera

Here is the place to download and commit source code into the Fonera 2.0 firmware (aka fon-ng) and report bugs. It is also the place that will host fon-ng Documentation. End user documentation of the Fonera 2.0 is on the Wiki:  Fonera 2.0n and  Fonera 2.0g

Resources

Getting Started with fon-ng