LokiPi: Small form factor wireless auditing and penetration testing toolkit

Final Report LokiPi

Small form factor Wireless Auditing and Penetration Kit

2014

Jonathan O’Brien 20056544

Waterford Institute of Technology

5/5/2014

Jonathan O’Brien May 5, 2014 [FINAL REPORT]

1

Contents Declaration of Authenticity ..................................................................................................................... 5

Acknowledgements ................................................................................................................................. 6

Abstract ................................................................................................................................................... 7

1. Introduction .................................................................................................................................... 8

2. Project Overview ............................................................................................................................. 9

2.1. Description ....................................................................................................................................................... 9

2.1.1. Chosen Hardware Platform ............................................................................................. 9

2.1.2. Target Audience ............................................................................................................ 10

2.2. Requirements............................................................................................................................................... 10

2.2.1. Functional Requirements .............................................................................................. 10

2.2.2. Non-Functional Requirements ...................................................................................... 13

2.3. Tools and technologies ............................................................................................................................ 15

2.3.1. Hardware....................................................................................................................... 15

2.3.2. Software ........................................................................................................................ 15

3. Methodology ................................................................................................................................. 17

3.1. Original Methodology Reasoning ........................................................................................................ 17

3.2. Methodology implementation outcome............................................................................................ 19

3.3. Original User Stories ................................................................................................................................. 20

4. Project Design ............................................................................................................................... 22

4.1. LCD interface ................................................................................................................................................ 22

4.2. Core Internal Routing ............................................................................................................................... 23

4.3. Core Functionality using Evil Twin ..................................................................................................... 24

4.4. Core Functionality using KARMA ........................................................................................................ 25

4.5. DNS Spoofing ................................................................................................................................................ 26

4.6. SSLstrip........................................................................................................................................................... 27

4.7. WEP Cracking .............................................................................................................................................. 28

4.8. Custom Exploitation System .................................................................................................................. 29

4.9. Reverse Shell Penetration Testing Dropbox ................................................................................... 30

5. Implementation ............................................................................................................................ 31

5.1. Iteration 0 ...................................................................................................................................................... 32

5.1.1. Overview ....................................................................................................................... 32

5.1.2. Original Task Breakdown .............................................................................................. 32

5.1.3. Task Outcomes .............................................................................................................. 33

5.1.4. Time Tracking ................................................................................................................ 36


2

5.1.5. Iteration 0 Review ......................................................................................................... 37

5.2. Iteration 1 ...................................................................................................................................................... 38

5.2.1. Overview ....................................................................................................................... 38


5.2.3. Task Outcomes .............................................................................................................. 39

5.2.4. Time Tracking Reports .................................................................................................. 42


5.3. Iteration 2 ...................................................................................................................................................... 44

5.3.1. Overview ....................................................................................................................... 44


5.3.3. Task Outcomes .............................................................................................................. 45



5.4. Iteration 3 ...................................................................................................................................................... 49

5.4.1. Overview ....................................................................................................................... 49


5.4.3. Task Outcomes .............................................................................................................. 50



5.5. Iteration 4 ...................................................................................................................................................... 54

5.5.1. Overview ....................................................................................................................... 54


5.5.3. Task Outcomes .............................................................................................................. 55



5.6. Iteration 5 ...................................................................................................................................................... 58

5.6.1. Overview ....................................................................................................................... 58


5.6.3. Task Outcomes .............................................................................................................. 59



6. Unit Testing .................................................................................................................................. 64

6.1. Iteration 0 ........................................................................................................................ 64

6.2. Iteration 1 and 2 .............................................................................................................. 66


3

6.3. Iteration 3 ........................................................................................................................ 68

6.4. Iteration 4 ........................................................................................................................ 69

6.4. Iteration 5 ........................................................................................................................ 70

7. Future Work .................................................................................................................................. 71

7.1. Flask Web Server ............................................................................................................. 71

7.2. Internal Security Hardening ........................................................................................... 71

7.3. Custom user Exploits....................................................................................................... 71

7.4. Custom method for alphanumeric character input from the LCD ............................... 72

7.5. Change all Bash scripts to Python code ......................................................................... 72

7.6. Add other tools with similar functionality .................................................................... 72

7.7. Portability ........................................................................................................................ 72

7.8. Logging ............................................................................................................................. 72

7.9. Start-up system checks ................................................................................................... 72

10. Conclusion ....................................................................................................................................... 73

Appendix ............................................................................................................................................... 74

Appendix A – log File ............................................................................................................................. 74

Iteration 0 .................................................................................................................................................................... 74

19/01/2014 ................................................................................................................................... 74

21/01/2014 ................................................................................................................................... 74

28/01/2014 ................................................................................................................................... 75

03/02/2014 ................................................................................................................................... 76

08/02/2014 ................................................................................................................................... 77

Iteration 1 and 2 ........................................................................................................................................................ 78

09/02/2014 ................................................................................................................................... 78

12/02/2014 ................................................................................................................................... 79

12/02/2014 ................................................................................................................................... 80

15/02/2014 ................................................................................................................................... 80

Iteration 3 .................................................................................................................................................................... 81

18/02/2014 ................................................................................................................................... 82

19/02/2014 ................................................................................................................................... 83

20/02/2014 ................................................................................................................................... 84

21/02/2014 ................................................................................................................................... 87

26/03/2014 ................................................................................................................................... 89

21/02/2014 to the 15/03/2014 .................................................................................................... 91


4

28/03/2014 ................................................................................................................................... 94

Appendix B – KARMA ............................................................................................................................ 95

Appendix C – Evil twin ........................................................................................................................... 95

Appendix D – WPS reaver attack .......................................................................................................... 96

Appendix E - Aircrack-NG Suite ............................................................................................................. 96

Appendix F – SSL stripping .................................................................................................................... 97

Appendix G – IPtables ........................................................................................................................... 97

Appendix H – LCD Hitachi Interface Research ...................................................................................... 98

Works Cited ......................................................................................................................................... 101

Table of Figures Figure 4.1 – GPIO and Hitachi Mappings .............................................................................................. 22

Figure 2.4 – Evil Twin ............................................................................................................................ 24

Figure 3.7 - SSLStrip .............................................................................................................................. 27

Figure 4.10 – reverse SSH ..................................................................................................................... 30

Figure 5.1 iteration-0 summery report ................................................................................................. 36

Figure 5.3 iteration-0 Detailed Report .................................................................................................. 37


Figure 5.5 iteration-1 Pie chart ............................................................................................................. 42

Figure 5.6 iteration-0 detailed report ................................................................................................... 43


Figure 5.8 iteration-2 pie chart ............................................................................................................. 47

Figure 5.9 iteration-2 detailed report ................................................................................................... 48

Figure 5.10 iteration-3 summery report ............................................................................................... 52

Figure 5.11 iteration-3 pie chart ........................................................................................................... 52

Figure 5.12 iteration-3 detailed report ................................................................................................. 53



Figure 5.15 iteration-4 detailed report ................................................................................................. 57





Declaration of Authenticity 5

Declaration of Authenticity

Except where explicitly stated, I declare that all material is my own work or acknowledged wherever

adapted from other sources. I have not submitted the work represented in this report in any other

course of study to an academic reward.

Name:

===========================

Date:

===========================


Acknowledgements 6

Acknowledgements

Foremost, I would like to express my sincere gratitude to my supervisor Mairead Meagher.

Thanks for guiding me and keeping me on track.

Thanks to my WIT class for making the process of changing colleges and city’s a breeze, also to

my family, friends and my girlfriend.

Thanks to http://www.offensive-security.com/ for their course “Penetration testing with

backtrack” that I took last summer. As I would not have been able to include exploit

development to this project without the practical knowledge gained from their fantastic course.


Abstract 7

Abstract

Academic Title: Small form factor Wireless Auditing and Penetration Kit

Commercial Title: LokiPi

The wireless penetration test has become a staple of the information technology security audit. It is

a systematic measurement and evaluation of a company’s network security posture, helping to

provide a service to expose potential vulnerabilities that arise from incorrect system configuration,

software flaws and operational weaknesses.

This project offers a penetration tester or security auditor, a small form factor portable concealable

wireless auditing kit. Although small this implementation still retains enough power to host a full-

fledged Linux security distribution with its accompanying flexibility. By controlling and interfacing with the kit through a mobile device or initiating an automated attack directly from an on-board LCD

interface, the auditor can draw less attention from security employees onsite by concealing obvious

wireless equipment.

The device incorporates methods for circumventing SSL encryption and trust exploitation with rouge

access points, man in the middle attacks, deep packet inspection, and automatic vulnerability

assessment and exploitation. It can also be utilized as a network tap creating a backdoor into an

organization through an automated reverse SSH tunnel.


Introduction 8

1. Introduction

Wireless LAN networking is becoming increasingly prevalent in today’s Corporations, Educational

Institutions and homes for data transmission; it is becoming an ever-increasing attack vector.

Wireless data is often transmitted through insecure means, such as open access points in cafes,

airports and colleges. This leaves them open to large variety of attacks and in some cases the fact

that they have previously connected to and stored these open networks keeps them vulnerable in

the future.1

The standard tools for a wireless audit are generally the combination of a laptop running a Linux

security distribution and wireless adapters with Linux kernel modules that support packet injection;

these are very noticeable to trained personnel. In instances like this an auditor would wish to

conceal his activates with greater confidence, to evade the watchful eyes of security employees and

CCTV cameras. To help hide some of these identifying characteristics, a Raspberry PI has been

modified for portability, and configured with Linux Security Auditing tools to attack wireless

networks. Once attacks have been initialised, their main functionality will be automated with

additional options for user interaction.

This project offers a penetration tester or security auditor, a small form factor portable wireless

auditing kit. Although easily hidden, this implementation should still have enough power to host a

full fledge Linux security distribution with its accompanying flexibility.

The project supports a number of functions:

• The ability to redirect HTTP traffic to an internal web server, for the purposes of targeted

phishing attacks.

• It can be used for the emulation and replication of access points, through a specific user

choice or automatically in response to 802.11 management probes frames from client

stations in proximity.

• Once client stations are connected, SSL traffic can be downgraded in a client side attack

depending on the client side browser in use, effectively stripping encryption from the

communications stream.

• There are two separate interfaces implemented, an LCD interface for direct interaction and a

Browser HTTP interface for remote interaction.

• The project can also be used as a penetration testing drop/pivot box where it can be used to

attach to an internal wired section of a corporations internal network and initiate a reverse

connection to a specified public sever, tunnelling through port 80. This is dependent on

whether they utilise a firewall that implements deep packet inspection, and their egress

filtering policy.

• The project also supports an advanced feature, automatic vulnerability assessment of

connected stations, which will allow the auditor to execute targeted and customised

payloads against a number of vulnerable services. These exploits will execute a buffer

1 (praetorian.com, 2014)


Project Overview 9

overflow condition on the target station, generating a bind or reverse command shell for the

auditor to connect remotely with full administrative privileges.

2. Project Overview

2.1. Description

The LokiPi has been designed to act as a portable wireless access point and router at its core, with

the intention of creating targeted and automatic Rouge Access points using an implementation of

the KARMA attack, further information can be found in Appendix B. Every time a Wi-Fi interface is

switched on, and on a periodic basis, it checks by means of 802.11 probe requests what networks on

its preferred network List are available in the current location. Based on the responses obtained, it

tries to connect to the most preferred network; KARMA was devised to dynamically set its SSID to

match these probes in beacon frames satisfying major criteria for a connection. Clients can then

accept this fake network and automatically connect without the knowledge or interaction of a

human user.2 The implementation of KARMA by Robin Wood used in this project goes further and

can respond to probes creating new multiple SSID’s dynamically and concurrently.

Although the KARMA attack has been known about since 2004, only some operating systems have

had fixes implemented since that time. Android, Apple iOS, BlackBerry, and Windows Mobile devices

still have inherent security weakness in the method they use for connecting to Wi-Fi networks, that

has the potential for exploitation by a KARMA implementation.3

Along with developing an effective tool for security auditors, the LokiPi project may help prove

useful in raising security awareness on this potentially devastating issue. A SANS Institute researcher

has stated that the modern smartphone could become the ultimate digital 'Trojan Horse' allowing

attackers to breach ultra-secure locations.4

KARMA is one of the most important tools installed and configured on the LokiPi, as it is the basis of

all the attacks that the Device will perform. While the LokiPi also has the ability to clone access

points through a selection process, this proved to be much less effective.

Once wireless clients have connected to the LokiPi there are implementations in place to provide

that device with the necessary services and addressing for full IP network connectivity, while

simultaneously altering, redirecting and analysing their network traffic incognito.

2.1.1. Chosen Hardware Platform

I decided that an ideal hardware platform for this project would be the Raspberry PI, a small single

board computer developed to be cheap and made with the intention of promoting the teaching of

computer science in schools. It utilises an ARM based Linux distribution as its operating system. The

2 (Johnny Cache, 2007)

3 (Harding, 2013)

4 (Harding, 2013)


Project Overview 10

Raspberry Pi’s hardware specifications are a 700MHZ ARM CPU, 512 MB RAM, USB, Ethernet and

HDMI for output to a display. Wireless USB adapter may be added by means of the two available

USB ports.

Its small nature, cheap price, and decent performance characteristics match my requirements well

for a concealable, low power, decent performance attack platform. But if I were to start the project

again I would implement it with an Odroid U35 because of its amazing hardware specifications and

relatively low price.

2.1.2. Target Audience

The LokiPi’s intended target audience are security professionals, namely auditors and penetration

testers, though it could also be geared towards IT professionals wishing to test their wireless

networks for potential vulnerabilities.

The device would have an application anywhere wireless networks are operating and require testing.

This would include but not be limited to corporate offices, libraries and college campuses.

2.2. Requirements

2.2.1. Functional Requirements

2.2.1.1. Supporting network services

There needs to be a number of networking services implemented on the LokiPi:

• DHCP server to allocate addresses to victims and users

• DNS server for creating spoofed address mappings

• NAT for translation of internal addresses and routing

• IPtables for controlling traffic, routing and NAT

• Software Access point

• HTTP server for hosting phishing web-sites

• Wireless AP to Wireless AP bridging

• Amazon AWS server instance accepting remote connections

• SSH tunnelling

2.2.1.2. Rouge access points

To implement the rouge access point features of the LokiPi, there had to be a software access point

implemented and patched with KARMA to add the desired functionality. The HOSTAPD software is

described as an IEEE 802.11 Access Point and IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator.6

5 (hardkernel, 2014)

