You are browsing the archive for Uncategorized.

I’M SO excited, Part 2

October 5, 2019 in Archaeology, Uncategorized, Undocumented Windows Internals

In my last post I touched on some basic mso.dll findings. Today we will continue with the same theme, but instead of exported functions, we will focus on low hanging fruits which are… yup, strings. And I don’t mean your usual dump of all strings from a binary (imagine what value you can get from strings ran over a 26MB DLL), but more focused and API-centric strings.

What is the value?

Knowing unique strings used by APIs can help us to narrow down some interesting functionality/features that may be undocumented, or otherwise useful. In my experience, many of these are good starting points for deeper research that culminates in new posts on this blog, or my better understanding of windows internals.

Let’s take Windows Properties for starters. Some of them can be used to code-inject. This offensive train of thought led me to ask a question: does MS Office offer any window properties that allow pointer overwrites? If it does, it is definitely interesting.

I have identified the following Windows Properties set by MSO.DLL:

  • AirSpace::LayerHost
  • AirSpace::FlipModel
  • AirSpace::IsOverlayWindow
  • MSO_UXHWNDEFFECTSMANAGER_WINDOW_PROP
  • NUINativeHWNDHost

I know there are more, but they need to be identified either via sandboxing, or better static analysis. I also didn’t identify any that allow pointer overwrites yet, but at least we have our foot in the doors.

There is also a list of atoms mso.dll creates:

  • VertLine
  • HorizSlider
  • ListColumnLabel
  • ColorAreaImage
  • ColorSwatchButtonContainer
  • GroupHeaderContainer
  • ColorSwatchElement
  • ScrollViewer
  • PanViewerScrollButton
  • ButtonDropArrow
  • TreeViewContentImage
  • TreeViewContentLabel
  • TreeViewContents
  • ListViewViewer

At the moment I don’t see any use for these, but again, the more strings you recognize, the less time you need to spend on them in a future & can also use them in exclusions of any sort (e.g. yara strings or code markups).

Another bit that is easy to spot are RichEdit Classes. I used to think I know them all, but mso.dll surprises us again. Here is a list of Window classes mso.dll recognizes:

  • RichEdit20A
  • RichEdit20W
  • RichEdit20WPT
  • RichEdit50W
  • RichEdit60W

Another interesting bits I found are some of the environment variables expected by mso.dll; among these common ones that everyone recognizes we can also see these two weird ones:

  • LORI_099F5E083DF84BC98E90139DFB45C0B9
  • msooaopt

Again, I have no idea what they represent at the moment, but it’s yet another research bit we should pursue.

Okay, now that we had a quick glance over exported functions that are directly mapped to Windows APIs, and unique strings that are easy to include/exclude, we should go a step further.

What about file names or anything that uses a file-extension-like strings e.g. MIME types or Object names?

