Monday, 9 January 2012

Facebook oAuth with PHP

Well one project we have been working on is SSO using facebooks oAuth model, this is the mechanism used to allow users to be authenticated on your own website using the Facebook app API.

This is a great API, and from scratch took about 2 days to reverse engineer and use, this system will be going live shortly on www.planettectnews.com also we have been working on some social media bolt ons.  So the nerdy stuff.

How the flow works, well first of all you click the signin with facebook link, this takes you to facebook if you haven't signed in and asks you to sign in, if your already signed in it goes straight to the APP dialogue.  At this stage you get the usual facebook wants to share your details with such and such app.  When you accept facebook fires a token to a PHP controller that i have written.  This in turn saves the token for use whenever needed.

The first stage now is the controller does a cURL to facebook using the token ID to get a me.js response, using JSON this is carved to useful information and this is stored in a database, a local user is created to incorporate the existing authentication model.

A second cURL using a post fires the new user details at the existing authentication model logging the user in, the local user account based on the facebook details can be synchronised at any stage using the token in an 'offline' poll.

That simples.

The twitter SSO API is scarey familiar using the same UML flow.

Sunday, 13 September 2009

IP Spoofing: An Introduction

Something I was reading that i have found interesting so i thought i would add the article on here.

Criminals have long employed the tactic of masking their true identity, from disguises to aliases to caller-id blocking. It should come as no surprise then, that criminals who conduct their nefarious activities on networks and computers should employ such techniques. IP spoofing is one of the most common forms of on-line camouflage. In IP spoofing, an attacker gains unauthorized access to a computer or a network by making it appear that a malicious message has come from a trusted machine by “spoofing” the IP address of that machine. In this article, we will examine the concepts of IP spoofing: why it is possible, how it works, what it is used for and how to defend against it.

History
The concept of IP spoofing, was initially discussed in academic circles in the 1980's. While known about for sometime, it was primarily theoretical until Robert Morris, whose son wrote the first Internet Worm, discovered a security weakness in the TCP protocol known as sequence prediction. Stephen Bellovin discussed the problem in-depth in Security Problems in the TCP/IP Protocol Suite, a paper that addressed design problems with the TCP/IP protocol suite. Another infamous attack, Kevin Mitnick's Christmas Day crack of Tsutomu Shimomura's machine, employed the IP spoofing and TCP sequence prediction techniques. While the popularity of such cracks has decreased due to the demise of the services they exploited, spoofing can still be used and needs to be addressed by all security administrators.

Technical Discussion
To completely understand how these attacks can take place, one must examine the structure of the TCP/IP protocol suite. A basic understanding of these headers and network exchanges is crucial to the process.

Internet Protocol – IP
Internet protocol (IP) is a network protocol operating at layer 3 (network) of the OSI model. It is a connectionless model, meaning there is no information regarding transaction state, which is used to route packets on a network. Additionally, there is no method in place to ensure that a packet is properly delivered to the destination.

Examining the IP header, we can see that the first 12 bytes (or the top 3 rows of the header) contain various information about the packet. The next 8 bytes (the next 2 rows), however, contains the source and destination IP addresses. Using one of several tools, an attacker can easily modify these addresses – specifically the “source address” field. It's important to note that each datagram is sent independent of all others due to the stateless nature of IP. Keep this fact in mind as we examine TCP in the next section.

Transmission Control Protocol – TCP
IP can be thought of as a routing wrapper for layer 4 (transport), which contains the Transmission Control Protocol (TCP). Unlike IP, TCP uses a connection-oriented design. This means that the participants in a TCP session must first build a connection - via the 3-way handshake (SYN-SYN/ACK-ACK) - then update one another on progress - via sequences and acknowledgements. This “conversation”, ensures data reliability, since the sender receives an OK from the recipient after each packet exchange.