6 (http://wireless.kernel.org, 2014)


Project Overview 11

This was patched with Robin Wood’s modern implementation of KARMA from ‘www.digininja.org’

and setup by means of configuration files and CLI interfaces.

The LokiPi contains a second means to generate a Rouge access point; this is completed through

manual interaction from the user. The LokiPi will clone and broadcast a mimicked version of the

selected access point. This method is known as the “Evil Twin”, see Appendix C.

2.2.1.3. LokiPi initialisation service

The LokiPi operates headless “missing a GUI” to save on system resources as the main interface

comes in the form of an attached 4X20 character LCD screen. This means that the LokiPi’s main

system code had to be initialised automatically on system boot. This was achieved by means of

writing a Linux system service file to start the main code, this initialisation file makes sure that

services are started and stopped in an appropriate manner and sequence, it also pre-empts

problems from the main code by shutting down services that may have been left operating due to

encountered errors.

Another useful feature of having the LokiPi service was the ability to manually start and stop the

service daemon through an SSH connection during testing and configuration.

2.2.1.4. Portability

The device needs to be made portable by including a suitable battery pack and encasing all the

components in a suitable container. Currently the prototype device has to be plugged into a

powered USB hub that is attached to a power outlet.

2.2.1.5. Interface

The LokiPi has a LCD interface for direct interaction, which allows for WAN connection setup and

attack initializations.

Initial stages of a web console interface have been implemented; currently it has a more limited set

of features than the LCD interface, but functions correctly.

2.2.1.6. Reverse Tunnel

The reverse SSH tunnel initiates a connection to a remote server from the LokiPi, depending on a

firewall implantation this can help circumvent firewall rules. The LokiPi can then be used as a

penetration testing drop-box by connecting it to a target sites internal network and leaving it

essentially phone home, creating a backdoor into the network remotely.

There is also a second implementation of this form of remote connection, but it does not utilise SSH

or encryption. It is a python coded standard TCP sockets connection implementation.


Project Overview 12

2.2.1.7. Exploitation system

I developed a minimal memory footprint exploitation system to identify vulnerable services on a

connected client, with the appropriate payloads coded and available for loading and execution.

Currently this is limited to 32-bit Windows XP and Windows Server 2003 targets, with exploits

written in Python for a small selection of FTP and POP3 servers running on those platforms.

2.2.1.8. Man in the middle attacks

Man in the Middle attacks currently implemented on the LokiPi:

• DNS-Spoofing

The Device incorporates an attack method that spoofs DNS records, intercepting IP address to

domain pointer mappings and altering them. This is then used to re-direct traffic from legitimate

sites to phishing sites hosted using an internal Apache web server.

• SSL Stripping

This attack is not targeting a specific vulnerability in software but a design flaw in the

implementation of SSL/TLS used for secure web browsing. When a HTTPS connection to a website

from the victim is sensed, the connection from the LokiPi to the victim is downgraded to a non-

HTTPS session. Then from the LokiPi it is routed to the web server in question with SSL applied so

that the traffic matches the requirements of the target server’s security policy.

• Further Iterations

In later iterations I would wish to include different varieties of these attacks using different software

implementations with the same functionality, I believe that this variety of options would be very

beneficial to a security auditor as many similar tools perform the same attacks with different

methodologies, producing different outcomes in some cases. Since there are large qualities of these

tools available and developed by the hacking community, it would simply be a matter of integrating

them; this would involve intense testing procedures to ensure compatibility.

2.2.1.9. Logging

This feature is currently not implemented fully, only SSLstrip logs its output to a file. In a later

iteration it’s probably just a matter of redirecting the standard output of the services to separate log

files rather than the terminal.


Project Overview 13

2.2.1.10. Eavesdropping and Packet Dumping

When clients are connected to the LokiPi, their network traffic can be dumped to a file for later

analysis using tools such as TCPDUMP.

SSLStrip current performs a simplified targeted version of packet capturing by logging and dumping

all downgraded HTTPS and standard HTTP packets to a log file on the LokiPi. This is then parsed, and

the output made available on the internal web server.

2.2.1.11. Flagging active services and attacks

I used Boolean variables to identify if attacks or services are active on the LokiPi, helping to prevent

conflicts with duplicate service initialisation attempts.

2.2.1.12. Interface initialisation verification

Some issues with the loading of OS kernel modules for the wireless USB adapters was randomly

encountered, on occasion an 802.11 interface module (driver) would not load during the boot up

sequence. There is currently a manually function implemented to check initialised interfaces and IP

addressing, in later iterations this will be integrated into an automated service system check on

device boot.

2.2.2. Non-Functional Requirements

2.2.2.1. Documentation

High-level documentation will be required to show the user the overall capabilities and functionality

of the system. It will specify where and how to configure the device and use the device, setup

network connectivity using an external WAN connection, attack initializations and shutdowns.

2.2.2.2. Ethical Considerations

There is ethical dualism to creating a device such as this, as it can be used for malicious purposes just

as much as legitimate ones. A major concern being that the device is essentially automating attacks

which will allow an unskilled user to perform these attacks with little knowledge requirements.

There of course would have to be disclaimers and contracts signed for this to be legal, this will be

addressed in later iterations.

Given the devices potential malicious nature, the legality of its creation, distribution and use will

have to be analysed. In a future iteration there will be the inclusion of a disclaimer warning to place

potential legal issues solely on the user.


Project Overview 14

2.2.2.3. Required Skills

• Networking knowledge

The project was heavily reliant on a proficient networking knowledge, from low level protocols and

up for implementing the necessary services for the attacks. This was required not only to configure

them, but also to debug issues with a packet analyser.

An understanding of DHCP, DNS, HTTP, SSL, SSH and TCP Sockets were vital to the LokiPi

implementation, these were used for address assignments, backend network services support and

man in the middle attacks. Also an understanding of 802.11 management and control frames for

implementation and control of the KARMA and Evil twin attacks were required.

Routing IP traffic through the LokiPi was achieved with IPtables, this required an understanding of

the routing process and the syntax required to implement the routing successfully.

• Linux Operating system and CLI

The LokiPi’s operating system is a Debian based Linux distribution called Raspbian. Configuring the

operating system for use in the project required a detailed knowledge of the Linux file system

hierarchy, system services, and terminal commands.

• Soldering and Electronics

The LCD interface was constructed from individual electronic components:

� Printed Circuit Board

� 20x4 character lCD Screen with a Hitachi HD44780 controller

� 4 Switches

� A GPIO header and a 16-pin header

� 4 Resistors

� Potentiometer

• Programming

Python was the main scripting language used from service initialisation to attack initialisations, LCD

menu interface interaction, hardware interaction, system service and process interaction, operating

system interaction, web services frameworks, exploit development and deployment, TCP sockets

and interaction.


Project Overview 15

Bash scripting was also used to quickly implement operating system services and apply groupings of

IPtables commands. The main LokiPi initialisation service daemon was also a bash script that was

converted to a daemon service using “update.rc”.

JQuery Mobile and HTML where required to implement the LokiPi browser interface, with the added

requirement of programming interaction and co-operation between the LCD interface code and the

browser interface code.

• Exploit development

The exploit development process required an understanding of assembly language, debuggers, CPU

registers, operating system specifics, fuzzing, Address Space Layout Randomisation (ASLR)

protection, and Stack based buffer overflows.

2.3. Tools and technologies

2.3.1. Hardware

• Raspberry Pi ‘B’ 512MB

• 16GB Class A SD card

• Printed Circuit Board

• 20x4 Character LCD Screen with a Hitachi HD44780 controller

• 4 Switches

• A GPIO header and 16-pin header

• 4 Resistors • Potentiometer to adjust contrast

• Soldering station and Solder

• 2x Linux compatible 802.11 USB adapters

• Powered USB hub

• Hardware access point

• Wireless devices for testing KARMA

2.3.2. Software

2.3.2.1. Main Software

• Python 2.7

• HTML5 • jQuery Mobile

• Aircrack-NG Suite

• IPTables

• HOSTAPD with KARMA patches

• DNSMasq

• SSLStrip


Project Overview 16

• Apache Web Server

• Wireshark

• Immunity Debugger

• VMware Fusion, Workstation

• Windows XP and Windows Server 2003

• Linksys Access point

• Kali Linux on Amazon AWS

• SSH , Putty and Terminal

• Komodo Edit

• LOG_EX: Automatic SSLstrip log parsing7

• TOGGL

2.3.2.2. Vulnerable software (Windows)

• FreeFloat Ftp Server: (Version 1.00)

• Ability Server: 2.34

• SLmail: email server

• 3Com 3CDaemon FTP Server Version: 2.0

2.3.2.3. External Python Modules

• Pylcd: LCD interface library8

• Wifi: Python wireless interface library9

• Netifaces: Python physical interface interaction library10

• WiringPi11

and RPgpio12

: Control and interaction with GPIO from python

• Flask13

: Python micro web framework

• Psutil14

: A cross-platform process and system utilities module for Python

2.3.2.4. Python standard library Modules

• Multiprocessing: supports spawning processes with both local and remote concurrency

• String: String manipulation

• Logging: disabling/enabling logging for web server

• Subprocess: Bash terminal interaction, sub process execution

• OS: Operating system interface

• Struct: Interpret strings as packed binary data, converting memory addresses to Little

Endian format

7 (moloc, 2014)

8 (Mezgrman, 2014)

9 (Rocky Meza, 2014)

10 (Houghton, 2014)

11 (Gordon, 2014)

12 (Croston, 2014)

13 (Flask, 2014)

14 (Rodolà, 2014)


Methodology 17

• Threading: Thread handling

• Socket: Low-level networking interface

• Time: Time access, especially needed as the LokiPi has no real time clock

2.3.2.5. Custom python modules

• Exploit: Custom exploitation system

• Loki_web_server: Implementation of the Flask web server console

Project Design

3. Methodology

3.1. Original Methodology Reasoning

Using a sequential methodological approach for this project would have undoubtedly failed because

there are so many different interacting functions and technologies. These have many dependencies

between each of the potential components, so that if something needs to be modified or rectified in

one area this could have had a cascading effect throughout the entire system. Attempting to finalise

each component in sequence and to expect a fully functional system at the end would have required

the unrealistic ability of clairvoyant foresight. Methodologies such as Waterfall would have greatly

hindered the effectiveness of the proposed projects development, focusing far too much on a rigid

plan and excessive unnecessary documentation.15

It was decided that ‘a more appropriate approach for this project would involve the use of

an Agile Methodological implementation’. Agile allows for specification changes at any point in the

process, allowing easier implementation of corrections and additions. It is iterative in nature and so

does not require completion of the project in linear sequence, instead frequently producing

incremental functional versions of sections of the overall system. It is used in time critical/limited

situations, which will be of benefit to this project considering the tight deadlines involved.

Prototyping is another added constituent of my recalibrated agile method. Involving an

attempt to include Evolutionary prototyping into the process with initial functional aspects of the

overall system created in stages, adjusting features as required in an evolution towards the final

product.16

Agile methodologies such as Scrum are indented for projects involving large teams. They

involve quick daily scrums of team members sharing issues and solutions, sprint reviews with team

demonstrations and Retrospectives where team looks for ways to improve the process.17 Since a lot

of agile methodologies are heavily team focused I used certain components of their processes in a

15

(Agileintro, 2008) 16

(Teach-ICT.COM, n.d.) 17

(Stine, 2010)


Methodology 18

more personalised individualised approach. The agile methodology that matched my needs the

closest was a variation of Extreme Programming (XP) called Personal Extreme programming.

Personal Extreme Programming is an amalgamation of the Personal Software Process (PSP)

and agile XP. PSP is the only process that is explicitly specified to be utilised by individuals, but it

involves extensive efforts at preparing and maintaining large amount of documentation, making its

implementation a tough endeavour. The time invested for learning this heavy system would have

been counterproductive to an autonomous developer. Personal XP aims to lighten the development

process, modifying and extending the personal software process while keeping its core features. The

main aim of PXP is to improve the performance and quality of autonomous engineers by automating

daily developer activities while performing regular retrospective glances at what been done so far. It

is iterative and allows for more flexibility and responsiveness to change.18

• PXP needs a disciplined approach- developers are responsible to follow the process and

apply PXP practices

• Developers should measure, track and analyse their daily work

• Developer should learn from their performance variations and aim at improving the process

based on the collected project data

• PXP involves continuous testing

• Defect fixing should happen in the early development stage, when the cost of it is lower

• Developers should try to automate their daily work

I will use a tool such as TOGGL or Pivotal Tracker to keep track of work completed for analysis.

Six of the PXP practices are taken from PSP:

• Time Recording

• Defect Type Standard

• Defect Recording

• Size Measurement

• Process Improvement Proposal

• Code Reviews

Six of the PXP effective development practices from Extreme Programming:

• Continuous Integration – PXP includes the practices of source control versioning, automated

builds, automated test executions, and automated defect submitting.

• Simple Design

18

(Yani Dzhurov, 2012)


Methodology 19

• Small releases

• Refactoring

• Test Driven Development

• Spike Solutions

3.2. Methodology implementation outcome

Originally I had believed that if I had used a Sequential methodological approach for this project it

would undoubtedly have failed because there are so many different interacting functions and

technologies. I believed that there were so many dependencies between each of the potential

components that if something needed to be modified or rectified in one area this could have a

cascading effect throughout the entire system, originally stating that expecting a fully functional

system from finalising each component in sequence would be unrealistic.

I hindsight I believe this was indeed closer to the reality than I would have initially expected it to

have been possible. My planning was initially good and very close to actual flow of the assembly of

the system, I had each required section of the project appropriately compartmentalised, so that I

was able to create each in sequence and successfully combine each element to the last. This

occurred without having to fix or refactor as often as I had originally believed, though I did occur

enough that it would have been a serious issue.

Although there was a small amount of sequential prototyping to my project I was glad that I had

used an iterative approach as it allowed me to return to older code and rectify issues that arose

from a new integration. It also allowed me to completely restructure code for more streamlined

functionality and system control in a later stage of the project, where I separated code into separate

classes, methods and Python modules.

Using the online time tracking software call Toggl19 I have kept very much in line with the personal

extreme programming’s philosophy on time recording, later being able to analyse my rate of success

and my personal work implementation efficiency. Toggl was a good choice primarily due to its ease

of use and automation; this provided a more realistic approach given the tight deadlines involved

and the fact that I am an autonomous developer. I had also looked at another tracking tool called

Pivotal Tracker but this was heavily focused on team development cycles and collaboration, it

appeared relatively more bloated and cumbersome.

Through the use of an accompanying log I was able to Log defects, personal statements and insights

that I found as I progressed through the Project. This is included in Appendix A.

Code refactoring was used later in the project when having all the main code in a single script was

getting very difficult to read, and difficult to locate functional areas of code requiring modification. I

moved the exploitation code into a separate class, the web server into a separate module and many

19

(toggl.com, 2014)


Methodology 20

areas of procedural code into functions. In a personal style used what I will call “billboard”

comments on sections of code to make scrolling to areas at speed much easier, increasing efficiency.

I kept to the philosophy of attempting to create the functionality through the simplest design that

would achieve the end goal, later allowing for more complicated implementations. This was

extremely useful in this project as it had a massive scope and rather than reeling this in I was able to

get mostly everything achieved. Some of these achievements though are only really a stop gap

measure and would not be effective solutions for a production level model of the LokiPi.

Testing was completed at the end of the iteration and even each subsection of the iteration to make

sure that a certain level of functionality and stability was achieved through each stage.

Fully automatic testing on most of the work was not possible in this project, as all code had to

execute through the LokiPi, as it was reliant on the imported modules and physical wiring of the

GPIO buttons and LCD screen. Even the addition of a single line of code would have to be tested on

the LokiPi and manual executed at the appropriate section of the coded menu system.

In some areas I found some time saving methods, I would test code that was not overly dependent

on hardware and test that section directly in a Python interpreter by using small scripts to import

the minimal required code without the LCD interaction.

Writing test code with appropriately similar code functionality without the LCD interaction for the

iterations would have been possible I believe, but would have taken more time that just testing

directly on the device itself.

3.3. Original User Stories

As a Wireless Penetration Tester:

I want the ability to connect to a External Wan connection of varying types of encryption

So that I can seamlessly route client traffic through the device


I wish to be able to increase the Power of the Wireless transmission output

So that I can overpower signal transmissions for legitimate access points


I want to have an exhaustive set of penetration testing security tools installed on the device

by default, with a repository to automatically update base code

So that I can save time


I want the ability to connect to an External Wan connection of varying types of encryption

So that I can seamlessly route client traffic through the device


Methodology 21


I want the ability to configure the active attacks though an interface, including an SSH

terminal control

So that I can automate certain tasks or take full control when necessary


I want the ability to break WEP encryption on weaker access points

So during an audit if this weak encryption is encountered I can break it without extra

hardware


I would wish to have the option of adding my own custom attack code

So that new attacks vectors can be implemented and exploited as every audit could end up

being potentially very different in configuration to the standard.


I want the ability to store results in real time to a database system

So that I can produce effective reports from my clients


Project Design 22

4. Project Design

4.1. LCD interface

I wanted a LCD interface for the LokiPi that could display a large quantity of characters on the screen

simultaneously; the Hitachi HD44780 LCD controller suited this purpose perfectly with its 20

characters by four lines.

Individual Components:


• 20 x 4 lCD with Hitachi HD44780 controller

• 4 Switches


• 4 Resistors for the Switches

• Potentiometer to adjust contrast

Mappings used for the GPIO connection to the Hitachi LCD controller:

GPIO Number R-Pi Hitachi HD44780 LCD Pin Function

7 4 Register Select

8 6 Enable

17 11 Bit 1

18 12 Bit 2

27 15 Bit 3

22 14 Bit 4 Figure 4.1 – GPIO and Hitachi Mappings

Figure 4.2 Python GPIO mapping implementation


Project Design 23

4.2. Core Internal Routing

Traffic is routed through the LokiPi from the Software Access point generating a fake Rouge SSID,

this as achieved using KARMA and Evil Twin based attacks. Then the soft AP is connected to a

physical 802.11 USB Interface attached to the LokiPi. Traffic from this interface is routed though the

device to another interface acting as the wide area network, both Wireless and Ethernet destination

interfaces are available. Modification or interception of any traffic occurs in between. The use of

IPtables, see Appendix G, and the combination of a special kernel parameter are used in the LokiPi to

enable this routing capability.

Figure 4.3 – Internal Routing


Project Design 24

4.3. Core Functionality using Evil Twin

Below is a diagrammatic view of the functional interaction of the Project. This version utilises the Evil

Twin attack method to attract potential victims, cloning a legitimate access point in proximity while

disconnecting its associated stations with 802.11 de-authentication management frames, then

broadcasting a Twin access point at a higher power output than what is specified in European Union

regulations.20 The disconnected clients should in theory then connect the SSID with the strongest

signal output, in this case the LokiPi.

The LokiPi initially scans for access points in in vicinity; it then displays these results on a menu

system through the LCD interface. When a user selects one of these from the menu system, the

LokiPi generates a cloned software access point using its SSID and broadcast channel. It then uses a

secondary wireless adapter to transmit 802.11 de-authentication management frames towards the

original access point, disconnecting any connected client.

Once connected to the LokiPi the victims will have a valid internet connection as they as routed

through the LokiPi’s WAN interface.

I will be adding this ability to the web console interface in future released on the LokiPi project.

Figure 2.4 – Evil Twin

20

(madwifi-project.org, 2014)


Project Design 25

4.4. Core Functionality using KARMA

This is an alternative version of the Evil Twin attack. It is highly dynamic and does not require that

the targeted physical access points be in proximity. KARMA listens for probe requests from clients

for previously connected networks on their preferred network lists; it then generates fake

broadcasted AP’s based on these, responding to them with beacons. Depending on configurations

and operating system versions, the sequence of preferred networks and current connections, some

clients will connect automatically and transparently to a KARMA enabled access point. Then the

traffic can be modified at will as it is routed through the LokiPi.

De-authentication of surrounding access points should be another feature that will be need to be

added in future as this may have a similar effect to the Evil Twin attack.

Figure 4.5 - KARMA


Project Design 26

4.5. DNS Spoofing

DNS spoofing is a primary MITM (man in the middle) attack implemented on the LokiPi, specific

domain names are mapped to an internal LokiPi authoritative DNS server which is given to

connected clients in DHCP address assignments. The internal address mapping redirect requests for

target websites to an internal Apache web server running multiple virtual hosts coded to respond to

a specific target domain name, and then load the appropriate phishing page for the connected

station.

All other traffic not matching specified spoofed domains will remain unaffected and

outgoing/incoming traffic will directed through the device to their legitimate destinations.

Figure 4.6 – DNS Spoofing


Project Design 27

4.6. SSLstrip

SSLstrip is a tool that implements a man in the middle attack by keeping communications encrypted

to a destination HTTPS enabled web server while also downgrading the client side of the connection

to standard HTTP. This keeps the HTTPS enabled Web Server satisfied that the pre-requisite

encrypted connection is being enforced, while keeping all client side communications unencrypted.

It also has the option for injecting a fake lock icon in the HTTP traffic returned to the client.

Figure 3.7 - SSLStrip


Project Design 28

4.7. WEP Cracking

WEP cracking functionality did not end up being included in the project at its current stage, due to

hardware/driver issues during the LokiPi development. If a solution to the previous problem is found

then this feature will be added in a later iteration.

WEP cracking has many methods, the quickest is ARP replay and this requires a connected client to

the target access point. The client is disconnected and upon reconnection an ARP packet that said

client transmits is captured. This is rapidly and consequently injected into the communication

channel to increase the data rate. The data packets between from the AP are then captured and the

WEP key is cracked. This is dependent on having enough Initialisation Vectors from the captured

data packets, hence the need to speed up the process through ARP replay.

Figure 4.8 - WEP


Project Design 29

4.8. Custom Exploitation System

The custom exploit system identifies specific vulnerable services running on a connected station; it

then loads the appropriate exploit with a choice of payload type. Once the service is exploited on the

target it generates a reverse shell back to a specified server awaiting a connection, there is also the

option to have a shell bound to a specific port on the target machine directly.

Figure 4.9 – Custom exploitation system


Project Design 30

4.9. Reverse Shell Penetration Testing Dropbox

The LokiPi has penetration testing pivot box functionality, where it can be attached to an internal

networks infrastructure, acquire and address, and send a reverse command shell through the

perimeter defence firewall by tunnelling through a HTTP socket. This will give the remote machine a

pivot point into the internal network through NAT and firewall configurations.

Figure 4.10 – reverse SSH


Implementation 31

5. Implementation

Using Toggl allowed for simple task naming, project specification and time recording. This

information was sent to my account on their servers where I could later process it into reports based

on time segments. I think this approach fell in line with PXP’s ideology to aim for the simplest

solutions when attempting to achieve functionality. Using these reports I was able to compare

results with task difficulty estimates created during the planning process.

During this process I also wrote to a Log file, keeping a record of the problems encountered,

solutions found and the potential for improvements. The log file can be viewed in Appendix A. As

entries to the log file were made they were time stamped, which for me was not concurrent with the

implementation but after I had achieved a variety of tasks. This was to stop the logging process from

interrupting my productivity.

The project was implemented using a Test Driven Development process, having some functional

tests competed at the end of each iteration helped me to determine its success or failure, later

refactoring the implementations if it was proven necessary.

In the planning phase I combined these tests with an outline for the iteration, they were then

created from an assembled set of tasks taken from the requirements.

The functional design was kept as simple as it can be for a completed iteration, but would retain a

plan for a more complete solution achievable in the future. There were small functional releases

every couple of weeks.

At the end of the iteration, code was continually integrated into the functional prototype. The

Iteration life-cycle effectively and sometimes logically, depending on the approach, took me around

2 to 3 weeks.

Since I have nothing to compare these tasks to in my experience, I did not initial use time based

estimations. But just a 1 – 5 based rating system on a task’s difficulty level. I then converted these to

a time based format.

In future iteration plans I would be able to use the information gathered from Toggl and use that to

produce more defined and specific estimations based on this recorded experience.

Task Rating System

Effort Estimate <1> Lowest and <5> Highest effort

Average effort: the addition of all tasks, divided by the number of tasks

1 Estimate Unit <1> = 3 Hours


Implementation 32

5.1. Iteration 0

5.1.1. Overview

In iteration 0 I implemented the LCD menu interface for the LokiPi by modifying and utilising an

existing library. After researching the requirements for coding a custom library, this was the most

appropriate direction to take in the end. I was also able to use this library to create a viable system

for entering alphanumeric sequences using a selectable menu of ASCII characters.

I also found a viable library for managing wireless connections, connection, entering encryption keys,

and roaming.

5.1.2. Original Task Breakdown

1) Research HD44780 LCD display controller and GPIO programming <5>

