How To Recovers All Wireless Network Keys (WEP/WPA)

How To Recovers All Wireless Network Keys (WEP/WPA) stored in your computer by the 'Wireless Zero Configuration' service of Windows XP or by the 'WLAN AutoConfig' service of Windows Vista. It allows you to easily save all keys to text/html/xml file, or copy a single key to the clipboard.

License

This utility is released as freeware. You are allowed to freely distribute this utility via floppy disk, CD-ROM, Internet, or in any other way, as long as you don't charge anything for this. If you distribute this utility, you must include all files in the distribution package, without any modification !
Be aware that selling this utility as a part of a software package is not allowed !

Disclaimer

The software is provided "AS IS" without any warranty, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The author will not be liable for any special, incidental, consequential or indirect damages due to loss of data or any other reason.

Known Problems

False Alert Problems: Some Antivirus programs detect WirelessKeyView utility as infected with Trojan/Virus. Click here to read more about false alerts in Antivirus programs. Also, if you have any problem with using WirelessKeyView, please read the WirelessKeyView Frequently Asked Questions page

Versions History

• Version 1.36:
  • Fixed bug on Windows 7/2008/Vista: WirelessKeyView truncated the key after 32 characters.
• Version 1.35:
  • Added 'Mark Odd/Even Rows' option, under the View menu. When it's turned on, the odd and even rows are displayed in different color, to make it easier to read a single line.
  • Added 'Add Header Line To CSV/Tab-Delimited File' option. When this option is turned on, the column names are added as the first line when you export to csv or tab-delimited file.
• Version 1.34:
  • Fixed bug: pressing the delete key in the find window deleted an item in the main window.
• Version 1.33:
  • When loading WirelessKeyView under Windows 7 in the first time, the 'Code Inject' mode is now turned on by default.
• Version 1.32:
  • Added /codeinject command-line option.
• Version 1.31:
  • Fixed a crash problem with Application Compatibility Engine on Windows 7/Vista (only when 'Use code injection method' is turned on).
• Version 1.30:
  • Added 'Use code injection method' option in the Advanced Options window, as a workaround for using this utility on Windows 7. (See below)
• Version 1.28:
  • Added sorting command-line options.
• Version 1.27:
  • Fixed bug: In Vista, WPA-PSK keys in Ascii form displayed additional space character.
• Version 1.26:
  • Fixed bug: In Vista, if WPA-PSK key contained 32 characters, the key was not displayed in Ascii form.
• Version 1.25:
  • New and safer method to extract the wireless keys of the local machine: In previous versions, WirelessKeyView injected code into lsass.exe in order to grab the wireless keys from the system. In rare cases, this technique caused a crash inside lsass.exe process. Starting from this version, WirelessKeyView uses a new method that extract the wireless keys without any code injection.
• Version 1.20:
  • WirelessKeyView now allows you to extract the wireless keys from external instance of Windows XP. (In Advanced Options)
• Version 1.18:
  • You can now send the information to stdout by specifying an empty filename ("") in the command-line. (For example: WirelessKeyView.exe /stab "" >> c:\temp\keys.txt)
• Version 1.17:
  • Fixed bug: WirelessKeyView failed to find the adapter name
  • Fixed bug: Bad color in HTML report
  • Fixed bug: The main window lost the focus when the user switched to another application and then returned back to WirelessKeyView.
• Version 1.16 - Added support for saving as comma-delimited file.
• Version 1.15 - Added support for deleting the wireless keys of old network adapters.
• Version 1.13 - Under Vista, this utility now runs as admin automatically. You don't have to explicitly choose the "Run As Administrator" option.
• Version 1.12 - The configuration is now saved to a file instead of the Registry.
• Version 1.11 - Fixed 'Access Violation' problem under some wireless cards.
• Version 1.10 - Added support for Windows Vista. (both 32-bit and x64 versions)
• Version 1.00 - First release.

System Requirement

• Windows XP with SP1 or greater.
• You must login to windows with admin user.

Using WirelessKeyView

