Analyzing a Hack


, , ,

There has been a lot of discussion on the internet recently on the ability of an attacker to test unlimited numbers of PIN/Passcode values without triggering the auto-delete function puilt into the iPhones. So I have put together this article to show a means of looking at such a problem logically.

Determining Probable Location of Vulnerability

The exploit involves testing more than ten possible passwords without triggering the erasure of data on the phone. According to the Apple literature, this would not be possible without flaws in the hardware, firmware, or software in the Secure Enclave Processor (SEP). There may be flaws in other parts of the phone that enable the flaw in the SEP to be exploited, but the exploits described involving Cellebrite, GrayKey, and others require flaws in the SEP that violate the postulates that make up the requirements for the SEP. Some of these postulates are as follows.

  • It is not feasible to remove the cover of the chip carrier containing the SEP and inserting probes to access or modify data without triggering the erasure. The description of several of the exploits state that the case and chip carriers are not opened or modified.
  • Key pieces of persistent data contained in the SEP can’t be read or written using the pins for the chip carrier without going through the software in the SEP.
  • There are certain “salt” values that are set during the manufacture of the device and stored in persistent memory in the SEP. Output data lines for memory containing this information only connects to the cryptographic portion of the chip and not by the general purpose CPU in the SEP. It is not possible to read operating system, firmware, or other files without using the cryptographic portion of the chip.
  • Certain variables, such as the number of consecutive unsuccessful login attempts and the time of the last unsuccessful login attempt are considered extremely critical. They should only be accessible by the SEP firmware and the code in the firmware capable of reading and/or writing this information has been subjected to additional review.

Web Search

The first step in analyzing anything is generally research. So I spent a little time on the internet using Google to search for relevant articles. Some combinations that will work well with Google are the following.

  • ios unlock tool
  • “ios 11” unlock tool
  • iphone crack passcode

When you use something like Google Search, it isn’t enough to just look at the first few entries. It is necessary to go through pages of listings and then try new searches based on the items you find.

Relevent Events

Based on the Google search, I found that the relevant literature seemed to fall within a few categories. I have listed them below in chronological order.

  1. Apple CVE-2014-4451 This was an exploit that allowed users to try an unlimited number of PIN codes. The articles were dated November 18, 2014, and the vulnerability was reported detected and resolved within the development of iOS 8.
  2. Secure Enclave Processor Decryption – Articles published on August 17, 2017 indicate that the decryption key for the Secure Enclave Processor had been published. This means that an attacker could reverse compile the SEP code to learn how it works.
  3. Chinese Cracker Box – This is a cracker box (reportedly from China) that will crack the PIN code on the latest iPhones. The articles were dated August 17, 2017. I am simply referring to it as the “Chinese Cracker Box” for convenience. The cracker community is not necessarily known for “truth in labeling”.
  4. GrayKey Cracker Box – GrayKey is a cracker device manufactured by GrayShift. The articles state that information on the device first appeared in late 2017.
  5. Cellebrite Exploit – Celebrite provides much less information than the others, but a number of articles in February and March 2018 indicate claims that Cellebrite has developed mean of unlocking the latest iPhones.It appears that development of this technique was in late 2017 since one of the articles stated that it was developed in the last few months.

A review of the dates seems to indicate a few connections between the problems.

  • Reports on the decryption of the Secure Enclave Processor (SEP) and the Chinese Cracker Box appeared at the same time. This was a few years after CVE-201404451.
  • Usage of CVE-2014-4451, the Chinese Cracker Box, and the GrayKey device appear to interrupt a process after a passcode is tested, but before the counter for unsucessful login attempts is incremented.
  • The GrayKey and Cellebrite cracks appear to have been developed at about the same time and development was after
    the Chinese Cracker Box.


Scientific analysis first requires observation and research. The next step is to create a hypothesis. Let us consider the following as a hypothesis.

  1. Assume that a person interested in studying vulnerabilities on the iPhone has been collecting iPhones after each update. That would seem reasonable given the amount of money being spent.
  2. After the firmware decryption key was determined, it would be possible to reverse compile the SEP code before and after CVE-2014-4451 was resolved.
  3. Comparing the two versions of the SEP code would enable the researcher to find the section of code that waschanged to remove the vulnerability.
  4. (This step is a wild-ass guess.) The fix may have been to move the incrementing of the counter before the test of the trial password. After all, a successful login will reset the counter, so the overall logic would remain unchanged.
  5. You would then examine the current version for other places where the same erroneous code appears. (e.g., other locations where the password is tested before incrementing the counter.) Each of these locations would then be checked against the exploit in CVE-2014-4451 to see if any of them could be exploited.
  6. The Chinese Cracker Box would then be developed using the newly found vulnerability. Sales of the device took place by August, 2017.
  7. The release of the firmware decryption key came from someone who had access to the development of the Chinese Cracker Box. This is based on the fact that both items were reported at the same time.
  8. Since the Chinese Cracker Box was available on the underground market, both GrayShift and Cellebrite would have purchased copies of the unit. Four months sounds like a reasonable development time for them to implement their “new and improved” versions.