a) Assembly and Soldering

b) Timing for character display

c) Inputs

d) Character Coding

e) Animations

f) Execution of code

2) Access point Scanning/Sniffing in Scapy and Python <1>

a) Store MAC and SSID

b) Channel Hopping

3) Convert and display SSID’s to LCD characters <5>

a) Transfer in Nibbles

b) Prepare and convert for display

c) Have method of identifying selections

4) Selections completed through GPIO buttons and LCD display <4>

a) Implement identification of selections

b) Give options

c) Scrolling capability

d) Execute scripts on selection

5) Develop a method for associating a menu selection to a MAC (BSSID) <2>

a) Ensure connection to chosen AP


Implementation 33

6) Connection with access point to act as WAN <3>

a) WEP

b) Open (minimal requirement)

c) WPA

7) WPA and WEP require an input method (character cycle selection) <5>

a) Research

b) Plan, code and test a small implementation

Average Effort <3.5>

Estimated Total Hours (50)

Tests:

• Initiate connections to various access point types

• Disconnection and roaming from different AP’s

Risks:

• Failure to find a method to effectively input characters through GPIO/LCD would effectively

stop connections to anything apart from open access points.

• LCD soldering causing damage to components

5.1.3. Task Outcomes

5.1.3.1. LCD Controller

Researching the coding involved and knowledge requirements in implementing a usable custom LCD

GUI menu system for the LokiPi, I quickly came to the conclusion that this was a very difficult and

time consuming task. I saw that this potentially could have been a dedicated project in itself, I

deciding then to move forward and search for a HD44870 compatible LCD GUI python library that I

could use to generate the menu system.

After searching and testing a variety of potential libraries I located one that appeared to function to

a certain degree on the HD44870 called PyLCD,21 it was displaying characters but in a mangled and

corrupted manner. This problem was caused by incompatible display line memory addressing used

in the PyLCD library source code to write characters to the display, after adjusting these addresses

the library functioned properly for the LokiPi.

GPIO lines and Buttons were setup with a mapping of the appropriate lines to the physical pins on

the GPIO interface during PyLCD library initialisation.

21

(Mezgrman, 2014)


Implementation 34

This solution saved me from having to learn how to code the GUI through means of character

encoding, timing for writing data to the LCD buffers and display, and shifting the characters across

the interface for the illusion of movement through a selection cycle.

Task Estimate Combination

The PyLCD library implemented the following tasks in a simple manner, saving me a lot of time.

• (1) Research the HD44780 LCD display controller and GPIO programming <5>

• (3) Convert and display SSID’s to LCD characters <5>

• (4) Selections completed through GPIO buttons and LCD display <4>

These tasks should have taken 42 hours based on the original estimates, but probably would have

taken hundreds if attempted manually. Thanks to the PyLCD library they were completed in 27

hours, this was calculated from the Toggl Report shown in the next section.

Task Outcome

LCD Controller

Estimate (3x) 42 Hours

Outcome 27 Hours

5.1.3.2. LCD character Input

Generating a manual working Character selection input method would have proved very difficult as I

would have had to override the PyLCD library code, writing the appropriate calls to shift characters,

shift cursors, keep a visual representation of previous entries, and allow for deletion on the LCD

plate at a low level.

Since the PyLCD implementation has no comments and has a vast amount of code, attempting to

reverse engineer that implementation of accessing the LCD controller would have taken too much

time, interfering with the true goals of the LokiPi project.

I decided on using a less elegant solution to the issue, which would have to be corrected in a future

iteration. Using the PyLCD library I generated a selectable menu system that displayed all the ASCII

characters in a list, but I modified the code so that the menu “header” would continually update

showing the previous entries and deletions. The major problem with this solution is that every time

a character is selected the list gets reset back to the initial selection character.


Implementation 35


� WPA and WEP require an input method (character cycle selection) <5>

The original task estimate relates to 10 hours and the actual outcome came in at around 11 hours.

Again though if I had not used this simple workaround this would not have been so close by any

means.

Task Outcome

Character Selection and Input


Outcome 11 Hours

5.1.3.3. Wan Connection

I found a very efficient python module called “wifi” which allowed for easy wireless connection

control using python code. The module allows easy identification of all AP features, and most

importantly allows for the configuration to be saved to the Linux interfaces file for automatic

connections later on.

This made the manual implementation in Scapy unnecessary as the Wifi module uses this by default

to achieve its implementation.


The ‘wifi’ Python module gave simple implementations to a number of the tasks:

• (2) Access point Scanning/Sniffing in Scapy and Python <1>

• (5) Develop a method for associating a menu selection to a MAC (BSSID) <2>

• (6) Connection with access point to act as WAN <3>

Task Outcome

Wan Connection


Outcome 11 Hours


Implementation 36

5.1.4. Time Tracking

5.1.4.1. Iteration 0 (19/01/2014 – 08/02/2014)

Figure 5.1 iteration-0 summery report

Figure 5.2 Iteration-0 Pie Chart


Implementation 37

Figure 6.3 iteration-0 Detailed Report

5.1.5. Iteration 0 Review

I was very fortunate to have found the compatible python libraries/modules that I had otherwise I

would have had to have redesigned the entire project without the use of the LCD interface, while

also spending excessive amounts of time configuring a character input method and wireless

interface control from python.

Other Risks that I would now include:

• Having to code the LCD menu GUI manually

• Having to control wireless interface connections from code, notoriously difficult


Implementation 38

5.2. Iteration 1

5.2.1. Overview

For this iteration the underlying networking support services were implemented such as DHCP and

DNS. Also a software access point was integrated which was suitable for both the Evil Twin and

KARMA based attacks.


1) Design a Method for choosing an Access point to clone <4>

a) Similar code to the WAN connection of Iteration 0

b) Store the details

c) Method to create Software AP and implement

2) Increasing Broadcast power <1>

a) Make effective and trustworthy

b) Check legality in Europe

3) DE-authentication of clients from original access point <2>

a) Method to forcibly disconnect clients from the original AP

b) Decide on existing tool or Scapy code, speed vs. control

4) Alterative KARMA Implementation <5>

a) Compile, configure and install

b) Research command line based operation

c) Plan, design and implement operation in Code

d) Store current associations

e) Have method to display these on LCD, without interrupting execution flow

f) Integration

5) Choice between Karma and Evil Twin <3>

a) Karma may have code for DHCP/DNS implementation integrated

b) Will have different setup requirements for Evil Twin Cloning

c) Discover, Plan and implement

6) Implement DHCP and DNS services <3>

a) Local DHCP server for associating clients

b) Local DNS for domain/IP address conversion - seamless

7) GPIO/LCD options and execution <2>

a) Integrate scripts into the execution menu of the LCD display


Implementation 39



Tests:

• Cloning various Access point types, and testing with De-authentications/Broadcast power if

clients associate automatically

• Test manual and automatic connection by different clients OS’s

• Have a connection log to display details

• Attempt the same with Karma

• Verify correct address assignments to clients

• Attempt to execute these features though GPIO interface

• Test connections from various operating system types

Risks:

• Clients will not associate with the evil twin automatically due to any number of reasons, this

may be operating system specific

• KARMA will not function or may not be able to integrate into the system

• Encryption in target access points may cause issues

• KARMA might be the best solution, but only functions with Open Access point probes from

client nodes


In reality this iteration ran simultaneously with iteration 2, due each being completely dependent on

the other. I will keep them separated for readability.

5.2.3.1. DHCP and DNS

When KARMA was installed and operating, client stations would attempt to connect to the access

points that it had created, they would associate but would then fail soon after. The reason was that I

did not have a DHCP server running on the LokiPi to distribute the appropriate address assignments

to the new clients, stopping IP connectivity.

I located a very lightweight DHCP server called DNSMasq, this had the added benefit of being a DNS

server as well. Once a Subnet, DHCP pool and listening interface specification were configured on

the DHCP server, and the specified physical interface with the Software access point had an IP

address in that subnet range, then clients connected and stayed connected.

The DNS server can also be used in authoritative manner so that I will be able to use it for DNS

spoofing in a later iteration.


Implementation 40

Task Estimate

DNSMasq worked as both the DHCP and DNS server for the LokiPi:

• (8) Implement DHCP and DNS services <3>

Task Outcome

DHCP and DNS


Outcome 7 Hours

5.2.3.2. KARMA

I found a suitable implementation of KARMA for the LokiPi project, written as a Patch for the

Hostapd22 software access point software for Linux, created by Robin Wood.23 Once compiled and

installed it operated quite well, but did require the DHCP server to be fully implemented. For full

operation and testing the KARMA access point had to be routed to a WAN gateway using IPtables,

this is listed in iteration 2.

KARMA is initialized from a Python call to the underlying operating system, executing a BASH

terminal script that initialises the appropriate services, interface addresses and IPtables routing

rules.


KARMA but not including the time for IPtables routing and other related tasks:

• (4) Alterative KARMA Implementation <5>

• (5) Choice between Karma and Evil Twin <3>

Task Outcome

DHCP and DNS


Outcome 14 Hours

22

(Malinen, 2014) 23

(Wood, 2014)


Implementation 41

5.2.3.3. EVIL Twin

The Evil twin method was dependant on the Python Module ‘Wifi’ that I had installed earlier; this

was useful as I could create an object that would store the details of the scanned access points in a

manner that was easy to access. This could then be used to replicate the chosen access point.

The Evil twin is also completely dependent on the IPtables routing from iteration 2.

It would replicate an Access point, but because the original access point I had tested with was

encrypted, the connection would fail/timeout once the de-authentication attack finished. I will

speak of this in detail in the testing section of this document.

De-authentication of clients from the original access point was achieved by using a second wireless

adapter running Aireplay-NG from the Aircrack-NG24 suite of tools. This was able to send targeted

de-authentication packets at the original access points BSSID.


• (1) Design a Method for choosing an Access point to clone <4>

• (2) Increasing Broadcast power <1>

• (3) De-authentication of clients from original access point <2>

Task Outcome

DHCP and DNS


Outcome 7 Hours

24

(www.aircrack-ng.org, 2014)


Implementation 42

5.2.4. Time Tracking Reports

5.2.4.1. Iteration 1 (08/02/2014 – 18/02/2014)


Figure 8.5 iteration-1 Pie chart


Implementation 43

Figure 9.6 iteration-0 detailed report


Other additional Risks that I would now include:

• May not successfully be able to use DHCP or DNS with software access point

• Clients will have security implementations to counteract the attacks

• Evil twin will only successfully work with open access points

• Routing may fail in next iteration

• Uncertainty of the stability and future usability of solutions

• Physical card issues, such as disconnections, power related issues or Linux kernel modules

problems causing card interaction failure

• Library Wi-Fi interface source code bugs

• Changing to different access point after original connection potential issues

• Not implementing the Evil twin attack successfully

• Not having enough different devices and operating systems to have thorough test

• Operating system network and interfaces services causing random issues

• Kernel drivers issues stopping an increase in broadcast power

• Kernel driver issues causing problems with Air crack-ng interaction with physical interfaces


Implementation 44

5.3. Iteration 2

5.3.1. Overview

Iteration 2 was essentially running consecutively with the previous iteration. Routing and verification

of network traffic relied heavily on the implementation of the networking services, software access

point and WAN connection, but relied equally on the IPtables commands to forward packets to the

appropriate interfaces.


1) Internal routing with IPtables <5>

a) Scripting for automation of setup

b) Factor in Dynamic change to a new Software Access point

c) Research packet flow paths control and implementation

d) IPtables scripting implementation and testing

2) Enable IP forwarding to enable packet routing <1>

a) Simple one line command

b) Turn Raspberry Pi into a packet router

3) Network service integration, DHCP and DNS <2>

a) Make sure these services are operational throughout system

4) Network Tap interface to Software Access Point <5>

a) Create functioning Network tunnel/tap for routing from the software access point

5) Scripting the connection (bridging) WAN, TAP, AP interfaces <4>

a) Changing interfaces on the fly

6) Network Address Translation implementation to route packets through different public/private

and subnet addresses. <3>



Tests:

• Connection from client to Internet addresses

• ICMP echo request/reply tests

• Packet Capture to trace connections through interfaces


Implementation 45

Risks:

• IPtables scripting may be more complicated than originally considered

• Is heavily reliant on other iterations functionality


5.3.3.1. Routing

Through the use of Bash scripts I invoked IPtables commands to route traffic received on the

software access point implementation, KARMA or Evil Twin based, to either the Ethernet or

secondary wireless interface being used for WAN connectivity.

These bash scripts are called using the sub process module from Python, I could have embedded

each terminal command directly into the python script but this would have been much more

involved. The Bash script was better for setup and testing, and it was easily modified.

Routing required that the default gateway for a WAN connection be received from DHCP, without

this small piece the routing procedure appeared to be malfunctioning. This was noticeable when

attempting to use WLAN to WLAN interfaces routing, as my test Ethernet interface had the default

gateway hard coded in the OS, utilising a WAN with a different gateway address would kill IP

connectivity. A small addition the “/etc/network/interfaces” file corrected this.

The speed of the HOSTAPD software access point was amazing, no slow down for connected clients

with web pages loading like normal. This was in stark contrast to the software access point

implemented by the Aircrack-NG suite called Airbase-NG which I had attempted to use in the first

semester, it was ludicrously slow and would be obvious to anyone connected that there was an

issue.

The IPtables commands implemented the NAT address translations between interfaces and enabling

IP routing on a Linux kernel is a simple one line command changing a Boolean value in a system file

“echo 1 > /proc/sys/net/ipv4/ip_forward”.


• (4) Network Tap interface to Software Access Point <5>

• (2) Enable IP forwarding to enable packet routing <1>

• (1) Internal routing with IPtables <5>

• (6) Network Address Translation implementation to route packets through different

public/private and subnet addresses. <3>


Implementation 46

Task Outcomes

LokiPi Routing


Outcome 23 Hours

5.3.3.2. Scripting

I found that the initialisation of supporting services from Bash terminal scripting proved very flexible

and easy to change, allowing me to test a modification without restarting the main LokiPi service as

these scripts were separate, with the bash scripts just being executed by the main Python code. The

only issue that could be said to exist with this is the only feedback given to the main Python code is

either an overall success or failure, removing the ability to know exactly which command caused an

issue.

I had to write a Debian Linux compatible system service initialisation script to start the LokiPI code

on system boot with the appropriate execution privileges. This was required as the LokiPi is headless

apart from the LCD interface.

I also added scripts to tear down the services, but also preventative code to stop services that may

have been left running from an error or unforeseen circumstance in the start-up scripts and the

main system service script.

DNS and DHCP are initialised on a software access point initialisation. They can be shutdown

manually, but are also shut down on termination of the LokiPi service.


• (5) Scripting the connection (bridging) WAN, TAP, AP interfaces <4>

• (3) Network service integration, DHCP and DNS <2>

Task Outcomes

LokiPi Routing


Outcome 16 Hours


Implementation 47


5.3.4.1. Iteration 2 (08/02/2014 – 23/02/2014)


Figure 11.8 iteration-2 pie chart


Implementation 48




• Changing interfaces will create increased complexity, especially with address assignments

• Conflicts between networking services


Implementation 49

5.4. Iteration 3

5.4.1. Overview

DNS spoofing and phishing web pages were successfully implemented, responding to a variety of

DNS requests for domains and returning DNS A records indicating the address of the internal Apache

web server. SSLstrip also was implemented, and would depending on the client browser; downgrade

the HTTPS connection to HTTP on the client side successfully. Code refactoring was applied at this

stage also.


1) Research and implement a method to tap into traffic between a Software access point/at0

interface and the WAN connection <4>

a) Point of traffic modification

2) Implement ability to enable/disable redirection to internal DNS Server <3>

3) Allow for customizable Domain address mappings <5>

a) Create HTTP service

b) Allow custom HTTP phishing pages

c) Redirection to internal HTTP server

4) Packet dumping and Cookie Side-jacking <4>

a) Method of storage

b) Accessibility for download or automatic transfer

5) With enough available time implement SSLstrip <5>

a) Additional extra, not a requirement

6) Control interface <4>

a) Choose between Android and GPIO



Tests:

• Connection from client to Internet addresses with redirection enabled

• Check if redirected to internal phishing site

• ICMP echo request/reply tests


Implementation 50

• Packet Capture to trace connections through interfaces

• Transfer of captured packets to automated processing

Risks:

• It is heavily reliant on other iterations functionality

• There will be hidden technical requirements and design methods that I am not familiar with.

In other words many unknown factors.


5.4.3.1. DNS Spoofing and Phishing

DNS spoofing was easily integrated into the LokiPi by using the previously installed DNSmasq

software package with a few additional configurations; this was the DNS server being assigned in

DHCP address assignments to connected clients. The DNSmasq server implements its own

authoritative and overriding DNS record mappings for specified domains while forwarding on

unknown requests to a legitimate DNS server.

I used an internal Apache webserver to host the phishing sites and captive portal; this was

implemented using multiple virtual hosts for concurrency which would respond to the specified

domain name in the http requests.

I then used DNSmasq to map these domains to the internal web server, and allow all other DNS

requests for non-spoofed sites to be forwarded to a legitimate DNS server.

To enable and disable DNS spoofing on the LokiPi I wrote a simple script that wrote the appropriate

values in an address mapping file. This is not the best method, but was the quickest to get an

implementation working immediately.


• (1) Research and implement a method to tap into traffic between a Software access

point/at0 interface and a WAN connection <4>

• (3) Allow for customizable Domain address mappings <5>

• (6) Control interface <4>

• (2) Implement ability to enable/disable redirection to internal DNS Server <3>

Task Outcomes

DNS Spoofing and Phishing


Outcome 12 Hours


Implementation 51

5.4.3.2. SSLStrip

All that SSLstrip required was to be compiled, installed and have some IPtables rules implemented

on start-up and shutdown. It worked immediately, redirecting encrypted HTTP traffic to local port

10000, where it intercepted HTTPS traffic. Although, it is fairly specific on the browser

implementations that it works fully with, more on this in the testing section.

SSLstrip log outputs are very heavy; it logs all HTTP and downgraded HTTPS requests to the console

or to a file. Passwords and usernames can then extracted using patterning matching. But each

website implements their variable names a little differently, so a unique regular expression would

have to be constructed for each. Since it took some time to be able construct even one I looked to

see if something had already been created for this purpose and found LOG_EX25, a nice script that

achieves just this.


• (5) With enough available time implement SSLstrip <5>

• (4) Packet dumping and Cookie Side-jacking <4>

Task Outcomes

SSLstrip


Outcome 5 Hours

5.4.3.3. Refactoring and Restoration

Since the SSLstrip implementation was achieved much faster than I had originally expected, I

decided to go back through the code I had written and separate it into functions. I also added a

main function to act as a main menu for the LCD GUI which could be used to initialize different

modes in the LokiPi, allowing the system to be set back to the original menu from any point in the

LokiPi LCD menu sub-systems.

Using a root account to modify files on the LokiPi, I accidently deleted the entire Root folder with a

single recursive terminal command. Since it had been a while since I had backed up the entire SD

card, I backed up the individual files, scripts and service configurations from LokiPi before a reboot

would render the system inoperable. I then restored the last backup and modified each file

individually by comparing them and identifying the changes performed. At this point I wished that I

had used a system such a GITHUB to perform the backups originally.

25

(moloc, 2014)


Implementation 52

Task Outcomes

Refactoring and Restoration

Outcome 11 Hours


5.4.4.1. Iteration 3 (12/02/2014 – 22/02/2014)




Implementation 53




• Logging in as the root account, user error and corrupting the operating system


Implementation 54

5.5. Iteration 4

5.5.1. Overview

After some though I decided to implement a mobile remote control interface for the LokiPi using a

micro web framework called Flask and JQuery mobile, over using an Android specific application.

This had the benefit of being compatible with any browser interface on any platform.


1) Socket Programming <5>

a) Implement a Java server on Raspberry Pi

b) Implement a Client Android APP

c) Attempt compatibility between them

d) Have threading capabilities to transfer data without disrupting current operations

e) Transfer updates and logs for display on phone in real time

f) Back grounding processes

g) Changing running scripts, services and processes on the Raspberry Pi

h) How to execute python scripts from Java server and receive data back for transfer over

socket?

2) Design android interface in XML with Android Studio <4>

a) Menu systems

b) Logs displays

3) Server and client side database storage <5>

a) Storage of Logs, Results and current configurations

b) Enable transfer of these between devices

4) Python Server and Android Client Option <5>

a) Python for android (py4a) research and implementation

b) Inter-process/Dbus communication research

c) (Twisted) and event driven networking engine in python

5) Web2Py web FrameWork Option <4.8>


Implementation 55

Tests:

• Enable simple Client server interactions, executions and data transfer to verify

Risks:

• There are many ways to approach this, each with a high learning curve. Choosing the wrong

approach will waste a great deal of time.

• Will require collaboration with my Project supervisor to advise on most effect method for

me to attempt.




The android application tasks were dropped in favour of using a JQuery Mobile, Flask web server

framework interface.

5.5.3.1. Web Browser Interface

I decided that the most universally compatible method of interfacing with the LokiPi would be

through the use of mobile devices, the most ideal implementation of this being a browser console

management interface. I located a lightweight Python web framework called Flask, this appeared

easier to me to use than Web2Py or other implementations.

There was difficulty in syncing the changes implemented through the LCD menu interface code and

the web server code. This was resolved in the testing section.


• (5) Web2Py web FrameWork Option <4.8>

Task Outcomes

SSLstrip

Estimate (3x) 14.4 Hours

Outcome 27.7 Hours


Implementation 56


5.5.4.1. Iteration 4 (04/03/2014 – 28/03/2014)




Implementation 57




• Syncing changes between different processes

• Security of the web server implementation


Implementation 58

5.6. Iteration 5

5.6.1. Overview

A working method for breaking WEP encryption could not be successfully implemented due to

kernel module issues, this and custom user modules were omitted from this iteration but would be a

definite target for the future.

A reverse shell was implemented utilising a simple TCP Python socket connect to a server listening

with Netcat26 and by initialising a reverse SSH connection using a bash script. This appears to work

through my own gateway and it worked in the college the one time I tested it, but would definitely

require more testing.

I was able to integrate a simple, low memory footprint, exploitation system written in Python using

Windows XP SP2, SP3, server 2003 on VMware and a Debugger called Immunity to aid in testing the

exploits for specific vulnerable software packages. To support this I also implemented a method for

identifying the MAC addresses of the currently associated stations, isolating there IP, automated a

banner grabbing and identification process, and created options for payload customisations such as

target operating system and shell type.


1) Addition of WEP cracking <5>

a) Method of automating versions of the attack

b) Identifying WEP enabled AP’s

c) Identifying when AP has an Associated client connected

d) Packet capture and Injection based on that client

e) Alternative method automated if client not associated

2) Custom user modules <5>

a) Enable the ability to add custom code

3) Device internal Security implementations <3>

a) Password accounts

b) Mac Changing

4) Exploitation <4>

a) Compile specific exploits

b) Loaded to a list with identifiers

c) Scan attached targets for identifying features of specific vulnerabilities and operating

systems

d) Send payload if identified

26

(sourceforge, 2014)


Implementation 59

e) Remote Reverse Shell back to a specified Client

5) Remote Wireless Backdoor <4>



Tests:

• Test exploits with Immunity Debugger on an virtual machine test environment

• WEP enabled access point to attack and verify connection

Risks:

• Absolutely reliant on successful competition of all other iterations

• Extremely high learning curve

• Automation on WEP attack may prove overly complicated for the timeframe


5.6.3.1. WEP

A requirement to implement breaking WEP encryption effectively and quickly is to have Linux

compatible 802.11 adapters which can be placed into monitor mode and support injection of

packets. While my adapters work perfectly in this regard in standard x86 architecture versions of Kali

and Debian Linux, they appeared to suffer from a random failure issue on the ARM architecture

distributions used for the Raspberry Pi.

I attempted to recompile the 802.11 wireless kernel drivers for the system using patches specifically

designed to aid in the required functionality. Since the Raspbian foundation does not release kernel

headers for their operation systems, the task was made even more difficult as I had to also compile

the kernel headers myself, which took about half a day on the Raspberry Pi’s hardware. Once this

was completed injection still would still randomly fail, this would not be acceptable in the LokiPi. I

finally attempted to change the Host operating system that I was using from my modified Raspbian

foundation distribution to a Kali Linux installation and the PWNPI distribution, these had similar

problems.


• (1 ) Addition of WEP cracking <5>


Implementation 60

Task Outcomes

WEP


Outcome (incomplete) 9 Hours

5.6.3.2. Reverse Shell

I implemented two versions of the reverse shell in the LokiPi, one was written only in Python code,

this created standard TCP socket connect to a listening Netcat service on the a server. Python passed

any output from its CLI interaction back to Netcat, and Netcat passed command backs to the LokiPI.

This was unencrypted communication, so I imagine a corporate firewall with deep packet inspection

could flag this traffic as potentially malicious.

The second implementation utilised a reverse SSH connection back to the listening SSH server, this

was encrypted and in my opinion more likely to bypass egress filtering.


• (5) Remote Wireless Backdoor <4>

Task Outcomes

Backdoor


Outcome 10 Hours

5.6.3.3. Exploit system

To be able to target vulnerabilities I first needed IP connectivity to them. A system of using the

HOSTAPD cli to return the mac addresses of all connected stations was implemented. I then

attempted to use RARP to return IP addresses for these MAC address, but for some reason the Linux

kernel has currently depreciated the use of RARP and it is not supported in the kernel. To circumvent

this issue I interacted with a program called Fping27 transmitting an ICMP echo request (ping) sweep

to the subnet range of my LokiPi’s DHCP pool. A system active with one of these addresses would

return an ICMP echo reply adding an entry to the LokiPi ARP table. Finally using a pattern matching

search utility called GREP I was able to isolate the MAC address and its accompanying IP address

from listing the ARP cache table contents.

27

(Dzubin, 2007)


Implementation 61

Once I had to ability to initiate IP connectivity with connected stations. I focused my attention on

developing some exploits for known vulnerable software. To implement this I used Microsoft

Windows in virtual machines, installed the vulnerable software packages, and installed Immunity

debugger. I used a wireless USB adapter in the VM to allow it to connect to the LokiPi KARMA

implementation.

Through a process of Fuzzing I would crash the vulnerable service on the target VM; this involved a

process of sending increasing buffer sizes to the target services vulnerable command such as “STOR”

for the Ability FTP Server. In the latter case the buffer would overflow in the memory stack of the

VM at around 2000 bytes; this would cause the service and connection to crash. The fuzzing process

had identified the buffer size to overflow the stack.

Using immunity debugger and attaching directly to the running service on the virtual machine and by

sending a sequentially unique buffer of 2000 bytes, I could identify the bytes that overwrote the EIP

instruction pointer register on the virtual machine. These 4 bytes could then be used to identify the

offset position in the sequentially unique buffer.

Once EIP would be overwritten, control of the next instruction to be executed on the remote

machine could be initiated.

After placing exploit shell code generated with metasploit into the buffer at a viable position after

the EIP overwrite, I needed a method to get the instruction pointer to execute this memory address

of the ESP stack pointer. Since windows always loads software into random memory positions with

its protection system called Address Space Layout Randomisation (ASLR), overwriting EIP with the

current ESP stack address would work only until the service was restarted. To get around this a JMP

ESP assembly command can be located in a Windows DLL file such as USER32.DLL which is always

loaded to the same memory address, I then used the memory address of this command to overwrite

the instruction pointer (EIP), which would make the CPU execute the command at that memory

address and Jump the execution flow to the Stack where the exploit code had overwritten the

memory located there. The exploit code would then be executed after a NOP slide (no operation

slide/landing pad).


• (5) Exploitation <4>

Task Outcomes

Exploit System


Outcome 23 Hours


Implementation 62


5.6.4.1. Iteration 5 (17/03/2014 – 31/03/2014)




Implementation 63




• Hardware issues associated with the ARM architecture

• Deprecation of well-known services from the Linux Kernel


Implementation 64

6. Unit Testing

6.1. Iteration 0

Component LCD Assembly communication through GPIO

Function Display Characters and Input correctly

Test Write code to register button presses by outputting strings on the LCD display

Problem Display not showing characters

Resolution Increase the contrast sufficiently, around 30 turns of the potentiometer

Integration Attach LCD plate to the GPIO header

Component LCD Menu Library

Function Display Characters and Input correctly in scrollable menu system, inputs from button

used to scroll and execute code through selectable UI.

Test Test correct GPIO pin mappings and Library Initialisation by generating a 20x4 character menu system and attempt to display it on the LokiPi.

Problem Characters corrupted, overwriting, and not aligning with 4 Lines of LCD

Resolution Correct the LCD line memory addresses used by the PyLCD library source code

Integration Use as a template for main system code

Component LCD Menu Library

Function Display Characters and Input correctly in scrollable menu system, inputs from button

used to scroll and execute code through selectable UI.

Test Test correct GPIO pin mappings and Library Initialisation by generating a 20x4

character menu system and attempt to display it on the LokiPi.

Problem Characters corrupted, overwriting, and not aligning with 4 Lines of LCD

Resolution Correct the LCD line memory addresses used by the PyLCD library source code

Integration Use as a template for main system code

Component Back button

Function Showing a continually updating LCD display like a time clock and having the ability to

stop and return to main menu system.

Test Used code to continually show a clock on the LokiPi, and attempted to return back to

previous menu.

Problem I had only connected 4 GPIO input buttons to the LCD assembly; the library was

specifically mapped for 5. The LokiPi would remain stuck on the LCD display and

require a code restart

Resolution 1 Wrote separate function in library source to return to previous menu

Resolution 2 Appended a ‘back’ string to scrollable menus, exiting that loop if chosen which

returns user to the previous menu loop

Integration Used for clock, memory usage, IP addressing and system information displays,

returning back from entered menu sub systems


Implementation 65

Component LCD Character Input

Function Display ASCII Characters to input, scroll through and display each selected character

as chosen. Functioning Deletion. Store and use as password.

Method After failing to write custom code to generate this, I decided to temporarily use the

menu system functions of PyLCD to generate a scrollable menu of all ASCII

characters, appending each character selection to the Menu header every loop.

Including deletion.

Test Enter characters on the LokiPi and once completed output the concatenated

character string to a terminal console.

Problem Resets to start of ASCII list on each selection, extremely slow, but functions

Resolution In later iteration write custom code to scroll, display, add and remove character

sections from the LCD display. Reverse engineer the PyLCD low interaction methods.

Integration Used as input when joining an encrypted access point

Component WIFI – Python Linux wireless interface library

Function Interact with the Wireless interfaces, scanning, connections, uses python objects so

can be integrated into the main code. Saves connections to

“/etc/network/interfaces” for re-use.

Method While research how to interact with Wireless interfaces through Python and Bash

scripting, I located this library.

Test 1 Connect to Different access points with different encryptions

Problem Changing Access points sometimes cause internet connection to drop

Resolution Was not setup to request a Default gateway dynamically - DHCP

Integration Used as connection method for Wireless interface used as Wide area network

Test 2 Attempt a reconnection a number of times sequentially

Problem On some occasions the code would crash on a connection attempt

Resolution Added Error handling and outputting details to the terminal, this showed that on

some occasions a connection would fail on the interface. Due to a power issue or just

a Kernel driver module for the wireless adapter.

I Wrote code to restart the connection attempt if a failure occurs.

Resolution 2 Updated the WIFI module as I saw code entries on GITHUB indicating better support

for error handling had been implemented

Component WIFI addressing Test

Function The ability to check address assignments of interfaces on the LokiPI

Method Used a module called netifaces to interface with the network interfaces

Test 1 Return addresses of all connected interfaces, remove wireless USB interface and retests, assign and remove addresses and retest

Outcome Addresses or lack or address can be shown on the LCD interface

Integration Used in debugging connection problems, or can be used in code to check if a connection is up.

Component Interface address stability

Function Interface ability to keep and assigned address

Test 1 Have an address assigned and leave for period of time then check if same assignment

problem Addresses would be sometimes null

Resolution Located all network services running on the LokiPI by default, identified which

services were attached to which interfaces. Shutting each service down one by own


Implementation 66

and retesting showed me that the “ifplug daemon service was somehow resetting

the addressing that had been implemented.

I Disabled this service on interfaces that did not require it, The wireless adapters.

6.2. Iteration 1 and 2

Component DHCP

Function DHCP assignments made to devices to connecting to Rouge Access points

Method Install, configure subnet and pool range and assign listening device

Test 1 Attempt to start the DCHP service

Problem Would fail

Resolution Statically assigning an IP address and Subnet for the wireless interface that the Rouge

access point was generated on, this address would be in the same subnet as the

DCHP pool

Integration Allowed address assignments and KARMA to function

Component KARMA Implementation

Function Find appropriate Implementation of KARMA for the LokiPi

Method Download, install and setup

Test 1 Attempt to install and run the Metasploit framework, to use its karmetasploit

integrated function.

Problem The metasploit framework would take over 10 minutes to load on the LokiPi

Resolution I Attempted to free more memory, overclock the processor and memory, and attach

a database instance for caching.

Integration No integration as regardless it was still far too slow to be usable

Test 2 Use Robin Woods KARMA patch for HOSTAPD

Problem No problem

Integration Used as main Rouge access point method on the LokiPi

Component KARMA

Function Software Access point – Automatic Beacon generation, Multiple simultaneous Rouge

access points

Test 1 Enable KARMA and use Wire-shark to scan wireless traffic

Problem No problem

Outcome Was able to see multiple Beacons for unknown SSID’s emanating from the KARMA

wireless interface BSSID (Mac address)

Integration Added to bash script to initialise and shutdown KARMA

Test 2 Enable KARMA and use android phone, IOS tablet and Laptop In proximity

Problem Automatic connection occurred only sometimes

Resolution Identified that depending on the order of the client’s preferred network list, if access

points that are on their PNL are in proximity, and if the original AP’s on the PNL used

no encryption.

Integration Used as an automatic rouge access point generator

Test 2 Connect client’s through KARMA with stability

Problem Automatic connection, association, occurred but soon disconnected


Implementation 67

Resolution Added a valid DHCP server to the LokiPi in same subnet as the interface

Integration Used for address assignments; IP and subnet, gateways, and DNS server for spoofing

Test 3 Various Operating systems

Problem A friend’s android phone using an OS version 4.4 Kit-kat would go into an infinite

connection attempt/failure to the generated Rouge AP; this was with a valid

preferred network list order with an Open access point in the listing.

Resolution Requires further testing as this is only one case, I need to find another Kit-kit android

phone to test.

Component Wireless to Wireless Interface IPtables routing

Function Passing traffic from the Rouge access point interface to the Wireless interface acting

as the WAN gateway

Method Connect to WAN and initialise KARAM on second interface

Test 1 Attempt to surf the internet through a connected client

Problem No Internet connection

Resolution Added line to the Linux network interfaces configuration file to enable receiving the default gateway by Dynamically on connection

Integration Ability to have a Wireless to Wireless, and Wireless to Ethernet internal routing bridge

Component Evil Twin

Function Find appropriate Implementation of KARMA for the LokiPi

Method Scanned access point and cloned them

Test 1 Attempt the cloning of a Access point with WEP encryption with a connected client,

disconnect client from original and see if client connects to higher powered Evil Twin

Problem Access point would be cloned and broadcasted; client would disconnect but would

flutter on a connection attempt, not connecting successfully. It was hard to see what

was happening with the Android interface and IOS.

Used Wire-shark and could see Two access points, so they were cloned. Both could be seen sometimes on the Android and IOS devices.

Cause My Macintosh laptop showed me what the issue was, It was attempting to connect to an access point that had encryption enabled previously and now was open.

Integration Works, but I left it in its current state as KARMA is far better method when the

original target access point is open.

My interest in Evil twin was to see if I could get a client to disconnect from an

encrypted network and attach to a cloned un-encrypted version, seamlessly.

Test 2 Attempt to increase broadcast Power by setting the wireless registration domain to

BO (Bolivia I think) this allows for a higher broadcast power than Europe or US.

Problem Would not set the power by issuing the appropriate command to the terminal, an

interface access issue

Resolution Found that by setting the registration domain to BO, and then starting the interface

using Airmon-NG would increase the Power output.


Implementation 68

6.3. Iteration 3

Component LokiPi system service

Function LokiPi code start-up, shutdown and maintenance

Method Linux service script

Test 1 Restarting LokiPI, having the service enabled, checking functionality

Problem Once a Bash script was executed from main service code, it would crash

Resolution Permissions and environmental variables problem, I added the absolute paths for the

Bash scripts in the main Python service, stopping each account from having envoi

mental variables set for these programs/scripts.

Created a new account with SUDOERS privileges, moving all LokiPi code from the

root account home folder to this accounts home folder.

I then added a ‘sudo’ prefix to the commands in the Service script, to execute the script with heightened privileges on start.

Integration Used as an auto start functionality, and gives the ability to start and stop the service

from the command line when testing additions to the code base.

Component DNS spoofing, enabling and disabling

Function Turn DNS spoofing on or off

Method Script to copy address mapping, or delete all current mappings and restart the DNS

service

Test 1 Enable and disable, then test for redirection

Problem Sometime would not work on a client immediately

Resolution Clearing the client’s DNS cache would amend this, not sure if there is anything that

can be done on the LokiPi side

Integration Added as option to LCD menu

Component DNS spoofing and Apache phishing web sites

Function Return false address mappings from client requested domains

Method Have Apache Virtual hosts representing different web sites, I have cloned copies of

Facebook, Yahoo. These virtual hosts will respond to the requests for the domains

they represent only. The DNS server will hand client’s the Software access point

address as the DNS record; they should then be directed to the LokiPi server.

Test 1 Make client’s request different web sites that are being spoofed, and then check the

web sites login capture files for the captured login details.

Problem Similar issue with DNS cache on client’s, if they had the real DNS mapping in cache

they would not request it from the LokiPi

Resolution Clear Client cache

Integration Added option to LCD menu


Implementation 69

Component SSLstrip

Function Downgrade connected client’s HTTPS connections

Method Enable internal web proxy and redirect HTTP traffic to the listening proxy port, where

SSLstrip is functioning

Test 1 Use different browsers on a connected android phone to connect to a HTTPS version

of Facebook

Problem Would not function with certain browsers such as Mobile Chrome, the android

default browser is vulnerable, and so is safari on IOS.

Resolution No resolution, integrated security feature of Chrome

Integration Enabled through menu system

Test 2 Parse Log Outputs successfully

Problem No issue

Outcome Successful capturing of Passwords for m.facebook.com using default browser on

Android

Integration Enabled through menu system

Component Power

Issue LCD brightness fluctuations when wireless to wireless bridge enabled

Test 1 Enabling the wireless interfaces manually and checking the stability of the power to

LCD

Problem Too much power drawn from Raspberry Pi

Resolution Attached Wireless USB adapters through a powered USB hub

Integration Would have to find a method of giving more power to the PI through the GPIO

headers and or using an inline powered connection attached the USB interfaces in

the final LokiPi product.

6.4. Iteration 4

Component Web Server

Function Web server interaction with main system code

Test 1 Change a Boolean value through the LCD interface and then see if the web interface

sees the change, while printing the memory address of this object to the console before and after a change has occurred.

Problem The address to the referenced object would change by changing a Boolean value from the LCD interface, but attempting to change the same Boolean value from the

web interface would make the address change to the same as the LCD change.

They were not synchronised between the 2 running processes, The LokiPi web

service and the Web server instance.

Possible

Resolutions

Store values in accessible database

Inter process communications

Shared memory segment

Utilised

Resolution

I used a shared memory dictionary (associative array) to synchronise changes

between the two processes. It was a simple and elegant solutions seeing as the only

data that I wanted synchronised were Boolean flags.


Implementation 70

6.4. Iteration 5

Component Connected stations

Function Identification of IP addresses of associated stations

Method Use operating system ARP to return IP from HOSTAPD MAC address listing

Test 1 Use Linux command line to attempt resolution

Problem Linux kernel depreciated support for ARP

Resolution Used a Ping sweep to fill the ARP table from the replies of connected stations and

extracted the IP from this

Test 1 Attempt resolution a few times in sequence

Problem Sometimes the object containing the ARP table mappings would be null

Resolution Couldn’t isolate the issues, appears to have stopped. Anytime I tested the code in

isolation using a python interpreter there was never an issue.

Component Exploit System

Function Identification of vulnerabilities and delivery of exploits

Method Use python code to banner grab the service connection headers, do string

comparisons

Test 1 Connection to service, store header and do comparison, return an ID

Problem No problem

Integration Used after IP address retrieval of connected stations

Test 1 Test exploits on different virtual machines

Problem Exploits would fail at times

Resolution 1 It would appear that having the target service installation directory in different

locations changes the offset at which EIP can be overwritten

Resolution 2 Sometimes it would require a different exit method in the Exploit shell code

Resolution 3 Different incompatible characters would have to be encoded out of the Shell code as

they would either terminate the network connection or cause issues in the CPU execution on the target machine

Component Reverse Shell

Function Create a reverse connection to a remote server

Method Using a Python TCP socket connection and Reverse SSH

Test 1 Connect to Amazon AWS instance running Netcat

Problem No issues

Test 2 Connect to Amazon AWS instance listening with SSH server

Problem No issues

Test 2 Potential issues with other gateways

Problem Requires testing in the appropriate network topologies


Future Work 71

7. Future Work

7.1. Flask Web Server

The LokiPi is currently using the built in development web server from the Flash Framework, this has

potential issues in relation to speed as it as a development test server, as it is handling only one

request per time sequentially. This also has absolutely zero security hardening and would be a

serious vulnerability to leave as the main web server on the system.28

The environment/container in which the web server runs will have to be implemented in a stand-

alone HTTP server such Apache.

7.2. Internal Security Hardening

Security hardening for the entire system will have to be implemented; the LokiPi is attempting to

accept automatic connections from potential clients to initiate attacks against them, giving the

associated client stations IP connectivity to the LokiPi. The connected stations will have just as much

opportunity to implement attacks against the LokiPi if it is not hardened against these.

In the LokiPi’s current implementation associated stations are not placed into a separated subnet

from any of the services running on the system. Currently the only securities in place are passwords

placed on the Root and User accounts. Separation of vulnerable areas of the system will need to be

isolated.

All services will have to be hardened and tested for vulnerabilities, such as the Apache web server

where I have file permissions ands group ownerships that “just work” and have not been setup with

security best practices in mind.

The operating system should be scanned for anything that can be removed, such as disabling any

unnecessary services, or kernel parameters that could potentially lead to exploitation.

A password login implementation for the LokiPi flask web control will need to be added, using a

backend database authentication and SSL.

Add an option to enable WPA2 encryption for the main user access point, also have the ability to

disable the SSID broadcast.

MAC address white and back filtering enable ability to add user accounts, though this is already

achievable from an SSH terminal login.

7.3. Custom user Exploits

Add a system for allowing a user to add their own exploits, create a framework and a set of rules for

their creation.

28

(stackoverflow, 2014)


Future Work 72

7.4. Custom method for alphanumeric character input from the LCD

The current implementation of the inputting characters from the LCD is cumbersome and slow. The

Hitachi HD44780 controller datasheet will need to be used to code this implementation from

scratch. 29

7.5. Change all Bash scripts to Python code

Remove all the Bash initialisation script and convert to python code, this will allow for much better

error handling and speed.

7.6. Add other tools with similar functionality

I wish to include different varieties of these attacks using different software implementations with

the same functionality; I believe that this variety of options would be very beneficial to a security

auditor as many similar tools perform the same attacks with different methodologies, producing

different outcomes in some cases. Since there are large qualities of these tools available and

developed by the hacking community, it would simply be a matter of integrating them; this would

involve intense testing procedures to ensure compatibility.

7.7. Portability

The device needs to be made portable by including a suitable battery pack and encasing all the

components in a suitable container. Currently the prototype device has to be plugged into a

powered USB hub that is attached to a power outlet.

7.8. Logging

I wish to have detailed logs produced by all the running services and software packages directed to a

single hierarchal accessible database storage system.

7.9. Start-up system checks

I wish to include some start-up system checks on boot, for example these would verify if interfaces

were initialised properly, and have code to implement fixes if possible. A major one required would

be code that would be a software facsimile of the process of physically resetting a USB device.

29

(Hitachi, 2014)


10. Conclusion 73

10. Conclusion

I am very happy with the project as it stands as I have completed much more than I could have

anticipated. I am glad that I took the risk on such an adventurous project as I have gained a depth of

experience and knowledge from the process.

Toggl was an especially useful tool, allowing me to meticulously track time spent on individual

component development. This has become a staple of any autonomous tasks that I endeavour with.

Python is beautiful language, since indentation is used to separate logical blocks of code it

produces/forces extremely well styled and structured code. Another benefit of Python is the

supporting documentation and API is very detailed and easy to navigate. There are also a large

variety of supporting modules produced by the Python community, allowing a component based

approach with rapid development and prototyping.

I do have some moral issues with the project; I am beginning to believe that the main demographic

user of the LokiPi would end up being people with malicious intent, lacking knowledge of technical

detail and wishing to “Hack” through a few clicks using an automated device such as this. This was

especially apparent to me when I created a facsimile of Facebook, Yahoo and Gmail websites with

ease and initiated a DNS phishing attack. This was so simple once set-up initially I could immediately

see that there would immense interest from the morally challenged of the world. This being the case

I think I may suspend development on the LokiPi until I can come to the appropriate decision on its

final fate


Appendix 74

Appendix

Appendix A – log File

Iteration 0

19/01/2014

• Soldered LCD plate during the Christmas break so that was already completed.

• Setup, SSH and VNC on Raspberry Pi.

• Found Komodo Edit which allows for SCP remote file editing, much faster than VNC.

• Komodo also has more features over using VI or NANO editor over SSH.

• Installed dependencies for LCD menu including GPIO communications.

• Compiled and Installed Aircrack-NG suite

• Implementing SCP backup script for Daily backups of code from PI and then implementing weekly backups in the form of a complete image of the Raspberry-Pi SD card to PC.

21/01/2014

I Researched the creation of an LCD texted based menu system and quickly discovered that coding it

from scratch would be a considerable feat, so instead opted to search for compatible python library

for a Graphic text based UI implementation. Coding this alone would have greatly impeded the

progress of the main project functions, to the point where the project would have ended up being

the LCD GUI library by itself, that being said this could potentially be the basis of a project idea for

another time.

Looked into using the Adrafruit library for their implementation of a similar Hitachi based LCD plate,

but this used an IC2 chip which serialised GPIO communication of the Raspberry Pi down to only 2

addressing lines to and from their custom implementation LCD. This addressing utilised in their

library would most definitely not function with my fully wired LCD which would use 6 addressing

lines for output to the LCD + 4 for the inputs.

I then discovered the PyLCD library after rigorous searching, written by Julian Metzler30 for a variety

of LCD’s and hardware backbends inclusive of the Hitachi HD44780 and the Raspberry-Pi. It allowed

for custom mapping of the GPIO communication pins and a DisplayUI class for the creation of

scrollable text based menu systems.

30 (Mezgrman, 2014)


Appendix A – log File 75

I located, compiled from source, and installed “wiringpi” for library specific GPIO access instead of

the RPi.GPIO because PyLCD utilises both.

Fixed an elusive Line addressing issue in the PyLCD Library to account for my setup of the

4x20 LCD screen, the addresses for the arrangement were slightly out in the source code of the

library. The Problem was visible in that a displayed line of 20 characters would be chopped down by

4 in 2 of the lines, with these bytes overwriting other lines causing the perceptible errors.

[0x80, 0xc0, 0x90, 0xd0] – Original

[0x80, 0xc0, 0x94, 0xd4] – Amendment to module code

28/01/2014

Since the line addressing issue was successfully rectified, I attempted to utilise the Library to build a

test menu system based around example code that accompanied the library. The code functioned to

a point, but was missing one glaringly obvious feature when outputting dynamic changing data such

a clock timer to the LCD, it would not return back to the previous menu in response to any of my

GPIO input button selections.

I attempted to locate a method for circumventing the lack of a functioning back button on my

implementation of the raspberry pi, I tried to just use a reassignment but that still wouldn’t function.

The library sample code appears to be implemented for a keyboard input method. Modification

currently is not producing results.



Attempted to import and utilise a GPIO library to manually recognise button presses, this

semi-functioned but on return there was massive conflict with the assignment implemented by the

PyLCD library and its use of wiringpi to program, activate and assign GPIO configurations.

Also attempted to use a function from the INPUT class called read_key but this would just

pause the execution waiting for input, this was not ideal.

I the read through the source code and identified how the Library was verifying if a key was

pressed. I then used this to add a simple function to the library code to return where the OK button

had been pressed or not. Calling this function allows me to break from a Display output when the OK

button is pressed.

03/02/2014

Found simple method for Character inputs using GPIO with button presses. Originally i was

overcomplicating the issue, trying to find appropriate calls to shift characters, cursor on LCD and

create cycle-able selections while also allowing for deletions. These could have been written from

scratch using the “Rpi.GPIO” library that I was familiar with, but since I have as utilising the PyLCD

library which uses “wiringpi” there would be major conflicts.

So for the sake of speed I attempted to use what already existed in the PyLCD libray,

creating a selectable sub menu with a list of ASCII characters for selection. When a selection is made

it is appended and removed from a String while also being printed on the first line of the LCD screen

for checking. It is not very elegant but achieves the goal; this could be implemented better in a later

Iteration.



08/02/2014

Found very efficient module called “wifi”31 which allows for easy connections to AP’s using

python code. The module allows easy identification of all AP features, and most importantly allows

for the configuration to be saved to the “/etc/network/interfaces” file for automatic connections

later on.

Looks for pre saved access points, has one issue though. If Encryption key was originally

incorrect the code does not check and saves it anyway. This will cause saved details to be

permanently incorrect. I need a check mechanism to stop the configuration save if the association

fails.

31

(Rocky Meza, 2014)



Iteration 1 and 2

09/02/2014

I Found that there are varying different versions of the Karma patches available. The original Patches

from Dino and Shane32 from 2006 but these are antiquated by now. Then there are digininja’s

KARMA patches for the HOSTAPD software access point, including a later version from another

individual. There is also a version that emulates the KARMA functionality for the metasploit

framework called karmetasploit, but considering the pervious slow experience with metasploit on

the Raspberry Pi it may be a poor option.

I am currently testing patched HOSTAPD version 1 and 2. Downloaded compiled and

installed, found dependencies and installed. Ran KARMA on WLAN1, it created a FAKEAP on a

monitor interface “mon.wlan1” and also began responding to Beacons; and in the case of my

android phone it is attempting to associate. This was failing, but I knew this would be the case to

begin with.

So I installed a DHCP server, gave the monitor interface and IP and assigned the DHCP pool to that

subnet, but received errors indicating that the DHCP server could not listen on a monitor interface.

After much searching I made an attempt at assigning the DHCP server to the physical interface

WLAN1 rather than the monitor interface layered on top of it, this worked and clients started

associating and receiving DHCP assignments. I’m not sure if this is a fully working solution as may

have an impact on routing…. May need a method for attaching a network tap to the monitor

interface such as what is done by airbase-ng.

I also downloaded, compiled and installed the Metasploit framework, it proving a little

difficult to install on the raspberry. There appear to be dependencies issues with Ruby modules; I am

attempting to sort them out.

32

(Zovi, 2005)



I eventually got it to start up but had a 10 min boot time and used nearly all the available

memory on the PI.

Purging the memory caches helped a lot, but the boot time is still ridiculous.

$ sync

$ echo 3 > /proc/sys/vm/drop_caches

$ free –m

Amendment – with simple IPtables commands routed wlan1 to eth0 for testing, pages

loaded through android phone connected to Fake KARMA Access point. Not sure if I will still require

a network TAP for traffic modification, but probably will require something. Maybe the monitor

interface and the physical interface implementation using HOSTAPD implements this function.

• iptables --flush

• iptables --table nat --flush

• iptables --delete-chain

• iptables --table nat --delete-chain

• iptables --table nat --append POSTROUTING --out-interface eth0 -j MASQUERADE

• iptables --append FORWARD --in-interface wlan1 -j ACCEPT

• echo 1 > /proc/sys/net/ipv4/ip_forward

12/02/2014

Identified Issue with one of my WLAN cards, one card 50% of the time fails at scanning… probably a

power issue it appears to be drawing too much from the Raspberry Pi.



Temporarily fixed this by using a USB power hub for the ALFA wireless card, for a final version of this

I would have 2 Tenda 311u+ cards as they function perfectly with the PI and there are no power

issues. Amendment: still the same issue with that card. I decided on purchasing a cheap alternative

with known working chipset.

I fixed Errors accounting from wireless connection faults by adding additional code for error

handling. Updated the WIFI module as I saw code entries on GITHUB indicating better support for

error handling had been implemented.

Added code to delete a connection attempt that has failed from the

“/etc/network/interfaces” file. This allowed for connections to be reattempted.

12/02/2014

Implemented ability to check if any network interface has an IP address, this may come in

useful later + as simply display utility, I used the module “netifaces” 3334 to achieve this.

Attempted KARMA from a WIFI to WIFI interface, wasn’t working until I added the gateway

address for the Android wireless tether manually. Then it functioned, I think I will be looking into

bridge interfaces as this would work better, otherwise I would have to code the checking and

extrapolation of the gateway address from different phones with this method. To then add the GW

route to the routing table.

May temporarily move onto Evil Twin, but keeping in mind this will still need to have this

issue resolved.

Also noted that Apache server became unreachable when the Ethernet connection was

detached when testing this. I think that it may need to be bound to multiple interfaces, primarily the

fake AP address (wlan1) (10.0.0.1).

15/02/2014

33

(Houghton, 2011)



“Wlan to Wlan” KARMA routing was not functioning because of an incorrect gateway

assignment when connected to Android HotSpot, It Works when scripted to start up without SSH

and Ethernet was detached. I will have to test fully by removing static address and gateway

assignment for Eth0 as my wireless uses the same gateway, to prove that an address can be

dynamically assigned with KARMA still functioning.

Below is the Bash Script that the python script executes to setup KARMA. DNSmasq has a

configuration file listening for requests on the 10.0.0.0 255.255.255.0 subnet. It also is running a tiny

DNS server that intercepts DNS Requests and Responds with custom DNS A record mappings for

specific sites, responding with the address of the Client side access point “10.0.0.1” where apache is

running.

DHCP address assignment stopped working, eventually by checking console output I could

see that the wlan1 address would get reset after KARMA and DNSMASQ start. Think this may be

down to DHCP and so will try a static assignment in the “/etc/network/interfaces” files for WLAN1.

I also tried auto starting the script, for testing WAN to WAN routeing without Ethernet

attached, this wouldn’t work as I believe there is a privilege escalation issue when the Bash Scripts

are executed.

Iteration 3

Giving permissions of www-data to “/var/www” folder and adding captive portal.

The speed increase from using patched hostAPD over airbase-ng for the Software access point is

amazing, glad I went this route.

The gateway issue was being called because I had omitted a line in the Linux Interfaces file “iface

default inet dhcp” telling the system to obtain the default gateway from the DHCP server of the

WAN access point.



SSLstrip

Got SSLstrip functioning, IPtables redirects all encrypted HTTP traffic to local port 10000,

where SSLstrip is intercepting.

Seems to Works against Firefox and Safari but not chome.

Captive Portal

I also added Captive portal running on Raspberry Pi Apache instance, this could be easily modified to

look like a Firewall portal login (for example WIT firewall authentication for its Open Wireless Points)

Massive client side security hole.

18/02/2014

Attempted Evil Twin

I attempted using two different methods, the first was to use the Aircrack-ng suite to create the

cloned access point and the other was to use HOSTAPD again and disable KARMA.

Both required the AP scanning feature again, which I copied from earlier WAN implementation. Only

adding the capacity to get more information about the selected AP, its MAC and Channel specifically.

Had a lot of issues with Aircrack-ng, had to use an ”ignore-negative-one” to get a lot of features to

work as otherwise it would see the interface as being set to channel “-1”. It would appear to be a

driver kernel module issue.

There were also a lot of issues when attempting to increase the broadcast power of the interface,

but I found a temporary solution that was to just set the wireless registration domain to BO (Bolivia I

think) which allows this high broadcast power. I would then attempt to set the interface broadcast

power manually “iwconfig wlan0 txpower 30”; as this wouldn’t do anything even though I should

have.

I found that if I just initialised airmon-ng or HOSTAPD with the “BO” registration set it would increase

the interface power by itself.



This method + the HOSTAPD method ended up having the same poor results, they would clone the

AP fine and broadcast the clone, but when de-authenticating the original AP and depending on the

client OS (android and IOS in my case) they would only sometimes register the Open Twin AP. This

looked to be a security feature as they IOS would change the Original Connected Access points

encryption to open, but switch right back after the De-authentication attack was over.

Android would just show both Open Twin and WPA original but not attempt connection.

Also made attempts at using original AP mac and separate made up MAC address to create the EvilT

Twin, though this may have something to do with it as death attacks by use of the MAC address.

19/02/2014

LOG_EX Script Allows for the parsing of the SSLstrip output log, as can be seen below my Mobile

facebook login was captured while connected to the raspberry Pi through KARMA. I May automate

this so that the LOG can be parsed, this HTML file generated and sent to a virtual host on Apache

that can accessed on a specific independent socket.35

Very useful too, this can be done with GREP and regular expressions would be very time

consuming to identify and filters all the possible different identifying characterises of passwords in

HTTP traffic…… This script has them all integrated and converts the output to a HTML page.

Create SOCKET based virtual host available on port 666

35

(moloc, 2014)



Found Python Bottle Web Server for quick easy web development – will research as may be able to

include in current code, activating and deactivating with the current Flags.

20/02/2014

I found that I had left out a line in the network interfaces configuration file that was causing the Pi to

not request a Default gateway through DHCP when connecting through the WLAN interface. Adding

this fixed the WLAN to WLAN KARMA implementation, but introduced another issue.

The issue appeared to be power related, when both WLAN interfaces and the LCD where active the