As you can see above, a TCP header is very different from an IP header. We are concerned with the first 12 bytes of the TCP packet, which contain port and sequencing information. Much like an IP datagram, TCP packets can be manipulated using software. The source and destination ports normally depend on the network application in use (for example, HTTP via port 80). What's important for our understanding of spoofing are the sequence and acknowledgement numbers. The data contained in these fields ensures packet delivery by determining whether or not a packet needs to be resent. The sequence number is the number of the first byte in the current packet, which is relevant to the data stream. The acknowledgement number, in turn, contains the value of the next expected sequence number in the stream. This relationship confirms, on both ends, that the proper packets were received. It’s quite different than IP, since transaction state is closely monitored.

Consequences of the TCP/IP Design
Now that we have an overview of the TCP/IP formats, let's examine the consequences. Obviously, it's very easy to mask a source address by manipulating an IP header. This technique is used for obvious reasons and is employed in several of the attacks discussed below. Another consequence, specific to TCP, is sequence number prediction, which can lead to session hijacking or host impersonating. This method builds on IP spoofing, since a session, albeit a false one, is built. We will examine the ramifications of this in the attacks discussed below.

Spoofing Attacks
There are a few variations on the types of attacks that successfully employ IP spoofing. Although some are relatively dated, others are very pertinent to current security concerns.

Non-Blind Spoofing
This type of attack takes place when the attacker is on the same subnet as the victim. The sequence and acknowledgement numbers can be sniffed, eliminating the potential difficulty of calculating them accurately. The biggest threat of spoofing in this instance would be session hijacking. This is accomplished by corrupting the datastream of an established connection, then re-establishing it based on correct sequence and acknowledgement numbers with the attack machine. Using this technique, an attacker could effectively bypass any authentication measures taken place to build the connection.

Blind Spoofing
This is a more sophisticated attack, because the sequence and acknowledgement numbers are unreachable. In order to circumvent this, several packets are sent to the target machine in order to sample sequence numbers. While not the case today, machines in the past used basic techniques for generating sequence numbers. It was relatively easy to discover the exact formula by studying packets and TCP sessions. Today, most OSs implement random sequence number generation, making it difficult to predict them accurately. If, however, the sequence number was compromised, data could be sent to the target. Several years ago, many machines used host-based authentication services (i.e. Rlogin). A properly crafted attack could add the requisite data to a system (i.e. a new user account), blindly, enabling full access for the attacker who was impersonating a trusted host.

Man In the Middle Attack
Both types of spoofing are forms of a common security violation known as a man in the middle (MITM) attack. In these attacks, a malicious party intercepts a legitimate communication between two friendly parties. The malicious host then controls the flow of communication and can eliminate or alter the information sent by one of the original participants without the knowledge of either the original sender or the recipient. In this way, an attacker can fool a victim into disclosing confidential information by “spoofing” the identity of the original sender, who is presumably trusted by the recipient.

Denial of Service Attack
IP spoofing is almost always used in what is currently one of the most difficult attacks to defend against – denial of service attacks, or DoS. Since crackers are concerned only with consuming bandwidth and resources, they need not worry about properly completing handshakes and transactions. Rather, they wish to flood the victim with as many packets as possible in a short amount of time. In order to prolong the effectiveness of the attack, they spoof source IP addresses to make tracing and stopping the DoS as difficult as possible. When multiple compromised hosts are participating in the attack, all sending spoofed traffic, it is very challenging to quickly block traffic.

Misconceptions of IP Spoofing
While some of the attacks described above are a bit outdated, such as session hijacking for host-based authentication services, IP spoofing is still prevalent in network scanning and probes, as well as denial of service floods. However, the technique does not allow for anonymous Internet access, which is a common misconception for those unfamiliar with the practice. Any sort of spoofing beyond simple floods is relatively advanced and used in very specific instances such as evasion and connection hijacking.

