i took in the four stages of pen testing. That was supplied to me by TheCotMan.
Actually, That list was copied and pasted (as cited) from the web page of your course. It is not my list. A URL is included in the post where I mention it.
Also I showed them my posts at Defcon. That is basically it. OH yeah, I told them to never DOUBLE POST!!!
Better to have them read and understand the rules. ;-)
Sorry for the long wait on the results for my network security class. I got a 3.8 (out of 4.0) out of the class. Which i am very proud of, and I would like to thank Highwizard, TheCotMan, and voltage spike for their words of wisdom. That helped me though my group project. Which was poorly setup by the sounds of it. The computer that was setup for my group to pen test was being altered though all of my test. Which is a bitch to do when trying to gain access to this computer.
I went though my presentation describing each step i took in the four stages of pen testing. That was supplied to me by TheCotMan. This made for an interesting presentation. I kept finding myself repeating over and over in hopes it ingrains this information not only in their heads, but mine as well. I never got into the computer that was designated for the pen testing. Which saddened me, but will make me work harder in my studies to get better. I never got to mess around with Nesus as much as I wanted, but I the experiences in various other programs was fun. Also helping out the Honeypot group was fun. They downloaded the trial version of a windows honeypot. Then we worked together to present some information that would help in the discovery of a honeypot, and the setting up of one. Also I showed them my posts at Defcon. That is basically it. OH yeah, I told them to never DOUBLE POST!!!
-Enjoy
================================================
Four stages of Pen Testing
==================================================
1. planning
2. discovery
3. attack
4. reporting
=================================
This is the port scan on target computer.
==============================
[root@localhost ~]# nc -v -z -w 3 134.39.10.240 1-65321
dpsvr2003.mtolympus.local [ 134.39.10.240] 3389 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 3269 (?) open
dpsvr2003.mtolympus.local [ 134.39.10.240 ] 3268 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 1088 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 1038 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 1028 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 1025 (?) open
dpsvr2003.mtolympus.local [ 134.39.10.240] 636 (ldaps) open
dpsvr2003.mtolympus.local [134.39.10.240] 593 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 464 (kpasswd) open
dpsvr2003.mtolympus.local [134.39.10.240] 445 (microsoft-ds) open
dpsvr2003.mtolympus.local [134.39.10.240] 389 (ldap) open
dpsvr2003.mtolympus.local [134.39.10.240] 135 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 88 (kerberos) open
dpsvr2003.mtolympus.local [ 134.39.10.240] 53 (domain) open
[root@localhost ~]#
==============================================
Second scan
=======================================
root@l19msftxps10 ~]# nc -v -w3 -z 134.39.10.240 1-60000
dpsvr2003.mtolympus.local [134.39.10.240] 3389 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 3269 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 3268 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 636 (ldaps) open
dpsvr2003.mtolympus.local [ 134.39.10.240] 593 (?) open
dpsvr2003.mtolympus.local [134.39.10.240] 464 (kpasswd) open
dpsvr2003.mtolympus.local [134.39.10.240] 445 (microsoft-ds) open
dpsvr2003.mtolympus.local [134.39.10.240] 389 (ldap) open
dpsvr2003.mtolympus.local [134.39.10.240] 135 (?) open
dpsvr2003.mtolympus.local [ 134.39.10.240] 88 (kerberos) open
dpsvr2003.mtolympus.local [134.39.10.240] 53 (domain) open
================================================== =
Port info
====================
135 UDP epmap DCE endpoint resolution
88 TCP kerberos Kerberos
53 UDP domain Domain Name Server
389 TCP ldap Lightweight Directory Access Protocol
445 TCP microsoft-ds Microsoft-DS Lioten, Randon, WORM_DELODER.A, W32/Deloder.A, W32.HLLW.Deloder, Sasser
445 UDP microsoft-ds Microsoft-DS
464 TCP kpasswd kpasswd
464 UDP kpasswd kpasswd
593 TCP http-rpc-epmap HTTP RPC Ep Map
593 UDP http-rpc-epmap HTTP RPC Ep Map
636 TCP ldaps ldap protocol over TLS/SSL (was sldap)
636 UDP ldaps ldap protocol over TLS/SSL (was sldap)
1025 TCP blackjack network blackjack Fraggle Rock, md5 Backdoor, NetSpy, Remote Storm
1025 UDP blackjack network blackjack Remote Storm
1038 TCP mtqp Message Tracking Query Protocol
1038 UDP mtqp Message Tracking Query Protocol
1088 UDP cplscrambler-al CPL Scrambler Alarm Log
1089 TCP ff-annunc FF Annunciation
3268 TCP msft-gc Microsoft Global Catalog
3268 UDP msft-gc Microsoft Global Catalog
3269 TCP msft-gc-ssl Microsoft Global Catalog with LDAP/SSL
3269 UDP msft-gc-ssl Microsoft Global Catalog with LDAP/SSL
3389 TCP ms-wbt-server MS WBT Server
3389 UDP ms-wbt-server MS WBT Server
=======================================
checking 134.39.10.17
=============================================
[root@l19msftxps10 ~]# ping 134.39.10.17
PING 134.39.10.17 (134.39.10.17) 56(84) bytes of data.
64 bytes from 134.39.10.17: icmp_seq=0 ttl=64 time=0.267 ms
64 bytes from 134.39.10.17: icmp_seq=1 ttl=64 time=0.236 ms
64 bytes from 134.39.10.17: icmp_seq=2 ttl=64 time=0.229 ms
64 bytes from 134.39.10.17: icmp_seq=3 ttl=64 time=0.239 ms
64 bytes from 134.39.10.17: icmp_seq=4 ttl=64 time= 0.245 ms
64 bytes from 134.39.10.17: icmp_seq=5 ttl=64 time=0.204 ms
64 bytes from 134.39.10.17: icmp_seq=6 ttl=64 time=0.223 ms
=============================================
Ports open for 134.39.10.17
==============================================
22 ssh open
25 smtp open
111 sunrpc open
113 auth open
1241 unknown open
=========================================
Programs under the port
=========================================
593 ncacn_http/1.0
=================================
Information on ports and vulnerablities
=================================== http://web.mit.edu/kerberos/www/advi...3-004-krb4.txt
I don't think so. Ozone seems genuine, and he already knows more about the available tools than most of his peers.
This is such a great comment. At first there is a counter to Ozone now being labeled a script kiddie, but then there is suggestion that counters the former when he is compared to his peers.
If it was intentional, that was nice. :-)
If we assume that Ozone eventually moves beyond script kiddie, but still plays this role now, he is still playing this role.
Beyond this, we cannot be certain that a lurker won't use the advice too. If this is the case, then the comment about a script kiddie being born can be true for for than just one person.
Let's see what kind of progress this user makes between now and their next post.
Stumbling to me is a sign that something is not quite right with this project.
I think it has more to do with the teacher assuming self-motivated students. Most undergraduate classes tend to give the students 1 and 2 and ask for 3, but some of the better projects ask for 3 and let the students make their own discoveries.
Originally posted by TheCotMan
If you build a library of exploits with source code, you can better understand what they share in design.
This is an excellent suggestion. Unfortunately exploit code tends to be ... obtuse. Work through it and figure out how each exploit works you will be infinitely better. This does take time, but it will ultimately be the best education at conquering stage 3. You have already discovered a running service on the server with a known exploit, and I applaud you for not simply running a canned script (if an actual implementation exists). Now you get to the fun part.
Originally posted by TheCotMan
And another script kiddie is born.
I don't think so. Ozone seems genuine, and he already knows more about the available tools than most of his peers.
Ozone has demonstrated a willingness to learn, wants to do things himself rather than use existing tools when he thinks it will aid his understanding, and is apparently setting up test systems outside of class so that he can examine an attacked computer in a controlled environment.
Being willing to learn is not enough; there must be ambition to try to work on things while waiting for help. Lack of progress is an indication to me that there is expectation to have others do the work.
Finding exploits for a specific service does not take much time with google. Finding an exploit for a specific version may take a little longer.
There has been mention of "nessus" but an implication that it has never been used. There are other tools out there that will "automagically" scan a host for service versions to look for services with known exploits in the application's DB. There are even tools that allow a user to choose to enable "dangerous tests" that could potentially DoS a box during the testing process where security holes to network services are sought out.
From my point of view, a class like this would have at least covered some of these by name if this was a task given to this user by the professor.
He isn't asking for you to do his work for him, but he is looking for a nudge in the right direction at a point in his learning where he is still stumbling around.
Stumbling to me is a sign that something is not quite right with this project.
Cut him some slack, TheCotMan. After all, you must remember what the level of teaching was like when you were in college.
:-P~~~~~ (heh)
PS: It sounds like Ozone is in an interesting class. I wish something like it were available when I was an high school/undergraduate student.
What about "extracirricular activities"? ]:>
OK. Voltage Spike has granted you some pity, and that is worth something. Here is an obvious resource:
Check out MS KB articles for security updates and notices per service with each SP and hotfix. MS can be helpful when pointing out what security problems exist in unpatched services. Some can even tell you the CAN or Sec-ID or ... that is addressed with a particular hotfix/SP.
Determination of service version can help determineSP/Hotfix. Backtracking from an announcement to fixes gives you a huge collection of keywords to use in searching, and things to try. Some exploits will even include statements like, "This works on Win XP pre SP2," and may even list hotfixes names that defeat them as well.
If you build a library of exploits with source code, you can better understand what they share in design.
In your class, using the short list they have on penetration testing:
1. planning
2. discovery
3. attack
4. reporting
You will spend most of your time in state changes from 1 to 2 back to 1 back to 2. Planning leads to discovery which may improve your planning for another round, and then help you to discover more. This is your research. This is time consuming. 3 is very fast, and you go back to 2 to examine the result. From there, you may go back to 1, or you may move on to 4.
1 and 2 are the most sexy of the the items listed. 3 is the biggest rush, and 4 is boring. For me, the best 4 is, "Your system service XXX is vulnerable. Fix it." Writing up reports on the process is the worst part.
Here is your push:
Identify a chosen service. Find a way to determine the name of the application (like the .exe name for windows), the name of the application (like apache vs IIS) and version (if possible) and get hints to what SP/Hotfixes are included. Search for notices on new hotfixes/SP that have come out since then and backtrack to see what security holes have been fixed. This is your keyword list. Google is your friend.
Leave a comment: