Wireless Access Points, PEAP and Radius Servers

Started looking up what it takes to use PEAP with wireless access point.

There are a bunch of parts and pieces need to put together...

RADIUS protocol ... RADIUS service on a server to auth.

http://en.wikipedia.org/wiki/RADIUS

http://www.petenetlive.com/KB/Article/0000685.htm

Note that is you use an EAP solution that incorporates a vulnerable version of SSL you will probably be subject to HeartBleed attack.

ARP cache entries - view, modify, secure

The following links go to commands to view and modify ARP cache on a machine. In order to prevent cache poisoning you might want to prevent gratuitous ARP by forcing MAC addresses for various machines.

Windows

http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/arp.mspx?mfr=true

http://m.youtube.com/watch?v=g0YUIuzmSTI

Linux

http://linux.about.com/library/cmd/blcmdl8_arp.htm

http://linux.about.com/od/lna_guide/a/gdelna50.htm

Mac

https://developer.apple.com/library/mac/documentation/Darwin/Reference/Manpages/man8/arp.8.html

GARP

Guard against gratuitous arp vulnerabilities for VOIP phones

http://www.uoverip.com/what-is-garp-gratuitous-arp-protection/

Cisco document with details about gratuitous arp

http://www.opus1.com/www/whitepapers/4500_ha.pdf

Decoding IP Header - Example

Let's take a sample IP packet header and see what's in it. Here's our sample random IP header pulled out of WireShark traffic:

45 20 01 b4 96 25 40 00 39 06 60 6a 5d b8 d7 c8 0a 01 0a 13

A packet is between 20-60 bytes and a length greater than 20 means we have options. So how long is this packet?

Each hexadecimal character is four bits and 8 bits = a byte, so every two characters is one byte.So let's count the bytes:

45	20	01	b4	96	25	40	00	39	06	60	6a	5d	b8	d7	c8	0a	01	0a	13
1	2	3	4	5	6	7	8	9	10	11	12	13	14	15	16	17	18	19	20

Ok looks like we have a 20 byte header so there are no options.

We'll need a couple things for our translation -- the cheat sheets in my last post to convert hex to binary and decimal:

http://websitenotebook.blogspot.com/2014/05/hexadecimal-to-binary-to-decimal-cheat.html


Also the layout for the IPv4 header in this post which tells us the purpose of the hex values in the various positions:

http://websitenotebook.blogspot.com/2014/03/ip-internet-protocol_1.html

Byte 1 (45)

The first two numbers are always the version and header length.

4 in hex = version 4  (IPv4) which is the default version.

5 is the length. 5 in hex = 5 in decimal and it's a quad number so we multiply by 4 to get our length = 20 (confirms our analysis above).

Byte 2 (20)

Byte 2 is 20. This is Type of Service. Going to skip this one for now as most routers ignore

Bytes 3-4 (01 b4) 

This is the datagram length (header + payload)

So the binary version of this, using our cheat sheet in prior post is:

0 0 0 0 0 0 0 1 1 0 1 1 0 1 0 0

We've got 1's in positions: 2, 4, 5, 7, 8

We grab the decimal values for these and add them up:

4 + 16 + 32 + 128 + 256 = 436

Yep, that matches up with Wireshark so cool.

Bytes 5-6 (96 25)

This is our unique id - it should be a random number so not going to bother translating this one righht now. Might be important if you want to verify randomness.

Next 4 bits - flags (4)

We need to turn this value into 4 bits to determine our flags.

Binary version of 4 is:

0 1 0 0

That means we have one flag set - 1 indicates datagram may be fragmented, however the next bit indicates no more fragments exist.

Next 12 bits (0 0 0)

This is our fragment offset. Although the packet says it may be fragmented, the flag to indicate no more fragments was set as noted and the fragment offset of this packet is 0 so seems like there is only one packet.

Next byte (39)

Next byte is time to live.  39 in hex translated to binary:

0 0 1 1 1 0 0 1

We've got values in positions: 0, 3, 4, 5 - grab the decimal values:

1 +  8 + 16 + 32 = 57

Cool - matches Wireshark again.

1 byte for the protocol (06)

Translate to binary

0 0 0 0 0 1 1 0

Translate to decimal - positions 1, 2

2 + 4 = 6

Take a look at our nifty protocol chart:

#	protocol
1	ICMP
2	IGMP
6	TCP
9	IGRP
17	UDP
47	GRE
50	ESP
51	AH
57	SKIP
88	EIGRP
89	OSPF
115	L2TP

Looks like we have TCP (#6).

Next 2 bytes (60 6a)

This is our checksum. Equipment uses this to verify nothing has inadvertently changed.

4 bytes  (5d b8 d7 c8)

Source address

We need to figure out if we have a Class A, B or C IP address to know which bytes refer to network and which bytes refer to host in the address.

A - one byte for network, three bytes for host
B - two bytes for network, two bytes for host
C - three bytes for network one byte for host

Look at first number to determine if class A, B or C:

1-127 = A
128-191 = B
192-223 = C

Each byte is part of address with dot (.) in between (dotted notation)

5d = 0 1 0 1 1 1 0 1 = positions = 0, 2, 3, 4, 6 = 1 + 4 + 8 + 16 + 64 = 93
b8 = 1 0 1 1 1 0 0 0 = positions = 3, 4, 5, 7 = 8 + 16 + 32 + 128 = 184
d7 = 1 1 0 1 0 1 1 1 = positions = 0, 1, 2, 4, 6, 7 = 1 + 2 + 4 + 16 + 64 + 128 = 215
c8 = 1 1 0 0 1 0 0 0 = positions = 3, 6, 7 = 8 + 64 + 128 = 200

So we have a class A address (93).

Address is 93.184.215.200

We can look that up at ARIN.net...but wait...it's a RIPE address?? Not sure why a computer on my network is connecting to a European address...but that's a topic for http://randominternet.blogspot.com

inetnum:         93.184.212.0 - 93.184.215.255
netname:         EDGECAST-NETBLK-03
descr:           NETBLK-03-EU-93-184-212-0-22
country:         EU
admin-c:         DS7892-RIPE
tech-c:          DS7892-RIPE
status:          ASSIGNED PA
mnt-by:          MNT-EDGECAST
source:          RIPE # Filtered

4 bytes (0a 01 0a 13)

Destination address

Same concept as above.

Hexadecimal to Binary to Decimal - Cheat Sheet

I'm studying hexadecimal to decimal conversions for packet header analysis (IP, TCP, UDP, etc).

Trying to come up with a cheat sheet to make the whole thing easier to remember.

First of all each numbering system has a single character representing each possible single digit value. After these values are used up you start tacking these single digits together to come up with bigger values.

For example the single digit values for each of the following numbering systems are:

Binary = base 2 = 0, 1
Decimal = base 10 = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
Hexadecimal = base 16 = 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, A, B, C, D, E, F

In the list of characters above for hexadecimal the letters are just a way to use a single character for a two digit decimal number. So our 16 base numbers are 0-15 and we use letters for 10-15 (which are 2 digit numbers) as follows:

A = 10
B = 11
C = 12
D = 13
E = 14
F = 15

So why the heck are we making this all complicated and using these crazy numbering schemes instead of the decimal numbering system we know and love? Computers need a way to store and represent numbers. They don't have fingers. They have circuits. (I'm probably way over-simplifying this - intentionally) These [Boolean] circuits can either be on or off. I like to think of it as a row of light switches. Flip some of them on, some of them off. On is represented as 1 and off is represented as 0.

So let's say you had a row of 4 light switches and starting from right to left, first is off, second is on, third is on, fourth is off. That would look like:

0 1 1 0

The light switches on or off allow you to represent a binary number. So what's that binary number in decimal? Binary is base 2. For each position that has a 1, we take the value of the position (starting with position 0) to the power of 2 and add up the results to get the decimal number. So we have in this case positions: 3, 2, 1, 0. Position 1 and position 2 have a value, position 0 and position 3 don't so:

(0) + (2²) + (2¹) + (0) = 0 + 4 + 2 + 0 = 6

So 0 1 1 0 in binary (or circuits in a computer turned on and off) = 6 in decimal

So what's hexadecimal for anyway? It takes less space to represent a hexadecimal number where a single hexadecimal digit can represent four binary digits. In other words instead of representing 15 as 1 1 1 1 we can just use F. Hexadecimal is used instead of decimal because 10 is not a value that comes from 2^x, so it's not easy to translate a series of 1's and 0's to base 10.

In computer terminology each single digit of storage (circuit on or off, i.e. 1 or 0) is a called a "bit". 8 bits = a "byte". 4 bits = half a byte or a"nibble". (har har)

One hexadecimal character is 4 bits (with a 1 or a 0 in each spot). If you think about it, it makes sense. Turn all four bits on (1) and calculate the decimal number:

1 1 1 1

or: (2³ = 8) + (2² = 4) + (2¹ = 2) + (2⁰ = 1) = 15 (counting from 0 to 15 = 16 digits).

We can turn that single four digit binary number into a 1 digit hexadecimal number and store 1 digit instead of 4

Ok now we want to take a hexadecimal digit and convert it to decimal. So let's take 6, for example.

We'll have four bits to represent 6.

_ _ _ _

OK so for each of those spots we have to either put in a 1 or a 0 as required to represent a 6. If each of those slots represents a binary value and if each spot were filled with a 1 we'd have these decimal values for each corresponding position (again 2⁰, 2¹, etc.):

8 4 2 1

Ok so how do we come up with 6? 4 + 2. So the slots for 4 and 2 are set to 1 and the slot for 1 and 8 are set to 0. That gives us binary 6:

0 1 1 0

Let's try D. D in hexadecimal = 13 in decimal as shown above. We will need the slots to have 1 for positions 4, 3 and 1 (8 + 4 + 1) so binary digit D is represented as:

1 1 0 1

Now we can look at this another way to come up with our cheat sheet. We know the decimal value of each hexadecimal digit above. We can map out the binary to hex translation in a table like this:

Hex		Binary
0		0 0 0 0
1		0 0 0 1
2		0 0 1 0
3		0 0 1 1
4		0 1 0 0
5		0 1 0 1
6		0 1 1 0
7		0 1 1 1
8		1 0 0 0
9		1 0 0 1
A (10)		1 0 1 0
B (11)		1 0 1 1
C (12)		1 1 0 0
D (13)		1 1 0 1
E (14)		1 1 1 0
F (15)		1 1 1 1

It will also be helpful to memorize or table-ize the values of each binary position for our translations from hex to decimal. For each position in a binary number there is a corresponding decimal number which is (2^[position]) or 2^position. We know already that position 0 = 1 (2⁰), position 1 = 2 (2¹), position 2 = 4 (2²) and position 3 = 8 (2³). Our full table for 16 positions could look like this where each subsequent value doubles the value in the prior position:

Position	Decimal
0	1
1	2
2	4
3	8
4	16
5	32
6	64
7	128
8	256
9	512
10	1024
11	2048
12	4096
13	8192
14	16384
15	32768

Ok now let's say we have some crazy looking Hexadecimal number that looks like this: 

AE06

First of all we know there are four bits for each hex digit:

_ _ _ _ | _ _ _ _ | _ _ _ _ | _ _ _ _

Now as above we know that for each four slots we'll have 8 6 4 2 as the decimal representation of 1 1 1 1. So let's translate that crazy hex number into binary one character at a time.

A = 10 as shown above and in our chart we see that is 1 0 1 0.
E = 14 and that is 1 1 1 0
0 = 0 and that is 0 0 0 0
6 = 6 and that is 0 1 1 0

Put that all together and what does it spell?! Ok I'll get out of cheerleader mode now.

1 0 1 0 1 1 1 0 0 0 0 0 0 1 1 0

What do we do with that?? Well we know that it's base 2 so for each digit we calculate 2^position and add up the result. So we have a 1 in positions (starting with position 0 on the right): 1, 2, 9, 10, 11, 13, 15.

We can grab the decimal value for each of those binary digit positions from the above binary position to decimal table and add them up:

2 + 4 + 512 + 1024 + 2048 + 8192 + 32768 = 44550

We can check that calculation on the handy dandy Windows calculator. Open it up and choose "programmer" from the view menu. Click on the "hex" radio button. Enter AE06. Then click on the decimal radio button. Yay it worked! I'm typing this all up from scratch and I guess I got it figured out.

Hopefully having the translation cheat sheets above will help in a pinch, or can go the route of memorizing all of the above - kind of like my parents used to grill into me and their grade school students to learn their math facts :)

Related - Translating IP headers (and UDP, TCP, etc. not mentioned in the post below) from Hex to meaningful values humans can understand - I'm assuming here most people don't speak hex.

http://websitenotebook.blogspot.com/2014/03/ip-internet-protocol_1.html

Key Management Systems & Cloud Encryption

Listening to SANS cryptography session. I've always wondered why there is so much focus on secure code for encryption but not a lot of discussion about key management. I've blogged and tweeted about this mystery in the past and caveat about the first link - I'm digging into cryptography a bit more right now and may be revising:

http://websitenotebook.blogspot.com/2009/05/java-encryption_24.html

http://websitenotebook.blogspot.com/2010/10/securing-encryption-keys.html

http://websitenotebook.blogspot.com/2014/03/encryption-protecting-key.html

Data needs to be protected at rest, in transit and protect the key. If you fail at any one of these your encryption is useless. A lot of people understand the first two. The third is often overlooked and possibly most important, because a short key length still takes some time to hack, but keys out in the open mean you might as well hand the data to the adversary.

Oh and about the "well it's on our internal network behind the firewall" argument, I hope anyone involved in a corporation of any size that is utilizing pen testing services and/or has been breached understands by now this is a completely naïve viewpoint. I used to have to argue with network admins at managed data centers who didn't want to set my outbound traffic firewall rules. Now outbound traffic is one of the primary ways for determining if you're hacked since all malware calls home. APTs have attackers infiltrating systems throughout corporate networks. If they get access to your data you want to have the keys that decrypt that data in a separate place.

So now that we understand that even if our key is in our own house we need to separate it from the data and protect it from people who might get access to the encrypted data, how and where do we store and manage the keys?

We need to store them away from the data, make them accessible to the applications that need to decrypt the data, protect the data in transit and rest (and in memory for things like credit cards on POS machines...)

There are conceptual discussions of protecting the key, and I understand you should put your key on a separate server, away from your data. But what is the best way to actually implement this solution?  What about protecting keys in conjunction with using a cloud provider where you want to protect your keys and have them completely managed by someone other than the cloud provider so anyone that gets access to your encrypted data in the cloud cannot access the keys?

One of the quandaries I have with using these vendors is the Trojan horse concept. If you're keys are the absolute most critical thing you need to protect because they provide access to all your data, giving your keys to a third party system is a bit scary.

One thing would be to make sure very limited amount of people have access to the keys. Additionally through separation of duties you can make sure the same people who manage the keys do not have access to the encrypted data. But how do you actually implement that?

I remember from a business school class a company that outsourced production of certain products to China. Their approach was to have different companies to produce different parts with no single company having access to the complete formula. Perhaps such an approach would work with key management, similar to multi-factor authentication. In order to decrypt you need multiple pieces of information. Of course this adds overhead to processing and slows things down.

The other issue is actually limiting access. After my first graduate degree in software engineering in 2000 I went out to look at technology for a couple of venture capital firms. I didn't have much security knowledge at that point but I remember going to look at some technology from a company one of the VCs was considering for investment. A Russian guy proudly explained how they were able to bypass corporate firewalls by tunneling through SSL ports. This freaked me out somewhat. If these guys can tunnel through an SSL channel which is supposed to be for SSL and completely bypass the firewall, it made the firewall kind of useless. I didn't understand all the ins and outs of networks, ports, packets, etc. at that point but I thought: what's the point of blocking all these ports if someone can use any old port to get into your network?

