Shellshock and the Servers Behind Small Sites

A flaw in a program most servers carry

On Wednesday, a serious flaw was disclosed in bash, the program that reads and runs commands on most Linux servers, including many that host small business websites.

The flaw has been nicknamed Shellshock. Attackers began scanning the internet for servers they could exploit within hours of the announcement.

Within a day, researchers showed that the first fix did not close every route, and a second round of updates has been coming out since.

For most small businesses, the people who must act are their hosts. For some, the job is closer to home.

What bash does on a web server

Bash is a command shell: the program that runs instructions typed by an administrator or passed to it by other software.

When a web server runs certain kinds of script, it passes details of the visitor's request, such as the browser's name, to the script as environment settings. If the script starts bash, bash reads them.

The flaw lets an attacker hide commands inside those details. A vulnerable bash runs the hidden commands, with whatever permissions the web server has.

Which sites are exposed

Plain pages are not the risk. The risk is any script that ends up starting bash while it handles a visitor's request.

Old scripts in a folder called cgi-bin are the best-known case: form mailers, counters and guestbooks installed years ago. Some other setups start bash less obviously, which is why the server itself must be updated.

Servers running Windows do not include bash as standard. Office computers are not the main concern either; the exposed machines are the ones answering requests from the internet.

What to ask your host

On shared hosting, you cannot update bash yourself. The host does it for every account on the server, and your part is to ask clear questions and act on the answers.

• Whether bash has been updated on the server that runs your site, including the later fix.
• Whether mail and other servers in your account were updated too.
• Whether requests carrying the attack are being blocked before they reach any site.
• Whether the logs show attempts against your site, and whether any succeeded.
• Which scripts in your account the host would advise removing.
• How you will hear about further updates.

A good host will answer the first question in a sentence. If the answer is still vague after two days, that tells you something about the hosting as well.

Your own server is your own job

A virtual or dedicated server rented without management, or a server in your office, is updated by nobody unless you arrange it. The host keeps the hardware running; the software is yours.

Bash has to be updated through the system's own update tools, and updated again as further fixes are released. Your developer or administrator can confirm the result with the published test.

Check every machine that runs Linux and faces the internet, not only the web server: a mail server, a test server someone set up and forgot, an office storage device with a web control panel.

A worked example

A magic shop on an older shopping street sells tricks, cards, books and costume pieces, and runs an online store from a virtual server a developer set up four years ago.

That developer has since moved on, and nobody had logged in to the server for months. The hosting company keeps the machine running but, under the plan the shop chose, updates nothing on it.

On Thursday the shop hired a developer to look. Bash was the old, vulnerable version, and the server's cgi-bin folder still held a form mailer from the shop's first website.

He updated bash, then updated it again when the second fix appeared, and removed the old scripts. The logs showed scanning requests from Thursday morning, aimed at addresses that do not exist on the site.

Nothing suggested the scans had succeeded, but he checked for unfamiliar files and accounts before calling it done. The shop is moving to a managed plan, where the host applies such updates.

Old scripts in forgotten folders

Many small sites carry scripts nobody remembers: a form mailer from the first website, a hit counter, a guestbook that was switched off but never deleted.

Each is code that a visitor's request can reach. Ask your developer to list everything in cgi-bin and similar folders, and remove what the site no longer uses.

Replace old forms with current ones that your developer maintains, rather than leaving a script nobody updates on a public address.

Signs that someone got in

The attack often leaves a recognisable pattern in a web server's access logs, and a developer can search for it. Most hits will be scans that found nothing.

Signs of a successful attack include unfamiliar files, new user accounts, unexpected processes, and mail sent from the server that nobody wrote.

If you find any of these, treat the server as compromised and have a professional clean or rebuild it. An update closes the door; it does not remove what came through it.

Not a repeat of April

Heartbleed, in April, could leak passwords and keys from a server's memory, so certificates were reissued and passwords changed. Shellshock lets an attacker run commands instead, so the first job is updating, then checking for intrusion.

Change passwords stored on a server only if there are signs someone got in, and only after the server is clean.

The counter-case

If every page on a site is plain HTML, hosted on a well-run shared server with no scripts in the account, there may be nothing to do but read the host's notice and confirm the update.

That is a fair position, and a common one. It still depends on the host doing its part, which is why the one question worth sending today is whether bash has been updated.

Patching bash and clearing old scripts

1. Find out what kind of hosting your site uses.
2. Ask your host whether bash is updated, including the later fix.
3. List every server you run that faces the internet.
4. Update bash on each one, and again as fixes appear.
5. Remove old scripts from cgi-bin and similar folders.
6. Search the logs for the attack pattern.
7. Get professional help if anything looks wrong.

Step one decides who does the rest. On shared hosting, most of it falls to the host; on your own server, all of it falls to you or to whoever you hire.

Heartbleed and the padlock on your site sets out the questions to ask a host after April's server flaw, which touched certificates and passwords.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.