In this article we explain how to increase your security posture against online spoofing.

1. Marc-Andre Heroux, CGEIT, CISA, CRMA, CRMP, ABCP, CISSP, NSA-IAM, NSA-IEM
LinkedIn: http://ca.linkedin.com/in/herouxma
Twitter: @herouxma | IRC: herouxma on irc.freenode.net
There are many types of
spoofing attacks online
In this article we explain how to increase your security
posture against online spoofing
Date: May 16th, 2014
Draft Version
1
Online Authentication
Federated information technology systems

2. Prerequisites
• In this presentation, the clients and servers were
not compromised;
• for critical Web applications, all communications
must be in a tunnel (ex.: VPN);
• for critical activities accessing sensitive
information, using a RSA Secure ID is strongly
suggested;
• all exchanges must be done with the corrected
SSL if not in a tunnel.
2

3. Validating against a server, a nonce at layer 5 can prevent:
CSRF and spoofing (ex.: SAML).
Web servers cluster
Identity Provider (IdP)
If authentication successful (receive secret)
Receive requests based on a secret
Verify and validate
Secret (ex.: SAML ID)
Use Web Application
Directory (ex.: secure LDAP)
1
2
3
4
Deliver authorized content6
Server validation (SAML)
Threat Agent
Sends email with malicious codes and conduct
various external attacks from layer 3 to 7.
3
JavaScript/Ajax
Authentication
Hijacking
5

4. ● Comparing server generated nonce vs nonce submitted in hidden HTML
form field value is also considered a good practice;
● then we have Web authentication as follow: something you receive from
web server (nonce) and something you send to web server as a client
(nonce).
Server validation (CSRF)
Threat
Web Server
SAML TTL
Web Server
Read cookie
SAML ID
Cookie in
browser
Web
Brower
Nonce
hidden field
Malicious code sent in custom
form and post to Web server
1. The attacker doesn’t know
the nonce;
2. The attacker can’t guess the
nonce;
3. The attacker cannot send the
nonce in a hidden field;
4. Server or WAF reject the
post.Confidentiality, integrity and accessibility of
the SAML ID
1. The IdP must always be available so well
protected (hardened, monitored, etc.);
2. The ID can be retrieve in header by a
Man-in-the-middle attack (VPN and
correct SSL can protect);
3. The ID must be long enough and not be
guessable;
4. The ID must be compared between Web
server and IdP before authorizing access.
Likelihood of the attack
If the SAML ID is compromised:
1. The attacker will gain access to your Web
application for the time-to-live of the
SAML ID;
2. If the IdP or the LDAP server are
compromised, the overall solution is
compromised;
3. To prevent a complete take over of your
infrastructure by an attacker, never use a
critical account without a RSA Secure ID.
Compare nonce
post vs set by
server
Success
4
Cookie

5. Subject and object: always make sure to identify
and authenticate your subject or your object and
provide proper authorization to reduce potential false
negative results and security incidents;
JavaScript/AJAX: can be easily injected and you
cannot rely on it without server validation (ex: IdP);
The cookie: name and values must not be
guessable or stealable;
The maximum cookie size: about 4K.
Few basics principles
5

6. Among others, when using cookies its
important to follow these principles:
• Limit the amount of sensitive information stored in the cookie;
• Limit the subdomains and paths to prevent interception by
another application;
• Enforce SSL so the cookie isn’t sent in cleartext;
• Use values hard to guess (name, IDs, etc.) and set expiration
value (the more critical, the shorter);
• Make the cookie HttpOnly so its not accessible to javascript.
6
Who stole my cookies?

7. If form hidden nonce value different than server nonce set for
current client session, it's a threat;
if SAML ID in header is different than server xml http request
result of ID stored @identity server provider, a threat tried to
forged the SAML ID;
else, the context can be considered acceptable.
Exemple of a SAML ID:
<saml:Assertion ID="_b07b205c-7c29-gr16-4300-5f3e6f7923vc "
IssueInstant="2014-18-05T18:35:10.728Z" Version="2.0">
<saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
https://saml.oracle.com
</saml:Issuer>
Pseudocode
7

8. Also and not new: most common IP spoofing can usually be
dropped and logged by a basic packet layer 3 firewall.
# netfilter/iptablesRule 0 (eth0)
#
# anti spoofing rule
#
$IPTABLES -N In_RULE_0
$IPTABLES -A INPUT -i eth0 -s 192.0.2.1 -j In_RULE0
$IPTABLES -A INPUT -i eth0 -s 192.168.1.1 -j In_RULE_0
$IPTABLES -A INPUT -i eth0 -s 192.168.1.0/24 -j In_RULE_0
$IPTABLES -A FORWARD -i eth0 -s 192.0.2.1 -j In_RULE_0
$IPTABLES -A FORWARD -i eth0 -s 192.168.1.1 -j In_RULE_0
$IPTABLES -A FORWARD -i eth0 -s 192.168.1.0/24 -j In_RULE_0
$IPTABLES -A In_RULE_0 -j LOG --log-level info --log-prefix "RULE 0 -- DENY "
$IPTABLES -A In_RULE_0 -j DROP
! Cisco Rule 0 (Ethernet1/0)
! anti-spoofing rule
!
access-list outside_acl_in remark 0 (Ethernet1/0)
access-list outside_acl_in remark anti-spoofing rule
access-list outside_acl_in deny ip host 192.0.2.1 any
access-list outside_acl_in deny ip host 192.168.2.1 any
access-list outside_acl_in deny ip host 192.168.1.1 any
access-list outside_acl_in deny ip 192.168.1.0 255.255.255.0 any
access-group outside_acl_in in interface outside
Here is an example of iptables and cisco rules for internal network
(match all addresses of the firewall (192.168.1.1, 192.0.2.1) and network
behind it (192.168.1.0/24):
State-full Packet firewall
8

9. Integrity and confidentiality are very important in the authentication process and
avoid the use of cookies is suggested, especially for critical applications;
In order to support the authentication, authentication systems must be available at
all time (ex: IdP server);
The likelihood of an attack in this scenario is considered the duration of the session
SAML ID key, little bit similar to the likelihood of a RSA secure ID token;
Restrict POST from legitimate and acceptable source only and use nonce;
While using an RSA Secure ID device for critical activities, we increase the security
posture to a very interesting level;
Many security appliances are using the same CA private key across all devices.
This is particularly dangerous, since the universal CA private key can be extracted
from any single device by an attacker. With the private key, the attacker can be
seen as trustable by all devices using the public key to secure transport as well as
payload.
Conclusion
9

10. Carnegie Mellon University, Analyzing Forged SSL Certificates in the Wild,
Lin-Shung Huang, Alex Rice, Erling Ellingsen, Collin Jackson
Oracle, Developing Security Providers for WebLogic Server, Identity Assertion Providers,
http://docs.oracle.com/cd/E15051_01/wls/docs103/dvspisec/ia.html
Robert Hafner, How to Create Totally Secure Cookies,
http://blog.teamtreehouse.com/how-to-create-totally-secure-cookies
FirewallBuilder, Anti-spoofing rule,
http://www.fwbuilder.org/4.0/docs/users_guide5/anti-spoofing-rules.shtml
IBM Research - India, Security Analysis of Web-based Identity Federation,
Apurva Kumar
Cisco, SAML SSO Deployment Guide for Cisco Unified Communications,
Applications, Release 10.0(1),
First Published: December 06, 2013,
Last Modified: May 08, 2014
OASIS, Assertions and Protocols for the OASIS, Security Assertion Markup Language, (SAML) V2.0,
OASIS Standard, 15 March 2005
I want to thanks the following sources and authors:
10
References