So clearly blocking access to your keys by just adding firewall rules for ports is not enough. You'll need authentication to limiting access to only specific IP addresses, authorized users and servers and you have to make sure no one can get into the servers, IP addresses or insert a man in the middle attack because then they can tunnel through to your key management store.

Obviously a number of layers of security are needed at different levels to protect your keys and make sure the only applications that should access those keys can get to them to decrypt only the data to which they should have access. There are complications with unencrypted data in memory as well. Thinking about the way SSL VPNs work - they download a thin client and everything runs in an encrypted RAM drive. Maybe something like that could be used for corporate applications running in the cloud.

Going to great lengths to encrypt every piece of data and protect it in every possible way can get very expensive and slow down system performance. Perhaps a better approach is to limit the risk of exposure to a reasonable degree, and add additional layers of detecting any malicious or unauthorized activity. Detection in this day and age of APTs and complexity which can be mind boggling at times, I would argue, is more important than prevention and have mentioned that in my own company in terms of auditing financial systems for data errors. This viewpoint was confirmed in SANS 401 class I took which has the motto: "Prevention is Ideal, detection is a must". So perhaps you limit your exposure and add a lot of auditing and alerts for unexpected activity.

I'm currently listening to Diffe-Hellman key exchange from SANS 401 (sans.org) which operates under the concept of asymmetric encryption and being able to do key exchange in the presence of an adversary. Being able to utilize vendor systems that can provide amazing value in terms of innovation, reduced time to market, segregation, fault tolerance, scalabilty and performance - without - a capital expenditure while minimizing the risk of loss of intellectual property, NPI data and credit cards at the same time is an interesting problem.

For the moment I'll be going through this list of vendors that have key management systems (from Wikipedia) and reading a few books on the matter ... to be continued (I know the suspense is killing you).

http://en.wikipedia.org/wiki/Key_management

• Bell ID Key Manager
• Cryptsoft KMIP C and Java Servers
• Gazzang zTrustee
• HP Enterprise Secure Key Manager
• IBM Enterprise Key Management Foundation
• IBM Tivoli Key Lifecycle Manager
• KEYper Systems
• Oracle Key Manager
• Porticor Virtual Private Data
• RSA Data Protection Manager
• Safenet Enterprise Key Management
• SSH Communications Security Universal SSH Key Manager
• Thales Key Management
• Townsend Security Alliance Key Manager
• Unitech Power Technology Co. Smart Key Cabinet
• Venafi Encryption Director
• Vormetric

Maybe we can get a panel from these vendors to do a presentation at an upcoming Seattle AWS Architects and Engineers meet up:
http://www.meetup.com/Seattle-AWS-Architects-Engineers/

AWS NoSQL Event

Gartner says Amazon has 5 times amount of compute power than next 18 cloud providers combined.

Pace of innovation increases when increase deployment iterations and reduce the risk.

AWS builds custom servers. Optimized performance and 30% off the cost compared to private cloud purchasing servers from vendors.

DynamoDB gives you NoSQL with consistent (as opposed to eventually consistent) reads.

Because Amazon has built so many data centers they are obtaining expertise and getting better at it.

The success of Amazon is based on a big way on a distibuted model of teams who manage their own technology [and interact through services based through a blog post I read].

Scaling SQL databases is easy - partition the database. The problem is repartitioning the data while taking on new traffic. Initially Amazon avoided by buying bigger boxes

Then....

Amazon wrote a paper on Amazon Dynamo, highly available key-value store.

Distributed hash table.

Trade-off consistency for availability.

Allowed scalability while taking live traffic.

Scaling was easier but still required developers to benchmark new boxes, install software, wear pagers, etc.

Was a library, not a service.

Then...

DynamoDB: a service.

- durability and scalability

- scale is handled (specify requests per second)

- easy to use

- low latency

- fault tolerant design (things fail - plan for it)

At Amazon when talk about durability and scalability always go after three points of failure for redundancy.

Quorum in distibuted systems

