[EAS] Password Cracking Basics

[John Willkie]

I stated "Computers running and Windows Update have have about zero code-based intrusions in the last decade." because there was a mindless trope to the effect that "replacing windoze will solve everything"
 
Alan Hartman replied with shovelware.  I'll only address the first four links.  Three are for applications that are made by MS but run under windoze.  Off-topic; I was speaking of the operating system.  If someone is watching Debbie Does Dallas and writing using a cribbed copy of Word on a computer running an EAS or PSIP application, that's on them. 
 
One link was for a real security issue: the lately-announced GDI+ vulnerability.  Of course, this involves a feature that is only used in applications that display graphical information (like a graphical user interface) and that need dynamic graphics updates (GDI+) and the only way to make use of the exploit would be to access a web page.  Computers running embedded applications like those used in broadcast operations should never have a browser and should only access data that is stored locally and which passed through all the other protections in the system.
 
I did say "close to zero" but I should have said "close to zero in cases that are exploitable in real life." 
 
This particular area -- the exploitation of vulnerabilities discovered after the OS was installed -- is something that only Apple and MS seem to have solutions for, and Apple is by far the laggard.  Updating FreeBSD, Apache, Linux (except for Debian; perhaps others) automatically, or with minimal operator involvement.
 
You get the idea, I hope Alan.  A specialist tends to have better knowledge than a generalist.  And, to say that Windows is a stiched-together system isn't really true, and to the extent it's true, it isn't relevant.  All OS's use plug-in modules, and with *nix that is easier than with windoze. 
 
As for there being a delay between use of an exploit in the wild and Microsoft patching it, you are counter-factual.  In all but the GDI+ exploit, all were patched weeks to months before any attempt to exploit.  In recent years, virtually all day zero exploits went through Flash and Java.  Yet, idiots still load those on dedicated professional machines.  This is why systems need to be locked down to prevent customers from compromising them. 
 
"Simple PAM hash" sounds like MD5; sorry, SHA1 is the minimum.  But, passwords need to be salted as well, to defeat rainbow tables that greatly simplify and shorten the time to derive a password from a hash.  MD5 has turned out to not be mathematically secure.
 
Security design rests solely within the hands of the vendor, whether they realize it or not.  "We use Unix" just means "we don't pay much attention to security." Security practice is solely in the hands of the customer.  Hopefully, the vendor retained the ability to wipe out all customer security changes.  My customers would just be required to swap their existing SSD with our replacement unit.
 
As for programming practices, I suspect you last looked at code before everything became "modular."  Modern programming practices involve modules (functions, subroutines) with defined interface elements, but with the inputs and outputs sealed.  If you change the properties of an interface element, the development environment tells you every element that needs to be changed.  Using properties or sub-elements that aren't present in the interface will cause exception messages or halt execution.  Those tend to show up quickly.
 
Most modules are cracked for a simple reason: no proper exception handling, and an element permits more data to be inserted into the module than the module can handle.  (This is platform-independent, it even happens in old silicon).  So, the program chokes on the overmuch data, then it starts to process raw instructions that are located just one byte beyond the data that broke the program.  With proper exception handling, the exploit wouldn't work.  By setting the maximum size (at the point of input) that the data should be, this exploit won't work a single time.
 
My modules have all been run a few million times, and I've tried to inject bad or overmuch data.  Unfortunately, all user data goes through the bulletproof user interface, and all outside data goes through SQL server.  If the data is in an unexpected format, nothing happens.  This is by design: don't give any feedback to hackers. 
 
It takes a long period of time and testing to get secure code.  There is no real way to shortcut that.
 
If you think it's easier to code (and 'sanitize' code, whatever that means) in Unix, well, then you are decades behind the curve.  But, that's what *nix seems to be about.  True dat, unix programmers don't need to worry about GDI+ or even graphical user interfaces.
 
Effectively, all computer languages are cross-platform these days, but c++ is the least platform independent language out there.  You actually meant to mention c in this regard, not cpp.  Even a VB programmer can write code that runs under windoze on all those machines, and runs under Mono on *nix machines. 
 
The ability to reverse engineer is not a function of how "secure" a codebase is, and then you conflate that with license terms.  Object code security is put into the build, not the code. And, you alluded roughly to the "copy left" provision of SOME open source licenses.  That's well off-topic and orthogonal to this discussion. 
 
There are two basic types of code: proprietary and open-source, and there are combinations, with or without regard to copyleft.
 
As to your assertions about ports.  I was speaking about the innate requirements inherent in ports.  Of course, it depends on the software: some was written by ignorant programmers with no sense of interoperability or "working well with others" and some was written by programmers versed well in the art.  If a PSIP generator is monitoring port 3821 for PMCP messages, then no other application can administer that port.  But, just because one remote device requires PMCP output on a particular port, does not mean that very same port can be used for other traffic using other protocols to other remote devices in the time when PMCP isn't being transmitted. 
 
As for echo, etc.  this is legacy hangover.  These are the commonly-used port assigment for commonly-used (if only at one time) services on the computer. There are 7 -- count them -- Internet standards published by IANA.  Not a SINGLE provision in any RFC "requires" anything.  They are written in the manner of, "if you want to do this this way, then you use this port for this, with this protocol and we think it should work this way."  Sorry to delve into standarditus here, but there is a significant difference between a standard and a recommended practice, and RFCs are suggested recommended practices.  Recommended practices can never mandate anything; standards tend to have mandatory requirements.
 
Indeed, the IANA has stopped issuing even most "common port registrations " http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
 
Cracking a windows ACL requires, as I stated, three levels of decryption, without talking about session keys and how to derive passwords.  And,you point back to shovelware in your assertion that windows in insecure.  You do know that security breaches can and do flow back to Microsoft in winqual reports, right?  But, I was asing for code, not commentary. 
 
As for the lockout approach, just the other day, I was trying to get into a copy of windows using my regular "processing" passwords.  I noticed on the fifth attempt, it took about 30 seconds to tell me that one wasn't good.  In the end, I wiped the drive.  All important customer-facing passwords are written down, stored securely and available in mutiple ways.
 
And, I offer this nit to the third picking because I find very few people conversant in the real world of computer security seem to address the false notions of those who know less than they do in this area.  I am always ready to learn more about computer security. 
 
As for the "social engineering" part, that's old-hat.  It's been replaced by people supposedly in my support department sending me email with hostile attachments that would bypass all that.  Social engineering takes time, and native Chinese speakers aren't all that good at it.   I got one yesterday from "finance" or was it "LinkedIn.com password" that said the ACH payment was cancelled, and here's the details.  Eventually, these buzz-phrase bound hackers will realize that Linkedin.com doesn't hold passwords for any company's accounting systems. 
 
Speaking of intrusions, does anybody remember the time the Chicago TV STL was hijacked?  I read all sorts of crap at the time as to how (security theater) new security measures were happening everywhere in TV-land.  Really, I asked?  How do you protect an STL path from a closer-in, more powerful transmitter drowing out the remote transmitter?
 
This is just another way for a malefactor to insert dirty words and images into your service.
 
Best;
 
John
 

illkie at etherguidesystems.com
telephone (Google Voice) +1 619 567-9486
skype: jmwillkie
Google Plus: John Willkie