LCD brightness would flicker and sometimes disconnect from the PI. I attempted to solder my

backup LCD, but this proved to have the same issue. I then added a small USB powered Hub and

powered the Raspberry Pi, and Both WLAN adapters from this….. Everything Stabilised

Taking this into account, I may attempt the evil twin attack again as increasing the broadcast

power would increase power requirements.



I amended Auto-start feature by adding the full path (absolute) to all other bash scripts in

the main Python script, this stopped reliance on user accounts having the appropriate

environmental variables for the required software. I then added a new account with SUDOERS

privileges and moved all files from the “/root” home folder for the root account to a more

independent folder. I created a file that would run as a service on start-up by adding it to the

/etc/init.d folder and giving it executable permissions.

I finally used “update-rc.d” to manage the service by activating it. This worked but I found that it

caused an issue with the power off and shutdown commands were they would just stall and do

nothing. I imagined that this was due to them requiring the ability to shutdown service; I added code

to the service start-up-script to amend this. This corrected the issue allowing the OS to shut the

service down.



21/02/2014

Phising Pages and DNSspoofing

I was having issues with addresses not being assigned to interfaces and after some testing

and research though that it may have been related to “iflugd” daemon server that was defaulted to

run on all interfaces. I made it so that it would only run on WLAN0 where it was required for the

WAN connection DHCP setup.

“ifplugd is a daemon which will automatically configure your ethernet device when a cable is

plugged in and automatically unconfigure it if the cable is pulled.”

So far this issue has not shown itself again, will continue testing.

Added the capability to disable and enable DNSSpoofing via the LCD Menu. I also added

phishing sites for Facebook.com, yahoo.com and gmail.com. These are just proof of concept and

would not be released with the source code. These run as virtual hosts on apache on the Raspberry

Pi IP address, when a DNS request comes for facebook.com, the internal dns server responds with an

A record for the Raspberry pi apache server, then apache reads the request header and forwards to

the appropriate Virtual Host facebook.com internally. The Facebook page has a PHP script (very

common and wildly used) that on a post action gets called and logs everything to a file.

These are proof of concept and would not be included with the code.



Since attempting to use Reaver I noticed that there is a serious inconstancy in the current

wireless card modules for the RALINK chipsets I have in my cards. They randomly fail packet injection

tests and have issues with only seeing channel negative one, which disables reavers functionality.

To fix this issue there are patches available for the Wireless modules that are loaded into the

Linux kernel. For these to be compiled GCC+ and the Linux header for the specific kernel version

being used must be installed in the system. After much searching I have found that the Raspbian

Foundation does not package kernel headers for the Raspberry Pi. This is very frustrating, as I had

also tried to install and set up PWNPI another distribution but this also had issues with my cards

even though it was patched (I assume since it’s a pen test distro). But this also has same issue as it is

a derivative of Raspbian.

I am now downloading the latest release of a custom image of Kali Linus for Raspberry pi,

this is not based on Raspbian but directly of debian. Wireless was totally non-functional in the last

release so I’m not that hopeful.

Eventually got kali working, had similar issues with the RALINK chipset based cards, but worked with

my Alfa, saying the remained the same issue with that card and the RPi, it stalls the boot process at

times.

May return to Raspbian and give up on the idea of WEP cracking and REAVER for the time being, too

much time attempting to hunt down this issue. I have ordered a more compatible WIFI card and will

test that later on.

The raspberry pi is realistically to slow for these functions anyways, if was to really continue with this

project after college I would use an Odroid U2, Quad core 1.6 GHZ credit sized ARM with 2 GB RAM.

Kali was working but caused other issue such as incompatibilities with compiled x86

executables such as HOSTPAD, this totally ruled this out.

In the mean time I found a method to download the kernel source code and prepare the

kernel headers needed to compile driver modules; I did this and then successfully compiled the



drivers with patches. Though the “negative one” patch would fail as this “modern” kernel version

the Pi is using is supposed to have that issue resolved already.

I returned to my previous image and tried one last thing, to use the internal IWCONFIG tool

to turn the WIFI adapter in top monitor mode, by first disabling it and then setting this. This with the

use of an older version of aircrack-ng allowed for channel scanning and packet injection to function. I

find it very strange and am a little distrustful of it. I really am totally unsure what I did to make it

function for the time being, it tried many things… So it could easily stop and I may not replicate it…..

Anyways I need to leave that alone; I may attempt an automatic script for WEP cracking. But not all

that pushed as that may be a very difficult task as it appears like a very interactive process. Also the

Pi is quite slow.

It is Nice to have the option though.

26/03/2014

Found simple python web server WSGI container interface library called “flask”, this will allow me to

make a web server to hopefully easily integrate into the current code.

Located some example code that interacts with GPIO pins though a web interface, had pieces that

looked like they would be useful. Not direct GPIO interaction.36

Jinja2 expands the template

Though modification of the code I was able to get from simple jquery, html, python, ajax, to do

requests to execute code and get state information returned. This done by jquery code that

I figured out ways to correctly position button sliders on the web interface using CSS.

Issues with attempting to use a thread to start the Flask web interface, as it would block on the web

server start-up stopping the rest of the code from executing, thought at the time that my method of

using a sub-process fixed the issue completely. The web server had access to variables in the main

application, or so I thought.

Tried threading but in the once instance that I got that functioning it would mess up the LCD

graphics interfaces, messing the timings I assume. I Had to use a Sub-process instead.

Global variable access issue

Starting today I noticed that changing a global variable from within the main code would work, but

when accessing this “change” from the web server through ajax call it would not be visible. But if

changed from the webserver it would work, well from the perspective of the Web server it would

work.

36

(Blais, 2014)



I starting to think that the webserver has its own global variables that it copied from main code on

initialization. I have tried and tried to access the main global variables; initially thinking I may have

something to do with Ajax jQuery state call to the method that check’s the global variables value

every 500 milliseconds. So I investigated CTX (something to do with flask) global variables with flask

and pushing and popping them off of a stack.

I found this “To share data that is valid for one request only from one function to another; a global

variable is not good enough because it would break in threaded environments. Flask provides you

with a special object that ensures it is only valid for the active request and that will return different

values for each request.” 37

Didn’t help,

I realised that this definitely has to do with my implementation of the code using a separate process

to start the web server; I think I would have to use a remote procedure call from process to process

to pass these variable values back and forth between the main web server and the script.

If get the time to achieve this I will use this, https://pypi.python.org/pypi/rpyc or python twisted to

achieve this.

But I may just have to leave this for a completely different time.

Connected stations

I used a call to “hostapd_cli” command line interface through python to return a list of

connected stations by their MAC address. I then split the addresses into a List (array) and returned it

for processing. HOSTPAD is the software Access point daemon running with the KARMA patches.

I needed to get the IP addresses that had been assigned to these connected stations, since I

had the MAC addresses I thought it would have been a simple process of using the linux terminal

RARP command, but this has been discontinued for use in the current Linux kernel. Since ARP still

worked I used a work around of pinging the DCHP pool address range in a sweep using the utility

“fping”, I anything exists from an address on this range then it would be added to the ARP cache on

response.

Thinking of this now, I could have also used some method of querying the DHCP process for

the assignment that it has given by MAC address, this may have an issue with client disconnections,

reconnections and IP address renewals. But work keeping in mind as another method.

I would use a pattern matching to filter out the output from ARP that contained the MAC address

that I’m investigating. This line will also contain the IP address of that machine.

I converted this output to a python List and extracted the correct index [0] which contained

the IP address.

Had a lot of issues where after some use, the output from theses command would be empty

(null) and the whole process would fail. I could not identify exactly what was causing it. I used print

37

(Flask, 2014)



statement to DEBUG to the console, identifying example what the variables contained at a point in

the execution sequence, this was the only valid method that would work while using the LCD control

interface.

Every time used the code in an isolated manner, executing in a separate python Interpreter

it would function perfectly. I think something has fixed this issue, and I am guessing that it had

something to do with the Wireless interfaces not being properly put down and up when restarting

the “Lokipi” custom service. I have changed that in the server script in the meantime and since

haven’t seen this issue arise again, but have not been testing so it may still exist. But honestly still

don’t really have a clue as to why.

21/02/2014 to the 15/03/2014

Since I have created the code to identify the ip address of a connected client, I thought I may

use this to add some explit code to the system.

This is a very basic outline of code that would work, it is missing the ability to correctly identify if the

target is vulnerable prior to attempting an exploit against it. This could be added by just using some

of the code that is contained in the exploit and adding it to the main script with some modifications.

But what would be harder would be to automatically identify what Operating system version +

service pack is running on the target, this is vital information for exploitation.

Nmap and such utilities have OS identification features embedded, from what I remember has

something to do with differences in the TCP/IP stack being used by the operating system and the

default ports that are visible. Nmap uses intelligent informed guessing when achieving this. This

could be added but would require user interaction to make the final decision as it can be very

inaccurate at times using this heuristics based approach. There is a nice library that uses Nmaps

functions directly as python code that could be used to achieve this.

As it stands my code asks the user to select the target service port and operating sysystem version, I

have only coded for Windows XP Service pack2 and pack3 due to the time limitations.

To create the exploit code I used a Window XP virtual machine, SP2 and SP3 for testing. Connected it

to the Lokipi and started installed very vunrabile software on this.

I then when through a process of “Fuzzing” the target service, looking for a buffer size that would

crash the service and overwrite the CPU insertion pointer EIP. From this I would be able to write a

memory address to this location to redirect the execution flow to custom exploit code.

Patten_create used to create an sequentially unique pattern of Hex that when the EIP is overwritten

on the service buffer overflow and captured with a debugger such as Immunity, I will be able to use

this to find the byte offset at which the buffer overwrites EIP register on the target.



The shell code (exploit) is placed in the buffer that is sent to the service to crash and overflow it.

I need to redirect the execution to this Shell codes address, this code gets placed in the Stack as

these attacks as Stack based overflows. Occurring when the input to the remote service overflows

and writes over the memory Stack.

This can’t be accessed through another register called “ESP” Stack pointer, since I can’t call

this directly from the shell code by placing this “address” in the EIP of the overflow. This is because

windows use Address space layout randomization (ALSR) and this memory address changed each

time the service is executed.

A trick is to use a Windows DLL that is always loaded to the same address in memory, this address

will be specific to the Operating system and service pack, Then decompile this address looking for a

JMP ESP command (jump to Stack). This is the reason why exploits of this type are OS specific.

I had to find a valid address for the exploits by disassembling the DLL loaded by the different version

of windows in virtual machines.

I used metasploit to generate the Shell code, made different versions such as a bind shell, reverse

shell. That can be chosen by the user. TO make this fully use full in a fully released product I would

have to be able to take user input such as the listening IP address and generate the Shell code on the

fly. As it stands I have the destination IP in amazon hard coded in hex in the shell code.

The code can identify vulnerable services on choose ports and automatically. Loads the

correct one is available.

Some of exploits I had previously created where not working anymore, I have noticed that by moving

the installation directly fort the service on the file system changes the address at which EIP gets

overwritten.



EXITFUNC will be useful in some cases where after you exploited a box, you need a clean exit, even

unfortunately the biggest problem is that many payloads don’t have a clean execution path after the

exitfunc .

SHE - This method should be used when there is a structured exception handler (SEH) that will

restart the thread or process automatically when an error occurs.

THREAD - This method is used in most exploitation scenarios where the exploited process



PROCESS - This method should be used with multi/handler. This method should also be used with

any exploit where a master process restarts it on exit.38

28/03/2014

Address was very close so got me thinking, something I had read about the python garbage

collector having free roam and always moving objects around memory. SO printed the memory

address before mutation from the LCD interface this time and it was identical (same reference to

same object in memory). One process appears not to be updates about this fact though and still

holds the old reference to essentially a different object.

Shared Memory manager fixed this issue39

I separated out the web server code into a module.

Changing the Slider value when changed on the Server Side (LCD side)

If you are a seasoned front-end developer, you might already understand why these two libraries

cannot work well together: jQuery Mobile “processes” the DOM only once--at the beginning of the

life of the page--so “enhanced” HTML components cannot be updated by simply changing their

backing variable because Knockout.js doesn’t know how to update the new UI generated by jQuery

Mobile.40

38

(Valentino, 2014) 39

(python.org, 2014) 40

(Chiaretta, 2013)


Appendix B – KARMA 95

Appendix B – KARMA

In the original Rouge Access Point attack an enticing SSID would be set up, in the hope that a

user made a manual connection to this network by choice. Due to its very nature this is an

increasingly antiquated vector of attack. But since the introduction of the resilient WPA encryption

standard, there has been an increasing interest in wireless client side attacks. A fairly insidious and

ingenious tool devolved by Dino Dai Zavi and Shane Macaulay41 called KARMA allows an attacker to

circumvent/side-step the issue of manual connection depending on if they had previously connected

and stored an open networks SSID.

Previously Operating systems such as Windows XP Service pack 2 had a fatal flaw in that

they would accept and connect to a network fake SSID even if the Authentication and encryption

settings were incorrect as long as the SSID matched. This has been rectified as of Windows XP

service pack 3, but systems that have previously connected open networks in their preferred

network list are still vulnerable to this attack.

Since clients broadcast the SSID’s of Access points they are looking for in probe request

packets, KARMA was devised to dynamically set its SSID to match these probes in beacon frames

satisfying a major criteria for their connection. They can then accept this fake network and

automatically connect without the knowledge or interaction of the user42. This is dependent on

whether their Operating System’s Wireless connection software automatically saves and connects to

open Access points or if they manually have done so in the past.

Appendix C – Evil twin

The Evil Twin attack makes a software access point on the Raspberry Pi emulate a valid

access point SSID and MAC address, cloning itself to these identifying features. A scan is performed

in a target geographical area to identify the SSID’s of the surrounding access points, an appropriate

SSID is chosen and a software access point is initiated on the Raspberry Pi using this SSID.

Since potential victims are already associated and authenticated with this access point, the

Raspberry Pi performs de-authentications by transmitting the appropriate 802.11 management

frames to the Access point disconnecting the victims. These victims should try and automatically

reconnect to the strongest access point signal for that SSID. Wireless cards such as Alfa cards in Linux

allow for the transmission power output to be set at 1000 mWs or 2000 Mws depending on the

model, this will greatly increase the chance of success since clients automatically connect to the

strongest signal source. Then depending on their configuration and operating system version some

of victims will associate with the evil twin regardless of the lack of encryption.

41

(MACAULAY, Dino A. Dai Zovi and Shane, 2005) 42

(JOHNNY CACHE, Joshua Wright and Vincent Liu)


Appendix D – WPS reaver attack 96

Appendix D – WPS reaver attack

WI-FI Protected Setup was designed to make secure wireless setup easier to implement. This

uses a PIN created to identify devices that are to be added; when this pin is entered correctly the AP

will share the Pre-shared key with the device and complete the setup.

There is design flaw in this that allows an attacker to determine if half of the 8-digit pin is

correct. This vastly speeds up brute forcing as it can now be done in two sections. This could still

take a lot of time and not be suitable for the Raspberry Pi.43

Appendix E - Aircrack-NG Suite

Aircrack-NG is a suite of software tools for attacking and auditing wireless networks. It has

WEP/WPA cracking and analysis functionality. Aircrack-ng is the primary application in the suite that

is used for breaking the encryption of captured packets.

Airmon-NG

Allows changing a wireless interface into monitor mode or RFMON (Radio Frequency

Monitor) mode, which enables the interface to monitor all traffic from the wireless network. It is

similar to Promiscuous mode in an Ethernet network.

Airodump-ng

Allows for packet capture of the wireless traffic through the Monitor mode interface. It

displays all surrounding Access Points details such as encryption methods, the operating channel,

transmission power, packets transmitted and/or captured, ESSID of the network.

Aireplay-NG

Allows for fake attention and Associations with access points. De-authenticating other

clients from an access point. It can also be used to capture legitimate traffic destined for an access

point and replay that packet to increase amount of traffic sent from access point

Airbase-NG

Allows for the creation of a software based virtual access point, used in rouge and evil twin

attacks44.

43

(VIEHBÖCK, Stefan, 2011) 44

(OCCUPYTHEWEB, 2013)


Appendix F – SSL stripping 97

Appendix F – SSL stripping

HTTPS Stripping

Moxie Marlinspike demonstrated a HTTPS striping attack at Black Hat in 2009. It can

