LinuxQuestions.org came in my help, suggesting simply to delete some network files because apparently those files get corrupted when the battery runs out.

To fix it type the following comand on the command line sudo rm -rf ~/.gconf/system/networking or follow this step by step guide.

1. From the regular Aspire One options page, go to the Files panel

2. Click on the triangle to see more icons

3. Click on MyFiles, which opens a file manager window.

4. In the menu bar, select View->Hidden files, to show a tick in the box. (Sorry, I’m translating from a German display, so the option names may not be spot on.)You should be in the “My Disk:///” directory.

5. Find folder “gconf” and click on that

6. Find folder “system” and click on that

7. You should now see folder “networking” listed as one of the folders.

8. DELETE IT! (Right click on the networking folder, and select option delete.)

Okay, once you have recovered from the fear of deleting goodness-knows-what-file because you are just following some internet instructions, you have to re setup your wireless connection:

1. Shut down all those windows, and go back to the regular Aspire One options page.

2. Click “Settings” on the bottom right.

3. Click icon for “Netwrok Center”. If this works, and a window pops up then it’s going well.

4. Click on “New”, and follow the on screen instructions to connect and re-setup your WLAN or LAN.

Comments

It’s an unexpected update, given that version 2.8.1 was released less than two weeks ago. But good to see that the community involved in WordPress development is on the case and with a quick fix.

The announcement post says this about the issue:

WordPress 2.8.2 fixes an XSS vulnerability. Comment author URLs were not fully sanitized when displayed in the admin. This could be exploited to redirect you away from the admin to another site.  Download 2.8.2 or automatically upgrade from the Tools->Upgrade page of your blog’s admin.

I’m updating and I recommend you do, too, if you run WordPress.

Comments

Dave’s Answer:

The way that Mac OS X and its underlying Unix foundation are designed, it’s relatively easy to set up account and computer names and related on first run, but can be quite complicated to change them once you’ve gotten apps installed, documents created and otherwise have used the machine for a while.

In fact, I recently changed the admin account on a MacBook, including the home directory, and it took almost half an hour of careful steps, most done from the Terminal at the command line, before I was convinced it was done correctly and wouldn’t blow up on the new owner of the system when they tried to restart or log in. (if you’re trying to do that, you might well find that the Apple support docs are insufficient for 10.5 and above too)

Changing the name of your used iMac on the network shouldn’t be quite so difficult because there’s a place in the System Preferences to do just that, but what is a bit tricky is that you have to change the name twice for it to work.

First off, go to Apple –> System Preferences…. You’ll see this:

What you seek here is “Sharing”, almost exactly dead-center in the window.

Click on it and you’ll jump into the sharing configuration window:

As you can see, I already have a name collision on my network, which is why this computer is identifying itself as “Dave’s MacBook Pro (2)”: the “(2)” is added by Mac OS X when it finds another computer on the network with the same name. Not so good, but let’s fix things in order. First, click on the “Edit…” button:

Change the computer name here to what you want to have as your computer’s identity on the local network, and click “OK”.

Now, while you’re at the main Sharing window, change the name here too:

If you close this window and restart the computer, you should find that your iMac now identifies itself with the new name you’ve specified.

Good luck with your new Apple iMac!

Comments

I will give credit to bandit defense for posting something interesting and new when it comes to WordPress hacking. The process is simple and elegant, which is always a good thing when it comes to hacking. The problem is that it relies on a number of security flaws that may or may not be present in the system. That is what will make this hard to accomplish unless you already know things, or the web site is poorly secured.

I made references in my previous post about the Semisecure Login WordPress plugin about how if an attacker gets a WordPress username and password for your website, it can be used to wreak havoc on the web server that’s hosting it. This post will show you exactly how to do that. It doesn’t teach how to hack WordPress installs. That would be a very interesting thing to talk about, but I’m honestly not the most knowledgeable on the subject (any comments or emails to me about it would be greatly appreciated). Rather this is what an attacker could do if they already successfully have access to an account. Source: Bandit Defense

The first thing the hacker would need to know is the admin password to the WordPress installation. Usually the WordPress password that people use is either the default password made when the account was initialized, or they use some nice dictionary word that would be easier to brute force your way into. I would not hesitate to guess that the majority of WordPress installations have one or the other. If it is the default password, then it is a combination of numbers and letters of varying lengths that will take time to brute force.

Bandit does bring up the idea of the wp_config file, that will give you the credentials to the database. If you want to go mucking about in the database there is also the connect string to the database. Harder if it is local host, easier if the database points off to something like a separate server. That would be tons easier if the goal is to control the database and do interesting things with the person’s site. WordPress gives some incredibly good examples of how to secure your default word press installation, but my belief is that few people will do this; it is always easier to just do the normal install and be on your way to using WordPress the way that it comes out of the box.

What is interesting and something that does make the approach unique is the idea of using the C99 shell, a php file with a ton of shell commands that will let you romp around the web server. What Bandit is counting on to gain access to other web sites is that each web site on the shared server is visible to each other. Not an unusual thought when it comes to low cost shared servers. It is possible to tool around other people’s web sites if the security configuration of the shared server is very poor.

Overall it is fairly unique in that the C99 shell (and he recommends you make your own) is in the uploads directory when you are done, pretty much so allowing you to run around and use PHP commands at the server.

The problem is that the person has to already have access to the WordPress installation in one form or another, and unless the installer did something really bad, like use the same name and password for the DB connection as they are using for accessing admin on the WordPress installation then this starts making sense. If they did not, it is much easier to use the wp_config file and finding out where the database is hosted to do things to someone’s WordPress installation.

Interesting way of looking at WordPress though, the problem is that this is not a “technique for everyone”, there are easier ways of accomplishing things that would be more devastating to the original WordPress installation. The cool part is that few if any have thought of dumping the C99 script in the uploads directory and using that to tool around the web site, and possibly, if the server is very poorly secured, tooling around all the web sites on the shared server.

The other really simple way of doing this, Google search “index of site:com +wp_config” will give you pretty much the same power to tool around directories.

Comments