Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Perimeter

5/20/2009
02:52 PM
John H. Sawyer
John H. Sawyer
Commentary
50%
50%

Educating Our Clients Is Part Of Our Responsibility

Have you ever had a client (or your own employer) say, "There's no way a user could hack our internal Web apps; they can't run anything but authorized applications like a Web browser and e-mail client." Happens all the time, right? Guess what -- you're not alone.

Have you ever had a client (or your own employer) say, "There's no way a user could hack our internal Web apps; they can't run anything but authorized applications like a Web browser and e-mail client." Happens all the time, right? Guess what -- you're not alone.Jeremiah Grossman has posted a list of the top eight reasons Web vulns aren't fixed on his blog, and Chris Eng has a great follow-up titled, "But That's Impossible!"

It's not uncommon to find organizations that take the ostrich-with-its-head-in-the-sand approach to security, hoping that if they ignore it, then it will go away. I think we've all run into those types of managers and/or clients, but what about issues where a lack of understanding of the problem and attack methods is what's leading the company to think they are more secure? Let's use a couple of the statements from the Veracode blog.

"That system isn't even exposed to the outside." -- This is a great starter because by now you all should know that this is a non-issue for attackers when other systems on the same network are exposed or internal users who access that system are also receiving e-mail and browsing the web. Can you say client-side exploit? Maybe something like a zero day exploit against Adobe Acrobat that phones home giving an attacker an interactive shell to then attack internal systems?

"You are using specialized tools; our users don't use those." -- You gotta love this one! I've blogged about weaponizing Firefox with some great add-ons. All it takes is a Web browser, or even telnet, to exploit a Web browser vulnerability. I'd love to see reaction of the person who made that statement when you display the contents of his database through SQL injection with nothing but Internet Explorer.

"We don't even link to that page." -- How many data exposures could be attributed to this misguided statement? Tools like Nikto have existed for years that enumerate directories on a Web server by running through a common list of directories. In fact, that's how Metasploit and a new script for Nmap work to detect servers vulnerable to the IIS WebDAV zero-day vulnerability. They make repeated requests to a Web server looking for common directories, send a request using the Unicode string to any directories found, and determine whether it's vulnerable based on the HTTP response code.

Oh, I could go on and on with examples, but what I want to leave you with is that we as security pros must realize it is our responsibility to educate the people who respond with statements such as those. Our reports should detail the vulnerability and the risk carried with it. We should also be able to explain it to our clients during a presentation or in a private meeting in a way that they can understand it and aren't left feeling insulted them. That last part can be difficult, but it's crucial to getting repeat business and recommendations.

John H. Sawyer is a senior security engineer on the IT Security Team at the University of Florida. The views and opinions expressed in this blog are his own and do not represent the views and opinions of the UF IT Security Team or the University of Florida. When John's not fighting flaming, malware-infested machines or performing autopsies on blitzed boxes, he can usually be found hanging with his family, bouncing a baby on one knee and balancing a laptop on the other. Special to Dark Reading.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Why Vulnerable Code Is Shipped Knowingly
Chris Eng, Chief Research Officer, Veracode,  11/30/2020
Inside North Korea's Rapid Evolution to Cyber Superpower
Kelly Sheridan, Staff Editor, Dark Reading,  12/1/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Assessing Cybersecurity Risk in Todays Enterprises
Assessing Cybersecurity Risk in Todays Enterprises
COVID-19 has created a new IT paradigm in the enterprise and a new level of cybersecurity risk. This report offers a look at how enterprises are assessing and managing cyber-risk under the new normal.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-25465
PUBLISHED: 2020-12-04
Null Pointer Dereference. in xObjectBindingFromExpression at moddable/xs/sources/xsSyntaxical.c:3419 in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25461
PUBLISHED: 2020-12-04
Invalid Memory Access in the fxProxyGetter function in moddable/xs/sources/xsProxy.c in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25462
PUBLISHED: 2020-12-04
Heap buffer overflow in the fxCheckArrowFunction function at moddable/xs/sources/xsSyntaxical.c:3562 in Moddable SDK before OS200903.
CVE-2020-25463
PUBLISHED: 2020-12-04
Invalid Memory Access in fxUTF8Decode at moddable/xs/sources/xsCommon.c:916 in Moddable SDK before OS200908 causes a denial of service (SEGV).
CVE-2020-25464
PUBLISHED: 2020-12-04
Heap buffer overflow at moddable/xs/sources/xsDebug.c in Moddable SDK before before 20200903. The top stack frame is only partially initialized because the stack overflowed while creating the frame. This leads to a crash in the code sending the stack frame to the debugger.