WirelessKeyView doesn't require any installation process or additional DLL files. Just copy the executable file (WirelessKeyView.exe) to any folder you like, and run it.
After you run it, the main window should displayed all WEP/WPA keys stored in your computer by Windows 'Wireless Zero Configuration' service. For WEP keys, the key is also displayed in Ascii form. Be aware that this utility can only reveal the network keys stored by Windows operating system. It cannot recover network keys stored by any other third-party software.

Notice About WPA-PSK Keys

When you type a WPA-PSK key in Windows XP, the characters that you type are automatically converted into a new binary key that contains 32 bytes (64 Hexadecimal digits). This binary key cannot instantly be converted back to the original key that you typed, but you can still use it for connecting the wireless network exactly like the original key. In this case, WirelessKeyView displays this binary key in the Hex key column, but it doesn't display the original key that you typed.
As opposed to Windows XP, Windows Vista doesn't convert the WPA-PSK Key that you type into a new binary key, but it simply keep the original key that you type. So under Windows Vista, the original WPA-PSK key that you typed is displayed in the Ascii key column.

Registry/File Location of The Stored Keys

Windows XP and Windows Vista stores the wireless keys in completely different locations:

• Windows XP: The wireless keys are stored in the Registry under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WZCSVC\Parameters\Interfaces\[Interface Guid].
• Windows Vista: The wireless keys are stored in the file system, under c:\ProgramData\Microsoft\Wlansvc\Profiles\Interfaces\[Interface Guid]. The encrypted keys are stored in .xml file.

Deleting Wireless Keys Of Old Network Adapters

Starting from version 1.15 of WirelessKeyView, you can delete wireless keys of old network adapters that are no longer plugged to your computer, by using the 'Delete Selected Items' option.
Be aware that this delete option only works for network adapters that are not active anymore. If your network adapter is active, use the standard user interface of Windows to delete the unwanted keys.

Using this utility on Windows 7

Starting from Windows 7, Microsoft changed the encryption and hashing algorithms that are used by the Windows Data Protection (DPAPI) system. This change also affects the encryption of the wireless keys stored by Windows, and thus WirelessKeyView failed to retrieve the wireless keys under Windows 7.
The research and development of a new code that will decrypt the keys of Windows 7 may take a while. So for now, I added a workaround that will allow Windows 7 users to retrieve their wireless keys. This workaround uses an old method of code infection that I used until version 1.25 and it still works properly under Windows 7. This method has one drawback that you should be aware: In some circumstances, it may crash the lsass.exe process and will require your system to restart. In order to use this code injection method under Windows 7, go to 'Advanced Options' (F9), and choose the 'Use code injection method' option.

Command-Line Options

/external <Windows Directory>	Load the wireless keys from external instance of Windows XP.
/codeinject <0 | 1>	Specifies whether the use the code inject method. 1 = yes, 0 = no.
/stext <Filename>	Save the list of all wireless keys into a regular text file.
/stab <Filename>	Save the list of all wireless keys into a tab-delimited text file.
/stabular <Filename>	Save the list of all wireless keys into a tabular text file.
/shtml <Filename>	Save the list of all wireless keys into HTML file (Horizontal).
/sverhtml <Filename>	Save the list of all wireless keys into HTML file (Vertical).
/sxml <Filename>	Save the list of all wireless keys to XML file.
/sort <column>	This command-line option can be used with other save options for sorting by the desired column. If you don't specify this option, the list is sorted according to the last sort that you made from the user interface. The <column> parameter can specify the column index (0 for the first column, 1 for the second column, and so on) or the name of the column, like "Key Type" and "Network Name". You can specify the '~' prefix character (e.g: "~Network Name") if you want to sort in descending order. You can put multiple /sort in the command-line if you want to sort by multiple columns. Examples: WirelessKeyView.exe /shtml "f:\temp\1.html" /sort 2 /sort ~1 WirelessKeyView.exe /shtml "f:\temp\1.html" /sort "Network Name"
/nosort	When you specify this command-line option, the list will be saved without any sorting.

Translating WirelessKeyView to other languages

In order to translate WirelessKeyView to other language, follow the instructions below:

1. Run WirelessKeyView with /savelangfile parameter:
   WirelessKeyView.exe /savelangfile
   A file named WirelessKeyView_lng.ini will be created in the folder of WirelessKeyView utility.
