Last Updated: 2019-07-10 13:50:14 UTC
by Rob VandenBrink (Version: 1)
Samba 4.11 (preview release) came out 2 days ago (4.11p0). Not huge news you say, except for one detail - the default settings on this version now have SMBv1 disabled. Better yet, they've started to set the stage for removing it completely.
Yes, 2 years after WannaCry, Petya, NotPetya Eternal-everything and all the rest, they've come around and joined the party. Mind you, this does not change any settings on existing installations, fixing those is still a manual change.
Hopefully you've used tools like NMAP (nmap -p445 --open <your subnet here> --script smb-protocols.nse) to find and fix any hosts that still support SMBv1, which hopefully includes and *nix/SAMBA hosts in your environment. I'm also hoping that you've scanned any "storage appliances", which mostly are Linux + SAMBA + iSCSI under the covers. If you haven't done these scans and remediations, you've likely had a some bad days over the last 2 years.
If you require SMBv1 support in Samba, the team requests that you let them know via a bug report. This gives them the feedback they need to work on scheduling the deprecation and final removal process for the protocol.
Anyway, good news from the Samba project, and better days ahead!
Full release notes are here: https://github.com/samba-team/samba/blob/59cca4c5d699be80b4ed22b40d8914787415c507/WHATSNEW.txt
Last Updated: 2019-07-10 13:49:46 UTC
by Rob VandenBrink (Version: 1)
I got to thinking about file dumps in hexadecimal this week. This is something I do at least a few times a week - usually to look at file headers or non-printable characters for one reason or another.
File headers will usually let you know what type of file you're looking at (no matter what the file extension is). More here on that: https://linux.die.net/man/1/file
When looking at or for non-printable characters, this can be for any number of reasons, but almost always it's to figure out what some crazy application is doing with CRLF (Carriage Return / Line Feed) so that I can fix the output to properly feed the next script or tool, or so that Word will read it correctly (which I guess is the same thing).
Anyway, the go-to tool for this is XXD:
# xxd /usr/bin/vi | more
More on XXD here (or type"man xxd"): https://linux.die.net/man/1/xxd
If you're on a stripped-down Linux version, something like busybox, XXD won't be there (it comes with VIM, not VI), but often those distro's will still have the "hexdump" command:
# hexdump -C /bin/vi | more
But what if you're on a customer Windows host? And what if they haven't installed any of the Linux tools? Well, as you might guess, "PowerShell to the rescue!" Powershell's "format-hex" command gives you much the same output:
PS C:\> Get-Content \windows\system\cmd.exe |format-hex |more
00000000 4D 5A 3F 00 03 00 00 00 04 00 00 00 3F 3F 00 00 MZ?.........??..
Better yet, format-hex handles multiple encodings, so if you have a specific character encoding to work with, "-encoding" is your friend! The default is UTF8BOM (for "byte order marker"), "unicode" encoding will give you UTF-16
The full "format-hex" docs are here (along with dozens of other places that google will find for you): https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.utility/format-hex?view=powershell-6
(or "get-help format-hex")
More on the various encoding options here: https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.codepage?view=netcore-2.2
If you've seen a situation where you needed a different method to accomplish this task, please use our comment form to share!!