Human Behavior

I have seen many cases where a maintainer will fix one occurence of a bug but not look for other occurences. In fact many times, the word from management is “Just fix this bug and close out the task. Don’t waste time.” I have heard this expressed very frequently and very forcefully.

Since the potential hackers can now reverse compile the code on the SEP, it would be only logical for them to determine the coding changes that fixed earlier problems and then look for other occurrences of the incorrect logic. In this case, a good method would be to look for all code that can change the value of the counter, a task well within the capability of many IDE’s (Integrated Development Environment) or even the UNIX grep command.

Another problem that I have seen is that nobody seems to use fault trees or coverage charts. This is an attempt to use formal logic to determine items that need to be examined. Many consider it too much work to through all the possibilities, and state that it’s good enough. People keep telling me “Don’t worry. It’s good enough”. My experience in these cases is that it’s almost never good enough and I worry a lot. However, this will covered in more detail in a future post.


I have divided the references according to the events that they describe.

Apple CVE-2014-4451

Decryption of Secure Enclave Processor

Chinese Cracker Box

GrayKey Device

Cellebrite Exploit

Secure Enclave Processor


System Architecture and Patching

I was just watching some videos today and they were emphasizing how important it was to install patches immediately.  Unfortunately, when dealing with reality, there are some problems with this.  Fortunately, appropriate system architecture provides methods for dealing with the problems.

Requirement for Testing

The problem with automatically installing patches is that you should test patches before installing them on production systems.  I once worked with an organization that didn’t install any patch from a vendor until it was six months old.  In some cases, patches were replaced after a few weeks because errors were sometimes found and this policy sounds reasonable when you first see it.  However, the vendor was infamous for providing patches that patched earlier patches without indicating which patches they were patching.  When I contacted the vendor’s help desk about a problem, he informed me (with a straight face) that he had never heard of his company’s patches causing problems.  So I knew which patch caused the problem, which patch patched the patch and solved the problem, and the nature of the problem.  I couldn’t get the IT department to install the fix, since I couldn’t get documentation from the vendor and they stated that they wouldn’t install the fix for six months.

Danger of Installing Patches

So you end up with a situation where people don’t trust the patches, but management won’t let you spend the time to test the fix, and you receive the blame from everyone. So if a vendor wants people to automatically install patches, the vendor needs to provide better quality patches, better documentation for the patches, and honest answers from the help desk.

I’m not going to give the name of the vendor.  I know of a number of vendors who have bad reputations in this regard.  So pick the vendor of your choice to fill in the blank.

Can’t Wait For Patches

The next problem is that you can’t assume that all problems will be identified and patched before malicious actors learn of them.  After all, that is the definition of “zero day” vulnerabilities.  This means that installing patches immediately won’t necessarily stop your system from being breached.

The Solution

If you don’t install patches, you will be hacked.  If you install patches, you may still be hacked.  The solution is to assume that one of the components (either hardware or software) in your system contain bugs which create vulnerabilities for malicious parties.  You then organize the system such that a lack of security in one component will not compromise the entire system.

Although the standard approach to single points of failure is to add redundancy, this is not always feasible or appropriate.  Adding redundancy also adds more components that can fail.  You actually have to think about your design of the system to insure reliability and security.  There is no simple way to achieve total reliability, and it probably won’t be cheap.

The following are some things you might want to consider:

  • Have a simplified version of the system with reduced capabilities that that can be activated if problems are detected with the main system.
  • Have monitoring systems that will indicate the existence of improper signals and take appropriate action.
  • Divide the system into multiple components with strictly defined interfaces.  This can prevent faults in one component from causing failures in other systems.  If you can identify the most security sensitive components, you can spend more effort on making those components secure.  If you can reduce the complexity of the security sensitive, it will be easier to make those areas secure.
  • If the system depends on passcodes for its security, design the system with the assumption that the attacker knows all of the code and all of the passcodes that are known or accessible by human beings.  It may not be possible to design a system that will fully meet this criteria, but you will surprised how close you can come.


“Single point of failure”, Wikipedia,

“Super Bowl Blackout Caused by Device Installed to Prevent Power Outage”, CBS News, February 8, 2013.

Irrationally Increasing the Load

Laser Printers