2. Open the created language file in Notepad or in any other text editor.
3. Translate all string entries to the desired language. Optionally, you can also add your name and/or a link to your Web site. (TranslatorName and TranslatorURL values) If you add this information, it'll be used in the 'About' window.
4. After you finish the translation, Run WirelessKeyView, and all translated strings will be loaded from the language file.
   If you want to run WirelessKeyView without the translation, simply rename the language file, or move it to another folder.

Feedback

If you have any problem, suggestion, comment, or you found a bug in my utility, you can send a message to nirsofer@yahoo.com

Read more »

Remote Connectivity and VoIP Hacking

OVERVIEW

With the writing of the fifth edition of this series, not much has changed when it comes to the technology aspect of those plain-old telephone system (POTS) lines, and yet many companies still have various dial-up connections into their private networks or infrastructure. In this chapter, we'll show you how even an ancient 9600-baud modem can bring the Goliath of network and system security to its knees.

It may seem like we've chosen to start our section on network hacking with something of an anachronism: analog dial-up hacking. The advent of broadband to the home through cable modems and DSL continues to make dial-up destined for retirement, but that trip to the old-folks home has yet to begin. The public switched telephone network (PSTN) is still a popular and ubiquitous means of connecting with most businesses and homes. Similarly, the sensational stories of Internet sites being hacked overshadow more prosaic dial-up intrusions that are in all likelihood more damaging and easier to perform.

In fact, we'd be willing to bet that most large companies are more vulnerable through poorly inventoried modem lines than via firewall-protected Internet gateways. Noted AT&T security guru Bill Cheswick once referred to a network protected by a firewall as "a crunchy shell around a soft, chewy center." The phrase has stuck for this reason: Why battle an inscrutable firewall when you can cut right to the target's soft, white underbelly through a poorly secured remote access server? Securing dial-up connectivity is still probably one of the most important steps toward sealing up perimeter security. Dialup hacking is approached in much the same way as any other hacking: footprint, scan, enumerate, exploit. With some exceptions, the entire process can be automated with traditional hacking tools called war-dialers or demon dialers . Essentially, these are tools that programmatically dial large banks of phone numbers, log valid data connections (called carriers ), attempt to identify the system on the other end of the phone line, and optionally attempt a log on by guessing common usernames and passphrases. Manual connection to enumerated numbers is also often employed if special software or specific knowledge of the answering system is required.

The choice of war-dialing software is therefore a critical one for good guys or bad guys trying to find unprotected dial-up lines. This chapter will first discuss two of the most popular war-dialing programs available for free on the Internet (ToneLoc and THCScan) and one commercial product: Sandstorm Enterprises' PhoneSweep. As of this edition, Secure Logix's TeleSweep Secure has been discontinued (January 22, 2003). All that is left of TeleSweep Secure is a web link: http://applications.securelogix.com/tss_information.htm.

Following our discussion of specific tools, we will illustrate manual and automated exploitation techniques that may be employed against targets identified by war-dialing software, including remote PBXs and voicemail systems.

Read more »

Hacking UNIX

Some feel drugs are about the only thing more addicting than obtaining root access on a UNIX system. The pursuit of root access dates back to the early days of UNIX, so we need to provide some historical background on its evolution.

THE QUEST FOR ROOT

In 1969, Ken Thompson, and later Dennis Ritchie, of AT&T, decided that the MULTICS (Multiplexed Information and Computing System) project wasn't progressing as fast as they would have liked. Their decision to "hack up" a new operating system called UNIX forever changed the landscape of computing. UNIX was intended to be a powerful, robust, multiuser operating system that excelled at running programs—specifically, small programs called tools. Security was not one of UNIX's primary design characteristics, although UNIX does have a great deal of security if implemented properly. UNIX's promiscuity was a result of the open nature of developing and enhancing the operating system kernel, as well as the small tools that made this operating system so powerful. The early UNIX environments were usually located inside Bell Labs or in a university setting where security was controlled primarily by physical means. Thus, any user who had physical access to a UNIX system was considered authorized. In many cases, implementing root-level passwords was considered a hindrance and dismissed.

