Presentation given by Thomas Powell (tpowell@pint.com) and Joe Lima (jlima@port80software.com) - 2-15-2012 covering WebAppSec issues with an emphasis on concerns with the Sitecore CMS platform. Sorry for any small quirks in slideshare conversion.

1. Thoughts on
Defensive Web
Development
Today’s Flavor - Sitecore
Thomas A. Powell
tpowell@pint.com
Joe Lima
jlima@port80software.com

2. Before We Start
• Getting “defensive” requires a mindset
change
• Serious threats really exist
• They can happen to you
• Much can be prevented
• But…there is no such thing as
absolute security

3. Todays Focus -
Sitecore
• First Question: Is Sitecore the target or is it
a site run by Sitecore?
• Oh BTW security isn‟t really as app specific
as you might think
• If it is you might have really big problems!
• If you don‟t remember much today you
won‟t act so … let‟s get memorable

4. OpenSource Fail?
• It‟s open code to “hackers” too and if
widely used becomes a big target

5. Zoinks!

6. Woohoo!

7. Careful…
Did “they” turn on you yet and with what
force?

8. There Be Web Orcs!
I can SQL injectz you!

9. And They Cause
Troubles

10. Why – Ego
Defacement
Relax – Faked This type of “tagging” for cred

11. Why - Hactivism
All fun and games until LOIC is aimed at your site

12. Why – 4 Lulz
Ok so it isn‟t funny to you but it is to them

13. Why – Spread
Malware “Germs”
Put malware on your home page to infect others

14. Why – ID Theft
You (or your users) are a commodity
(at least your id, IP or cc# is)

15. Why – Zombie
Recruiting
Grow and army and then…
“Awake my Zombie army and attack!”

16. Why – For The $£¥€!

17. Yes - Bad people are
real
credit: From Russia With Love - Fyodor Yarochkin and The Grugq - http://tinyurl.com/frmrussiawlove
And they‟re in your country too…

18. Build some walls

19. Man the defenses!
“No worry, firewall is in place”

20. We‟re awake!
and what exactly do you see?

21. Just another day on the
Internetz

22. The Usual Suspects
Input Tampering
SQL Injection
XSS
CSRF
RFI/LFI

23. The Toolbox is
Overflowing

24. Attack #1
Stupid Bot Brigade - “Charge!”
../cmd.exe &1=1;droptable

25. Attack #2
“I‟m just a lowly peasant HTTP request
, may I pass?”

26. Think like a bouncer?
“Yer not on the list. Come on in?!”

27. The weak minded are
easily tricked
“These are not the requests you are looking
for”

28. 0-day to the Face!
“To get our new signature files you
need a valid support plan”

29. The Appearance of
Security
The Intent Thief: “How quaint a club!”

30. Real Security
Tradeoffs
This...

31. Security Tradeoffs
...or this?

32. I want it all!

33. Attack Surfaces are
Growing
and many more. Notice that
these may be indirect

34. Many Targets Within

35. What‟s Your
Password?
Keys to the Sitecore (or any CMS)
Kingdom

36. Finding the Right
Door
Is your Sitecore instance public
IP accessible and at the standard path?

37. Psst….This isn‟t hidden

38. No Try Limit = No
Security Eventually*
No retry limits
+ No Easy Alerting
Let a bot work on it

39. Policy Time!
• Active Directory module for
authentication can help
leverage any better policies
you may have already
• Custom validators can (and
should) be built
• Enforcement is key

40. Keeping It Clean
• Scan files with external services
• Strip XSS triggers like <script>
• Check for objectionable content

41. Hack There To
Hack Here
• Your security posture may be weaker
on your other sites and...

42. Password Reuse +
No Second Form =
Fail
“Take this key and believe
you are secure”*

43. Who‟s Watching?
• Enjoy your double cap, venti, packet
captured browser session!

44. The Hijacker‟s Guide
• Grab a few .NET and Sitecore cookies
• Start in the middle of the login sequence
• Keep replaying them and stay logged in
forever!

45. Better SSL Your
Sessions
No SSL out in open = grab and go admin session cookie

46. Custom Risk
• The CMS admin shell can be
extended with custom ASP.NET
applications
• Watch out for expanded attack
surfaces!
• Remember to make sure that
users have to be logged in to
gain access
• Sitecore.Shell.Web.UI.SecurePa

47. Custom Trouble
• Reality: Customer often their
own worst enemy
• Excessive theme
customization by non-security
minded devs
• Now in some third party
components with their own
troubles for good fun

48. Face Palm
Customized templates without proper
validation introduced XSS all over site

49. Double Face Palm
Using pluploader for open source
See upload of new aspx file into site‟s Web root

50. It‟s a 3 rd Party Security Party!
<script src=“http://other.com/libs/whatcouldgowrong.js”>
</script>
<!-- Don‟t be such a hater everybody‟s doing it -->

51. Dangerous Domains?
• CMS in its own domain by
default
• But public and private sites with
shared content aren‟t
• An easy fix -- if you remember
to do it!

52. More XSS Fun
Product reviews, forums, and blog
comments are generally ripe for XSS
trouble

53. XSS – Just Part of the
• XSS site with cookie grabber
Plan
on review, blog comments,
etc.
• Do something to attract
attention of site admin, like
email saying problem on
page X (the one with XSS)
• Grab cookie for auth
• Go back to admin or known
URL of a backend – add user
account, etc.

54. Cookies really are
Yummy!
Me likey the Web...everyone gives
me COOKIES!!! Num num num
num

55. Always Easiest to
Attack People!
Name : Jim
LaFleur
Occupation : Chief of Security
Organization: Dharma Initiative
• Find Jim‟s name/email in your site
comments, Linkedin, Facebook, etc.

56. Spear Phish Scenario
• Find XSS hole for
reflection, search
query, URL, etc.
• Email as “end user” asking for
support on the XSSable URL
or get them to click on the
XSS
• Steal their cookie and login as
them

57. Rise of DoSing &
Electronic Sit Ins

58. DoS Attack Sadness
• It can be „legit‟ traffic that just
overwhelm with regular correct
HTTP
• Watch dynamic pages in
particular
• POSTs and writes in particular
• They can crowd source it easily
• Countermeasures cost you $ if
attackers know how to do it right

59. Just Throw Money At
IT
• Sure it helps but there is no “silver
bullet” box especially without a posture
change

60. Wrap Your App
• Reality is in some cases
you just have to put a
WAF in – no way to patch
fast enough
• WAFs have their issues
though often not strong
enough or too strong
• WAFs are only a part of
covering yourself

61. Tech Can‟t Solve
This

62. Go Back to Dev
School
If Johnny builds a Web site he must not
trust______
A) form inputs B) query strings C) cookies
D) end users E) all of the above

63. Summary
• Don‟t broadcast you use Sitecore (or
.ASPX, IIS, etc.)
• Remove backend from public access
• Strengthen your auth – 2 factor if you
can!
• Avoid rich user submissions
• Harden your sessions

64. Summary
• Scrub your source
• Add an App Firewall
• Plan for DOS attacks
• Talk to your people
• And most importantly pay attention

65. Questions?
Thomas A. Powell
tpowell@pint.com
Joe Lima
jlima@port80software.com
http://www.pint.com
http://www.port80software.com
Twitter: PINTSD
Twitter: port80software