A quick regexp reveals the following strings of interest:

  • Access.Application
  • AccessAddin.DC
  • AssetLibrary.ico
  • blog_request.xml
  • blog_response.xml
  • client_LocationBasedDefaults.html
  • communicator.ex
  • CompositorFrames.csv
  • ContactPicture.jpg
  • CorelPhotoHouse.Document
  • CsiVersionSupportsSecureHttpRedirection
  • customStreamsXsn.xml
  • DataContext.Label
  • DataSource.Anchor
  • DataSource.CanGrow
  • DataSource.Categories
  • DataSource.Commands
  • DataSource.EventingItem
  • DataSource.FilterIndex
  • DataSource.FilterItems
  • DataSource.HelpId
  • DataSource.HighlightedItem
  • DataSource.HighlightedValue
  • DataSource.ImageSource
  • DataSource.InRibbonItemsHeight
  • DataSource.InRibbonItemsWidth
  • DataSource.IsAnchorEnabled
  • DataSource.IsAnchorPressed
  • DataSource.IsAutoCompleteEnabled
  • DataSource.IsBitFiltering
  • DataSource.IsDropFullWidthEnabled
  • DataSource.IsDropped
  • DataSource.IsFilterVisible
  • DataSource.IsScrollToSelectedEnabled
  • DataSource.IsSelectionRequired
  • DataSource.Items
  • DataSource.ItemsHeight
  • DataSource.ItemsWidth
  • DataSource.Label
  • DataSource.Layout
  • DataSource.ResizeType
  • DataSource.SelectedItem
  • DataSource.SelectedString
  • DataSource.SelectedValue
  • DataSource.StatusText
  • DataSource.SuperTip
  • DataSource.Tooltip
  • DocumentRepository.ico
  • EasyPhoto.Photograph
  • editdata.mso
  • Excel.Application
  • ExcelPlugInShell.PowerMapConnect
  • exp_pdf_server.dll
  • FaxImage.tif
  • GetFeatureDS.cs
  • HiJaak.Image
  • Imaging.Document
  • InfoPath.Application
  • infref.chm
  • InternalTailDS.HighlightedItem
  • InternalTailDS.ListHeight
  • InternalTailDS.SelectedItem
  • InternalTailDS.TailContext
  • IPM.Appointment
  • IPM.DistList
  • kernelBase.dll
  • meetings.asmx
  • mergedoc.rcd
  • METTrace.log
  • microsoftonline.com
  • mscreate.dir
  • msodatalast.dat
  • msohdinh.tmp
  • msosqmcached.dat
  • MySharePoints.ico
  • Node.StyleTree
  • Normal.dotm
  • NormalEmail.dotm
  • ODC.TableCollection
  • office-AppPrivilege.OPEP
  • OscAddin.SharePointProvider
  • Outlook.Application
  • Outlook.FileAttach
  • Paint.Picture
  • PersonaMenus.ribbonpp
  • pg_custom.xml
  • Photohse.Document
  • PhotoSuite.Image
  • PowerPoint.Application
  • PowerPoint.Slide
  • proppanel.xsn
  • prottpln.doc
  • RenderFrames.csv
  • sampledata.xml
  • SharePointPortalSite.ico
  • SharePointTeamSite.ico
  • skydocsservice.svc
  • SocialConnector.dll
  • typeSchema.xsd
  • UIAutomationCore.DLL
  • verifier.dll
  • WangImage.Document
  • Word.Application
  • Word.Document
  • xlimpconv.dll

As I go through functions that reference these strings I gain more insight into logging, debugging functions that are built-in into MS Office. In fact, the Office persistence mechanisms I discovered in the past are a direct result of digging in some of these artifacts…

And now it’s time to introduce a MsoFWzEqual and MsoFSzEqual functions that mso.dll relies on to compare many strings. I cannot list all the strings that these 2 functions operate on, but many of them are good pointers for further analysis as well. The comparisons include file extensions, MIME types, data block headers, etc. Yup, they are used during data parsing so highly possible there will be some vulns possible…

Not much, but at the same too much. You be the judge…

RunDll32 — API calling

September 28, 2019 in Uncategorized

This is a quickie.

Using rundll32 to run stuff is well-known. You can load DLLs, and call APIs.

Sometimes tho, we may get confused about data format we need to provide to APIs. If your API accepts an ANSI, or a Unicode string, different rules apply.

The best way to test _any_ API executed via rundll32.exe is to call it by a ‘native’ name w/o a suffix (A or W). This way, it will go through a sequence of:

  • Loading our DLL
  • Retrieving an address of the API with a ‘W’ suffix (Wide/Unicode)
  • Retrieving an address of the API with a ‘A’ suffix (ANSI),
  • Retrieving an address of the API with no suffix at all (ANSI, assumed)

What it means (practically) is that if you supply an API name with a ‘A’ or ‘W’ suffix, the sequence of API name resolving is going to look like this:

  • FunctionNameAW
  • FunctionNameAA
  • FunctionNameA

or

  • FunctionNameWW
  • FunctionNameWA
  • FunctionNameW

Knowing the way rundll32.exe accepts and processes the API function names is actually very helpful – especially when you are calling functions that require Unicode strings as an argument…