are these security defects in your .net apps?

1Proprietary and Confidential. Do Not Distribute. © 2015 Optiv Inc. All Rights Reserved.

github.com/malcomvetter

St. Louis Days of .NETAre these Security Defects in Your Apps?

2015.11.13


Pause for Station Identification

Thanks to our sponsors for making

St. Louis Days of .NET possible!


Platinum Sponsors

Silver Sponsors

Gold Sponsors


Quick SurveyRaise your hand if …–You are your organization’s SME for AppSec.

–Your organization recently started paying a lot more attention to developing secure apps.

–Security is just a requirement, so give me what I have to know quickly so I can go learn cool new tech in another session.


Bio

Tim MalcomVetter•Local: Born & Raised in St. Louis• IT for ~15 years:–Corporate Defender–Builder: Lead Developer/Architect–Breaker: Consultant @Optiv

•Spent too much time in school•CVEs and ABC Soup (OSCP, CISSP, MSIA)•Scraped CCs from POS you’ve used


Agenda•Will look at some Case Studies like an ATTACKER–Got to think like a bad guy sometimes

•(Silly) Demo code is up on •https://github.com/malcomvetter/WidgetSender


State of .NET Security•Kudos to Microsoft

–It’s easy to write a .NET app that is free of the

Big 3 Software Sins:

•XSS

•CSRF

•SQL injection


State of .NET Security

Yet there are more Security Talks in

the conference this year. Hmmm…


Agenda by VulnerabilityStill talking about the Big 3 and a few others:•SQL Injection

•Cross Site Scripting (XSS) and HTML/JS Injection

•Cross Site Request Forgery (CSRF)

•Insecure Direct Object References

•Missing Authentication/Authorization

•Missing Transport Encryption


Why?

Devs == Human


(not a real case study)

Case Study #0:SQL Injection


Case Study #0: SQL Injection•It’s 2015, why do we still have SQL Injection in .NET Apps?–Use Prepared Statements

--OR--–Favorite ORM (e.g. Entity Framework)–NO STRING CONCATENATION!

•Still see SQLi occasionally (<2% of the time)–Usually it’s a small percentage of an app’s SQL code

–Or a less common DB API (e.g. Informix)


Case Study #0: SQL Injection•It’s 2015, why do we still have SQL Injection in .NET Apps?…

var sql = new SqlCommand(null, db);

sql.CommandText = "SELECT * from Orders where OrderID =

" + orderID;

var param = new SqlParameter("@id", SqlDbType.int, 0);

sql.Parameters.Add(param);

…

^^^ Oops. All I’m going to say about that today.


ASP.NET Web Forms

Case Study #1:Retirement Financial

Services Firm


Case Study #1•Web Forms App –Nothing wrong with that (Dance with the one you brought)

•No obvious XSS (request validation on by default)•No obvious SQLi (prepared statements)

•… But …Direct Object Reference in a PDF Report Page


Case Study #1: IDOR•“Insecure Direct Object Reference”•https://www.example.com/Print.aspx?ID=SomeReport.pdf

•ID is vulnerable •How about:

?ID=C%3a%5cWindows%5cwin.ini(c:\Windows\win.ini)C:\inetpub\wwwroot\default.aspxC:\inetpub\wwwroot\bin\

myapp.example.com.DLL


Case Study #1

DEMO:Insecure Direct

Object References


Case Study #1: IDOR•Turn out I could:–Download all .aspx source code–Enumerate the namespace for the code behind–Download all app DLLs–Point REDGATE Reflector at the DLLs

•Bonus points for mentioning a conference sponsor, right?

–I turned the blackbox pentest into a source code review


Case Study #1

Reflection Demo


Case Study #1: IDOR•Now that I had the code, guess what else I can find?–Hardcoded passwords/encryption keys–Dead pages that don’t have links to them any more

–All the pages that turned off request validation•XSS!!!

–Code paths to a DAL that didn’t use Parameterized Queries•SQL Injection!!!

–I had all the skeletons


Case Study #1

Web Forms XSS Demo:

with and without Request Validation


Case Study #1: Lessons•App was compromised without the Big 3 vulns

(SQLi, XSS, CSRF)

•.NET framework features won’t save you from IDOR

•Input Vectors == Attack Vectors–Users control the ?ID= parameter

•Don’t turn off request validation!•Only write raw html if you Server.HtmlEncode() user input

•Dead/test pages in the app? Remove them!


ASP.NET MVC + WCF

Case Study #2:Multi-Tiered

E-commerce App


Case Study #2•MVC App–New Shiny–JS Flavor of the Week Libs

•No obvious XSS (HTML Encoding Everywhere)•No obvious SQLi (Entity Framework)

•… But …Server-to-Server Communication using WCF NET.TCP

Endpoints set to Security.NONE mode!


WCF NET.TCP Mistakes•SecurityMode.None–Anybody can talk to it–Can see data over the network (no encryption)–“But it’s inside the firewall.”