While UNIX and UNIX-derived operating systems have evolved considerably over the past 30 years, the passion for UNIX and UNIX security has not subsided. Many ardent developers and code hackers scour source code for potential vulnerabilities. Furthermore, it is a badge of honor to post newly discovered vulnerabilities to security mailing lists such as Bugtraq. In this chapter, we will explore this fervor to determine how and why the coveted root access is obtained. Throughout this chapter, remember that UNIX has two levels of access: the all-powerful root and everything else. There is no substitute for root!

A Brief Review

You may recall in Casing The Establishment we discussed ways to identify UNIX systems and enumerate information. We used port scanners such as nmap to help identify open TCP/UDP ports, as well as to fingerprint the target operating system or device. We used rpcinfo and showmount to enumerate RPC service and NFS mount points, respectively. We even used the all-purpose netcat (nc) to grab banners that leak juicy information, such as the applications and associated versions in use. In this chapter, we will explore the actual exploitation and related techniques of a UNIX system. It is important to remember that footprinting and network reconnaissance of UNIX systems must be done before any type of exploitation. Footprinting must be executed in a thorough and methodical fashion to ensure that every possible piece of information is uncovered. Once we have this information, we need to make some educated guesses about the potential vulnerabilities that may be present on the target system. This process is known as vulnerability mapping .

Vulnerability Mapping

Vulnerability mapping is the process of mapping specific security attributes of a system to an associated vulnerability or potential vulnerability. This is a critical phase in the actual exploitation of a target system that should not be overlooked. It is necessary for attackers to map attributes such as listening services, specific version numbers of running servers (for example, Apache 1.3.9 being used for HTTP, and sendmail 8.9.10 being used for SMTP), system architecture, and username information to potential security holes. Attackers can use several methods to accomplish this task:

• They can manually map specific system attributes against publicly available sources of vulnerability information, such as Bugtraq, Computer Emergency Response Team (CERT) advisories (http://www.cert.org), and vendor security alerts. Although this is tedious, it can provide a thorough analysis of potential vulnerabilities without actually exploiting the target system.
• Attackers can use public exploit code posted to various security mailing lists and any number of websites, or they can write their own code. This will determine the existence of a real vulnerability with a high degree of certainty.
• They can use automated vulnerability scanning tools, such as nessus (http://www.nessus.org), to identify true vulnerabilities.

All these methods have their pros and cons. However, it is important to remember that only uneducated attackers, known as script kiddies, will skip the vulnerability mapping stage by throwing everything and the kitchen sink at a system to get in without knowing how and why an exploit works. We have witnessed many real-life attacks where the perpetrators were trying to use UNIX exploits against a Windows NT system. Needless to say, these attackers were inexpert and unsuccessful. The following list summarizes key points to consider when performing vulnerability mapping:

• Perform network reconnaissance against the target system.
• Map attributes such as operating system, architecture, and specific versions of listening services to known vulnerabilities and exploits.
• Perform target acquisition by identifying and selecting key systems.
• Enumerate and prioritize potential points of entry.

Read more »

Hacking Windows

INTRODUCTION

By most accounts, systems running Microsoft's Windows family of operating systems comprise a significant portion of any given network, private or public. Largely because of this prevalence, Windows has remained a dedicated target of the hacking community since at least 1997, when a researcher named "Hobbit" released a paper on the Common Internet File System (CIFS) and Server Message Block (SMB), the underlying architectures of Windows networking. (You can find a copy of the paper at http://www.insecure.org/stf/cifs.txt.) The steady release of Windows exploits hasn't abated.

Microsoft has diligently patched most of the problems that have arisen and has slowly fortified the Windows lineage with new security-related features as it has matured. Most significantly, with the advent of Windows XP, Microsoft for the first time offered both businesses and consumers a platform based on the NT kernel, which was formerly focused primarily on the needs of the enterprise such as built-in networking support, scalability, fault tolerance, and security. Therefore, we think the common perception of Windows as an insecure platform is simply uninformed. In knowledgeable hands, Windows can be just as secure as any other system, be it based on UNIX, Linux, or any other OS. As an old security saying goes, "The driver bears more responsibility than the car."

Note

This chapter will treat only Windows XP and Server 2003 and later versions, since most previous versions are no longer under mainstream support.

Clearly, however, this chapter would not be as lengthy as it is if Windows were 100percent secure out of the box. In thinking about and observing Windows security over many years, we've narrowed the areas of highest risk down to two factors: popularity and default insecure configuration.

Popularity is a two-sided coin for those running Microsoft technologies. On one hand, you reap the benefits of broad developer support, near-universal user acceptance, and a robust worldwide support ecosystem. On the flip side, the dominant Windows monoculture is increasingly becoming the target of choice for hackers who craft sophisticated exploits and then unleash them on a global scale (Internet worms based on Windows vulnerabilities such as Code Red, Nimda, Slammer, Blaster, Sasser, and so on all testify to the persistence of this problem). When it comes to notoriety among hackers (both legitimate and illegitimate), there is no bigger feather in the cap than to tar Microsoft.

At the risk of oversimplifying, default insecure configurations have historically made this monoculture so easy to mow down. There are several corollaries to this principle: ease of use, legacy support, and a burgeoning feature set.

The perceived simplicity of the Windows interface makes it appealing to novice administrators who typically adjust few Windows settings once they get the shrink-wrap off. This simplicity is deceptive, however—as any experienced Windows administrator knows, there are dozens of settings that must be tweaked to ensure solid system security (hence the reason for this book!).

Legacy support confounds this problem and makes Windows less secure than it could be. As you will see in this chapter, Windows' continued reliance on legacy features left over from its LAN-based heritage leave it open to some simple attacks. Of course, this legacy support is enabled by default out-of-the-box configurations.

Finally, what keeps Windows squarely in the sights of hackers is the continued proliferation of features and functionality enabled by default within the platform. For example, it has taken three generations of the operating system for Microsoft to realize that installing and enabling Windows' Internet Information Services (IIS) extensions by default leaves its customers exposed to the full fury of public networks (both Code Red and Nimda targeted IIS, for example). One of the cardinal rules of security is that the security risk to any system is directly proportional to its complexity, and Microsoft seems to only now be beginning to learn from its past sins of enabling the maximum functionality out of the box.

There are some signs that the message is beginning to sink in. In January 2002, Microsoft's corporate and spiritual leader, Bill Gates, sent out a memo to the company elaborating on a concept called "Trustworthy Computing" (TwC). TwC seeks to set the same expectations for Microsoft products that consumers have come to associate with the more mundane technologies of daily life, such as dial tone, running water, and electricity. More important than these high concepts was the statement in the memo that security should come before new features in future development projects at Microsoft. It was subsequently reported that the release of Microsoft Windows Server 2003 was delayed while Microsoft performed a "security push" to examine the design and implementation of the product for possible weaknesses. This push seems to be paying dividends in terms of a reduced number of security vulnerabilities in Windows Server 2003 versus its predecessors.

As always, however, only time will tell how great the dividend—recall that it wasn't until Windows NT4 Service Pack 3 that some of the OS's current core security features (such as SYSKEY) were added, and until around Windows 2000 Service Pack 2 that some of the most critical IIS flaws were uncovered and addressed, all in response to devious attacks cobbled together by an ever-tenacious hacking community. At the time of this writing, we give Microsoft a C+ on Windows security, mostly because of the apparent improvements made to IIS, which hasn't seen a serious security bug since our last edition of this book. Of course, other significant flaws have been found elsewhere in the OS, and we will spend significant time with these in this chapter.

So, now that we've taken the 100,000-foot view of Windows security, let's review where we are and then delve into the nitty-gritty details.

Read more »

System Hacking

Hacking Windows

Hacking UNIX

Remote Connectivity and VoIP Hacking

I HAVE A MAC—I MUST BE SECURE!

If we had a nickel for every time we heard this statement, we wouldn't be writing this book. Well, we are gluttons for punishment, so we still would probably be writing this book. We are also huge Macintosh fans, since the Mac is now one of the most popular versions of UNIX!

That's right, if you have been under a rock for several years, you might not realize that with the introduction of OS X, the Mac is UNIX down to the core. Apple's underlying operating system is based on the MACH kernel (derived from Apple's acquisition of NeXT) and the venerable and ever popular FreeBSD. Why is this important? Well, security for Macintosh users has never been much of an issue. Old Mac diehards revel in the days of never worrying about a vulnerability, worm, or virus since versions prior to OS X were very difficult to compromise. Why, you ask? Well, there just wasn't that much functionality built into the underlying operating system; hence, part of the reason Apple spent so much time trying to figure out what its new OS platform would be. After many stops and starts, UNIX was chosen for a myriad of reasons, including functionality.

Like all good things in life, there are tradeoffs. All the new power, speed, elegance, and functionality of OS X are derived from its UNIX heritage. Yet with this newfound functionality comes the potential for additional exposure. Now, the creative artists and Photoshop aficionados who didn't have a care in the world about security must be cognizant of the fact that they are no longer impenetrable. Let's take a look at what network services are running on one of our Macs.

A quick nmap scan of a Mac indicates the following open ports:

localhost:<126> gk$ sudo nmap 192.168.1.101 Starting nmap 3.48 ( http://
www.insecure.org/nmap/ ) at 2004-12-08 08:51 PST
Interesting ports on 192.168.1.101:
(The 1648 ports scanned but not shown below are in state: closed)
PORT     STATE SERVICE
21/tcp   open  ftp
22/tcp   open  ssh
80/tcp   open  http
139/tcp  open  netbios-ssn
427/tcp  open  svrloc
515/tcp  open  printer
548/tcp  open  afpovertcp
631/tcp  open  ipp
6000/tcp open  X11
Nmap run completed -- 1 IP address (1 host up) scanned in 12.287 seconds

As you can see on this particular installation, a multitude of services have been enabled and are accessible via the network. If we connect to a few services, we can see the following:

localhost:<126> gk$ nc 192.168.1.101 80 HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 08 Dec 2004 18:36:23 GMT
Server: Apache/1.3.29 (Darwin)
Content-Location: index.html.en
Vary: negotiate,accept-language,accept-charset
TCN: choice
Last-Modified: Wed, 18 Jul 2001 23:44:21 GMT
ETag: "64e3-5b0-3b561f55;406512c4"
Accept-Ranges: bytes
Content-Length: 1456
Connection: close
Content-Type: text/html
Content-Language: en
Expires: Wed, 08 Dec 2004 18:36:23 GMT

Ah ha…the Mac now runs Apache. In this particular case, it is a relatively current version; however, Apache has had its fair share of vulnerabilities in the past, so we will need to keep an eye on this service.

Next, we will take a look at port 22, which is ssh:

localhost:<126> gk$ ssh -vv 192.168.1.101
OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL
0x0090702f
debug1: Reading configuration data /etc/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be
trusted.
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.101 [192.168.1.101] port 22.

Well, what do you know? The Mac is running OpenSSH. Hmm…haven't we seen a few vulnerabilities related to SSH security recently? Of course. I guess we will have to keep our guard up on that service, as well.

We also notice from the nmap output that NetBIOS file sharing is enabled, which would allow connections from a Windows system to the Mac. This could be used legitimately to transfer files between systems or by attackers as a convenient way to gain access to all your sensitive files. Even scarier is the fact that many times when this service is enabled, people configure it without passwords or with very weak passwords—making it an excellent entry point into the system.

The Good and The Bad

While we won't go through all of the various open ports (and there are other juicy ones above), it is important to realize that "this ain't your grandma's Mac anymore." Mac users have to be keenly more aware about configuring their systems in a networked environment as well as keeping their software up to date. The good news for Mac users is that Apple has done a commendable job of shipping their systems with a "secure by default" configuration—including a built-in, industrial-strength firewall (BSD's IPFW). The bad news for the security administrators is that many powerful services can be turned on by users, and oftentimes those users have no idea that they are even using a UNIX-based system. So, pay special attention to Chapter 5, "Hacking UNIX," because we are sure the bad guys are licking their chops, just itching to have some fun with your new, shiny, cool-looking Mac!

Read more »