Link to disclosure: http://seclists.org/bugtraq/2015/Jul/23 Tried the POC but all got stopped by disabled Script Hosts.
OLE Packager has been used for many years in targeted exploits, where a company user is tricked into opening the "package." In the PoC, if you r-click on the Package Object and select "Edit Package", you can view the embedded file to see how the exploit works: In this case, it is a PoC JS file in a .ZIP file, but a real exploit would contain the bare executable which would automatically run when the user clicks on the file. From 6 years ago, a RTF file with embedded SCR file as the package object: ---- rich
It depends on the file type. If it is a JS file as in the PoC, then no. If it is an executable file such as the embedded SCR file in the example I gave, then yes, it is an easy catch. ---- rich
Does this apply to Office 2000 and 2003 or the later ones? Seems to be all of them. Bad news since they aren't even patched anymore. For JS, HIPS such as SSM on XP should alert about Word starting cscript.exe or wscript.exe and if you allow that, next alert would be about the specific script command. Yes? No?
I've tested Spychelter FW using OrderRemittance.xlsx...and YES it alerts many times what you can see below on screenshots. First 8 actions are allowed and after ninth action I received firts effect...I couldn't use mouse, menus in all opened windows so I was able use only buttons like Tab, Enter and arrows...the two latest screenshots are made using cellphone So...at the end...I think SS give us enought alerts to "stop-think-and block" mentioned danger behaviour of MSO files. ----------------------------- edit: I've tested also files SalesInvoice.docx and SalesInvoice.rtf and at this time I've blocked "action 9"...from this time SS automaticly blocks every such actions
Actually, I didn't see anything really dangerous in those alerts, it just alerts about MS Word and Excel trying to execute other apps. The alerts about ADS are indeed a bit strange, but I'm not sure how many legit apps are making use of this. I do wonder why SS didn't block the mouse hijacking. But it's probably best to run MS Office sandboxed or restricted.
It's easy to answer...SS was on "ask user" level and it's my normal level of working so every next possible behaviour depends on my decision. In this case every action was allowed to see what will be the next I'm quite sure that enabling option of automaticaly blocking of suspicious action will give result which you expect. I'm working usualy/daily with Firefox as restricted app so tested file executed through browser will be also restricted...I'll check it.
That is nice. From where I sit, however, it seems like the first alert should be in the user's thinking: Did I request this document? I should check with the sender. This would reveal the trick, and it would not have a chance to execute. However, in the business world, this is not always convenient, where an employee may receive many emails with attached documents daily. Here is the InfoSec Handlers Diary Entry from the 2009 RTF document OLE Packager exploit I referenced earlier in my Post #3: https://isc.sans.edu/diary/Targeted e-mail attacks asking to verify wire transfer details/6511 The point of entry in so many targeted exploits is the user at the computer, who is tricked into clicking. This has proven to be so in some of the recent security breaches at large organizations. In the business world, where this type of attack would be most prevalent, it is not an easy situation to deal with. ---- rich