A directory containing personal details about more than 100 million Facebook users has surfaced on an Internet file-sharing site.

The 2.8GB torrent was compiled by hacker Ron Bowes of Skull Security, who created a web crawler program that harvested data on users contained in Facebook’s open access directory, which lists all users who couldn’t be troubled to change their privacy settings to make their pages unavailable to search engines.

What Bowes did is completely legal as the information is public. Maybe when a stalker comes to call on you folks who don’t protect you information (or your “friends”, you’ll realize the importance of securing your profile.

Bowes’ directory contains 171 million entries, relating to more than 100 million individual users – that’s 1/5 of all Facebook’s  half billion user base.

The file contains user account names and a URL for each user’s profile page, from which details such as addresses, dates of birth or phone numbers can be accessed. Accessing a user’s page from the list will also enable you to click through to friends’ profiles – even if those friends have made themselves unsearchable.

Facebook (FB) should be ashamed of themselves for not being more vigilante by either setting the user profiles to secure by default, or by forcing users to make wise choices about their information setting not to mention the information of their friends.

What are you thoughts, is it an issue that FB should deal with directly? Or perhaps, FB should be more diligent in educating it’s users?

In the last two or three releases there have been some major issues, one that directly effects me is a missing method from the DataProvider in 5.4.3. What’s makes it slightly more strange is a very similar issue was found in the previous release (5.4.2). Two other “showstopper” issues that also appeared in recent builds are DNN -12501 and DNN-12412.

In DNN 5.4.0 a change to the PageBase class in DNN has caused aspx pages to break in 3rd party modules. Meaning scripts wouldn’t run, RSS and some AJAX callbacks where broken. The problem was fixed, but a game of Jenga has begun.

When it was first announced the rigid release times sounded like a good idea. Every quarter there is a minor release, every Month a bugfix release. The dates for these releases cannot be missed. And to the Core Teams credit, they haven’t missed a date yet. That said, perhaps DNN needs to find a way to detect breaking issues before RTM, beta has always been an expensive way to do so, but one that DNN seems to avoid.

Of course, you’re going to get the people who press a beta into production, but the beta releases would certain produce a better production build to the DNN community.

• A website? That may be why they came to us and what the end goal is, but that’s not why they choose us. A lot of companies create great websites.

• A good time? Fun is a big part of it, who wants to deal with up-tight people all day. But even we know that there are better ways to spend money and have fun than hire us.

• Our methodology? They definitely want to know we have one, but the details aren’t as important to most clients as they are to us.

• Experience? Again, this is part of the reason but not what makes them say yes.

See, they don’t decide to hire us for the website they’ll get or the promise of  a cold beer, cocktail or even because we’ve got hundreds of web projects in our portfolio.

So why do they hire us?  Because we put them at easy about their project.

When most clients set out to select a web firm they are probably apprehensive at best. But somewhere along the project, some clients turn overbearing and feel they need to micro-manage. Most clients like to be in the front seat, but they prefer the shotgun position, not behind the wheel. So, what do you do with the client who insists on driving?

In my eyes, there are several ways to approach this issue.

• First, you could resign from the project and request the client find someone else to finish it (or recommend a company you don’t care for).
• Second, you could tactfully push back on the client and tell them who is in charge of the project and ask that they allow us to do our job.
• Third, you could take what the client says, give them what they want, and finish the project as quick as humanly possible so you can move on.

So which do you choose?

In my mind, the best thing to do is to finish the project as soon as you can (without jeopardizing the integrity and quality) and put the whole thing behind you. When it’s done you can always elect not to work with the client again. It may be difficult to handle it that way, as some dialogue will be needed in the future. However you always want to make sure you remain professional in all business situations regardless of whether or not the client is right or wrong. This will ensure that your reputation will always be positive and no bridges will be burned. At the end of the day, your responsibility is to make sure the client is happy.  Stick with that principle and you’ll be in a good position.

I have used this method several time in testing and found it to be flawless (2008 R2, 64-bit). It does come with a few restriction, such as you can’t install using a sub-domain. It said to work on IIS 7 and 7.5 both 32-bit and 64-bit and SQL Server 2005 and 2008 both full and Express editions.

Because MakeDNNSite works on both IIS 7 and 7.5, the Application Pool created uses the NetworkService account. While this is fine for IIS 7, however it is not the preferred account for IIS 7.5, rather the IIS AppPool Idently account should be used. This can be simply changed by right-clicking the newly created AppPool and selecting ‘Advanced Setting’. There, under Process Model, change the identity to ‘ApplicationPoolIdentity’.

If you opt to use the ApplicationPoolIdentity you will need to update you permissions on the website directory as well. I have blogged about this in detail (IIS 7.5 AppPool Identities).

In short, it’s a really nice tool at a great price (Free.) I highly recommend it for all DNN users, regardless of your environment or skill level.

When you first login to 2008 R2 you will be greeted with the Server Manager.

Server Manager

After you expand the Roles node and the Web Server node in the left pane you will be in the main IIS Manager.

IIS Manager 7.5

Right Click on the “Sites” folder and select “Add Web Site.”

Add Web Site

In the next screen we enter the web sites specifics. Fill in the highlighted areas with your information. Note that as you enter your site name an new Application Pool is created.

Web Site Details

During the above process you will create a new directory to which you will deploy your DNN code.

Create Website Directory

After this is complete, select Application Pools from the IIS Manager node. The detailed view should indicate that the AppPool is in Integrated Pipeline mode.

AppPool View

If you have not already done so, copy your DNN files to your website directory. In IIS Manager right click your new website and:

1. Select “Edit Permissions.”
2. Select the “Security” tab.
3. Click the “Edit” and then “Add” button
4. Click the “Locations” button and make sure you select your machine.
5. Enter “IIS AppPool\<YourAppPoolName>” in the “Enter the object names to select:” text box.
6. Click the “Check Names” button and click “OK”.
7. Grant <YourAppPoolName> modify permissions on the directory.

Securing Resources for your Process Identity

At this point you are ready to edit your web.config for your database connection., and get started.

If you have any questions on the Application pool details, I have covered this in an earlier Blog, you can read that here.

Task Manager - Worker Process

Application Pool Identity Accounts

Worker processes in IIS 6 and 7 run as NETWORKSERVICE by default. NETWORKSERVICE is a built-in Windows identity. It doesn’t require a password and it has only user privileges, i.e. it is relatively low-privileged. Running as a low-privileged account is a good security practice because then a software bug can’t be used by a malicious user to take over the whole system.

The problem is however that over time more and more Windows system services started to run as NETWORKSERVICE and services running as NETWORKSERVICE can tamper with other services running under the same identity. Because IIS worker processes run third-party code by default (Classic ASP, ASP.NET, PHP code) it was time to isolate IIS worker processes from other Windows system services and run IIS worker processes under unique identities. The Windows operating system provides a feature called “Virtual Accounts” that allows IIS to create unique identities for each of its Application Pools. Click here for more information about Virtual Accounts.

Configuring IIS Application Pool Identities

If you are running IIS 7.5 on Windows Server 2008 R2 you don’t have to do anything. For every Application Pool you create the IIS Admin Process (WAS) will create a virtual account with the name of the new Application Pool and run the Application Pool’s worker processes under this account.

If you are running Windows Server 2008 you have to change the IdentityType property of the Application Pool you created to “AppPoolIdentity”. Here is how:

• Open the IIS Management Console (INETMGR.MSC).
• Open the Application Pools node underneath the machine node. Select the Application Pool you want to change to run under an automatically generated Application Pool Identity.
• Right click the Application Pool and select “Advanced Settings…”

Configuring AppPool Identity

• Select the “Identity” list item and click the button with the three dots.
• The following dialog appears.

Selecting AppPool Identity

• Select the Identity Type “ApplicationPoolIdentity” from the combo box

To do the same step via command-line you can simply call the appcmd command-line tool the following way:

Securing Resources

Whenever a new Application Pool is created the IIS management process creates a security identifier (SID) representing the name of the Application Pool itself, i.e. if you create an Application Pool with the name “MyNewAppPool” a security identifier with the name “MyNewAppPool” is created in the Windows Security system. From this point on resources can be secured using this identity. The identity is not a real user account however, i.e. it will not show up as a user in the Windows User Management Console.

You can try this by selecting a file in Windows Explorer and adding the “DefaultAppPool” identity to its Access Control List (ACL).

1. Open Windows Explorer
2. Select a file or directory.
3. Right click the file and select “Properties”
4. Select the “Security” tab
5. Click the “Edit” and then “Add” button
6. Click the “Locations” button and make sure you select your machine.
7. Enter “IIS AppPool\DefaultAppPool” in the “Enter the object names to select:” text box.
8. Click the “Check Names” button and click “OK”.

By doing this the file or directory you selected will now also allow the “DefaultAppPool” identity access.

Securing Resources for your Process Identity

You can do this via the command-line using the ICACLS tool. The following example gives full access to the DefaultAppPool identity.

On Windows 7 and Windows Server 2008 R2 the default is to run Application Pools as this security identifier, i.e. as the Application Pool Identity. To make this happen a new identity type with the name “AppPoolIdentity” was introduced. If the “AppPoolIdentity” identity type is selected (default on Windows 7 and Windows Server 2008 R2) IIS will run worker processes as the Application Pool identity. With every other identity type the security identifier will only be injected into the access token of the process. If the identifier is injected content can still be ACLed for the AppPool identity but the owner of the token is probably not unique. Here  is an article that explains this concept.

Accessing the Network

Using the NETWORKSERVICE account in a domain environment has a great benefit. Worker process running as NETWORKSERVICE access the network as the machine account. Machine accounts are generated when a machine is joined to a domain. They look like this:

<domainname>\<machinename>$,

for example:

mydomain\machine1$

The nice thing about this is that network resources like file shares or SQL Server databases can be ACLed to allow access for this machine account.

What about AppPool identities?

The good news is that Application Pool identities also use the machine account to access network resources. No changes are required.

Note:

This article http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/ walks you through the process. This article was written for IIS 7, but will apply to IIS 7.5 as well.

In addition, if your server is 64 bit, you should set ‘enable 32 bit applications‘ to true in your application pools settings.

This probably isn’t anything earth shattering to most, but it certainly beats our old system of taking back-up tapes and DVD off-site every night. That method had too many short-comings to say the least.

Recently, for one of our secure document storage web applications, we started incorporating a data provider that utilizes the S3 API. Setting a search provider for S3 proved to be a bit of a challenge, but so far it has worked out fairly well.

So lets get back to the topic at hand. For the SMB looking for a cost effective way to keep file storage organized and highly available, I’m hard pressed to come up with another viable solution. If you’re the owner of a SMB or work for one, what options have you explored? What method of [off-site] back-up are you using? I’d really like to hear from you…

Keep in mind that 99.9% of these attacks stem from poor coding. It very important to implore beginners (and some more experienced programmers) to code against them. In brief:

• Constrain Data, Check for known good data by validating for type, length, format, and range.
• Use type-safe SQL parameters for data access. Use parameters with stored procedures or dynamically constructed SQL command strings.
• Use a low-permission database account for data access.
• Hide data errors, don’t give clues at to what maybe acceptable to the database.

Now, there is a reason the items above look simple. They Are!

All we need are programmers that will listen and not take short cuts.

The first problem is an XSS vulnerability in Press This discovered by Benjamin Flesch.  The second problem, discovered by Dawid Golunski, is an issue with sanitizing uploaded file names that can be exploited in certain Apache configurations. Thanks to Benjamin and Dawid for finding and reporting these.

Never, never assume that a beta piece of software is going to be upgradable. And when I say upgradable, I mean the next beta build release. This would especially hold true  with an RTM. Almost never would you want tot upgrade a beta to a production code, unless the manufacturer has explicitly said this is acceptable.