Many years ago, I was in an IT group that purchased dozens of Hewlett-Packard LaserJet II printers for internal use.  The problem was that the printers were designed for a maximum of 3000 pages a month and we were using them to generate 2000 pages a day.  They overheated so badly that the rollers inside were melting.  Management was complaining about shoddy workmanship by Hewlett Packard and the partially melted rollers were causing black streaks on the paper.  To get this throughput, we were using third party page feeders that would hold one thousand pieces of paper instead of the standard 100 page trays.  (HP informed us that any use of these giant page feeders voided all warranties and service contracts.)


Expecting a printer designed for 3000 pages a month to be able to produce 60,000 pages a month was not reasonable or rational.  It certainly wasn’t a sign of shoddy workmanship on the part of Hewlett-Packard.  There was a larger model (LaserJet 2000) that would handle the load, but management didn’t want to spend the money.  Given that the LaserJet 2000 had 2.5 times the speed and would have had much lower maintenance costs, it probably would have been better to buy the faster printers at the higher price.

Since the printers were producing more than an order of magnitude over what they were designed for, complaining about the workmanship was hardly rational, but it did provide a means for management to argue why they weren’t at fault.



Just Get It For Me

The Request

Many years ago, I had a manager who was unhappy with the number of facsimile messages he could send and receive each day.  He therefore instructed me to obtain a facsimile machine that was four times as fast.  Unfortunately the rate of receiving and transmitting facsimile messages was set by an international standard.  Limited increases in speed were possible, but the data was transmitted at the speed of the slower machine.

This meant that I couldn’t get a machine that would reliably send and receive pages at four times the rate.  However, I could place four facsimile machines on the same telephone number.  This meant that they could all be sending or receiving messages at the same time, enabling us to process four times as many messages in a single day.


I was told that I had a lousy attitude.  I should simply go and order what he wanted, and he didn’t want to hear any complaints.  The fact that what he wanted was unavailable was irrelevant.  The result was that he didn’t get either the electronic device or the business capability he desired.  (However, I could have easily supplied him with the desired capability.)

Saying what you need to be able to do is reasonable and logical.  Refusing to listen to the other person about how that need can be satisfied is not reasonable.  If he didn’t have the knowledge and skills to satisfy that need, why are you going to him?


Myers-Brigg Classifications

Logical Thinking and Gut Feeling

The Myers Briggs Type Indicator (MTBI) was designed to indicate the personality type of an individual. One of the ways of expressing the personality was Thinking (T) versus Feeling (F). In this case, “thinking” referred to making decisions with dispassionate logic as opposed to your gut feeling.

The company I was at decided to give everyone the Myers-Briggs test and then discuss the results. The department head was very unhappy because he felt he was a totally rational decision maker but the test indicated that he was going by his gut. Despite the fact that all of the other managers agreed with the result, his opinion was unchanged and he even implied that the other managers were lying to him. (By the way, I felt that the test result was accurate.)


  • If you are a “feeling” type and know that you are “feeling” when getting your ideas, you will probably still realize that you have to analyze the results to make sure that it is a good decision.
  • If you are a “thinking” type and know that you are a “thinking” type, you are going to come up with options based on logic.  One of the points to consider logically is to consider how the decision will be viewed by others.
  • If you are a “feeling” type and believe that you are a “thinking” type, you won’t see a reason to evaluate your decision logically.  The fact that you are misreading your own personality means that you aren’t that good at evaluating things, like the difference between emotional and logical arguments.  It also makes it difficult to understand the objections raised by others.

If you don’t understand your own thought processes, you will come up with very bad decisions.  If you don’t see a need to examine ideas logically (The conceit that “I am a genius.  My opinion must be correct.”), the chances for success shrink further.


Tales From the Irrational

Rational vs Emotional

If you look at the various Star Trek television series, you will find that many of them have a character whose primary attribute is being logical and unemotional: Spock on the original series, Data on The Next Generation, Seven of Nine on Voyager, Odo on Deep Space Nine, and T’Pol on Enterprise. In addition to a number of science fiction characters, many detectives in mystery novels, such as Sherlock Holmes and Hercule Poirot, would also seem to fit this archetype.

However, if you look at these characters in their respective stories, you will also see that they have a character who is a mirror image in many ways: more emotional and less logical. For Sherlock Holmes, there was Dr. Watson, while Spock had Dr. McCoy as his verbal sparring partner. The extremely logical characters often appeared slightly inhuman and perhaps a little bit ridiculous. However, they are also the ones who keep the spaceships running, solve the crimes, keep the city infrastructure running, etc. They are often viewed as humorless, but they definitely have a sense of humor, what I call engineering humor.

