- Email: [email protected]
Cracking PC security
rarely used area within the file. Then, whenever a new disk is introduced to the system, the virus can tell (if it has revectored the ‘read new disk
yet another system, once more the virus has the opportunity to replicate itself.
This way, any installed
its host program isn’t run, and any changes can be spotted. Write-protecting the security disk and renaming the files deter modification. The final stage of a virus’s lifecycle - the destructive phase - is the one least likely to
Finally, the purpose of the virus can be upon.
the security backups.
virus has no chance of becoming activated as
routines), and can take the opportunity to copy itself once more. When that disk is moved to
deliberated
utility used to check that the normal operating system files are unchanged and identical with
This stage is the one where
render the rogue program detectable until it chooses. However, if a virus is known to exist
the programmer has the most flexibility to follow his or her own personal sense of ‘fun’. Once more, the hobbyist has the greatest freedom in
and its behaviour is known, then checks can be made for such things as text strings or unusual system commands within a file.
his ability to design, write, test and modify the virus without fear of discovery. Each of the three stages can be used by potential victims to predict about what and when an infection is likely. The first part - the potential for introduction from an infection source - can be risk-minimized by common sense precautions (as detailed by Dr Jan Hruska in the April issue of CFSB). But there is no guarantee of safety. The second stage, the installation and reproduction of the virus within the system, is the one where effort will be rewarded. If the virus is installed and can do damage, then it has ipso facto made changes, and changes can be detected. It is in this area that commercial virus cures work; however, given the ingenuity of the virus producers, it is possible that super-viruses which can detect and nullify commercial programs will be written. The biological analogy is strong here too - overzealous use of an effective antibiotic can result in resistant strains emerging. Perhaps the safest option is for each system user to evolve a personal checking scheme; taking copies of the operating system files, renaming them and placing them on a write-protected disk together with a file comparison program (many operating systems have such a utility provided as standard MS/PC-DOS has FC and COMP) is likely to be safe.
What happens next? As computer software becomes more complex, so will viruses. Imagine two halves of a virus, each individually harmless and undetectable, which when they find themselves on the same system combine and become virulent. If a committed programmer is working on two consecutive projects for commercial programs which he knows are likely to be used together, then he could design such a horror in. Or a constantly mutating virus, which moves from file to file or installs itself in ‘unused’ and thus inaccessible disk space. Not uncodable. The best defence of all is to be aware that such things can and will happen, and to organize your work and system in such a way as to limit any damage that may happen and the possibility that it will. Rupert Goodwins,
CRACKING
UK
PC SECURITY
This article is not intended to give a guideline on how to break so-called PC security systems, but by illustrating how it was done in a particular, but un-named, case, to show how to investigate others for adequacy and to give some guidance to software developers on how to develop systems that do more than lip-service to security.
On a regular basis, the system should be re-started from this disk, and the comparison
o 1988 Elsevier
COMPUTER FRAUD & SECURITY BULLETIN
Science Publishers
B.V., Amsterdam./88/$0.00
+ 2.20
No part of this publication may be reproduced. stored in a retneval system. of transmitted by any form or by any means, electromc. mechanical. photocopying, recording or otherwise. without the pnor perrmsslon of the publlshers. (Readers in the U.S.A. - please see speaal regulations listed on back cover.]
Vol.
10, No. 7,
Page 5
clear pattern of a repeated single byte, which we guessed as being the representation of a blank.
The product we investigated is produced by a large software house and is claimed to provide security through user passwords at multiple levels. Only ten passwords could be specified, so that either it works only in a very small department or else it immediately breaks a ground rule of basic security that passwords should not be shared. A security administrator password, which cannot be deleted, is included and is supposedly provided to the purchaser in confidence when the product is being installed. The procedure follows: 1.
we adopted is essentially
Yes, the supplier had thought of the need to ‘encrypt’ the password file. The question was how good that was, and the pattern showed that it was relatively simple and that the master password was only three characters long. The field had a length indicator followed by the ‘encrypted’ characters.
as 4.
Read the manual.
This shows how
passwords are to be entered, how long they can be, and discusses the levels of security available. There is nothing wrong with this, but it does show that the user cannot change passwords and that the passwords can be displayed by the master administrator. Both of these are contrary to sound security practice. 2.
Scan a hexadecimal dump of the programs using DEBUG or a utility such as Norton or Mace. This led to locating the message instructing the user to enter the password. Hence, by scanning further, it was possible to determine the files addressed by the program and which might contain the passwords. This was needed because the supplier had used a hidden file, but not a hidden file name and extension. Encrypting the message in storage would help, but files would still be named, and the program files can be scanned to find the names. The only solution to this type of problem would be to use an encrypted operating system and programs, as with the ERACOM board, with a different key for the programs than for the data files. The dumped data would then all be encrypted - programs, messages, file names and all.
3.
With the name of a hidden file known, it is now simple to dump that file, also in Hex, for investigation. What we found was a
COMPUTER FRAUD & SECURITY BULLETIN
Where to go from there We did not have enough characters for frequency However, since we had
is the question. in three analysis. a random copy of
the programs out of a set of many copies, it seemed likely that the key would be the same in all cases and would have some relevance to the supplier or the purchaser (if the vendor had tailored all copies before delivery). Since the shrink-wrap package had not been broken, the latter was unlikely. We could have started an exhaustive test from AAA to ZZZ (or 999) but decided to try a few possible combinations related to the supplier and were quickly rewarded with access to the password control facilities. 5.
If all we wanted was to crack that particular PC and its software package, the above was enough. However, there are more of these around, so it might be useful to determine exactly how the thing was set up and then it could be used for other installations. This is something the crook would want to do. Hence, the next step is to enter passwords corresponding to all letters of the alphabet, and to use the Hex dump to see the actual bit patterns resulting from this. The procedure was to write the results out in two ways. One is as the recorded bit pattern in a matrix of the known character bit pattern, and the other is the converse. This showed a bulk shift of characters from their normal ASCII representations. Because this pattern was so regular, it was
o 1988 Elsevier Science Publishers B.V., Amsterdam./88/%0.00 + 2.20 No part of this publication may br rrproduced. stored in a rPtrlrwl qvstrm. of trx>smltted bv an>; form or by any means. electromc. mechanical. photocopying. retordingnr others-lw. wlthollt thr pnor perm~ssmn ofthe publishers (Readers m the U S.A. ~-- please see special regulatmns hsted on back cover )
Vol.
10, No. 7,
clear that there was no random character string or phrase used to select as in a Caesar Cypher, but that there had been an algorithmic modification, character by character. A few minutes testing on observed characters and checking on others showed that the ‘encryption’ was to XOR a single character, X’77’, to each of the password’s characters. 6.
Page 6
3.
The messages and file names should be protected, not just buried in code.
4.
The security administrator be varied and randomized the same for all copies.
5.
The security administrator should not be able to see user paswords after the user has changed an initial password. A means is required for the administrator to reset passwords without being able to read the file.
Now we had the lot. The master password derived from the supplier initials, the name of the ‘hidden’ file, the structure of the file, the encryption
algorithm,
and a technique
that would allow us to break similar systems in only a few minutes. Since we do not claim to be DOS experts, the ease with which the suppliers’ claims could be nullified is alarming. How many users are there who believe they are secure? Yet access to their PC, while they are momentarily away from their desk, is sufficient to break into the package, and the installation would not know. Can anything be done? We believe suppliers could learn a few lessons which are very basic. 1.
Have your claims substantiated.
2.
Encryption, rules:
4
if used, should follow some
The key requires random bit patterns. X’77’ is far from this. The key repetition should be longer than the message to be encoded. In this case a key longer than the longest password would be required, not one with a four-bit repetition frequency.
cl
Blanks should be encrypted significant characters.
4
A feed-back cypher of some kind is a lot stronger than one that remains the same for all characters or all usage.
COMPUTER FRAUD 81 SECURITY BULLETIN
password should so that it is not
as well as
6.
Passwords should not be shared under any circumstances. This means sufficient numbers to allow for the users to have their own passwords, and not an arbitrary limit.
It might be interesting to see if claims under consumer protection laws for false and misleading statements, or unfitness for the purpose, would succeed. Perhaps a case for negligence could be brought when the supposedly secure system is cracked to the detriment of an organization. Whatever possibilities exist for compensation, our investigation suggests that while the security facilities do not live up to claims, in this case at least, there are some simple steps developers could take to tighten up security. These can be at a software level, but ultimately, or for higher security, would need hardware encyption to protect critical elements of the security system. Dr Les Lawrence,
Vonaldy Pty Ltd, Australia
COMPUTER CRIME IN AUSTRALIA - IS THE LAW ENOUGH? Recent activity has occurred in some states of Australia to combat computer crime. The Queensland Government issued a ‘Green Paper’ late in 1987 for public review, but so far has taken no action on the submissions made on it, and has taken no steps to prepare any legislation. The first state to consider legislation was Victoria which introduced a Bill late last year, but deferred it to admit public discussion.
o 1988 Elsevier Science Publishers B.V.. Amsterdam.kl8/$0.00 + 2.20 No part of this publication may be reproduced. stored in a retrieval Fystem. OF transmltted bv anv form or by any means. electronic. mechanical, photocopying. rmording or otherwse. without the pnor permm~on of the pubhshers. (Readers in the U.S.A. - please see special regulations listed on back cover.)
yet another system, once more the virus has the opportunity to replicate itself.
This way, any installed
its host program isn’t run, and any changes can be spotted. Write-protecting the security disk and renaming the files deter modification. The final stage of a virus’s lifecycle - the destructive phase - is the one least likely to
Finally, the purpose of the virus can be upon.
the security backups.
virus has no chance of becoming activated as
routines), and can take the opportunity to copy itself once more. When that disk is moved to
deliberated
utility used to check that the normal operating system files are unchanged and identical with
This stage is the one where
render the rogue program detectable until it chooses. However, if a virus is known to exist
the programmer has the most flexibility to follow his or her own personal sense of ‘fun’. Once more, the hobbyist has the greatest freedom in
and its behaviour is known, then checks can be made for such things as text strings or unusual system commands within a file.
his ability to design, write, test and modify the virus without fear of discovery. Each of the three stages can be used by potential victims to predict about what and when an infection is likely. The first part - the potential for introduction from an infection source - can be risk-minimized by common sense precautions (as detailed by Dr Jan Hruska in the April issue of CFSB). But there is no guarantee of safety. The second stage, the installation and reproduction of the virus within the system, is the one where effort will be rewarded. If the virus is installed and can do damage, then it has ipso facto made changes, and changes can be detected. It is in this area that commercial virus cures work; however, given the ingenuity of the virus producers, it is possible that super-viruses which can detect and nullify commercial programs will be written. The biological analogy is strong here too - overzealous use of an effective antibiotic can result in resistant strains emerging. Perhaps the safest option is for each system user to evolve a personal checking scheme; taking copies of the operating system files, renaming them and placing them on a write-protected disk together with a file comparison program (many operating systems have such a utility provided as standard MS/PC-DOS has FC and COMP) is likely to be safe.
What happens next? As computer software becomes more complex, so will viruses. Imagine two halves of a virus, each individually harmless and undetectable, which when they find themselves on the same system combine and become virulent. If a committed programmer is working on two consecutive projects for commercial programs which he knows are likely to be used together, then he could design such a horror in. Or a constantly mutating virus, which moves from file to file or installs itself in ‘unused’ and thus inaccessible disk space. Not uncodable. The best defence of all is to be aware that such things can and will happen, and to organize your work and system in such a way as to limit any damage that may happen and the possibility that it will. Rupert Goodwins,
CRACKING
UK
PC SECURITY
This article is not intended to give a guideline on how to break so-called PC security systems, but by illustrating how it was done in a particular, but un-named, case, to show how to investigate others for adequacy and to give some guidance to software developers on how to develop systems that do more than lip-service to security.
On a regular basis, the system should be re-started from this disk, and the comparison
o 1988 Elsevier
COMPUTER FRAUD & SECURITY BULLETIN
Science Publishers
B.V., Amsterdam./88/$0.00
+ 2.20
No part of this publication may be reproduced. stored in a retneval system. of transmitted by any form or by any means, electromc. mechanical. photocopying, recording or otherwise. without the pnor perrmsslon of the publlshers. (Readers in the U.S.A. - please see speaal regulations listed on back cover.]
Vol.
10, No. 7,
Page 5
clear pattern of a repeated single byte, which we guessed as being the representation of a blank.
The product we investigated is produced by a large software house and is claimed to provide security through user passwords at multiple levels. Only ten passwords could be specified, so that either it works only in a very small department or else it immediately breaks a ground rule of basic security that passwords should not be shared. A security administrator password, which cannot be deleted, is included and is supposedly provided to the purchaser in confidence when the product is being installed. The procedure follows: 1.
we adopted is essentially
Yes, the supplier had thought of the need to ‘encrypt’ the password file. The question was how good that was, and the pattern showed that it was relatively simple and that the master password was only three characters long. The field had a length indicator followed by the ‘encrypted’ characters.
as 4.
Read the manual.
This shows how
passwords are to be entered, how long they can be, and discusses the levels of security available. There is nothing wrong with this, but it does show that the user cannot change passwords and that the passwords can be displayed by the master administrator. Both of these are contrary to sound security practice. 2.
Scan a hexadecimal dump of the programs using DEBUG or a utility such as Norton or Mace. This led to locating the message instructing the user to enter the password. Hence, by scanning further, it was possible to determine the files addressed by the program and which might contain the passwords. This was needed because the supplier had used a hidden file, but not a hidden file name and extension. Encrypting the message in storage would help, but files would still be named, and the program files can be scanned to find the names. The only solution to this type of problem would be to use an encrypted operating system and programs, as with the ERACOM board, with a different key for the programs than for the data files. The dumped data would then all be encrypted - programs, messages, file names and all.
3.
With the name of a hidden file known, it is now simple to dump that file, also in Hex, for investigation. What we found was a
COMPUTER FRAUD & SECURITY BULLETIN
Where to go from there We did not have enough characters for frequency However, since we had
is the question. in three analysis. a random copy of
the programs out of a set of many copies, it seemed likely that the key would be the same in all cases and would have some relevance to the supplier or the purchaser (if the vendor had tailored all copies before delivery). Since the shrink-wrap package had not been broken, the latter was unlikely. We could have started an exhaustive test from AAA to ZZZ (or 999) but decided to try a few possible combinations related to the supplier and were quickly rewarded with access to the password control facilities. 5.
If all we wanted was to crack that particular PC and its software package, the above was enough. However, there are more of these around, so it might be useful to determine exactly how the thing was set up and then it could be used for other installations. This is something the crook would want to do. Hence, the next step is to enter passwords corresponding to all letters of the alphabet, and to use the Hex dump to see the actual bit patterns resulting from this. The procedure was to write the results out in two ways. One is as the recorded bit pattern in a matrix of the known character bit pattern, and the other is the converse. This showed a bulk shift of characters from their normal ASCII representations. Because this pattern was so regular, it was
o 1988 Elsevier Science Publishers B.V., Amsterdam./88/%0.00 + 2.20 No part of this publication may br rrproduced. stored in a rPtrlrwl qvstrm. of trx>smltted bv an>; form or by any means. electromc. mechanical. photocopying. retordingnr others-lw. wlthollt thr pnor perm~ssmn ofthe publishers (Readers m the U S.A. ~-- please see special regulatmns hsted on back cover )
Vol.
10, No. 7,
clear that there was no random character string or phrase used to select as in a Caesar Cypher, but that there had been an algorithmic modification, character by character. A few minutes testing on observed characters and checking on others showed that the ‘encryption’ was to XOR a single character, X’77’, to each of the password’s characters. 6.
Page 6
3.
The messages and file names should be protected, not just buried in code.
4.
The security administrator be varied and randomized the same for all copies.
5.
The security administrator should not be able to see user paswords after the user has changed an initial password. A means is required for the administrator to reset passwords without being able to read the file.
Now we had the lot. The master password derived from the supplier initials, the name of the ‘hidden’ file, the structure of the file, the encryption
algorithm,
and a technique
that would allow us to break similar systems in only a few minutes. Since we do not claim to be DOS experts, the ease with which the suppliers’ claims could be nullified is alarming. How many users are there who believe they are secure? Yet access to their PC, while they are momentarily away from their desk, is sufficient to break into the package, and the installation would not know. Can anything be done? We believe suppliers could learn a few lessons which are very basic. 1.
Have your claims substantiated.
2.
Encryption, rules:
4
if used, should follow some
The key requires random bit patterns. X’77’ is far from this. The key repetition should be longer than the message to be encoded. In this case a key longer than the longest password would be required, not one with a four-bit repetition frequency.
cl
Blanks should be encrypted significant characters.
4
A feed-back cypher of some kind is a lot stronger than one that remains the same for all characters or all usage.
COMPUTER FRAUD 81 SECURITY BULLETIN
password should so that it is not
as well as
6.
Passwords should not be shared under any circumstances. This means sufficient numbers to allow for the users to have their own passwords, and not an arbitrary limit.
It might be interesting to see if claims under consumer protection laws for false and misleading statements, or unfitness for the purpose, would succeed. Perhaps a case for negligence could be brought when the supposedly secure system is cracked to the detriment of an organization. Whatever possibilities exist for compensation, our investigation suggests that while the security facilities do not live up to claims, in this case at least, there are some simple steps developers could take to tighten up security. These can be at a software level, but ultimately, or for higher security, would need hardware encyption to protect critical elements of the security system. Dr Les Lawrence,
Vonaldy Pty Ltd, Australia
COMPUTER CRIME IN AUSTRALIA - IS THE LAW ENOUGH? Recent activity has occurred in some states of Australia to combat computer crime. The Queensland Government issued a ‘Green Paper’ late in 1987 for public review, but so far has taken no action on the submissions made on it, and has taken no steps to prepare any legislation. The first state to consider legislation was Victoria which introduced a Bill late last year, but deferred it to admit public discussion.
o 1988 Elsevier Science Publishers B.V.. Amsterdam.kl8/$0.00 + 2.20 No part of this publication may be reproduced. stored in a retrieval Fystem. OF transmltted bv anv form or by any means. electronic. mechanical, photocopying. rmording or otherwse. without the pnor permm~on of the pubhshers. (Readers in the U.S.A. - please see special regulations listed on back cover.)