http://en.m.wikipedia.org/wiki/Quorum_(distributed_computing)

DynamoDB handles different scenarios of replica failures so developers can focus on the application.

SimpleDB has max 10 GB and customer has to manage their own permissions.

Design for minimal payload, maximum throughput.

Can run map reduce jobs through DynamoDB. EMR gives Hive on top of DynamoDB.

Many AWS videos and re:invent sessions on AWS web site.

HasOffers uses DynamoDB for tracking sessions, deduplication.

Session tracking is perfect for NoSQL because look everything up by a single key: session id.

Deduplication: event deduplication.

Fixing DynamoDB problems ... Double capacity, maybe twice, fix the problem, drop the capacity

Being asynchronous and using queues is nice option.

Relational databases are more flexible for querying. Something to consider when determining whether you want to use RDBMS or NoSQL.

---

Hash key is single key. Can also have combo key.

Hash key = distribution key

Optimal design = large number of unique hash keys + uniform distribution across hash keys.

Important to pick hash key with large cardinality.

Range key: composite primary key - 1:N relationships. Optional range condition. Like == < > >= <=

e.g.customer id is hash key and range key is photo id

Local secondary indexes. e.g. Two customers share a key. Requires more throughput capacity.

Hash + Range must be unique

Data types supported: string, number, binary and sets of the three.

Cannot add or change secondary indexes after initial creation of table...may be coming.

Global secondary indexes are separate tables asynchronously updated on your behalf. GSI lookup is eventually consistent. May require one or more updates.

Local secondary index = max 10 GB per hash key. May be a reason to move to GSI.

GSI has it's own provisioned reads and writes whereas LSI's use provisioned table reads and writes. 

1-1 relationship: hash key and secondary index

1-Many index: hash key and range key

NoSQL - no transaction support in DynamoDB

Can only double throughput when changing. Amazon looking at changing this.

Choosing the right data store:

SQL: structured data, complex queries, transactions.

NoSQL: unstructured data, easier scaling

DataPipeline automates moving between data stores.

A client only app is available which emulates DynamoDB to develop without paying AWS fees.

OSI and TCP Model - Network Layers

Studying for GAIC and just seeing if I can write these from memory.

We use the OSI model to talk about network layers and the TCP/IP model to implement.

OSI Model

(P)lease (D)o (N)ot (T)hrow (S)ausage (P)izza (A)way

Physical layer (layer 1) - transmission of raw binary data (0's and 1's). Typically via electrical (Ethernet), Radio Frequency (Wireless) or photo optics (Fiber).

Data Link Layer (layer 2) - Switches typically operate at this layer. This is the logical layer - where the data has meaning as opposed to raw binary data.

Network Layer (layer 3) - routing layer - where most routers operate and determine the path the data will take through the network. Some switches, referred to routing switches, operate at this layer.

Transport Layer (Layer 4)  - packages and orders data as it flows through the network.

Session Layer (Layer 5) - virtual connection between two points for transmission of data.

Presentation Layer (Layer 6) - transforms the data into machine independent data that can be read by any computer, whether big endian (left to right) or little endian (right to left).

Application Layer (Layer 7) - the layer that handles providing particular needed network services to the application (HTTP, FTP, etc.)

The TCP/IP Model

The TCP/IP Model has four layers but some layers are just a combination of the above layers. There are still 7 layers we just group them together in the TCP/IP model as follows:

Network - Layers 1 and 2
Internet - Layer 3
Transport - Layer 4
Application - Layer 5, 6, 7

Devices & Tools

NICs operate in Layer 1 and Layer 2, handling transmission of binary data via ethernet, token ring, wireless.

Sniffers operate at layer 2.

Switches natively operate at layer 2 though some have layer 3 routing capabilities and blade systems may allow for firewall.

Routers operate at layer 3. They use the IP to determine which network to go next but use ARP, routing tables and MAC addresses to get the packet from one hop to the next.

Firewalls operate at layer 3 or layer 4.

---

Not too shabby. Didn't have to look anything up :)

On to header analysis and protocols.

More...