Weekly "That's Interesting" Wrap-Up 11 Nov 2011

Intersystems Cache Database

I know, had never heard of it either. But here are some commands so you can enum some version and other system type infoz:

http://docs.intersystems.com/cache20111/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_cosvariables


Hacking Satellites
http://www.dailymail.co.uk/news/article-2055311/Hackers-infiltrate-US-satellites-taken-complete-control-achieving-steps-required-command-satellite.html


Finally a decent APT article
http://krebsonsecurity.com/2011/10/chasing-apt-persistence-pays-off/

decent APT advice
http://blog.deepsec.net/?p=684

Joe McCray made an APT resource
http://advanced-persistent-threat.com/

More Duqu stuff http://www.securelist.com/en/blog/208193243/The_Duqu_Saga_Continues_Enter_Mr_B_Jason_and_TVs_Dexter

Lets Get Real

We work in a variety of large environments, networks from 30k hosts up to 100k hosts and like many of you one of our jobs is to provide security advice to our customers. In the infosec industry many times this advice involves recommending things like patching, AV selection, FW rules, SEIMs, reverse engineering tools, app review, etc. (and most often purchasing more assessments ;)

However what we are finding most often is many places aren't even ready to deal with implementing advanced security as their basic IT operations are not in order. How many times have you pen tested a customer and heard "oh yeh that belongs to the desktop support group, good luck getting anything done there"?

Many times we have generated a number of serious alerts on a sensitive server including the use of stolen cached domain admin credentials, password dumping tools and even rebooting the server itself. We will see a ticket generated in the support system, an admin looks at the sever, fills out the ticket and says: "AV caught the attempt and the server came back up fine" ticket closed. Often users won't report anything suspicious, even when our actions are blatant, because they are so accustomed to everything being broken and unstable.

Beyond automating patch Tuesday and keeping AV up to date, and definitely beyond exploits, memory protections and reverse engineering, the most serious problem in security is that organizations lack even basic capabilities in managing their enterprises. Who's running still running XP SP2 (a vastly less secure OS than Win7) because of the expense involved in updating the enterprise? Businesses need security help that is willing to negotiate the maze of business concerns and understand enterprise IT needs in addition to being technically astute in security.

We've been to large companies where getting a network port to plug into to start testing can take 2 weeks. Where finding someone who understands how servers are configured or even how many servers there are can be a challenge. Environments that don't know what computers are on their own networks. Sure security needs to be built into the whole process, but I wonder, have we focused too much on what we want to do and not enough on what the customer's actually need?

Its not sexy or headline generating work, but little is more critical.

Val

Common mobile app vulnerabilities

After testing a fair number of mobile applications I thought I would share 3 of the most common vulnerabilities I've come across thus far. In regards to scope, when referring to "mobile applications", we really mean both the mobile application and the web-service.

"Hide-a-key-in-a-neon-pink-plastic-rock-next-to-the-front-door" storage:

This appears to be the most prevelant issue by far that I've come across. Insecure implementations include:

1) Storing plain-text credentials in a SQLite database
2) Storing XML files that contain plain-text credentials or other sensitive account details
3) Storing plain-text credentials in a system wide database (e.g. - accounts.db/Android)

Moral of the story is, if a mobile device is lost or stolen (happens way more often than it should), credentials are ripe for the picking. Physical access is not always required of course. Anyway, pretty much anyone who has spent 2 minutes on "The Googles" can find out where you are storing your metaphorical "house keys". There are solutions to this problem, for instance, I've heard great things about Android-SQLCipher and don't forget about platform API solutions as well (if your not a fan of third party libraries).

Crappy session handling:


I don't think this title will ever make its way on to an OWASP Top 10 but it certainly reflects the issue accurately. Not to say this is limited only to Mobile Apps & Web Services, far from it, it is just very common amongst them.

Examples -

