Penetration Testing: A Roadmap to Network Security

JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN : 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 187 Penetration T esting: A Roadmap to Network Security Mr . Nitin A. Naik, Mr . Gajanan D. Kurundkar , Dr . Santosh D. Khamitkar , Dr . Na mdeo V . Kalyankar Abstract:  Network  penetration  testin g  identifies  the  exploits  and  vulnerabilities  tho se  exist  within  compu ter  network  infrastruc ‐ ture  and  help  to  confirm  the  security  measures.  The  objective  of  thi s  paper  is  to  explain  methodology  and  met hos  behi nd  penetra ‐ tion  te sting  and  illustrate  remedies  over  it,  which  will  provide  sub stantial  va l u e  for  network  security  Pe n e t r a t i o n  testing  should  model  real  wor ld  attacks  as  closely  as  possible.  An  authorized  and  scheduled  pe netration  te sting  will  probably  dete cte d  by  IDS  (Intrusion  Detec t ion  System).  Network  penetration  te sting  is  done  by  either  or  manua l  auto mated  to ols.  Pe n e t r a t i o n  test  can  gather  evidence  of  vulnerabilit y  in  the  network.  Successful  testing  provides  indisputable  evidence  of  the  problem  as  w ell  as  starting  point  for  prioritizing  remedia tion.  Pe n e tr a t i o n  te sting  focuses  on  high  severity  vulnerabilities  and  there  are  no  false  positive . Index T erms — Attacks, Intruder , Penetration T esting, Social Engineering attacks, ——————————  —————————— 1 I NTRODUCTION enetration testing can reveal to what extent the se- curity of IT systems is threatened by attacks by hackers, crackers, etc., and whether the security measures in place are curren tly capable of ensuring IT security. For a clearer picture of t he risks to IT security, the term “penetration test” and the methods used for test- ing were established in 1995 when the first Unix-based vulnerability scanner “SATAN” was introduced. At that time the program was the first tool that was ab le to auto- matically scan computers to identify vulnerabilities. Nowadays, there are a numb er of freeware and commer- cial vulnerability scanners, most of which have an up- datable database of known hardwa re and software vul- nerabilities. These tools are a convenient way of identify- ing vulnerabilities in the systems being tested and there- fore of determining the risks invol ved. Penetration testing is also reffered as Pen Testing or White Hat Attack be- cause good guys are also try to break in to system. 2. INTRUDERS The term “Hacker” is used to refer to any person w ho illegally logged into other IT systems without authoriza- tion. “Hackers” are regarded as being i ntelligent pro- grammers who t arget security loopholes i n IT systems for technical reasons they are not destroy anything but only for curiosity they enter into someone else’s system. “Crackers” are people with criminal energy who utilize weak points of IT systems to gain illegal advantages, so- cial attention or respect.[1] They are normally peoples who get access of complete software by cracking the serial or password of software. “Script kiddies” are usually in- truders lacking in-depth background knowledge and driven by curiosity who mainly direct attack tools downloaded from the Internet against arbitrary or prominent targets.[1] Intruders can have a range of mo- tives for carrying out attacks on IT infrastructure.[1] 3. MAJOR NETWORK A TT ACK S There  are  many  ways  of  manipulating,  Il ligally  updatin g  or  damaging  IT  Networks  and  of  preparin g  an  attack  on  IT  Network.  3.1 Network-based attacks: “Network ‐ based  attacks”  use  network  protocol  function ‐ alities  for  exploitation  and  damage.  Network ‐ based  at ‐ tacks  are  extended  for  Po rt  Scanning,  IP  Spoofing,  Sniff ‐ ing,  Session  Hijacking,  DoS  attacks,  buffer  overflow  at ‐ tack  impairs  the  target  system  by  ove rflowing  a  buffer  whose  bou ndry  is  unchecked.[2]  ,format  string  attacks,  and  other  exploitation  of  vulnerabilities  in  operating  sys ‐ tems,  application  systems  and  network  prot ocols.  3.2 Social engineering att acks: Social  engineering  attacks  are  attempts  to  manipulate  people  with  privileged  knowledge  to  make  them  reveal  security ‐ related  information  such  as  passw ords  to  the  attacker .  The  ranges  of  possible  attacks  are  wide  with  this  technique.  In  its  broadest  sense,  social  engineering  can  also  cover  situations  in  which  security  related  information  is  obtained  by  extortion.  Social  Engineering  P enetrati on  test  wo rk s  be st  when  there  are  specific  policies  and  pro ‐ cedures  that  are  being  tested.[3]   4. P ENETRA TION TESTIN G : S TEPS Following  steps  are  followed  for  penetration  testing  over  the  network:  4.1 Information about the t arget system Ever y  Computer  that  can  be  accessed  over  the  internet  have  an  official  IP  address.  Some  organizations  provides  the  information  regarding  the  block  of  ip  addresses  about  the  systems  over  internet.  ——————————————— — • Mr. N.A.Naik is working as lecturer with Dept. of Computer Science and IT , Yeshwant College Nanded • Mr. G.D.Kurundkar is working as Le cturer with Dept. of Computer Sci- ence S.G.B. College Purna • Dr. S.D. Khamitkar is working as Director, School of Computational Sci- ences S.R.T.M.University , Nanded. • Dr. N.V.Kalyankar is working as Pr incipal, Yeshwant College Nanded. P  JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN: 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 188 4.2 Scan t arget systems for serv ices on offer An  attempt  is  made  to  con duct  a  port  scan  of  the  Sys ‐ tems(s)  being  tested,  open  ports  being  indicativ e  of  the  applications  assigned  to  them.  [2]  4.3 Identify systems and applications The  names  an d  ve r si o n  of  operating  syste ms  and  applica ‐ tions  in  the  target  systems  can  be  identified  by  “finger ‐ printing”.  4.4 Researching V ulnerabilities Information  about  vulnerabilities  of  specific  operating  systems  and  applications  can  be  researched  efficiently  using  the  information  gathered.  Ev ery  operating  system  have  some  loophole  in  it  so  that  the  data  or  the  informa ‐ tion  which  is  stored  in  the  operating  system  may  be  at ‐ tacked  by  an  intruder  ,  so  the  researchers  should  gathe r  the  initial  information  of  operating  system  and  then  try  to  penetrate  the  system  by  applying  some  rules.  4.5 Exploiting vulnerabilities Detected  vuln erabilities  can  be  used  to  obtain  unauthor ‐ ized  access  to  the  system  or  to  prepare  furthe r  attacks.  The  quality  and  va l u e  of  a  penetration  test  depends  pri ‐ marily  on  the  extent  to  which  the  test  caters  to  the  client’ s  personal  situation,  i.e.  how  much  of  the  tester ’ s  time  and  resources  are  spent  on  detecting  vulnerabilities  related  to  the  IT  infrastructure  and  how  creativ e  the  tester ’ s  ap ‐ proach  is.  This  process  cannot  be  covered  in  the  general  description  above,  which  is  why  there  are  huge  differ ‐ ences  in  the  quality  of  penetration  testing  as  a  service.   5. H OW IT WORKS ? The  following  introduces  the  five  phases  of  a  penetration  test  based  on  the  steps  given  above.  The  individual  phases  take  place  successively.  Phase  1:  Introductory  Preparation ;  It  is  difficult  to  fulfill  the  client’s  expectations  without  good  grounding,  such  as  reaching  a  settlement  on  the  objectives  of  the  penetration  test.  At  the  start  of  a  penetration  test  the  client’s  objectives  must  be  clarified  with  him  and  defined.  The  performance  of  a  penetration  test  without  taking  full  account  of  the  relevant  legal  provisions  could  have  cost  under  criminal  or  ci vil  law.  The  tester  must  therefore  ensure  that  the  test  procedures  are  not  going  to  violate  legal  provisions  or  contractual  Settlements.  The  failure  of  a  testing  could  also  lead  to  alternative  demands.  All  details  agreed  to  should  be  put  in  writing  in  the  contract.  Phase  2:  Investigation  :  After  the  testing  decision  ,  objec ‐ tives,  scope,  procedures,  emergency  me asures  ,limitations  have  been  defined  ,  taking  account  of  the  le gal  and  organ ‐ izational  aspects  and  other  conditions,  the  tester  can  start  gathering  information  on  the  target  system.  This  phase  is  the  passive  p e netration  test.  The  aim  is  to  get  complete  information  of  the  system  and  get  information  of  short ‐ comings  in  the  system.  Depending  on  the  size  of  the  net ‐ wor k  to  be  examined,  the  test  steps  may  be  extremely  time ‐ consuming.  These  long  test  steps  are  usually  per ‐ formed  automatically ,  the  time  required  for  them  still  needs  to  be  taken  into  account  in  the  planning.  Thus  a  penetration  test  can  take  several  days.  Phase  3:  Analyzing  information  and  risks:  A  successful,  clear  and  economically  efficient  procedure  must  analy ze  and  assess  the  information  gathered  before  the  test  steps  for  active ly  penetrating  the  system.  The  analysis  must  include  the  defined  goals  of  the  penetration  test,  the  possible  risks  to  the  system  and  the  time  required  for  ev aluating  the  possible  security  flaws  for  the  succeeding  active  penetrat ion  attempts.  The  aims  in  phase  4  are  then  selected  on  the  basis  of  this  analysis.  From  the  list  of  iden ‐ tified  systems  the  tester  may  choose  the  systems  which  have  known  potential  vulne rabilities  due  to  their  configu ‐ ration  or  the  identified  applications/services  or  those  about  which  the  tester  is  particula rly  knowledgeable.  In  a  penetration  test  for  which  the  number  of  target  systems  has  been  clearly  defined  in  phase  2,  this  selection  means  that  the  number  of  target  systems  for  pha se  4  is  automati ‐ cally  reduced.  The  restrictions  mu st  be  broadly  docu ‐ mented  and  justified  becau se  addition  to  the  desired  im ‐ provem ent  in  efficiency ,  they  also  lead  to  a  reduction  in  the  informative  va l u e  of  the  penetration  test  and  the  client  needs  to  be  made  aware  of  this.  Phase  4:  Active  intrusion  attempts:  Finally ,  the  selected  systems  ar e  activ e ly  attacked.  This  phase  involv es  the  highest  risk  within  a  penetration  test  and  should  be  per ‐ formed  with  due  care.  Ho wev er ,  only  this  phase  reveals  the  extent  to  which  the  su pposed  vulnerabilities  identi ‐ fied  in  the  investigation  phase  present  actual  risks.  This  phase  must  be  performed  if  a  ver i fi c a t io n  of  potential  vulnerabilities  is  required.  For  systems  with  ver y  high  av ailability  or  integrity  requirements,  the  potential  effects  need  to  be  carefully  considered  before  performing  critical  test  procedures,  such  as  the  utilization  of  buffer  overflow  exploits.  In  a  white ‐ box  test,  a  patch  may  need  to  be  in ‐ stalled  on  critical  systems  before  performing  the  test  to  prevent  syste m  failure.  The  test  will  probably  not  be  able  to  locate  any  vulnerability ,  but  will  document  the  security  of  the  system.  Unlike  a  hacking  attack,  however ,  the  pene ‐ tration  test  is  not  complete  –  it  will  be  continued.  Phase 5: Final analysis: As well as the individual test steps, the final report should contain an evaluation of the vulnerabilities found in the form of potential risks and recommendations for eliminating the vulnerabilities and risks. The report must guarantee the transparency of the tests and the vulnerabilities it found during testing. The findings of risks for IT security should be discussed in detail with the client after the successful completion of the test procedures. For  a  successful  penetration  test  that  meets  the  client’s  expectations,  the  clear  definition  of  g oals  is  mainly  essen ‐ tial.  If  goals  cannot  be  achived  efficiently,  the  tester  should  notify  the  client  in  the  preparation  phase  and  pro ‐ JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN : 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 189 pose  alternative  procedures  such  as  an  IT  audit  or  IT  se ‐ curity  cons ulting  services.  Client  goals  that  can  be  at ‐ tained  by  penetration  testing  can  be  divided  into  four  categories:  1. Improving  security  of  technical  systems  2. Identifying  vulnerabilities  3. Having  IT  security  confi rmed  by  an  external  agency  4. Improving  security  of  infrastructure  of  organiza ‐ tion  and  personal  infrastructure  The result of an IT penetration test should not be only list of existing vulnerabilities but also suggest specific solu- tions for their elimination because A penetration test is an authorized, local attempt to "h ack" into a system , to iden- tify exploitable weaknesses, and to reveal what systems and data are at risk.[4] 6. A PPLICA TIONS OF P ENETRA TION T ESTING • Understand and reduce the impact, frequency, and sternness of security incidents. • Meet compliance and regul atory requirements that re- quire security assessments[5]. • Optimize and prioritize resources used to remediate vulnerabilities[5]. • Gain peace of mind about security safeguards, controls, and policies[5]. • Identifies vulnerabilities and risks in your networking infrastructure. • Validates the effectiveness of current security safe- guards. • Quantifies the risk to intern al systems and confidential information. • Raises executive awareness of corporate liability. • Provides detailed remediation steps to prevent network compromise. • Validates the security of system upgrades. • Protects the integrity of online assets. • Helps to achieve and maintain compliance with federal and state regulations • Using  an  automated  product  allows  you  to  consistently  test  your  network  and  easily  integrate  the  practice  with  your  overall  security  program.  This  means  you’ll  have  more  confidence  in  the  overall  security  of  network[5]  • It  will  give  information  abou t  the  how  much  informa ‐ tion  is  publicly  available ?.  •  7. L IMIT A TIONS OF PENETRA TION T ESTING Now  a  days  attackers  or  hackers  are  becomes  more  smart  and  intelligent  and  the  new  sercurity  related  problems  in  IT  sercurities  are  reported  very  rapidly.To  make  a  system  more  sercure  it  is  necessary  to  take  bul k  tests  at  a  time.  A  new  security  loophole  may  mean  that  a  successful  attack  co uld  take  place  immediately  after  a  penetration  test  has  been  completed.[2]  It  is  possible  that  the  new  security  hole  which  is  not  discovered  during  test ‐ ing  may  result  into  attack[6].  As  definition  of  Testing  ser ‐ vice  can  only  find  the  vulnerabilities  and  cannot  prove  the  absence  of  vulnerabilities,  although  the  independent  client  test  consistently  show  the  quality  of  penetration  test.  As  penetration  test  report  shows  the  methodology  which  is  used  during  test  and  various  procedures  used  during  penetration  test  a  person  who  have  some  experi ‐ ence  about  the  network  sec urity  can  guage  the  through ‐ ness  of  the  test.   8. C ONCLUSION This  paper  gives  information  about  the  penetra ‐ tion  testing  ,  its  methodologies  and  its  application.  High ‐ lights  how  an  experienced  security  consultan t  is  neces ‐ sary  for  the  good  penetration  and  role  of  him  to  give  se ‐ curity  system  to  the  host  machine  by  expecting  the  secu ‐ rity  attacks.  The  institutions  /  offices  /  companies  where  the  network  system  is  installed  ,  it  is  necessary  to  deploy  the  security  personnal  who  knows  the  possible  modern  security  attacks  and  try  to  develop  a  me chanism  to  over ‐ come  these  security  attacks.  F or  this  it  is  necessary  that  the  penetration  system  should  be  accrurately  and  scien ‐ tifically  created  and  executed.  While  documenting  the  test  results  of  pen etration  system  a  scientific  and  procedural  approach  should  be  there.T he  penetration  testing  results  should  be  taken  frequently  as  there  are  day ‐ to ‐ day  modi ‐ fications  in  the  attacks  over  network.  As  per  the  new  modified  attacks  ov er  netw ork  the  penetratrion  test  should  be  modifie d  as  per  attack  (The  security  personnal  should  think  as  hacker).The  organizations  where  the  penetration  system  is  deployed  should  give  roadmap  to  the  security  personal  for  the  security  measures.  As  a  measurement  tool,  penetration  testing  is  most  powerful  when  fully  integrated  into  the  dev elopment  process  in  such  a  way  that  findings  can  help  improv e  design,  im ‐ plementation,  and  deployment  practices.   R EFERENCES [1] Federal office of Information Securi ty , Godesburger alee , 185-189 53175 Bonn. , http://www.bsi.bund.de [2] Diok Jin K im, Ta e Hyun g Kim , Jo ng Kim a nd Su ng J Hon g , “Re turn address randomization scheme for annulling Data Injection Buffer Overflow Attacks”, Inscript 2006 , LNCS 4318 , Springer Verlag Berlin Hiedilberg , pp. 238-252 , 2006 [3] “Penetration Testing Meth odology” , Syrnix Technologies : Confidential pp.4 [4] “2008 CSI Computer Crim e and Scurity Survey”, Computer Security institute publication , pp.2 [5] “Penetration Testing : Proactively Address Risk," www.tatacommunications.co m/ enterprise/security [6] Arif Zina , “Penetration Testing Techniques for an an alysis perspective” , http://www. scribd.com/doc/13470161/Final- Project-Penetrati on-Testing A UTHORS Nitin A. Naik Completed M.Sc. Computer Science from S.R.T.M. University in 1997 and from Dec. 1997 working as Lecturer in Dept. of Computer Science & IT , Yeshwant College Nanded.From Jan. JOURNAL OF COMPUTING, VOLUME 1, ISSUE 1, DECEMBER 2009, ISSN: 2151-9617 HTTPS://SITES.GOOGLE.COM/S ITE/JOURNALOFCOMPUTING/ 190 2007 working as Network Administrator for camp us wide network of same college. He is also life me mber of Indian Science Congress, Kolkata (India). Gajanan D. Kurund kar Completed M.Sc. Computer Science from S.R.T .M. University Nanded in 2000. He joined as lecturer in Dept. of Commputer Science from June 2001 to Jan. 2006 , Currently work- ing as Lecturer in Dept of Com puter Science at Sri Gurubuddhi Swami College Purna (India) from Jan.2006 to till date. He is also life member of Indian Science Congress, Kolkata (India) Santosh D. Khamitkar : Completed M.Sc. Computer Science from B.A.M. University , Aurangabad. in 1994. in 1995 he joined as Lec- turer in School of Computational Sciences in S.R.T .M.University Nanded. He Completed his Ph.D. from S.R.T .M. University in 2009 and currently he is working as Director , School of Computational Sciences , S.R.T .M. University , Nanded. He is T echnical Advisor (Freelance) of Portal Infosys, Nanded. He is also Research Guide for Computer S tudies in S.R.T .M. University , Nanded. He is life member of Indian Science Congress, Kolkata (India) Namdeo V . Kalyankar: Completed M.Sc. Ph ysics from B.A.M. Uni- versity , Auranga bad. in 1980. in 1980 he joined as Lecturer in De- partment of Physics in yeshwant College,Nanded. In 1984 he co m- pleted his DHE. He Completed his Ph .D. from B.A.M.University in 1995. From 2003 he is working as Principal since 2003 to till dat e in Y esh want college Nanded. He is also Research Guide for Computer S tudies in S.R.T .M. University , Nanded. He is also worked on vari- ous bodies in S.R.T .M. University Nanded. He also published re- search papers in various internati onal/ national journals. He is pe er team member of NAAC (National Assessment and Accreditation Council)(India). He published a book entitled “ DBMS Concept and programming in Foxpro”. He also got “Best Principal” award from S.R.T .M. University , Nanded(India) in 2009. He is life member o f Indian Science Congress , Kolkata (India). He is also honored with Fellowship of Linnean Society of London (F .L.S.) on 1 1 th Nov . 2009