Articles

Security Articles

Posted by Dave
Independent Security Specialist
Toymaster Security Lab
Member Microsoft ITAC
Member WhiteHat
toymaster@att.net

 

 *********************************

 

 

 

 

Reading URL’s

03/24/13

 

I have covered this subject before, but it has been quite a while so I thought a review was in order, especially since many of us are always in a hurry and click on links without really reading them or knowing where they will take us.  Consider what is offered below as part of your heightened awareness of browsing safety and security.  It just might help you avoid getting more than you bargained for.

 

Basics

 

• URL stands for Uniform Resource Locator and is the ‘address’ of a website.
• http stands for Hypertext Transfer Protocol, the set of rules used to access information on the web.
• www stands for World Wide Web, the set of documents residing on computer servers around the world which are made accessible by http.

 

In general, there are up to four parts to a URL.  A URL, or web address, stands for Uniform Resource Locator. URLs give Internet users a standard format for sending and receiving a wide variety of information. Understanding URLs will help you figure out what kind of organization or institution the information is coming from and from there you can decide whether or not it is where you really want to go.

 

URLs are constructed in four sections and look something like this:

type of transfer://servername.domain/directory/subdirectory/filename.filetype

 

Every URL will have the first two parts, but the third and fourth parts may not be present.  A good example of a common two part URL is

https://isc.sans.edu// which is the address of the SANS Internet Storm Center.

 

First part – type of transfer, “protocol://”

 

The first part of the URL is an indication of what kind of information is being transferred, known as the protocol, and defines what Internet protocol is required to reach the online resource.

 

• http:// - Hypertext Transfer Protocol - used to access a server that is supporting the WWW protocol (i.e. web server) - commonly used for downloading web pages and associated imbedded elements
• https:// - Technically, it is not a protocol in itself; rather, it is the result of simply layering the Hypertext Transfer Protocol (HTTP) on top of the SSL/TLS protocol, thus adding the security capabilities of SSL/TLS to standard HTTP communications.
• ftp:// - File Transfer Protocol - used to download a file from a server supporting the FTP Protocol - commonly used to download a software program
• news: - Used to access a usenet newsgroup from your news server - Your web browser  must be configured to access a specific news-server
• telnet:// - Establish a telnet session ( terminal emulation) to the specified host (often a VT100 Session)
• mailto: Initiates an outgoing email message to the address specified
• gopher: gopher format, text only precursor of the Web

 

 

 

Second part – computer and domain name, “computer.domain.name”

 

The second part of the URL tells you where a Web site resides and identifies the owner of the website. When a website is registered, it must use an established domain type.  This part of the address sometimes includes the name of the machine, the domain (where the computer lives), and the home country of the computer. It can also include the IP address of the server or computer. 

 

This part of the URL will show you not only where the information is coming from but whether or not the source is an educational (.edu) institution or commercial (.com) service.  Other common sources are: (.org [reserved for non-profit organizations]), (.net) [sponsor of the website], (.gov) [governmental], (.us) (.ca) (.ru) etc. which tells you the country of origin.

 

 

Third part – pathname, “/pathname/”

 

The third section of the URL shows you the place where the page you are looking for lives. If the directory or subdirectory begins with a tilde (~), looks like a person's name, and follows a directory called "users" or "people," the page is probably living on someone's personal Internet account. For example: http://home.comcast.net/~itdave/site/ is the address of my personal site: Toymaster Security Lab.

It usually consists of directory/subdirectory names. This defines where on the server's hard disk to look for the information.  Note that not all personal pages are indicated by a ~.  htm or html stands for Hypertext Markup Language, a language (computer code) used for writing web pages.

 

 

Fourth part – filename.filetype, “filename.ext”

 

The final part of the URL specifically names the individual document or file you are looking at.  If no specific filename is indicated, a file called "index.html", "default.html", or "home.html" may be downloaded if present. The ".ext" file extension cues the web browser on how to handle the downloaded file. The web browser can display some file-types within the browser display area, or it may invoke additional software such as a "plug-in" or external "helper application" to handle the file. Common file extension names include:

 

•   .html, .htm - Hypertext Mark-up Language ( a web page) ·
•  . gif, .jpeg, .png, .bmp - A picture ·
•  . wav, .au, .aif - A sound file ·
•   .mov, .avi, .mov, .mpg, .qt - a video clip ·
•   .exe - An executable program for DOS/Windows (might be a self-extracting archive) ·
•   .zip - A compressed archive based on pkzip (commonly used for DOS/Windows), these files will be downloaded onto your hard drive; your computer may not be able to interpret them, and you may need to get an "unzipping" utility like WinZip or 7zip.
•   .hqx - A file that has been "Binhexed" (commonly used for Macintosh archives)
•   .jar – A Java archive, executable Java file
•   .tar - (derived from tape archive) is both a file format (in the form of a type of archive bitstream) and the name of a program used to handle such files. The format was created in the early days of Unix.  TAR files are directories that hold multiple data files. Though most TAR files are created on Unix-based computers, they can be extracted on Windows and Mac as well. The multiple extension ".tar.gz" at the end of a file name indicates a file in the TAR format compressed for a smaller file size, according to the FileInfo website. Compressing TAR files makes it easier to send multiple files over the Internet. If you get a compressed TAR file, you will need to extract the contents using a file compression program.

 

 

 

Help with shortened URL’s

 

Shortened URL’s are becoming increasingly common, so I thought it would be beneficial to show you how to best deal with them and know where you are actually going before you click on a link.  The following tips should hopefully help.

 

Social-engineering threats are rapidly growing, and the security vulnerabilities of sites that regularly use abbreviated URLs have become a major contributing factor.  Anyone who reads Twitter or Facebook posts is familiar with shortened cryptic looking URLs such as bitly, tinyurl, and snipurl.  Because they are shortened to seemingly random letters, numbers, and characters, you don't know where they're actually taking you.  All too often, we are impatient and tend to click them anyway.

 

You can actually preview shortened URLs to see their true destination.  The trick is in knowing what to do and how to do it.

 

For bitly addresses, paste them into your browser and add a + after the URL.  For example, //bitly.com/{xxxxxxx}+ and press Enter.  Adding the plus sign takes you to the bitly site first, where you will see a stats page for the destination site.

 

For tinyurl addresses, you add "preview" before the address. For example, enter //preview.tinyurl.com/{xxxxx}, and the actual full address will appear at the tinyurl site.

 