So, here is a fun one, pure basic-authorization schemas . You typically see this in a SOAP-service-to-Mobile-App architecture but obviously the two aren't mutually exclusive. For those not familiar with basic-authorization, it  means the user's credentials are sent in the standard basic-auth format (Base64 encoded user:password). The problem occurs when, instead of leveraging a session handling schema, the user/password combo is sent with every request to the web-service as a means to authenticate the user for the requested resource. There are many disadvantages. Namely, if SSL isn't in play, you've increased the likelihood that the credentials will be stolen (ahhh....... lattes, croissants and good ol' packet sniffing). Additionally, because you haven't a session to destroy, there is no inactivity lock-out. Typically the creds are stored (plain-text of course) on the device, retrieved by the app and then sent in the request on a per-request basis. This means, the person on that device may not be the person you intended to view potentially sensitive information.

Another big session-related issue is leveraging device identifiers or good old client-side data to control privileges of a user. Imagine the classic parameter tampering (userid=100 becomes userid=101) but this time with the UUID of an iPhone device. The classic session identifier -> user map -> role enforcement still works so it is unnecessary to build your schema in this way.

API Keys, Test Accounts and Dirty Laundry


From test account credentials along with the test URL, which provided juicy insight into the inner workings of an architecture to the personal email addresses of developers (think - social engineering/username enumeration), the list of things put into the source code can still be fairly surprising.

These applications are reversible. Especially Android apps, between dex2jar/apktool/jd-gui.......its pretty easy to see things not intended for your eyes. Developers need to scrub sensitive data prior to sending the code out for production and treat data like its a public blog post......everyone can read it. Oh, and make sure you aren't hard-coding API or encryption keys!

Okay, so those titles will never end up on a Top 10 but the content has! I would encourage those interested to check out the OWASP Mobile Top 10 Risks and please, don't forget the project always needs additional collaborators.

Cheers,

Ken

nessuscmd for scanning a host with a subset of plugins

Need to check a few specifc nessus plugins against a host?

$ sudo ./nessuscmd 192.168.1.92 -p80,443 -v -V -i 38157,10107

Starting nessuscmd 4.4.0
Scanning '192.168.1.92'...

Host 192.168.1.92 is up

Discovered open port http (80/tcp) on 192.168.1.92

[i] Plugin 10107 reported a result on port http (80/tcp) of 192.168.1.92
[i] Plugin 38157 reported a result on port http (80/tcp) of 192.168.1.92

+ Results found on 192.168.1.92
+ - Port http (80/tcp) is open
[i] Plugin ID 38157 Synopsis :
The remote web server contains a document sharing software Description : The remote web server is running SharePoint, a web interface for document management. As this interface is likely to contain sensitive information, make sure only authorized personel can log into this site See also : http://www.microsoft.com/Sharepoint/default.mspx

Solution : Make sure the proper access controls are put in place

Risk factor : None

Plugin output : The following instance of SharePoint was detected on the remote host :

Version : 12.0.0.6327
URL : http://192.168.1.92/

looks like the functionality has been there for awhile:
http://blog.tenablesecurity.com/2007/07/nessus-32-beta-.html

Weekly "That's Interesting" Wrap-Up 21 Oct 2011

TEDxRotterdam - Mikko Hypponen - safe internet will lead the future


http://youtu.be/WQgeUHlTThc

Similar to his other TED talk but worth the 20min. Its good up to "fixing things". Not sure I agree with his "fixes". I do agree with a more unified way to fight/arrest/ cyber criminals, but bottom line its still way too easy to break into stuff and still to easy to conduct Credit Card fraud. We need to adress some of that as well.

Also, I think plenty of people would disagree that anything Mac is "safe" because of market share.

OMG OMG OMG Stuxnet Part 2 or the parent of stuxnet or whatever
http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/w32_duqu_the_precursor_to_the_next_stuxnet.pdf

Samples:
http://contagiodump.blogspot.com/2011/10/duqu-rat-trojan-precursor-to-next.html

Volatility Memory Forensics Federal Trojan aka R2D2

http://www.evild3ad.com/?p=1136

Weekly "That's Interesting" Wrap-Up 14 Oct 2011

Bios Rootkits (mebromi)
http://blog.webroot.com/2011/09/13/mebromi-the-first-bios-rootkit-in-the-wild/

Apache reverse proxy (mod-rewrite) bypass vuln details
http://www.contextis.com/research/blog/reverseproxybypass/

CCC Analyzes government malware (In German, go go gadget google translate)
http://www.ccc.de/system/uploads/76/original/staatstrojaner-report23.pdf

http://m.zdnet.com/blog/hardware/can-you-trust-your-antivirus-solution-to-protect-you-against-governmental-backdoors-and-lawful-interception-police-trojans/15280

Tips for evading AV during Pentests
http://pen-testing.sans.org/blog/2011/10/13/tips-for-evading-anti-virus-during-pen-testing

Check out the conversation between Dave Kennedy and Rafal Los on CSOs, popping shells, #secBiz from 13 Oct
https://twitter.com/#!/dave_rel1k
https://twitter.com/#!/Wh1t3Rabbit

Lastly, from the "no more free bugs" and "hey companies, this is NOT how you behave to people that report vulns" categories

"Security researcher threatened with vulnerability repair bill"
http://www.scmagazine.com.au/News/276780,security-researcher-threatened-with-vulnerability-repair-bill.aspx

Weekly "That's Interesting" Wrap-Up 7 Oct 2011

i'm probably gonna fail miserably at regularly posting anything but F it, im motivated right now and that's what matters.

So interesting stuff this week.

DerbyCon videos are slowly being posted. they're here:
http://www.irongeek.com/i.php?page=videos/derbycon1/mainlist

Specifically, watch Chris Nickerson's talk. Its funny and has a point.
http://www.irongeek.com/i.php?page=videos/derbycon1/chris-nickerson-compliance-an-assault-on-reason

So far i've watched Carlos Perez's and Rick Redman's, both were good. Caught most of jadedsecurity's on track2, also good.

SK Hack by an Advanced Persistent Threat
http://www.commandfive.com/papers/C5_APT_SKHack.pdf

Coldfusion is interesting to me, specially with the tight java intergration. You can do alot with it. The future of coldfusion from ColdFusionJedi
http://www.coldfusionjedi.com/index.cfm/2011/10/4/My-MAX-Preso--the-future-of-ColdFusion


The rest of the stuff that was interesting is shared via google reader:
http://www.google.com/reader/shared/carnal0wnage

ncrack with domain creds

little post on using ncrack to brute/check domain creds


user@ubuntu:~/pentest/msf3$ ncrack 192.168.1.52:3389,CL=2 --user=username@domain --pass=myl33tpassword -vvv -d7


Starting Ncrack 0.4ALPHA ( http://ncrack.org ) at 2011-09-29 14:48 PDT

rdp://192.168.1.52:3389 Account credentials are valid, however, the maximum number of terminal services connections has been reached.
Discovered credentials on rdp://192.168.1.52:3389 'username@domain' 'myl33tpassword'
rdp://192.168.1.52:3389 (EID 1) Attempts: total 1 completed 1 supported 1 --- rate 0.90
rdp://192.168.1.52:3389 finished.

My Personal War Against Overuse of Memory Corruption Bugs

I remember many years ago writing my first buffer overflow, a standard stack bug privilege escalation in I think RedHat 7x which I thought was awesome. I remember writing my first SEH overwrite on windows and marveling at POP POP RET's and spending hours pouring through memory in Windbg wondering why my shellcode was getting trashed. I even remember the moment when I "got" return to libc. Somewhat in contrast to many "researcher" exploit developers and bug hunters, I also break into computers, lots of them. At last count I was well over the 100,000 mark of computers I have personally gotten into, control over and extracted data from. This is not to tell you how awesome I think I am (I'm not, there are IRC script kiddies with 10x the amount of compromises under their belt) but rather provide a statistical frame of reference for what I am going to say next.

Several years ago I decided to pull back from the memory corruption rat race, but I never really talked about why.

When breaking into computers, I almost never use memory corruption bugs. I occasionally, but rarely develop new memory corruption bugs into exploits. Memory corruption bugs IMO are a bad long term return on investment. Sure someone like Charlie Miller can crank out 100 Adobe product crashes in the blink of an eye, but how much skilled time investment is required to take a bug from a crash to a highly reliable, continuation of execution, ASLR / DEP bypassing exploit ready for serious use? Average numbers I have heard from friends who do this all day long are 1 - 3 months, with 6 months for particularly sticky bugs. How many people are there that can do this? Not many. So you have a valuable resource tied up for months at a time to produce a bug which may get discovered and published in the interm ( a process you have no real control over), patched and killed. When was the last time you heard about a really bitchin Windows 7 64bit remote? Its been a while. So you put in all that time and investment to produce a nice 0day only to watch it get killed. Then you start looking for the next one. What's the going price on the market for an 0day? 100k, 200k, etc. Expensive for something with a potentially limited life putting aside that fact that people don't patch anyway for a moment.

So what do I like instead then? I like design flaws that are integral to the way a system works and are extremely costly to fix, that don't barf a bunch of shellcode across a potentially IDS/IPS ridden wire, that simply take advantage of the way things are supposed to work anyway. Lest you think I spend all my time keylogging "password123" let me give some real world examples:

- Proprietary & custom hardware/OS and software system used for some interesting applications. System has a UDP listening service. After reversing the service binary we discovered that it takes a cleartext, unauthenticated protocol blob. The process then, based on whats in the blob, calls another process that execs a variety of system commands. One of these commands sends out a message to the various systems in the network to mount a given network file system and load specified software. So we craft our own protocol blobs build our own network file system with specially crafted malicious software and take over all the systems at once. We spoke with the designers of the system about what it would take to change it, and due to various rules and policies we were looking at 18-24 months to push out a redesign, and thats after whatever time was needed to develop the new system.

- Foreign Client/Server ERP system that handles supply chain and even has some tie ins with some SCADA components. Authentication works as follows: Client enters a username and password. Client app connects to the server and sends an authentication request with the provided Username. The server checks to see if the username exists and if so it sends a hash of the user's password back to the client app. The client app checks to see if the local password hash matches the one sent from the server and if it matches the client informs the server the the account is valid and the server then successfully authenticates the client. So yes, very broken client side authentication. But to figure that out we had to analyse the network traffic between the two as well as reverse engineer the client application and binary patch the client app to always respond with a positive match. And the data or effects gained from compromising this system are way more interesting than your windows 7 home gaming system.

- Large company virtualization cluster using hardware from a well known vendor. Servers provide remote console / kvm functionality for management. Because of a previously unknown authentication vulnerability in the remote console app we were able to boot the server to remote media under our control (i.e. a linux boot disk). We had reverse engineered the virtualization technology in question and developed a custom backdoor which we then implanted by mounting the hard drive from our remotly loaded linux boot environment, allowing us to take control of the cluster.

With the exception of the last server reboot none of these above examples generated any traffic or logs that were flagged by any security system. No IDS or AV to evade. No DEP or ASLR to get around. And low chance of these bugs getting killed due to the cost and time frame involved in fixing them.

I believe that researchers should consider putting some of their time and resources into the above types of design flaws as well as in sophisticated post-exploitation activities. The market value for memory corruption bugs will go up for a while but so will the difficulty and time required to find them, and we have often seen patch release times decrease as well. Eventually that bubble will burst.

V.

Where have you been!?

I've been busy... :-(

But i do have some upcoming conference speaking engagements coming up.

So. If you are heading to BruCon

catch me and Joe McCray talk about Pentesting High Security Environments.

If you are heading to DerbyCon

Catch me and Rob Fuller talk about The Dirty Little Secrets They Didn’t Teach You In Pentesting Class


Lastly, if you'll be in Switzerland for Hashdays







You can catch me talk about From Low to Pwned.

I'll also be giving a talk at the Management workshop on Information Operations for Management (sorry the info isn't on the site yet but should be here https://www.hashdays.ch/management-session.html at some point).

I'm sure there will be more stuff in November/December its just not scheduled yet.