Their main source of humor is the illogical people they work for. I can assure you that the engineers find the non-engineers hilarious but a little scary. To demonstrate this, I am going to provide a number of scenarios, and you can decide which side seems more like you and which side you would like to resemble. (This may be a spoiler, but I prefer the rational people.)

Classic Example

The classic example of irrational thinking is a old joke about a man who was searching under a lamp post outside a bar.  A policeman walking by asked if he needed any assistance.  Upon learning that the man was looking for his wallet, the policeman asked when he had last seen the wallet and was told that he had last seen it inside the bar.

When the policeman asked why he wasn’t looking for it inside the bar, he was told “The light is much better out here”.

I think that most people would agree that it would have been more rational to search inside the bar, perhaps after asking to borrow a flashlight so that he could see better.  Before laughing at him too much, you might want to review your actions lest you resemble him.  The stories here will helpfully help you in your goal for rational and successful thinking.  (Irrational thinking is rarely successful.)


Auditing Access Attempts

In order to secure your web site, it is necessary to examine requests so that you can detect, report, and respond to attacks on the web site.

Persistent Data

In order to have a secure web site, it is necessary to store the information required for analysis.  Some of the information that will need to be stored for each account are the following pieces.

  • Account name and password
  • Flags indicating the current status of the account, including any red flags raised in the security audit. If access to the account is restricted to specific IP addresses, it will also contain a list of the authorized addresses.
  • Information on each logon attempt, both successful and unsuccessful.  In addition to date and time, this would also contain information on the IP address and port used to send the request, and the result of any validity tests applied to the logon request.

Password Requirements

The first step in planning is to determine the requirements for selecting passwords.  This would include the minimum and maximum lengths, and the characters that can be used in creating the password.  Some systems apply other considerations such as requiring both upper and lower case letters, numeric digits, and punctuation marks.  You have to consider usability, ease of memorization, and difficulty of guessing in determining your rules.

You should also consider creating a list of character strings that can’t be used as passwords, starting with a list of the most commonly used passwords (secret, password, 123456, qwerty, letmein, etc.)   For this purpose, case-insensitive comparisons should be used for rejecting the password, although case-sensitive comparisons will be used for testing whether the password is correct.  You should also reject the password if it is simply followed by a single digit or uses letter number substitutions (LEET speak).  Having “password” on the list should also reject “Password”, “Pa55w0rd”, “PASSWORD1”, “PA55word”, etc.  The reason is only partly to get people to use better passwords.  If you prohibit these passwords, any person using them has a relatively high probability of being an attacker.

Account Restrictions

You may want to have some restrictions on accounts, especially those with administrative privileges.  Some of these restrictions could include the following for specific accounts.

  • Restricting the IP addresses that can be used to access the account.  If a black list can be created of the IP addresses that have been known to launch attacks, the accounts could be set to reject access attempts from these attempts.
  • Require two-factor authentication on some accounts.
  • Some systems have additional information to identify systems that can be used to log on to the account.  This could include cookies, IP addresses, or information maintained by the browser, such as type of browser and operating system.  Adding new systems to the list would require additional confirmation from the user.

Concurrent Analysis

These are the tests that are applied to the request while it is being processed.

  • Since many of the vulnerabilities in web software is based on sending malformed requests, the first step would be to validate the format of the logon request.  If the request is invalid, it is best to return a 500 (Server Internal Error) rather than a 400 (Bad Request) since this gives the least information to an attacker but is still relevant to the problem.
  • The next step would be to make sure that the account name is valid.  If it isn’t, the account name used would be stored in the log of logon requests.  However, the password field in the log would be left blank, although the use of a forbidden password would be noted in the log.  The response to the requestor would be 401 (Unauthorized).
  • If the password is on the forbidden list described above, you should reject the attempt, returning a 401 (Unauthorized) response.
  • At this point, you can test whether the request is coming from a blacklisted IP address.  (The blacklist will be created from the retrospective analysis described in the next section.)  The 401 (Unauthorized) response is often used for blacklisted addresses, but different system administrators have different opinions about which response to use.
  • You can then test if the password supplied in the request matches the one stored in the database.  If it doesn’t, you will return 401 (Unauthorized) response, but also lock out the account for a period of time.  The subsequent requests with the wrong passwords will have gradually increasing time spans, such as 1, 2, 5, 90, and 300 seconds with attempts after the second returning a 500 (Server Internal Error) message with a text stating that the user should try again later.  After the longest lock period (300 seconds in this case) has passed, you can reset the lock out period to the smallest value.

At this point, the user has passed the tests for logging on to the system, and he can gain access.

Retrospective Analysis