“transparently hijack HTTP traffic on a network, watch for HTTPS links and redirects, and then map

those links into either look-alike HTTP links or homograph-similar HTTPS links. It also supports modes

for supplying a favicon which looks like a lock icon, selective logging, and session denial”45.

Appendix G – IPtables

The filter table is the default table for any rule. It is where the bulk of the work in IPtables occurs. It

has three commonly used built-in chains. Those chains are:

• INPUT

• OUTPUT

• FORWARD

The Network Address Translation or NAT table is used to map the source or destination field

in packets. IPtables also supports hosts with a dynamic connection to the Internet with a

masquerade feature. Masquerade uses the current address on the interface for address translation.

The NAT table has two built-in chains:46

● PREROUTING chain:

NATs packets when the destination address of the packet needs to be changed.

● POSTROUTING chain:

NATs packets when the source address of the packet needs to be changed.

45

(MARLINSPIKE, Moxie, 2012) 46

(RYAN, Vincent, 2012)


Appendix H – LCD Hitachi Interface Research 98

Appendix H – LCD Hitachi Interface Research

I purchased unassembled components to create an LCD interface for the Project; I was

drawn to this controller due to its use of Python GPIO and the display real estate available compared

to the smaller models from Adrafruit.

Individual Components:


• 20 x 4 lCD Screen With Hitachi HD44780 controller

• 4 Switches


• 4 Resistors for the Switches

• Potentiometer to adjust contrast

The assembly and soldering of the components was easier than expected and functioned

correctly on the first power initialisation of the device. There was great risk in damaging the

Raspberry Pi as its GPIO pins are directly connected to its Broadcom ARM processor47.

The Raspberry Pi has a 26 pin header out of which 17 are digital GPIO pins. I will be using the

RPi.GPIO Python library to interface and control the Hitachi LCD controller through these

Input/output pins. This will be set to use the “GPIO.setmode(GPIO.BCM)” Pin numbering system for

the Broadcom Chip.48

There was also some sample python test code available for me to use as a starting point that

allowed me to check my soldering was correct and the digital lines were functioning correctly, this

code will give me great insight into the use of the GPIO and will allow me to implement my own code

quicker.49

The Hitachi HD44780 LCD controller utilizes two 8-bit registers with its micro processing unit,

an instruction register (IR) that stores instruction codes such as ‘clear display’ and memory address

information, it also has a data register (DR) which stores temporary data that is to be written or read

to Display Data Ram (DDRAM) and Character Generator Ram (CGRAM)50.

The LCD controller has the ability to display alphanumeric characters and symbols and uses

Hitachi’s 16-pin informal standard interface from which 10 pins can be used for digital

communications. It allows data to be transmitted in one Byte or two Nibble chunks, the latter being

a better option since I/O lines are scarce and 2 Lines are required for control information. So for this

project I will use 6 GPIO lines, four for data and 2 for Control.

47

(OPENMICROS.ORG, 2013) 48

([email protected]) 49

(HALL, Bruce E.) 50

HD44780.pdf



GPIO Number R-Pi LCD Pin Function

7 4 Register Select

8 6 Enable

17 11 Bit 1

18 12 Bit 2

27 15 Bit 3

22 14 Bit 4

Sending bits to the LCD needs to be timed according to the controller’s specifications; this

can vary depending on what command/function is being used. To speed up this process I will

attempt to use an estimated largest functional timing universal assignment, finding the correct

timing will require some testing. The register select allows for information to be interpreted as

commands or as normal data.

The switches will be connected to the following GPIO lines and initialised to (GPIO.IN).

GPIO Switch

4 1

23 2

10 3

9 4

The switches can easily be checked to see if there are pressed or not by returning a Boolean

value from the Specific GPIO pins involved.



Before any characters can be written to the LCD the GPIO has to be initialised as either Input

or Output and setup for the Broadcom Chip pin layout.

It also has to have the bit-mode, screen line matrix and cursor visibility set. Characters sent

to the LCD are placed at the current position of the cursor. This can be changed through hexadecimal

addressing, though changing from one line to the next utilises a strange addressing scheme.

Line Hex Dec

1 0x00 00

2 0x40 64

3 0x14 20

4 0x54 84

Executing the complete test code on the Raspberry Pi allowed me to visually confirm that

each button was functioning and that the screen was displaying characters appropriately.


Works Cited 101

Works Cited adafruit, n.d. Adrafruit RGB negative 16x2 LCD. [Online]

Available at: http://www.adafruit.com/products/1110

[Accessed 14 11 2013].

Agileintro, 2008. Agile Introduction For Dummies. [Online]

Available at: http://agileintro.wordpress.com/2008/01/04/waterfall-vs-agile-methodology/

[Accessed 14 11 2013].

Billauer, E., 2012. [Online]

Available at: http://billauer.co.il/ipmasq-html.html

[Accessed 31 12 2013].

Blais, F., 2014. Raspberry Pi control from mobile device or desktop web browser. [Online]

Available at: http://electronicsbyexamples.blogspot.ie/2014/02/raspberry-pi-control-from-mobile-

device.html

[Accessed 15 05 2014].

[email protected], n.d. Python library for GPIO access on a Raspberry Pi. [Online]

Available at: http://code.google.com/p/raspberry-gpio-python/wiki/BasicUsage

[Accessed 31 12 2013].

Chiaretta, S., 2013. How to Two-Way Bind a jQuery Mobile Flip Switch to a Knockout.js Variable.

[Online]

Available at: http://architects.dzone.com/articles/hot-two-way-bind-jquery-mobile

[Accessed 15 05 2014].

Consulting, B., 2014. Optimizing Oracle RAM for SGA & PGA. [Online]

Available at: http://www.dba-oracle.com/art_dbazine_ram.htm

[Accessed 01 04 2014].

Croston, B., 2014. RPi.GPIO Python Module. [Online]

Available at: http://sourceforge.net/p/raspberry-gpio-python/wiki/Home/

[Accessed 08 04 2014].

darkaudax, 2012. airodump-NG. [Online]

Available at: http://www.aircrack-ng.org/doku.php?id=airodump-ng

[Accessed 14 11 2013].

Dzubin, T., 2007. fping. [Online]

Available at: http://fping.sourceforge.net/

[Accessed 15 05 2014].

Flask, 2014. Flask. [Online]

Available at: http://flask.pocoo.org/

[Accessed 08 04 2014].


Works Cited 102

Flask, 2014. http://flask.pocoo.org/docs/api/#flask.g. [Online]

Available at: http://flask.pocoo.org/docs/api/#flask.g

[Accessed 15 05 2014].

Gordon, 2014. WiringPi. [Online]

Available at: https://projects.drogon.net/raspberry-pi/wiringpi/

[Accessed 08 04 2014].

Hak5, n.d. [Online]

Available at: https://wifipineapple.com/

[Accessed 14 11 2013].

Hall, B. E., n.d. http://w8bh.net/. [Online]

Available at: http://w8bh.net/

[Accessed 31 12 2013].

Hamid, R. A., 2003. Wireless LAN: Security Issues and Solutions. [Online]

Available at: http://www.sans.org/reading-room/whitepapers/wireless/wireless-lan-security-issues-

solutions-1009

[Accessed 14 11 2013].

Harding, A., 2013. Wi-Fi Client Security Weaknesses Still Prevalent as Mobile Vendors Ignore the

Issue. [Online]

Available at: https://www.sans.org/press/wi-fi-client-security-weaknesses-still-prevalent-as-mobile-

vendors-ignore-the-issue.php

[Accessed 13 05 2014].

hardkernel, 2014. ODROID-U3. [Online]

Available at: http://www.hardkernel.com/main/main.php

[Accessed 15 05 2014].

Hitachi, 2014. HD44780U (LCD-II) (Dot Matrix Liquid Crystal Display Controller/Driver). [Online]

Available at: https://www.sparkfun.com/datasheets/LCD/HD44780.pdf

[Accessed 15 05 2014].

Houghton, A., 2011. Netifaces. [Online]

Available at: http://alastairs-place.net/projects/netifaces/

[Accessed 15 05 2014].

Houghton, A., 2014. Netifaces. [Online]

Available at: http://alastairs-place.net/projects/netifaces/

[Accessed 08 04 2014].

http://wireless.kernel.org, 2014. About hostapd. [Online]

Available at: http://wireless.kernel.org/en/users/Documentation/hostapd#About_hostapd

[Accessed 15 05 2014].

Johnny Cache, J. W. a. V. L., n.d. Hacking Exposed Wireless Security Secrets and Solutions.

s.l.:McGrawHill.


Works Cited 103

Johnny Cache, J. W. V. L., 2007. Hacking Exposed Wireless Security Secrets and Solutions.

s.l.:McGrawHill.

Krenger, S., 2011. ORAPWD example. [Online]

Available at: http://www.krenger.ch/blog/orapwd-example/

[Accessed 01 04 2014].

Low, C., 2005. Understanding wireless attacks and detection. [Online]

Available at: http://www.sans.org/reading-room/whitepapers/detection/understanding-wireless-

attacks-detection-1633?show=understanding-wireless-attacks-detection-1633&cat=detection

[Accessed 21 10 2013].

Macaulay, D. A. D. Z. a. S., 2005. Attacking Automatic Wireless Network Selection. [Online]

Available at: http://www.theta44.org/karma/aawns.pdf

[Accessed 14 11 2013].

madwifi-project.org, 2014. Countrycode. [Online]

Available at: http://madwifi-project.org/wiki/UserDocs/CountryCode

[Accessed 13 05 2014].

Malinen, J., 2014. hostapd: IEEE 802.11 AP, IEEE 802.1X/WPA/WPA2/EAP/RADIUS Authenticator.

[Online]

Available at: http://w1.fi/hostapd/

[Accessed 12 04 2014].

MarlinSpike, M., 2012. SSLstrip. [Online]

Available at: http://www.thoughtcrime.org/software/sslstrip/

[Accessed 14 11 2013].

May, D., 2006. Why Oracle Works the Way it Does (9) - Server Processes. [Online]

Available at: http://it.toolbox.com/blogs/confessions/why-oracle-works-the-way-it-does-9-server-

processes-9354

[Accessed 01 04 2014].

Mezgrman, 2014. pyLCD. [Online]

Available at: https://github.com/Mezgrman/pyLCD

[Accessed 08 04 2014].

moloc, 2014. Automatic SSL Strip Log File Parsing. [Online]

Available at: http://code.google.com/p/logex/source/browse/trunk/sslogDump/src/log_ex.py?r=3

[Accessed 08 04 2014].

moloc, 2014. logex. [Online]

Available at: https://code.google.com/p/logex/

[Accessed 14 05 2014].

N.Purdy, G., n.d. Linux IPtables Packet Reference. s.l.:O'Reilly.


Works Cited 104

nikolaev, a., 2010. Latch, mutex and beyond. [Online]

Available at: http://andreynikolaev.wordpress.com/2010/08/24/exclusive-latches-in-memory-and-

traces-oracle-versions-7-11-2/

[Accessed 01 04 2014].

Nyffenegge, R., n.d. René Nyffenegger's collection of things on the web. [Online]

Available at: http://www.adp-gmbh.ch/ora/admin/password_file.html

[Accessed 01 04 2014].

occupytheweb, 2013. How to Hack Wifi. [Online]

Available at: http://null-byte.wonderhowto.com/how-to/hack-wi-fi-getting-started-with-aircrack-ng-

suite-wi-fi-hacking-tools-0147893/

[Accessed 14 11 2013].

openmicros.org, 2013. Getting Started with Raspberry Pi GPIO and Python. [Online]

Available at: http://openmicros.org/index.php/articles/94-ciseco-product-documentation/raspberry-

pi/217-getting-started-with-raspberry-pi-gpio-and-python#3

[Accessed 31 12 2013].

Poder, T., 2009. Oracle 11g: Reading alert log via SQL. [Online]

Available at: https://blog.tanelpoder.com/2009/03/21/oracle-11g-reading-alert-log-via-sql/

[Accessed 01 04 2014].

praetorian.com, 2014. Penetrating testing Services. [Online]

Available at: http://www.praetorian.com/penetration-testing/wireless-penetration-testing

[Accessed 14 11 2013].

praetorian.com, n.d. Penetrating testing Services. [Online]

Available at: http://www.praetorian.com/penetration-testing/wireless-penetration-testing

[Accessed 14 11 2013].

python.org, 2014. Sharing state between processes. [Online]

Available at: http://docs.python.org/2/library/multiprocessing.html#sharing-state-between-

processes

[Accessed 15 05 2014].

Ramachandran, V., 2013. [Hack Of The Day Episode 8] Wireless Ssid Sniffer In 10 Lines Of Python.

[Online]

Available at: http://www.securitytube.net/video/7262

[Accessed 14 11 2013].

Rocky Meza, G. W., 2014. wifi, a Python interface. [Online]

Available at: http://wifi.readthedocs.org/en/latest/

[Accessed 08 04 2014].

Rodolà, G., 2014. A cross-platform process and system utilities module for Python. [Online]

Available at: https://code.google.com/p/psutil/

[Accessed 08 04 2014].


Works Cited 105

Ryan, V., 2012. Cork Institute Of Technology Network Security.

sourceforge, 2014. http://netcat.sourceforge.net/. [Online]

Available at: http://netcat.sourceforge.net/

[Accessed 15 05 2014].

stackoverflow, 2014. stackoverflow. [Online]

Available at: http://stackoverflow.com/questions/20843486/what-are-the-limitations-

[Accessed 15 05 2014].

Stine, M., 2010. Modular Agile: Loosely coupled, highly cohesive ceremonies. [Online]

Available at: http://agile.dzone.com/articles/modular-agile-loosely-coupled

[Accessed 14 11 2013].

Teach-ICT.COM, n.d. Evolutionary protoTyping. [Online]

Available at: http://www.teach-

ict.com/as_a2_ict_new/ocr/A2_G063/331_systems_cycle/prototyping_RAD/miniweb/pg3.htm

[Accessed 14 11 2013].

The Sprawl, n.d. Airoscapy. [Online]

Available at: http://thesprawl.org/projects/airoscapy/

toggl.com, 2014. https://www.toggl.com/. [Online]

Available at: https://www.toggl.com/

[Accessed 08 04 2014].

Valentino, V., 2014. What is Metasploit EXITFUNC?. [Online]

Available at: http://www.hacking-tutorial.com/tips-and-trick/what-is-metasploit-

exitfunc/#sthash.R0B8ZPgK.G7FFIayM.dpbs

[Accessed 15 05 2014].

Viehböck, S., 2011. BruteForcing WI-FI protected Setup. [Online]

Available at: http://sviehb.files.wordpress.com/2011/12/viehboeck_wps.pdf

[Accessed 21 10 2013].

wireless.kernel.org, n.d. Wireless Operating modes. [Online]

Available at: http://wireless.kernel.org/en/users/Documentation/modes

[Accessed 21 10 2013].

Wireshark, n.d. About Wireshark. [Online]

Available at: http://www.wireshark.org/about.html

[Accessed 14 11 2013].

Wood, R., 2014. Karma. [Online]

Available at: http://www.digininja.org/karma/

[Accessed 12 04 2014].


Works Cited 106

www.aircrack-ng.org, 2014. aircrack-ng. [Online]

Available at: http://www.aircrack-ng.org/

[Accessed 14 05 2014].

Yani Dzhurov, I. K. a. S. I., 2012. Personal Extreme Programming – An Agile Process for Autonomous

Developers. [Online]

Available at: http://research.uni-

sofia.bg/bitstream/10506/647/1/S3T2009_37_YDzhurov_IKrasteva_SIlieva.pdf

[Accessed 14 11 2013].

Yani Dzhurov, I. K. a. S. I., n.d. Personal Extreme Programming – An Agile Process for Autonomous

Developers. [Online]

Available at: http://research.uni-

sofia.bg/bitstream/10506/647/1/S3T2009_37_YDzhurov_IKrasteva_SIlieva.pdf

[Accessed 14 11 2013].

Zovi, D. A. D., 2005. KARMA Wireless Client Security Assessment Tools. [Online]

Available at: http://www.theta44.org/karma/

[Accessed 15 05 2014].

LokiPi: Small form factor wireless auditing and penetration testing toolkit

Internet

Transcript of LokiPi: Small form factor wireless auditing and penetration testing toolkit