For snipurl addresses, add "peek" before the shortened address. For example, //peek.snipurl.com/{xxxxxxx} takes you to the Snipurl site and displays the full URL.

 

For any link - short or long - in a webpage, hover your cursor over the link and the true, full address should appear at the bottom of the browser window.  If it looks odd or suspicious, don’t just click and go there, make sure you know where you are going.

 

 

I have one final tip for you:

Always be sure that after you click on a link and the page opens, you double check the address displayed in the address bar to be certain it is where you expected to be.  I say this because of a new trick in which our old friend Java Script can be used to alter your final destination even after you click on a link.  Consider the following short script that can be embedded for a link (and you will not see this when you hover over it either) on a web page;

 

var links = document.links;

for (i in links) {

      links[i].onclick = function() {

            this.href = ‘http://example.com/hmm.html’;

    };

}

 

Then, also embedded on the web page HTML coding is the corresponding href (hyper-reference) of the tag that is called for in the above script, called an anchor tag where the is the anchor attribute:

 

  

<a href=”http://example.com/here.html”>HERE</a> which would be a clickable link displaying "HERE"

 

 

 

 

This portion of the programming is what changes the onclick event attribute of the link on the page so the link you hovered over and clicked on takes you where I want you to go regardless of what the link says or displays as.

 

In the above script coding, example.com is where I really want to send you regardless of what the link showed when you hovered over it.  This sort of event driven programming is what makes current modern browsers behave the way we have demanded and expected them to.  Unfortunately, however, this illustrates another way in which they can also be abused.

 

The above scripting trickery will work on most current browsers, and I include Internet Explorer 9 and 10 in this list.   We will have to wait and see how the browser programmers respond to this information and what they do to prevent this kind of browser abuse.

 

In any case, always remember to check your browser address bar to be sure that where you are is where you wanted and intended to be.  And as a final tip - using Firefox with the NoScript add-on negates this issue entirely for you as the script that would have taken you to a different site will not be allowed to run.

 

 

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

 

 

UPnP can make you and your network vulnerable

 

01/29/13

 

 

 

According to the security team at Rapid7 (home of HD Moore and Metasploit), technology used worldwide in both routers and standard networking equipment is making it possible for hackers to potentially infiltrate approximately 40 to 50 million devices worldwide.

 

The vulnerability comes from the UPnP standard (Universal Plug and Play) which is a set of networking protocols that allow devices, such as PCs, printers and Wi-Fi access points to communicate and discover each other's presence. After discovery, devices can be connected through a network in order to share files, printing capability and the Internet.

 

Rapid7 released a whitepaper that indicates while UPnP might make network setup cheaper and more efficient, it harbors a severe security risk, something that some security researchers have been aware of for some time, and gives them incentive to lock down the ports that these protocols and services use as soon as the network is set up. 

 

The paper covers programming flaws in common UPnP discovery protocol (SSDP) implementations which can be exploited to crash the service and execute arbitrary code, the exposure of the UPnP control interface (SOAP) on private networks, and programming flaws in both UPnP HTTP and SOAP overall.  The paper also discusses the UPnP SOAP service that provides access to various functions that should not be allowed from untrusted networks or the open internet because the service opens ports (holes) in a firewall.

 

Using this, hackers could access confidential documents, steal usernames and passwords, take over PCs, and remotely access networked devices, such as webcams, printers, televisions, security systems, and other devices plugged in or wireless connected to networks.

 

US CERT recommends affected UPnP device vendors and developers obtain and employ libupnp version 1.6.18, which addresses these vulnerabilities.  The risk is that hackers could execute arbitrary code on the device or cause a denial of service, or install malware on your computer and/or run it as part of a botnet.

 

The DHS is concerned that the vulnerability could impact millions of machines, and warns users to update their software or disable UPnP altogether.  It then says to "disable UPnP (if possible)," along with restricting networking protocols and ports, including Simple Service Discovery Protocol (SSDP) and Simple Object Access Protocol (SOPA) services from untrusted networks, including the Internet.

 

Many, if not most, network and networking devices use UPnP including computers running Windows, Apple OS X, and Linux.  Many mobile devices also use UPnP to print to wireless or networked printers used in both homes and businesses.

 

The US CERT Vulnerability Note VU#922681 is here: http://www.kb.cert.org/vuls/id/922681 and it recommends applying libupnp 1.6.18 which has been released to address these vulnerabilities.  It further recommends deploying firewall rules to block untrusted hosts from being able to access port 1900/udp.  The advisory further suggests users &/or administrators consider disabling UPnP on the device if it is not absolutely necessary.

 

Most networking and many networked devices use UPnP, including computers running Windows, Apple's OS X, and Linux. Many mobile devices also use UPnP to print to wireless or networked printers. 

 

Rapid 7 security specialist HD Moore has a blog posting with some of the technical details and indications that their scanning efforts returned over 80 million unique IPs identified that responded to UPnP discovery requests from the internet. Somewhere between 40 and 50 million IPs are vulnerable to at least one of three attacks outlined in the paper.  It goes on to say “The vulnerabilities we identified in the Portable UPnP SDK have been fixed as of version 1.6.18 (released today), but it will take a long time before each of the application and device vendors incorporate this patch into their products. In most cases, network equipment that is "no longer shipping" will not be updated at all, exposing these users to remote compromise until UPnP is disabled or the product is swapped for something new. The flaws identified in the MiniUPnP software were fixed over two years ago, yet over 330 products are still using older versions.”

 

Rapid 7 has created a document available here: https://community.rapid7.com/servlet/JiveServlet/download/2150-1-16596/SecurityFlawsUPnP.pdf