Retrospective analyses are carried out by examining the logs for entries over an interval of time.  When attackers try to learn the account names and passwords on a system, they generally use one of two approaches.

  • Go for a specific user and learn all you can about him.  Use that information to guess his password.
  • Obtain a list of account names.  This may involve looking at bulletin boards and e-mails.  You will then try a list of the most common passwords against each of the accounts.  This is known as “account spraying”.  If you only try each account once a week, the chance of being detected is greatly reduced.
  • In “phishing” attacks, you obtain a list of e-mail addresses and send e-mails to each of them.  The e-mails may either contain attachments with malicious payloads or instructions on how to access web sites that contain pages that will corrupt your system.

Account spraying will result in a number of IP addresses having many unsuccessful logon attempts, and few, if any successful attempts. Similar patterns will be found with other types of attacks as well. In addition, it is possible to determine information about an attacker from the IP address. (The amount of information that can be obtained varies according to IP address. If you find a hundred successful logons from the eastern United States, and one successful attempt from Kazakhstan, it would be reasonable to make further inquiries into the person logging in from Kazakhstan.

Additional topics

The following are some additional topics to be discussed in future posts.

  • This is not artificial intelligence.  In fact, the concept of artificial intelligence is so poorly defined that people using the term are usually trying to mislead you or using hyperbole as a sales gimmick.
  • It is possible to identify systems by IP address, cookies, or other means.  If a login attempt is attempted from a new system, you may want to force the user to confirm his identity.  Confirmation may also be desired if a long period of time has elapsed since that system was last used.
  • Confirmation of identity can be carried out by a number of means such as two factor authorization and security questions.
  • You should confirm information when the account is created.  This applies especially to telephone numbers and e-mail addresses.
  • You need to have a policy regarding appropriate actions when penetration of the system is suspected.
  • You need to have a policy describing the actions when a user requests that his password be changed.


  • Security is not always convenient.  During the American Revolutionary War, the British garrison at Fort Ticonderoga left a gate open to make things easier for the cooks and washerwomen to get water and for the guards who would otherwise have to open and secure the gates at frequent intervals.  It did not go well, as the fort was captured before its commander was aware of the attack.
  • If you want to be secure, you will have to make an effort to detect and respond to unauthorized attempts to log on.  Otherwise you are simply leaving the gate open for attacks.
  • Furthermore, being told by your subordinates that the system is secure and you trusted them is not an argument that will go over well with the people you work for.




Paranoid’s Guide to Server Administration


Given the number of recent breaches in web sites, managers want to improve security. However, a manager ordering that all security problems be eliminated from a web site will have no more effect than King Canute ordering the rising tide to halt. You have to assume that things will break and then make sure that there are additional safeguards that will still prevent attackers from gaining control of the system after a single failure. You also have to seriously evaluate all possible attacks, even though this may make you seem slightly paranoid.

That is the true cause of the Equifax failure, which was caused by an unpatched flaw in the Struts software allowing malformed HTTP requests to cause the execution of code on the computer housing the web site.(Fox-Brewster, Newman) Lots of articles and white papers have been written describing the “true underlying cause” of the incident and how to stop it in the future.

  • Providers of firewalls will tell you that their firewall will check for malformed requests and would have prevented the problem by rejecting the malicious requests.
  • Other providers will check the versions of the software modules that you download from the internet and flag versions that have known problems.
  • No matter what they sell, vendors will find some way of claiming that their product will prevent future attacks.

There are usually several problems with these claims.

  • How do you know that the vulnerability will have been publicly reported before it is used to attack your system? Zero day defects are by definition not known to the public before they are used.
  • Even if a patch is available, there is still a very real danger that installing the patch without testing will introduce other problems. Any administrator who hasn’t had problems installing patches hasn’t worked with computers very long.
  • There are many avenues of attack upon a system. Some involve hacking from the outside and others involve gaining physical access and hacking from the inside.
  • Purchasing these products without a full security review can provide a false sense of security.

Finally, you should remember the following.

  • It’s not paranoia if people are out to get you.
  • If you actually believe that the security on your system is good enough, it isn’t.
  • Security done “on the cheap” is generally very poor security.
  • Expensive security is not necessarily good security.
  • For those who believe that security can be achieved by keeping facts secret, you should remember Benjamin Franklin’s comment on the subject: “Three can keep a secret, if two of them are dead”.(Gawalt) You have to assume that there is a good chance that attackers will learn your secrets and plan accordingly.
  • You will have to consider how you will maintain security if attackers discover vulnerabilities that enable them to compromise parts of your system.

Simple Layout

The following is a typical and very simple layout for web sites. From a security standpoint, it is very poor.

  • The application appears to users as a web site with account name and password serving to gain access to the application.
  • Administrators can also log on as a remote shell user using Telnet of SSH. Access is controlled by using the account names and passwords on the computer.
  • An additional option is for administrators to log on to the database as a database administrator. This usually uses a special website that is part of the database. Access is controlled by using an account name and password that belongs to the database.

In this simple layout, the application server and database are located on the same computer, and security is completely based on knowing the account names and passwords. There are a number of reasons why this is not adequate.


1. The database contains information whose exposure could be disastrous the company, while the application server is subject to frequent changes that may have to be installed on short notice. Valuable information means that you have to have a robust testing regime involving both manual and automated steps. Frequent changes means that it has to done frequently, increasing expense.

2. There have been a number of remote execution exploits on web servers, application servers, and other pieces of software, and there will be more in the future. You have to assume that vulnerabilities exist that nobody knows about.

3. You also have to plan for the possibility that a malicious actor knows the administrative account names and passwords.

4. The application server sends SQL commands directly to the database. If the application server is compromised, the attacker can send any SQL commands to the database.

5. An attacker with operating system access with administrative privileges can do almost anything to the computer. He can also hide his actions.

Hardening the System

The military protect facilities with multiple lines of defense. If the enemy overcomes the first line of defense, they still have to go through additional lines of defense before they can do serious damage.One way of hardening the system is to divide it into subnets, with formal rules for passing information between the subnets.

Consider the construction of a bank building. It is divided into multiple regions: vaults, public areas, areas for meetings, and employee only areas.It helps to think of the computer systems as castles with multiple rings of protective walls with guarded doors in the walls for data passing through the rings. In order to prevent attacks from malicious actors, you are going to have to harden the system. In order to demonstrate the concept, I prepared a second figure showing a somewhat hardened configuration. In this case, the web site is divided between multiple subnets and various methods are used to prevent malicious actions.

  • Administration of the system is carried out by members of an internal intranet which will be used for development, test, and configuration of the web site. For the purpose of later discussion, this will be designated as the IT intranet.
  • The demilitarized zone (DMZ) subnet faces the public internet and generates the web pages seen by the users. Requests are evaluated by the application server and valid requests are then passed to the production subnet using a well-defined set of protocols. Sensitive information is not stored in this system.
  • The production subnet contains the actual database and an aplication server that processes the requests from the DMZ. This application server then generates the SQL commands, executes them, and passes the information back to the DMZ.

By dividing the complete system into subnets with controlled interfaces, the subnets can be analyzed for security independently. Since each individual subnet is small and simpler, analysis can be carried out using formal proofs. So the next step is to consider the actual protection that can be applied to the individual computers and the effect that they will have in securing the system.



Access to the DMZ and production subnets will be controlled by routers using access control lists. This will insure that messages coming from a given subnet are actually coming from the specified subnet. This moves the authentication from “what you know” to “what you are”.

DMZ Node

The firewall for the server in the DMZ is set up so that access to the operating system (Telnet, SSH, X-Windows, Remote Desktop Login, etc.) can only be obtained from the IT subnet. Even if attackers from the public internet know the account name and password, they will be unable to gain access.

Protection for the application server will involve the use of filters. Requests into the server can be checked for correct format so that attacks involving corrupted messages can be intercepted. Outgoing responses can also be examined so that unexpected error or warning messages can be intercepted.

The application server will not contain the administrative, user, or database account names and passwords. This means that an attacker who has taken over the server will be unable to insert SQL code. Since the damage from a vulnerability is limited, the software on this server is more suited to automated testing and DevOps environments. This is important because it is expected that the code on this node will be changed frequently.

Attempts to penetrate the node on the protection subnet using compromised machines on the DMZ subnet will normally require modification of files on the DMZ node. This means that comparison of the files on the DMZ node against a known “good” version of the files has a very good chance of detecting intrusions. This means that the amount of time that an attacker has to penetrate the production nodes is very limited.

Production Node

The database is stored on the production server and contains the critical data that the attacker would be looking for. Therefore, this is the node that needs the most hardening and security review.

  • Database accounts on MySQL can be set up so that the requests can only come from selected IP addresses. In this case, the accounts would be set up so that requests are only accepted from the production subnet. Different accounts would also be set up for each type of database transaction so that requests are made with minimal privileges.
  • Nodes outside the production subnet would not have access to the production server at the operating system level. Updates and maintenance would be carried out by mechanisms such as the “software update” applications on Windows, Mac OS, and UNIX/Linux systems. This will require effort, but failure to do so makes it difficult to guarantee security.
  • The application server on the production server will accept requests from the DMZ server and generate and execute the desired SQL commands. These requests will only be accepted from the DMZ server.
  • The application server on the production server will also accept HTTP requests from workstations belonging to the IT subnet. These transactions will be used for administrative control of the system. All requests will be fully logged to enable tracing of any changes.  Users will not be able to access the server with Telnet, SSH, remote login, or other means except when the system is taken down from maintenance.  All housekeeping tasks will take place using the application server on the production subnet.

Changes on this system will occur infrequently, and changes will require a thorough security review. Although automated testing may be suitable for determining adherence to functional requirements, testing for security compliance will require a different type of review.

Impact of Exploits

Although the attacker may be able to take control of nodes on the DMZ system, he can’t start trying to penetrate the production system until he compromises the DMZ system. Furthermore, the firewalls prevent the attacker from obtaining shell, X-Windows, or remote desktop to the DMZ systems.

It should be noted that the purpose of a wall is not to stop attackers, but to stop them long enough for counter measures to be taken. That means that you must have a way of detecting the attacks.

Further Actions

This is just the start of the process of securing a site. Provisions need to be made for carrying out maintenance, development, testing, and backup in a secure manner. Users with administrative privileges should not be allowed to select their own passwords, and a host of other policies need to be established to develop and maintain good practices. However, these will be the subject for further posts.


  1. Thomas Fox-Brewster, “How Hackers Broke Equifax: Exploiting a Patchable Vulnerability”, Forbes, September 14, 2017, Retrieved from
  2. Lilly Hay Newman, “Equifax Officially Has No Excuse”,
  3. Gerard Gawalt, “In His Own Word: Library Exhibition Celebrates Tercentenary of Benjamin Franklin’s Birth”, — This is a page from the Library of Congress web site discussing the life of Benjamin Franklin.

Beware the Genie

via Daily Prompt: Genie

If you look at the old fairy tales, you will find that Genies grant your wishes according to Murphy’s law: “If anything can go wrong, it will go wrong”.  To a large extent, this applies to many pieces of computer technology.

  • You can wish to control the lights, air conditioning, and doors in your house from anywhere in the world via the internet of things (IoT) and then find out that everyone else also has the ability to do so, including the burglar who robs your house while you are out of town.
  • You can wish to have access to a site that will build your web site without your having to think, and then find that you have created a site that clearly shows the amount of thought that goes into it.
  • You create a web site because you want to be widely known, and find that the most avid readers are people who want to sell you resort timeshares and a piece of the Brooklyn Bridge.
  • You wish for web site development frameworks that will drastically reduce the effort required, and find that everyone can now hack your site and obtain all your personal information, including your credit card and checking account numbers.

There are a number of books and movies that will show you that magic is dangerous.  According to Florence Ambrose in the online comic Freefall, “Any technology, no matter how primitive, is magic to those who don’t understand it.”  So perhaps you should stop asking the Genie for things until you understand what is happening.  It may take some effort, but as stated by Agatha Heterodyne in the online comic strip Girl Genius: “Any sufficiently analyzed magic is indistinguishable from science!”.  So, before we go to the Genie and wish for things, we should analyze our desires and the available technology more closely.

After all, asking for a Genie and receiving an air to air missile with an atomic warhead would really be bad.

This is my first attempt at writing an entry for the WordPress Daily Post.  If you feel that it is taking the topic less than seriously, you are correct.  After all, if you learn to laugh at yourself, you will always have a source of amusement.  Or as the Cheshire Cat said in Alice in Wonderland, “We’re all mad, you know”.

Picking Your Password

Picking Your Own Password is Dangerous

Selecting your own password for a web site or computer is like hiding a spare key under the door mat and expecting that burglars won’t look there. It may be a surprise to some people, but the burglars know to look there along with a dozen other locations where people hide keys. For example, a number of people decided to use the names of sports teams as passwords, thinking that it was clever, but the passwords were easily cracked.(Dark Reading)

When dealing with user selected passwords, an attacker can generally create a list of a few hundred possible passwords where testing all of the items in the list will grant access twenty to fifty percent of the time for a given account. If the attacker can get a list of account names on a system, he can try this short list against the account names, a process known as “password spraying”.

Pick Passwords Randomly

If you want a password that people won’t be able to guess, there are several methods for randomly generating passwords, many of which produce passwords with billions of combinations that are still relatively easy to memorize.

When analyzing password security, the size of the password space is the number of possible passwords that can be generated. For example, the Diceware Passphrase method uses a number of lists selected from a list of 7776 (65) words. With three words, the size of the password space is 77763 or 4.7 x 1011 possibilities. Some possible phrases would be “good very elite” or “swamp time floor”.

How Big is Enough

  • On the other hand, there are people who talk about attackers being able to test millions of possible passwords every second. (The author of the Diceware Password site recommends using 6 words, for a candidate space of 77766 or 2.2 x 1023 possibilities.) This is usually based on the attacker getting a list of the hashed versions of the passwords. (A hashing algorithm will always produce the same number when applied to a password, and it is incredibly difficult to determine the original password given the hashed value.) I don’t find this argument meaningful for the following reasons.If the attacker has the list of hashed values, he already has access to the files on the system. At this point, he can probably also insert code that will record the account name and password as people log in to the system. The complexity of the passwords become irrelevant. There is no defense.
  • You can easily program a web site to require a period of time between login attempts. The required period usually increases with subsequent attempts. For example, the wait might be 1 second before the second attempt, with the wait time doubling after each successive unsucessful login attempt. (That would result in wait times of 2, 4, 8, 16, and 32 seconds for the third through seventh attempts.) After the seventh consecutive unsuccessful attempt, you could lock out the account for ten minutes, with the wait time for the first unsuccessful attempt after the lockout period reset to one second. This limits the login attempts for a specific account to less than one attempt per minute. With three words, it will take an attacker over five hundred thousand years to go through all of the possibilities for a Diceware Passphrase using three words. A two word Diceware Passphrase would still require over a hundred years. If the site doesn’t use techniques to set an upper limit on the number of attempts, the site is insecure.
  • If the web site doesn’t generate log files that are checked periodically, the site is insecure. If you have logging, attempts to guess passwords will become apparent. (To be described in more detail in a later post.)

Sometimes Smaller Is Better

For those that insist you use more than three words, I would note that many web sites will not allow very long passwords. (See Johnston) The article by Johnston indicates that most people are capable of easily memorizing strings of four tokens or less (a token could be a word, number, image, or musical note). (See articles by Cowan and McLeod) Increasing the size and complexity of the password makes it more likely that the user will write down the password, allowing other people to discover it.

Don’t Reuse Passwords

You should not assume that any web site will safely protect your passwords. In addition to the web site being hacked by somebody outside the site administration, you have to worry about other problems.

  • An attacker could create a web site simply for the purpose of collecting account names and passwords from users.
  • An attacker could gain employment at or physical access to a web site and attack the site from within.

You should therefore use a different password for each computer or web site. Otherwise, an attacker who learns your password on one system can break into other systems with the same password. There are password manager applications that will generate random passwords and store them for you. This means that you only have to remember the password for the password manager application.


  1. Nelson Cowan, “The Magical Mystery Four: How is Working Memory Capacity Limited, and Way?”, published in Curr Dir Psychol Sci, 2010, Feb 1: 19(1):51-57 (Retrieved from HHS Public Access on 2-April-2018 from ). – In this article, it is stated that four items seems to be a reasonable number of items that can be stored in short-term memory, and that the set of items can be composed of words, numbers, and images.
  2. The Diceware Passphrase Home Page,
  3. Diceware Security Blog,
  4. DoD Computer Security Center, “DoD Password Management Guideline”, 12-April-1985, Standard CSC-STD-002-85 – This document is part of the Rainbow Series of documents issued by the Department of Defense. Each of the documents in the series had covers in a different color, and this one had a green cover and was called the “Green Book”. Even though it is considered outdated, it is a good starting point as it avoids the hyperbole I have seen in other documents.
  5. Dan Goodin, “Why passwords have never been weaker – and crackers have never been stronger”, Ars Technica, 20-August-2012,
  6. Chris Hoffman, “How to Create a Strong Password (and Remember It)”, How-To Geek,
  7. Casey Johnston, “Why your password can’t have symbols – or be longer than 16 characters”, Ars Technica, 29-April-2013,
  8. “The Magical Number Seven, Plus or Minus Two”, Wikipedia,,_Plus_or_Minus_Two (Retrieved 2-April-2018).
  9. Saul McLeod, “Short Term Memory”, SimplyPsychology, (Retrieved 2-April-2018). – This is another article discussing the idea of seven plus or minus two representing the number of items that can be stored in short-term memory.
  10. NIST Information Technology Laboratory, “Digital Identiy Guidelines: Authentication and Lifecyle Management,” NIST Special Publication 800-63B. 09-April-2018, – This is part of a series of documents from the National Institue of Standards and Technology: Digital Identity Guidelines (Special Publication 800-63, Revision 3), Enrollment and Identity Proofing Requirements (Special Publication 800-63A), Authentication and Lifecycle Management (Special Publication 800-63B), and Federation and Assertions (Special Publication 800-63C).
  11. “Winners and Losers in Password ‘Bracketology’”, Dark Reading, 23-March-2018, – A discussion about people using the names of sports teams as their passwords.