Defending Against Spoofing
There are a few precautions that can be taken to limit IP spoofing risks on your network, such as:
Filtering at the Router - Implementing ingress and egress filtering on your border routers is a great place to start your spoofing defense. You will need to implement an ACL (access control list) that blocks private IP addresses on your downstream interface. Additionally, this interface should not accept addresses with your internal range as the source, as this is a common spoofing technique used to circumvent firewalls. On the upstream interface, you should restrict source addresses outside of your valid range, which will prevent someone on your network from sending spoofed traffic to the Internet.
Encryption and Authentication - Implementing encryption and authentication will also reduce spoofing threats. Both of these features are included in Ipv6, which will eliminate current spoofing threats. Additionally, you should eliminate all host-based authentication measures, which are sometimes common for machines on the same subnet. Ensure that the proper authentication measures are in place and carried out over a secure (encrypted) channel.

Conclusion
IP Spoofing is a problem without an easy solution, since it’s inherent to the design of the TCP/IP suite. Understanding how and why spoofing attacks are used, combined with a few simple prevention methods, can help protect your network from these malicious cloaking and cracking techniques.

Matt Tanase is President of Qaddisin. He and his company provide nationwide security consulting services. Additionally, he produces The Security Blog, a daily weblog dedicated to network security.

Thursday, 23 July 2009

Why is Exchange Store.exe so RAM hungry?

This seems to be one of most favorite questions ever: "How come that Exchange Store.exe keeps on grabbing more and more memory, even on the server that is not very busy? Is there a memory leak?". This is many times followed by "I am rebooting my server on the weekly basis to keep store memory consumption in check".

Well, let's see what we have here.

It is absolutely normal for Store.exe to grab as much RAM on the server as it can possibly get - as long as Store thinks it needs it to optimize performance. Store was written to do so. It does this as it wants to do as much stuff in memory as possible, without having to go to the slow page file. It is a common misconception - that Store.exe's increasing memory consumption is a "memory leak". This behavior is expected since Exchange 5.5 days:

182505 XADM: Memory Usage of Store.exe Is Higher in Exchange 5.5
http://support.microsoft.com/?id=182505

That being said:

1. Exchange Store will grab as much RAM as it can if it thinks it needs it, yes. But - we constantly monitor the performance of the system in regards to memory usage and we can use this data to infer when we need more memory and when other applications or the OS needs more memory. We then use this data to act accordingly. This scheme allows the system to act as if there is explicit control when in fact it is actually a few autonomous applications cooperating in a disconnected manner. That means that we should NEVER see a "out of memory" message by any application on the server because of the Store - unless there is a leak on the server, of course... or the page file is too small. If there was a malfunction in this Store mechanism it would cause a lot of paging. That is a big performance problem, but shouldn’t cause actual errors.

2. Store memory utilization can go up to 1.2 GB or sometimes even more when viewing through Task Manager. I have not seen it go over 1.5 GB, but it would typically not take more, even if there is 8 GB of RAM in the machine. So - Store taking 1.2 GB is not an indication of the problem all by itself.

3. Exchange Store is not the only product behaving like this... SQL does something very similar, for example. That is one of reasons why we do not necessarily encourage putting SQL and Exchange on the same server, as they will be fighting over whatever RAM is in the server.

All of the above being said, let's go into what can be manifestations of real problems:

- Are there actual performance problems that might be related to store taking up RAM? For example, other services on the server slow down noticeably when store gets "large", events are logged in the application / system log mentioning lack of memory?

- Does client access to the server slow down when Store.exe grabs a lot of RAM?

- Are there any "out of memory" errors on the server at all? Popups when trying to start applications/services on the server?

If not - there is most likely no problem. Again - Store.exe taking up a lot of RAM is NOT a problem on it's own, as the memory can be returned to the OS when needed by other processes. Store is simply taking advantage of the RAM - as it is in the machine :)

One more note - if Exchange 2003 SP1 is applied to the server and you used to monitor Store memory utilization, you could be seeing an increase in memory consumption unless you change the monitoring settings. This is normal and is covered in more detail here:

867628 Monitoring programs report that the Store.exe process consumes
http://support.microsoft.com/?id=867628