•SecurityMode.Transport–Encrypted across the network–Can be restricted to a specific user/group (Auth?)

•SecurityMode.Message–Don’t see it often, but easy to misconfigure


Why so many WCF Mistakes?•Mostly config mistakes, not code•WCF config can be complicated•No man’s land…–Devs: “It’s the admin’s fault”–Admins: “WCF config is part of the app”

•Nobody really looks at it once it “just works”–Especially, NET.TCP endpoints–PROD not like TEST/QA–(can’t just use your browser to view config)


WCF NET.TCP Mistakes•Tool Plug: WcfScanhttps://github.com/malcomvetter/WcfScan

https://github.com/malcomvetter/WcfScan



How WcfScan Works•https://github.com/malcomvetter/WcfScan •Simple Tool–WcfScan.exe net.tcp://[host]:[port]/[path]

•Creates a generic contract and programmatically connects to endpoint –Zero Configuration

•Iterates through Security Modes–With and without authentication for Transport Mode

•Parses Exceptions to enumerate security mode



Case Study #2

Quick WcfScan Demo


Case Study #2: Transport?•Endpoint with Transport Security Mode Enabled–Wide open AUTH!–Metadata Exchange (MEX) Published

•Attack: –Import the MEX as a Service Reference in VS

–Write a malicious client–Run as anybody in the AD domain–Bad Guy Wins


Case Study #2: Lessons•Take time to fix WCF NET.TCP configs–Transport Encryption–Authentication/Authorization–Do you really need to publish the MEX for NET.TCP?•Especially in PROD•Or lower environments –Attacker can import the MEX from TEST environments

•Rule of thumb: only publish MEX on developer’s desktop


WCF

Case Study #3:SOAP/XML

Web Services


Case Study #3: WCF•WCF SOAP/XML Web Services•Push authN or authZ to the app layer (custom code)–Not at the IIS layer via web.config

•Doing something custom like:–<xml>…<SignedXml> [sig here] </SignedXml> <x509Cert> [cert here] </x509cert></xml>

–Then not bothering to properly validate the signature


Case Study #3: Lessons•If you don’t use built-in security features, make sure you implement your own correctly.

•“Don’t roll your own security features.”


Case Study #4:CSRF via WebAPI,

MVC, WCF


Case Studies #4: Several Apps•Cross Site Request Forgery–Very misunderstood–User’s browser (or mobile app) is tricked to send an unintended request to the server.

–Requests are PREDICTABLE

•Common when mixing stateless services with a stateful app–e.g. throwing Web API controllers into an MVC project


Case Studies #4: CSRF•RESTful HTTPS POST Web API•__RequestVerificationToken in cookies

•BUT … MVC generated the CSRF tokens, Web API ignores it

•Tokens aren’t magic, they have to be validated.


Case Studies #4: CSRF

Web API & MVC CSRF DEMO


Case Studies #4: CSRF

Note To Self:Don’t forget to

*BYPASS*MVC CSRF Tokens via

XSS


Case Studies #4: Lessons•Web API requires careful planning for authentication

•MVC JSON Controllers easily support Auth/CSRF

•If XSS is present, all bets are off for CSRF!!!


Case Study #5:Vulnerable

Components


Case Study #5:•Your code does everything right, but …•You include vulnerable components, like:–JQuery with DOM XSS–AngularJS with DOM XSS–Other vulnerable JS libs–AjaxControlToolkit < v. 15.1

•Remote Code Execution!


Case Study #5: Lessons•Simple: Keep all your libs current.

•Hat Tip: Retire.JS •http://retirejs.github.io

http://retirejs.github.io/


stuff that still happens, but less so …

HonorableMentions


Honorable Mentions: XSS in MVC•You really have to go out of your way to make it work with config, but …

•ASPX View Engine:–First Name: <%: Model.FirstName %> (HTML Encoded)

vs. –First Name: <%= Model.FirstName %> (Raw)

•Razor View Engine [AllowHtml]:–@Html.Raw(somestring)


Honorable Mentions: Persisting JS in REST•Your front-end app may be HTML encoding all input today

•But …

•What if a junior support developer accidentally changes a form to write raw data that came from a service layer?

•Delayed onset of XSS. GIGO.


Honorable Mentions: CORS•Wide Open CORS – to whom are you sharing that data!

HTTP/1.1 200 OKDate: Fri, 13 Dec 2015 00:23:53 GMTServer: IIS Access-Control-Allow-Origin: *Content-Type: application/json


Honorable Mentions:Side Channel Status Codes•Specific status codes can signal interesting things

•POST /register/user•200 OK•201 Created•202 Accepted


Honorable Mentions: Business Logic Flaws

•This is on you – the .NET framework won’t save you from design flaws in your business logic.


Thanks for coming…


Thanks!

Q&ATwitter: @malcomvetter

github.com/malcomvetterlinkedin.com/in/malcomvetter [email protected]