as well as offering a free network scanner [http://www.rapid7.com/resources/free-security-software-downloads/universal-plug-and-play-jan-2013.jsp] for use on both home and business network capable of scanning the entire network looking for open ports that respond to UPnP requests, and also if the ports are vulnerable to exploitation. 

 

If you haven’t ever scanned your network for this type of vulnerability I can heartily recommend the above scanner – it is both fast and accurate.  I personally use different scanning tools on my networks and secured the ports against outside access a number of years ago.  Testing the above Rapid 7 scanning tool, a scan of all five networks at work showed only two IP addresses (out of 764) that responded at all, and the addresses returned a not exploitable result (both IP addresses were Lanier printers).  My home lab returned a flat zero.  As a tip, if you intend to use Nmap to scan the network for hosts replying to and supporting UPnP, but be advised you will need a NSE script that sends an "M-SEARCH" request to trigger a response as a UPnP listener will not respond to a typical "empty" Nmap UDP scan.  In any case, if you have not scanned your network, no matter how small, I strongly advise that you do, and then secure whatever vulnerable ports and addresses are found.

 

The research and scanning by Rapid 7 revealed that around 40-50 million network-enabled devices are at risk due to vulnerabilities found in the Universal Plug and Play (UPnP) protocol. UPnP enables devices such as routers, printers, network-attached storage (NAS), media players and smart TVs to communicate with each other. Three groups of security flaws in the protocol are exposing millions of users to remote attacks.

 

One of my biggest concerns is for modems and routers supplied by ISP providers that end users may not be able to access, or may not have privileges allowing them to turn off UPnP or configure ports.

 

 

Although no widespread attacks have currently been discovered or reported, now that this is public knowledge I suggest you make this little project a top priority before attacks are launched.

 

 

 

 

 

 

 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

 

 

 

NetBIOS

 

01/25/12

 

If you have been with the site or the security mailer for a few years, you should already know my stance on NetBIOS and my recommendations to make sure that NetBIOS over TCP/IP is turned off if possible – the ‘feature’ is turned on by default in Windows including Windows 7.  Unfortunately, depending on configurations, some networks will not function properly if these services are turned off.  Experiment first, then roll it out if successful.

 

The NetBIOS weakness has been well known since 2005, yet it remains in every version of Windows and allows for very easy spoofing attacks.  The old attacks don’t work anymore, but new ones most certainly do.  It is easy to forget about this, especially when you get a new machine, so after reading through this, take a minute to be sure it is turned off on your machine(s), all of them.

 

I also strongly recommend disabling support for LanMan (LAN Manager) Hash as well.  How to make sure both NetBIOS over TCP/IP is turned off and support for LanMan Hash is disabled will be covered in an accompanying article in order to assist those that may not be familiar with these services and settings.

 

The following recent post on this subject from Bojan at SANS –

 

Is it time to get rid of NetBIOS?

Published: 2012-01-24,
Last Updated: 2012-01-24 22:29:25 UTC
by Bojan Zdrnja

 

 

NetBIOS, and its weaknesses that allow extremely easy spoofing have been well known all the way since 2005. I recently discussed NetBIOS with a colleague of mine, Arcel, and this discussion prompted me to see if anything changed with NetBIOS and recent Windows releases.

While I was almost certain that the old NetBIOS spoofing attacks do not work any more, I was stunned to see that even the latest and greatest Windows 7 still enable NetBIOS over TCP/IP by default.

In today’s interconnected world, where we jump from one (wireless) network to another, this might have serious impacts on our security. The question is it time to get rid of NetBIOS sounds logical. Let’s see what’s happening here.
Starting with Windows 2000, all Windows operating systems (XP, 2003, Vista, 7, 2008) depend mainly on DNS to resolve network names. However, if DNS is not working, or the name cannot be resolved, Windows will try to use NetBIOS to resolve such network name.

Now, if a WINS server has been configured this should not be a problem, but in case when a WINS server is not present (or available), Windows will still try to use NetBIOS to resolve a network name. In such cases, Windows will send a NetBIOS Name Query packet, which is an UDP packet sent to a broadcast address. You can see one such packet in the screenshot below:

 

 

 

 

You can probably guess what an attacker can do – since this is a broadcast packet, the attacker does not even need to perform other initial attacks such as ARP poisoning. He can simply send a NetBIOS Name Query Response with any contents he wants! As a matter of fact, even a Metasploit module exists that does this automatically (see auxiliary/spoof/nbns/nbns_response).

Now, the question that we have to think about is what attack scenarios are we dealing with here? Here come a few, judge for yourself how serious they are:

1. Whenever a user mistypes a network name, the attacker can spoof the response. Depending on what the user tries to access (i.e. a SMB share or a web page), the attacker can use another Metasploit module in order to catch exchanged credentials. Keep in mind, though, that only hashes are exchanged here so the attacker still needs to crack the original user’s password (or try to perform some relaying attacks).
    
2. One of the names that is particularly sensitive is WPAD. It is used by web browsers for automatic retrieval of proxy settings. In a scenario where we connect to an open wireless network, where the local DNS server does not have this name registered, an attacker can spoof the WPAD’s entry’s IP address and further even serve a fake wpad.dat file. This would allow him to inspect the victim’s web traffic!
    
3. A lot of companies like to set their user’s home page in browsers (i.e. Internet Explorer’s home page). Now, when the user opens Internet Explorer on a malicious network, Internet Explorer will try to resolve that name. Since that name is usually something like “intranet” or “intranetweb” DNS will , of course, fail to resolve it. This gives the attacker an opportunity to fake this name. And what’s even worse, Internet Explorer will automatically send user’s credentials to the resolved web page, since it will consider it to be in the Local Intranet zone. The picture below shows my fully patched Windows 7 machine falling prey for this attack and trying to retrieve wpad.dat as well as giving my test account’s credentials when I opened http://intranet:

 

 

 

As you can see from the scenarios mentioned above, this “vulnerability” can be extremely serious. To make things even worse, if you use an older operating system such as Windows XP, and you haven’t disabled LANMAN (LM) hashes, cracking them in such a case is trivial. Luckily, as you can see in the picture above, Windows Vista and above disable LANMAN hashes by default, so only much stronger NTLMv2 is used. Still, if your password policy is inadequate, an attacker can crack such passwords.

So what can we do to protect ourselves and our users against this? This is one of those times when auditors that bug you about settings and configuration are really right:

1. Unless you moved everything to Windows Vista or newer, make sure you disable LANMAN hashes. They are insecure and should not be used under any circumstances.
    
2. Disable NetBIOS over TCP/IP. I don’t think that anything really uses this any more (if I’m wrong let us know please!)

If you want to learn more about this attack, read the excellent post at http://www.packetstan.com/2011/03/nbns-spoofing-on-your-way-to-world.html and, once you get scared enough, take care of your network and users.

 

 

 

=======================================================

 

 

 

Disable NetBIOS over TCP/IP and Disable LanMan Hash Support

 

01/28/12

 

 

In another article (NetBIOS) we looked at NetBIOS support over TCP/IP and the dangers present when it is enabled, and I also said that I recommend disabling support for LanMan Hash as well.  This article will cover how to accomplish both which results in lower network traffic and a safer more locked-down machine.

 

First, what the heck is NetBIOS. NetBIOS is an ancient session-level interface and transport protocol developed by IBM to network together PCs. It is a broadcast-based, non-routable and insecure protocol, and it scales poorly mostly because it was designed with a flat namespace. Since the late 1980s Microsoft has adopted NetBIOS for their LAN Manager product, and from there it found its way into early versions of Windows and all the way into Windows NT.

NetBIOS provides three distinct services:

• Name service for name registration and resolution (port: 137)
• Datagram distribution service for connectionless communication (port: 138)
• Session service for connection-oriented communication (port: 139)

Since Windows 2000 however, DNS has become the default name resolution method for Windows-based networks and is required if you want to deploy Active Directory domains.

Although Windows 2000, Windows XP, and Windows Server 2003 provide for the ability to disable NetBIOS over TCP/IP (NetBT), many corporate networks will remain reluctant to do so because of the fact that most of them still have legacy (Windows 9x or Windows NT) machines on their network. These machines need NetBIOS to function properly on a network because they use NetBIOS to logon to domains, find one another, and establish sessions for accessing shared resources. But for networks that are "free" of legacy systems you may want to consider disabling the NetBT transport altogether on all computers (it can be easily accomplished by using DHCP) or at least on critical file and print servers.

Please keep in mind that many networks today still have a need for NetBIOS communications even if there are no legacy systems in place, so make sure you check with your network administrator before trying to do anything in this article to avoid breaking things.  If you have a home network secured by a properly set up router, this should not be an issue, and you can have confidence in having the local machines follow the DHCP ‘server’ settings without any undo risk.  This article is mainly intended for use by individual private users without a network or a home network.  This is especially important to know how to do when using a laptop or tablet at a WiFi hotspot or public network that may not be secured. 

In order to disable NetBIOS over TCP/IPin Windows 2000/XP/2003 you should right-click on My Network Places and select Properties. Then right-click on the appropriate Local Area Connection icon, and select Properties.

 

 Next, click on Internet Protocol (TCP/IP) and Properties

 

 

 Now click Advanced

 

 

 And select the WINS tab.  There you can enable or disable NetBIOS over TCP/IP

 

 

 

The changes take effect immediately without rebooting the system.

Optionally, you can select the Use NetBIOS setting from the DHCP server if you are using a DHCP server that can selectively enable and disable NetBIOS configurations through DHCP option types. NetBIOS over TCP/IP can also be disabled for computers that are running Windows 2000/2003 by using the advanced DHCP option types that are supported by the Windows 2000/2003 DHCP Server service

 

 

 

 

Note: Computers that are running an operating system prior to Windows 2000 will be unable to browse, locate, or create file and print share connections to a Windows 2000/XP/2003 computer with NetBIOS disabled.

 

**********

 

Potential Problems

We are primarily talking about older legacy system issues, and please don’t even think about running WINS these days, but I thought it best to cover anyway

·         Computers Running Windows 2000

The computer no longer listens for traffic to the NetBIOS datagram service at User Datagram Protocol (UDP) port 138, the NetBIOS name service at UDP port 137, or the NetBIOS session service at Transmission Control Protocol (TCP) port 139.

If the computer needs to participate in WINS as a client, it must be physically multihomed (that is, it must have other physical network connections active and available for its use) for it to continue communicating with and using a WINS server.

·         Computers Operating as WINS Clients

The computer can no longer function as a WINS server to service WINS clients over the connection unless NetBT is re-enabled.

For those adapters to use WINS, you must either manually configure a list of WINS servers on the NetBT-enabled connections or provide such a list to these connections from a DHCP server.

Note: WINS servers that are configured in TCP/IP properties for the disabled network adapter do not apply for other installed network adapters.

·         Down-Level Clients, Services and Programs

NetBIOS defines a software interface and a naming convention, not a protocol. NetBIOS over TCP/IP provides the NetBIOS programming interface over the TCP/IP protocol, extending the reach of NetBIOS client and server programs to the WAN, and providing interoperability with various other operating systems. The Workstation service, Server service, Browser, Messenger, and NetLogon services are all direct NetBT clients. They use TDI (Transport Driver Interface) to communicate with NetBT. Microsoft Windows NT and Windows 2000 also include a NetBIOS emulator. The emulator takes standard NetBIOS requests from NetBIOS programs and translates them to equivalent TDI primitives.

Windows 2000/XP/2003 uses NetBIOS over TCP/IP to communicate with prior versions of Windows NT and other clients, such as Microsoft Windows 95. Careful testing should be done before disabling NetBIOS over TCP/IP in any production environment. Programs and services that depend on NetBIOS no longer function after you disable NetBT services, so it is important that you verify that your clients and programs no longer need NetBIOS support before you disable it.

·         Cross-Forest trusts

NetBIOS is still used in the trust creation process. Forests that have the same NetBIOS name for their Forest Root Domains will not be able to create trusts between them, and the only method around that is to re-install one of the forests and to re-create it from scratch.

·         Pre-Windows 2000 Logon names

NetBIOS is also used in the Windows domain logon screen, and it will not allow you to log on to domains that happen to have similar NetBIOS names. It will only show you the first domain and will not let you select the other domain names. This can be worked around by logging on with the User Principal Name (UPN) in the logon box, for example joesmith@test.com.

 

**********

 

SQL Server 2005

 

·  From the Start menu, right-click My Computer, and then click Manage.

·  Expand System Tools, and then clear the Device Manager check box.

·  Right-click Device Manager, point to View, and then select Show hidden devices.

·  Expand Non-Plug and Play Drivers.

·  Right-click NetBios over TCP/IP, and then click Disable.

This disables the SMB direct host listener on TCP/445 and UDP 445.

 

**********

 

More from Microsoft –

 

Disable NetBIOS on the DHCP server

To disable NetBIOS on the DHCP server, follow these steps:

1. Click Start, point to Programs, point to Administrative Tools, and then click DHCP.
2. In the navigation pane, expand the server_name, expand Scope, right-click Scope Options, and then click Configure Options.
   
   Note In this step, the server_name placeholder specifies the name of the DHCP server.
3. Click the Advanced tab, and then click Microsoft Windows 2000 Options in the Vendor class list.
4. Make sure that Default User Class is selected in the User class list.
5. Click to select the 001 Microsoft Disable Netbios Option check box, under the Available Options column.
6. In the Data entry area, type 0x2 in the Long box, and then click OK.

 

Configure the DHCP client to enable the DHCP server to determine NetBIOS behavior

For Windows XP, Windows Server 2003, and Windows 2000

1. On the desktop, right-click My Network Places, and then click Properties.
2. Right-click Local Area Connection, and then click Properties
3. In the Components checked are used by this connection list, double-click Internet Protocol (TCP/IP), click Advanced, and then click the WINS tab.
   
   Note In Windows XP and in Windows Server 2003, you must double-click Internet Protocol (TCP/IP) in the This connection uses the following items list.
4. Click Use NetBIOS setting from the DHCP server, and then click OK three times.

For Windows Vista

1. On the desktop, right-click Network, and then click Properties.
2. Under Tasks, click Manage network connections.
3. Right-click Local Area Connection, and then click Properties
4. In the This connection uses the following items list, double-click Internet Protocol Version 4 (TCP/IPv4), click Advanced, and then click the WINS tab.
5. Click Use NetBIOS setting from the DHCP server, and then click OK three times.

For Windows 7

1. Click Start, and then click Control Panel.
2. Under Network and Internet, click View network status and tasks.
3. Click Change adapter settings.
4. Right-click Local Area Connection, and then click Properties.
5. In the This connection uses the following items list, double-click Internet Protocol Version 4 (TCP/IPv4), click Advanced, and then click the WINS tab.
6. Click Use NetBIOS setting from the DHCP server, and then click OK three times.

Windows 7 screen shots –

 

 

 

 

 

Finally, is there a quick and easy way to tell if turning off NetBIOS over TCP/IP has caused any problems for you on the network?  Yes.  On the desktop, open your network locations and view the entire network.  If you can see the other machines on the network, all is well.  If all you can see is the machine you are sitting at, it broke network communications and NetBIOS over TCP/IP will unfortunately need to be re-enabled.  If this is the case, sorry, but it was definitely worth the shot taken.

 

 

 

===================================================

 

 

Now that NetBIOS is turned off, let’s turn our attention to LanMan

 

This should not cause any networking issues of any kind, but check first with your network administrator before attempting any changes

 

Disable Support for Lan Manager (LanMan) Hash

 

Windows systems before Windows Vista/Windows Server 2008 still compute and store the LAN Manager (LanMan) hash by default for compatibility. Due to the security weakness of the Lan Manager hash, configure your computers to not store the LanMan authentication. Samba configurations should be reviewed to ensure that the LanMan authentication is not stored.

By default, Windows allows a remote user to enumerate (list) the account names and shares without use of any identification via “NULL Sessions”. As this allows potential attackers to find out a lot of information about your computer, it should be disabled.  Samba configurations should be reviewed to ensure that remote users can not enumerate account names and shares via "NULL Sessions".

Instructions for Windows XP

To disable LanMan Support on Windows XP, follow these clicks:

1. Start -> Settings -> Control Panel -> Administrative Tools -> Local Security Policy
2. Expand the “Local Policies” folder and select “Security Options” beneath it.
3. Double click “Network security: LAN Manager authentication level”.
4. Change the setting to “Send NTLMv2 response only\refuse LM & NTLM”.

To disable NULL Sessions:

Still in the “Security Options” folder, double click

• “Network access: Do not allow anonymous enumeration of SAM accounts and shares”, and choose ‘Enabled”.
• “Network access: Do not allow anonymous enumeration of SAM accounts” and choose "Enabled".

To prevent the storage of LanMan hashes within Windows XP:

Still in the “Security Options” folder, double click

• “Network security: Do not store LAN Manager hash value on next password change”, and choose ‘Enabled”.

Restart your computer and change the password for all accounts on the computer.

Instructions for Windows Servers

Note: Windows Vista and Windows Server 2008 still include support for the LanMan hash, although it is disabled by default.

To disable LanMan Support, go to:

1. Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options
2. Double click “Network security: LAN Manager authentication level”.
3. Change the setting to “Send NTLMv2 response only\refuse LM & NTLM”.

To apply the change, run gpupdate /force

To disable NULL Sessions (anonymous access):

Still in the “Security Options” folder, double click

• “Network access: Do not allow anonymous enumeration of SAM accounts and shares”, and choose “Enabled”.
• “Network access: Do not allow anonymous enumeration of SAM accounts” and choose “Enabled”.

To apply the change, run gpupdate /force

To prevent the storage of LanMan hashes:

Still in the “Security Options” folder, double click

• “Network security: Do not store LAN Manager hash value on next password change”, and choose “Enabled”.

To apply the change, run gpupdate /force

 

 

Instructions for Samba

Couldn’t leave out our Linux based friends

To disable NULL Sessions (anonymous access):

For Samba servers there is no direct way of disabling null session access. A workaround is to specify a non exisiting UNIX account in global section of Samba config file.

        guest account = NON EXISTING USER.

        Adding 'restrict anonymous = 2' in smb.conf can help resolve the issue.

To disable Null NetBIOS sessions:

Make the following settings in smb.conf:

• set "security" to "user" or "domain" or "server" as per your requirements.
• set "map_to_guest" to "Never"

For SAMBA 3.0 and Active Directory, make the following settings in smb.conf:

       security = ADS

SECURITY = USER This is the default security setting in Samba 2.2. With user-level security a client must first "log=on" with a valid username and password (which can be mapped using the username map parameter). Encrypted passwords can also be used in this security mode. Parameters such as user and guest only if set are then applied and may change the UNIX user to use on this connection, but only after the user has been successfully authenticated.

SECURITY = SERVER In this mode Samba will try to validate the username/password by passing it to another SMB server, such as an NT box. If this fails it will revert to security = user, but note that if encrypted passwords have been negotiated then Samba cannot revert back to checking the UNIX password file, it must have a valid smbpasswd file to check users against. See the documentation file in the docs/ directory ENCRYPTION.txt for details on how to set this up.

SECURITY = DOMAIN This mode will only work correctly if smbpasswd(8) has been used to add this machine into a Windows NT Domain. It expects the encrypted passwords parameter to be set to true. In this mode Samba will try to validate the username/password by passing it to a Windows NT Primary or Backup Domain Controller, in exactly the same way that a Windows NT Server would do.

References

• NULL Sessions Info - http://www.brown.edu/Facilities/CIS/CIRT/help/netbiosnull.html
• NTLM Authentication Info - http://davenport.sourceforge.net/ntlm.html

 

This should do it for you, and you are certainly a lot more secure than when you started.

 

 

 

 

 

================================================================================

 

 

 PDF - the most dangerous document in the world

 

Arguably the most dangerous document to open for 2011 and the foreseeable future is the well known PDF file.  This is especially true of PDF files found on the Internet and PDF files sent in Email as attachments.  Why do I say this, especially now that Adobe has released Adobe Reader X (v 10.0) that includes a sandbox?  Let’s take a look.

 

First of all, I would like to acknowledge the work of Meredith Patterson, Len Sassman, Moxie Marlinspike, Dan Kaminsky, Didier Stevens and Julia Wolf over the past two years on PDF files.  Their research and postings have been most beneficial to everyone that has read them, and we have all certainly learned a lot from these brilliant experts.

 

The main problem with a PDF is that it is inherently unsafe.  This becomes apparent when one reads through the PDF ISO specification (ISO 3200-1) and you discover that you can indeed really just execute arbitrary programs and code from a PDF.  And, more than just Adobe Reader does this.  Reading through the ISO specification it is also important to note what is not said.  Nothing anywhere in the document addresses whether or not the document is well-formed.  This obviously means a malformed or modified malicious document can still fit the standard, and still be recognized and opened by a PDF reader.  Add whatever executable code you want, embed it in the document, and all you need do is wait for someone to open it.  Bingo, you are in business if you did the job correctly.

 

There are a number of enterprises and large corporations that currently use PDF files as a matter of choice because of their ability to run code.  They embed Java Script and Flash objects all the time in their internal documents.  The company users have become so used to this behavior that they think nothing of it and just click away on any PDF that comes their way.  This is just flat scary to me.  It is also the reason that most targeted attacks use email and malicious PDF attachments as the attack vector of choice, and it happens thousands of times a day, every day.

 

Attackers can also buy advertising that points to some HTML/JS that launches Acrobat in the browser and displays a rigged malicious PDF.  This also happens thousands of times a day.  You actually don’t even need JavaScript or other interactive features to exploit a PDF reader.  There is so much code, lots and lots of code, that it is quite difficult to secure it all.  This in itself makes the PDF an attractive target.  The more code there is, the greater the vulnerability and attack surface.  This is why most successful attacks today involving Adobe Reader are drive-by attacks from the Internet that hit while the user is just surfing along.

 

A brief history of PDF documents-

 

The PDF File Format was created by Adobe Systems in 1993 as a way of representing two-dimensional documents regardless of the application software, hardware, and operating system.  Adobe released PDF 1.0 / Acrobat 1.0 in 1993 and it was slow to gain acceptance until it was realized how truly universal a format it was for sharing documents cross-platform and regardless of hardware.  Adobe began distributing Acrobat Reader at no cost which helped it become the de facto standard for printable documents on the Web.

 

There are also a series of specialized subsets of PDF

 

• PDF/X
• PDF/A
• PDF/E
• PDF/VT
• PDF/UA

 

You can find out more on this most easily on Wikipedia:

 

http://en.wikipedia.org/wiki/Portable_Document_Format

http://en.wikipedia.org/wiki/PDF/A

http://en.wikipedia.org/wiki/PDF/X

http://en.wikipedia.org/wiki/PDF/E

http://en.wikipedia.org/wiki/PDF/UA

 

 

There is also a huge list of available PDF software available today.  Although developed under the same ISO standards, there have been many differing opinions and approaches that have resulted in a huge number of readers, converters, editors, creators, viewers and development libraries.  To get a good idea regarding the programs available you can go here.

 

Sticking with Adobe Reader, mostly because it is the standard and also by far the most popular and most used, there is one other important thing to consider.  Adobe Reader also contains within the reader an Adobe exclusive feature named ActionScript.  It is turned on by default; it has no user available settings, and cannot be turned off.  This, along with the huge code base, has made it a universally attractive target for hackers, especially in the past three years.

 

So, exactly how big is Adobe Acrobat?  At over 15 million lines of code, it is bigger than any browser, and bigger than the entire Linux kernel.  The code was written in Adobe’s labs in the 1990’s and remains largely unchanged with the exception of evolutionary changes and additions making it still bigger.  Another way to look at it is just Adobe Reader itself is a 36 MB install file white Firefox is a mere 8 MB in size.  That makes Adobe Reader 4.5 times larger than the Firefox browser in its entirety.  The end result is a huge attack surface that has resulted in one exploit after another.  In the past three years, there has been an average of one new exploit every 60 days, and many have been 0-day exploits that left Adobe scrambling for a fix while users simply had to wait it out and hope they weren’t hit.

 

Let’s take a minute and look at some examples of PDF files and how easily they can be corrupted –

Open your PDF document with a binary editor, search for references to the root object (/Root), and overwrite the reference (36 in this example) with a non-existing reference, like 00.  You’ll want to be careful and make backups first.

 

 

Tested on several PDF readers, we have the result:

 

 

Not too terribly difficult to corrupt the entire document, was it?  Just two little zero’s in one place did it all.

 

Next we look at an Adobe Reader trick from Didier Stevens.  We are going to look first at a PDF with an embedded file that many PDF documents contain on a normal basis.

Here’s how a PDF document with an embedded file looks like:

 

 

/EmbeddedFiles points to the dictionary with the embedded files:

 

 

As names defined in the PDF specification are case sensitive, changing the case changes the semantics: /Embeddedfiles has no meaning, and thus the PDF reader ignores it and doesn’t find the embedded file.

 

 

This was done by using the –stego option of make-pdf-embedded.py:

 

 

If you want to make it harder to detect, you can use PDF obfuscation techniques. Or maybe embed the file twice with incremental updates. The first version is the file you want to hide, and the second version is a decoy.

 

Using this technique, an attacker can hide one or more files of choice - How about a Trojan or two, and maybe a rootkit to complete the package.  These executable files would launch when the PDF was opened and run in the background, possibly even aided by the embedded ActionScript mentioned earlier, with no indication to the user of any kind.  It all depends on the coding of the hidden files.  That’s often the problem with code executed from within a PDF – there may be no warning or indication to the user of any kind.

 

You may be wondering about Adobe Reader X (v 10.0) at this point with the included new sandbox feature.  Yes, the sandbox would help protect you from the above simple attack.  But, keep in mind that as I have already told you in prior articles that the sandbox is not bulletproof and Adobe Reader X is not yet the main reader of choice for many, many users at this time.  The above attack will most certainly work on any prior version of Adobe Reader and many other PDF readers as well, and many enterprise users are still running Reader 8 because large enterprises are usually very slow to change or upgrade.

 

Now, let’s take a look at a recent special PDF hack from Didier that executes an embedded executable without exploiting any vulnerability.  An Adobe Reader X user will get a warning, but with a little social engineering, I would bet most users would fall for it rather easily.  The example shown below has an embedded file that will simply launch the calculator in Windows.

 

The most current PDF viewers like Adobe Reader and Foxit Reader don’t allow embedded executables (like binaries and scripts) to be extracted and executed without warning the user:

 

 

Didier found another way to launch a command (/Launch /Action), and ultimately run an executable he embedded using a special technique. With the most current Adobe Readers, a launch action needs to be approved by the user:

 

 

He can also partially control the message displayed by this dialog box:

 

 

 

He can then use this to social-engineer users to “Open” the file:

 

 

Do you believe this could this mislead some users?  I sure do.

How about the sandbox?  Well, this little test was run against Adobe Reader X with the sandbox, and the calculator did indeed launch when the user clicked on the ‘Open’ button.

 

How about other readers?  Rather scary.  Here is a screenshot of the same technique but with the hidden embedded file designed to launch the command prompt:

 

 

No warning of any kind was ever displayed, and there is the command prompt.

 

As stated by Didier Stevens: “With Adobe Reader, the only thing preventing execution is a warning. Disabling JavaScript will not prevent this (I don’t use JavaScript in my PoC PDF), and patching Adobe Reader isn’t possible (I’m not exploiting a vulnerability, just being creative with the PDF language specs).”

 

So, disabling JavaScript will not help, but what about disabling non-PDF file attachments in Trust Manager settings of Adobe Reader?  That will not help you against exploits that download and execute malware; it only helps you against already embedded or attached executables.

Modifications to a PDF must also be remembered.  The PDF file format supports Incremental Updates.  This means that changes to an existing PDF document can be appended to the end of the file, leaving the original content intact. When the PDF file is rendered by a PDF reader, it will display the latest version, not the original content. Remember that the basic structure of a PDF file (one without incremental updates) consists of 4 parts:

• header
• objects
• cross reference table
• trailer

A PDF file with one incremental update has the following structure:

• header
• objects (original content)
• cross reference table (original content)
• trailer (original content)
• objects (updated content)
• cross reference table (updated content)
• trailer (updated content)

Every object that has been modified can be found twice in the PDF file. The unmodified object is still present in the original content, and the edited version of the same object can be found in the updated content.

The cross reference table of the updated content indexes the updated objects and the trailer of the updated content points to both cross reference tables.

When a PDF reader renders a PDF document, it starts from the end of the file. It reads the last trailer and follows the links to the root object and the cross reference tables to build the logical structure of the document it is about to render. When the reader encounters updated objects, it ignores the original versions of the same objects.

Is Adobe aware of all this.  Yes they are, and Didier Stevens has been working with them and supplying a lot of vulnerability code to help out.  This will result in more updates and new versions of Adobe Reader.  In fact, new version releases of Adobe Reader are expected within a week as I am writing this.  And so the battle to secure PDF readers continues as it will for the foreseeable future.

 

As a sidebar, over this weekend researchers have reported that Adobe Reader X spoiled a new PDF attack.  They are not sure why it was so effective, however.  My best hunch on this after looking at the code is that the exploit was written to exploit earlier versions of Reader as it does work against Adobe Reader 8 and early versions of Adobe Reader 9 with default settings.  It never ceases to amaze me how few users actually keep Adobe Reader updated.  I have already seen machines this year still running Adobe Reader 7 and 8 and, believe it or not, one running Adobe Reader 5.  No version of Adobe Reader prior to v 9 contained the update notification feature, and even v 9 does not offer an update upgrade to v 10.  It is still a separate install and you have to go to Adobe.com to get it.

 

Even after all these things are considered, we must also remember that even Adobe Reader X with the sandbox, and all other PDF readers also contain a parser, which is designed to call up another process.  It is included as part of the overall PDF language and specification.  Where am I going with this? - Lexers.  Lexers are where I believe the next round of PDF exploits just might be headed. 

 

They (Lexers) have been around for quite some time, they just aren’t commonly known and have in the past been used mostly for Linux and Unix, but they also support many languages including C, C++, Objective-C, D, Java and Ruby.  A Lexer is most often generated with the Lex programming tool and its compiler is designed to generate code for fast lexical analyzers based on a formal description of the lexical syntax.  Are these in use anywhere?  You bet.  The GNU Compiler Collection (gcc) uses both automated and hand-written lexers.  I might be wrong in this prediction, but if I am right it would open up a whole new scary direction for malware authors to go next.

 

BTW, if I caught you off guard with Lexers, you are going huh? and you are interested in the details, I can direct you here: http://en.wikipedia.org/wiki/Lexical_analysis

 

 

If you are like me, you are probably stuck with Adobe Reader at the company you work for.  As it is the de facto standard, this is pretty common.  But, for personal use, I sure recommend using an alternative reader.  Don’t be afraid to experiment a bit until you find one you like.  I just think the lighter weight and more stripped down the better.  Fewer features usually means safer.  But, where do I go to find one?  Got you covered here as well:

 

http://pdfreaders.org/

 

http://www.techsupportalert.com/best-free-non-adobe-pdf-reader.htm

 

Trust me - there is indeed a world in which the common vulnerable Adobe PDF reader is not really necessary.  Try an alternative and you just might be pleasantly surprised.  Do I have a personal preference?  You bet – Cool PDF reader, but it does have readability issues with some files.  I also have PDF-XChange viewer as a backup plan and even use the portable version off a USB drive on laptops. 

 

You might also like Sumatra.  Foxit is also quite popular, but be careful of the Adware and check out the comments here: http://downloadsquad.switched.com/2010/06/29/foxit-updates-free-pdf-reader-to-v4-but-watch-out-for-adware

 

In any case, always use caution with any PDF files, and you might want to get in the habit of scanning them with your AV before opening any of them regardless where you find them or who sent them.  I always do this and it has saved me on more than one occasion.

 

In closing, I leave you with this post that came up this weekend from Sophos Labs –

 

UK foreign secretary: "We're under attack"

 

Yesterday, the UK foreign secretary, William Hague, explained to a security conference in Munich how cyber criminals were trying to infiltrate the UK government and defense contractors.

According to a BBC report, Mr. Hague explained that attackers had infected government computers with the Zeus trojan (Sophos calls Zeus "Zbot") in attacks similar to those on the Department of Homeland Security last June.

While I commend the government for publicly addressing these issues, I certainly hope this isn't news to those in the MoD (Ministry of Defence) or defense industries.

The types of threats Mr. Hague outlined are not just hitting the UK government. These types of malware, social engineering and targeted phishing are gaining momentum against businesses all over the planet.

Most of the examples he cited began as email attacks. While best practices suggest that you should block all executable content from entering your mail gateways, booby-trapped documents are still a risk.

Spend some time educating your users that Microsoft Office documents, PDFs and other commonly used file types can be dangerous. If you are not expecting a document, or if you find it out of context, don't open it.

Phone the person who appears to have sent it or use some other out-of-band communications method to confirm the document isn't phony.

For more information on how malicious PDF documents can be used to compromise your computers, check out "Finding rules for heuristic detection of malicious PDFs: With analysis of embedded exploit code", the paper that Paul Baccas from SophosLabs presented at the Virus Bulletin 2010 conference.

 

 

 

 

 

 

=========================================================================

 

 

Bye-Bye BIOS - Hello UEFI

 

BIOS (Basic Input Output System) has been with us for over 30 years, and basically has been performing without error all this time, something almost unheard of in the computer industry.

 

Over the next few years, however, BIOS will be replaced by the new UEFI specification which began life in 1998 when the traditional BIOS limitations were causing issues with the new Intel Itanium processors.  Originally an Intel project known as EFI, it was donated by Intel in 2005 to the newly-formed UEFI Forum, a consortium made up of the usual suspects: AMD, Apple, IBM, Intel, Microsoft, and so on.

 

So, what exactly is EUFI?  UEFI, or Unified Extensible Firmware Interface, is a complete re-imagining of a computer boot environment, and as such it has almost no similarities to the PC BIOS that it replaces. While BIOS is fundamentally a solid piece of firmware, UEFI is a programmable software interface that sits on top a computer’s hardware and firmware (and indeed UEFI can and does sit on top of BIOS). Rather than all of the boot code being stored in the motherboard’s BIOS, UEFI sits in the/EFI/ directory in some non-volatile memory; either in NAND on the motherboard, on your hard drive, or on a network share.

 

How does it work?  A computer boots into UEFI, an arbitrary set of actions are carried out, and then it triggers the loading of an operating system.  The UEFI spec defines boot and runtime services, protocols for communication between services, device drivers (UEFI is designed to work across all platforms), extensions, and even an EFI shell, where you can run EFI applications. On top of all this is the boot loader, which executes an operating system’s boot loader.

 

So far UEFI has been used by almost every combination of 32- and 64-bit ARM, Intel, and AMD chips, and in each case the boot code just had to be compiled for the target platform. Every major desktop (OS X, Windows) and server OS (Linux) supports UEFI boot today — and Windows 8, when it rolls out, will have features that only work with UEFI (though it will still run on conventional, BIOS-booted computers).

 

Lets have a quick look at EUFI on a machine with ASUS motherboard -

 

 

What about security?  UEFI also specifies a few standard features that must be implemented. Windows 8′s ability to detect rootkit and malware infections (and rogue Linux installations), for example, relies on UEFI’s secure boot functionality. Low-level cryptography, network authentication, universal graphics drivers, and more, are all provided as standard.  Microsoft now has an excellent article about UEFI, Windows 8, and secure boot that is well worthy of your time to read (Linux will be able to run just fine!), and you can be sure Windows 8 Server will use EUFI as well.

 

While the change will not happen overnight, it should be noted that Windows 8, when it launches in 2012, will probably be the first major OS to take extensive advantage of UEFI, with Restore, Refresh, secure boot, and possibly more.

 

Quite honestly, I welcome the change, and believe it will quickly put an end to the current malware attacks on BIOS that we are unfortunately seeing become more common these days.  It will certainly be easier for AV vendors to design their wares to work with UEFI than BIOS.

 

 

======================================================================

 

 

 

 Security Lies

 

From a blog by Lenny Zeltser

 

Many are exaggerating the truth in the belief they are truly safe and secure for the following reasons, some of which will probably sound familiar to you.  Let’s look at the lies and why they are really not true.

Our data is secure because:

• We use bank-level 128-bit AES encryption. Encryption by itself is not sufficient; there are numerous other ways in which data can be put at risk, and are all files encrypted, whole disk encryption for laptops and all portable media – very doubtful.

 

• We are compliant with applicable industry regulations. The compliance status demonstrates that a set of practices is being followed, but does not address all necessary security measures and does not necessarily mean all procedures are being followed by everyone at all times.  Many companies have been successfully breached soon after receiving a compliance certification.

 

• We have a security seal to demonstrate that we passed a security scan. Security scans are usually limited in the weaknesses that they examine, potentially leaving the organization to numerous other attack vectors.  Is a true vulnerability scanner actually being used (There are very few available – Qualys being the best) and what is actually being scanned for.

 

We protect ourselves on-line by:

• Not opening email attachments from suspicious senders. People often receive legitimate attachments from unknown senders; yet have no basis for determining what is suspicious.  And, what about known or trusted senders?  They can be easily spoofed and the email can easily contain malicious attachments – just ask RSA, etc. etc. etc.

 

• Not clicking on links in email messages. People are often in a hurry or are multitasking, which makes it too tempting to click a link rather than attempting to re-type it.  Everyone claims they never do this when in reality most actually do; it is human nature because it saves time and effort.

 

• Selecting a “strong” password. Opinions vary greatly on what constitutes a “strong” password; also, by selecting one that’s hard to remember, people are more likely to reuse it across sites and applications, increasing the risk that one compromise might grant the attacker access to other resources.  Teach employees the use of pass-phrases instead.

 

All data is safe with our employees because:

• We conduct background checks. A “clean” record now does not ever guarantee that the person will exhibit ethical behavior in the future (ever watched an episode of ‘American Greed’?); also, many background checks are quite limited in their scope and depth.  Does anyone monitor behavior after employment?

 

• We provide mandatory security awareness training. Many training programs don’t affect employees’ security-related behavior; also, participating in the session doesn’t imply that the employee absorbed the material or will follow approved procedures.  I suggest periodic internal ‘tests’ be conducted and not telling the employees the tests are being done.

 

• We have a security policy. Security policies seem to be rarely read and even more rarely understood; also, the existence of security policies doesn’t imply that they are being followed by anybody.  Is this being monitored in any way and is the monitoring actually provably effective?

 

The above are all too commonly found in many businesses and enterprises, and the common belief is that they are true and everything is safe while nothing could actually be further from the truth.  The situation also rapidly gets much worse if the ‘cloud’ is being used for data storage – but that’s a different story for another time.

 

I hope this serves as a wake-up call.