TECH 581 W Computer Network Operations: Laboratory 5, Team 3

12 thoughts on “TECH 581 W Computer Network Operations: Laboratory 5, Team 3”

1. The group’s abstract starts off with a very brief explanation of what the purpose of this lab is. This explanation could have been expanded on. Most of the abstract is about what needs to be done in this lab. The abstract could have included more on how this lab ties into the course and the importance of this lab was. The group then goes into an introduction. In the introduction the group does make up for the examination of the importance of this lab. The introduction does a great job at introducing the idea of reverse engineering a security document and using the vulnerabilities against a system that is not hardened by this document. The group explains that there are two sections to this lab. The first section being, exploring the vulnerabilities uncovered by reverse engineering the security document that was used in this group’s lab. The second section of the lab that the group talks about is the examination of tools that could be used in exploiting the vulnerabilities in the first section. This group seems to have missed a section of the lab in both the abstract and the introduction. The group does not mention anything about exploring vulnerabilities that service packs or patches fix. In the introduction they talk about finding tools that exploit the vulnerabilities in the first part of the lab. I believe that this part of the lab is supposed to be about finding tools that exploit vulnerabilities fixed by the patches and service packs. In the beginning of the literature review the group does a good job in transitioning past labs into what this lab is about. The beginning of the literature review is a little wordy. The group could have left out the definitions and examples of active and passive attacks, this seemed to be redundant. The literature review in this group’s lab was done very well. The only thing that the group could have done was to tie the literature into the current lab better. Also the methodology and research was not examined. Each of the articles showed how they tied into each other and also a good explanation of what each article was about. The methodology starts off with the group breaking down the security document into baseline security and they also include other securities the document did not cover, like firewall policies. The group does a very nice job in explaining how they went about setting up the table of vulnerabilities. They explain what they included and what the left out. Next they explain how the vulnerabilities were categorized and how tools were found to use in exploiting the vulnerabilities. They also described what tools they were going to test and what they were going to leave out of the tests. Again there was no mention of examination of security patches and service packs this group, among others, left this section out and tied the tools that needed to be found with the vulnerabilities that were listed in the first section of the lab. The group did a very good explanation of the tests they did on all the vulnerabilities that they determined could be done on their network. These tests covered all aspects of security on the computer that they were testing. The group even gave explanations on why a test might have failed and a possible solution was given. The results did not include anything else in them. As an example, the group did not discuss any patterns that might have been present in the tables that were created. The group mentioned a few issues they had with doing this lab. They mention that they had problems with matching vulnerabilities to the OSI model, finding tools to fit some of the vulnerabilities, the amount of changes that the document provided, problems with creating there tables, and issues in the document that did not pertain to security issues. In the conclusion the group found that the process of reverse engineering could be feasible. They broke down the how the lab was accomplished and gave explanations of each section of the lab. The conclusion could have had more to it. It could have included what was learned in doing this lab and what could be accomplished with this learned material.

2. I liked the correlation to military strategy in the introduction. It fits very well in the context of this lab. The literature review could use some work. The first paragraph is a tease by summarizing and relating all of the previous lab exercises, I thought it was going to be tied smoothly into the activities of this lab along with a discussion of the assigned literature. The first two pieces of assigned literature are merely summarized in a paragraph about viruses and buffer overflows yet nothing is tied to the lab activities. How does the class that taught virus writing relate? The virus class taught about virus defense through the process or reverse engineering how viruses were created in the first place. Are we not reverse engineering the security of the systems we’re attacking or testing from documentation on how they are configured or secured? Same concept applies to the testing of data streams, find out how the programs handle data inputs at different points except in this instance we’ll know how it should behave from the documentation. If we note one area that’secured sufficiently, maybe this left a hole somewhere else. The discussion on Jajodia et al.’s article was good but felt just shy of tying it in to the other articles. The attack path method is what we’re attempting to discover through these lab exercises by analyzing what may (or may not) be in place according to the guides, we can find other avenues of attack.

   The methodologies section was very detailed and left very few questions. I liked the mention of referencing MSDN for information but is this really the best place to go? What about TechNet? The discussion about the tools used to test could’ve been a little more detailed. Instead of talking about what tools you were going to run against the VM, where you were going to run those tools from, and most importantly why, the section comes off more just like a list of tools from previous labs.

   The paragraphs leading up to the tables in the finding section provide some useful information about various items discovered but seem disjointed from the activities as a whole. The tables are very well organized with ascending OSI layers and an incrementing key column for future use. My main concern with the table is the lack of detail or discussion on the elements discovered. Providing the name of the security change recommended by Microsoft doesn’t really tell the reader why this is done or, more importantly, what the implications of not making the change could have. Without this, the table lacks depth and relevance. The second table adds some depth to each of the items but lacks specificity. Instead a vague vulnerability is mentioned and the change references are fit into that reference.

   The mention of difficulties with OSI layer is evident in some of the classifications but was handled pretty well by the statement in the methodologies. Whenever I didn’t necessarily agree with an item, I thought back to the methodology of tying it back to the lowest level it would affect. The conclusion could benefit from mentions of the overall topic or goals of the lab rather than restating some of the activities that were performed.

3. I think that this team could use a longer abstract. While it did mention some points that needed to be covered, it did not answer all of them. Maybe to add to the length of the abstract, some of the points talked about in the introduction could be added to the abstract, so it can meet all of the requirements of the lab report. As with this team’s use of single quotes in a lot of places, they are not needed and actually make reading the lab report more difficult. This is especially true when they use quotes for article names instead of italicizing the titles. The team never answered my question from last time, for the introduction items is this common knowledge that everyone in the team has , or did they find this information somewhere else and not cite it properly? Like in all of this team’s previous lab reports, they discuss how this lab experiment has built on the previous research and lab experiments. I don’t think that this part of the lab is needed in the literature review; it should go into the abstract or even the introduction. The team citations are in the wrong location. Citations go after the content from the article, not after the name of the article. This is not following APA 5 require format of lab reports. For some of the citations in the literature review, the team follows the author, year, page format, but from the middle of it on, the team did not follow APA 5 format, the year was missing.
   I have one major problem with how the team handled the majority of the common tools. It states that the team relied on experience. This would not help anyone who was trying to duplicate the lab experiment and did not have this experience. The steps of the process need to be written so that the lab experiment can be duplicated by anyone. It may seem unnecessary, but all steps need to be written out. One thing that I did notice that this team did that no other team did, was spelling out the acronym before giving it to us. That is a nice touch for anyone that doesn’t know them. The team needs to stop writing “we” and use team or group instead. These are not the typical lab reports, and the reports should be written almost like a paper. Most of the findings section read like it should have been the methods section. The testing seemed random and seemed to skip from place to place. As stated before, the steps of the process seemed to skip around a lot, where did all of these findings come from? An issue for the team was time. Use time management, you have 3 members in your group, split the work equally. The last item I have to talk about is, how did the team not have a date for one of the article? Google it to find the date, n.d should never be an option.

4. Team 3’s abstract got right to the point. It was short but it did a good job of telling me what they were going to do in lab 5. The introduction was well written and helped me to understand more about this topic. Like their previous lab reports, they discuss how this lab experiment has built on the previous research and lab experiments. This probably should have been included in the introduction instead of the literature review. The literature review was well written. However, there were numerous formatting and citation errors They could have improved on their literature review by understating the correct way to format and cite with the APA 5 format and to make sure there is a correlation between the articles and the lab. The methodologies section was very thorough. However, the discussion of the tools used to test could have used more detail.
   Team 3’s tables were very well organized. I thought they were very detailed. Their results and conclusions were well written and provided insight into the topic.

5. Team three’s abstract section seemed somewhat brief, but did give an overview of the laboratory assignment.

   In the introduction section, I thought the military analogy was able to fit well with parameters of the assignment. I was unclear what the group meant when they stated “A situation arises were the ‘opponent’ is actually many similar installations (e.g. Microsoft XP), with some being ’strong’ from hardening measures and others remaining weak as these measures are not taken.” Did the group mean that improperly configured boxes are so much of a vulnerability that they are an opponent to themselves? Team three’s introduction also set them apart from the other groups because they would “work to discover areas of weakness implied in the “Security Compliance Management Toolkit for Windows XP” which we hypothesize to be present in this ‘hardening kit.’” Most of the other groups including my own interpreted exploits as meaning weaknesses that would exist if the recommendations were not followed.

   Team three’s literature review contained a detailed introduction that recapped the past assignments and tied the laboratories assignment’s articles to the assignment itself by explaining how they are different approaches to discovering vulnerabilities. Team three seemed to also take from the Wales article, that the author had a bias for external penetration testers. I agree that the author of the article used several testimonies from consultants who preformed penetration test, but I gathered that the author thought that a hybrid solution between in house and external was best. There were other teams who also came to a similar conclusion as your team.

   In the methodology section, team three described how the data that they retrieved from their chosen document would be categorized into their table. In regards to determining where some of the recommendations would fit within the OSI model, team three decided to fit the changes in question in the lowest layer possible. The group also discarded recommendations that would have no bearing on their test environment, such as active directory recommendations. The group also described the services that they tested by stating “We evaluated such tools as Microsoft remote registry editor, auto-run configuration of removable media, and compromised executables via the ‘FU’ rootkit Trojan inserted with Micro-joiner. Furthermore, we examined the information returned by such built-in tools as ‘nbtstat,’ ‘arp,’ ‘route,’ and ’systeminfo.’ Finally, an evaluation of the state of the Windows XP firewall was made via the Nmap security tool.”

   In the results section, team three briefly described the contents of both of their tables. Team three was also able to describe the parameters of the tests they conducted with the outcomes that occurred.

   In the issues section, team three listed a few issues. The team stated “This exercise proved challenging, in that many issues of configuration change did not easily fit into the OSI model layer.” The team also stated “some of the vulnerabilities which we speculated to exist may not have known attack tools:” Team three was also somewhat overwhelmed by the first table that they had created.

   Team three gave a descriptive summary of what they learned and had problems with in the conclusion section. The team also revisited their test results.

6. Team 3 starts with their abstract and states that they will be going over Windows XP and using the management tool kit from windows during the lab. Then they go over their introduction and it went over reverse engineering and what they are going to use within the lab. The introduction seemed just to be a reiteration of the abstract and not needed. Then the group goes into the literature review. Again at the beginning of the literature review it seemed like they were giving another abstract. Some of the points at the beginning of the literature may have been able to go into the introduction and discussed in more depth upon. Then the start of the review of the actual articles begins. The team goes over each article and again this week is just a reiteration of what happened within the articles. At the end they talk shortly about vulnerabilities and using the resources to resolve any problems area within systems. The literature section of the document can still be improved upon. It can be improved by comparing the articles between each other and creating arguments on the issues within them. They then go onto the methodology section. This area of the lab is the strong point where they are able to go into detail what is going to occur within the hands on portion of the lab. The team then goes onto the findings for their hands on testing. Within this section they explained some of the vulnerabilities with Windows XP. At the end of the document is where they placed the tables that were part of the requirements for the lab. These table where will structured and had the information that provides information about the vulnerabilities and the tools that where, and can be used in attacking Windows XP. They then go onto the issue section and state they have an issue defining where powering down the system is at on the table and put it in too layer 2. Does there have to be a change to the network if the system is down? So can this still fall into the physical layer? The team then goes onto the conclusion section, and discusses the lab and reverse engineering. Within this section they added information that could have been added to the results and findings sections. Overall the group did a good job with lab, again the strong point is the methodologies and the literature could be work on to provide arguments on the articles.

7. I think that group 3’s write-up for lab 5 was good. The abstract and introduction for this lab was very good. The literary review was somewhat very good. Group answered all of the required questions for the literature review. All of the citing for the literary review was present, but not proper throughout the lab. The literature review was cited properly throughout. The author and year of the reference was included and all of the page numbers were present. For this lab, the group answered all of the desired questions. The group created a large and complete table that indicated all of the found vulnerabilities in their document and indicated their affected layer of the OSI model. However, in their issues and problems they indicated that they did not know which “layer does a machine power down affect?” This struck me as odd because it’s not a vulnerability or exploit. Powering down a machine is a legitimate function and may be an important action once the machine has been exploited, but it is not an exploit unless someone physically unplugs the computer. If someone physically unplugs the computer, this would be a physical attack. The group indicated that a shut down would be considered a layer 2 attack. As stated before, it must be physical; however, even if a legitimate shutdown IS an attack does the NIC turn off when the computer does? What about wake on LAN or link lights remaining on? Finally, the conclusion to this laboratory was also well done because it accurately sums up their procedures and findings.

8. The team starts off with a strong abstract. The team’s source of security configuration is from Security Compliance Management Toolkit for Windows XP. There synapse of the literature reivew was also strong.

   In the Methodology and Procedures sections the team talks about how Microsoft divided this document into two sections, baseline security and additional hardening methods. The group also mention of Windows Firewall is enabled by default and would “bore” if mentioned. The team claims that if the firewall is turned off that the XP machine would be more open to vulnerabilities. I would agree that Windows Firewall does provide a Windows XP user with an extra security out of the box. After there is user interaction does the firewall still stand up to security? Windows firewall does pop-up often asking the users to block or unblock. Soon after a user may get irritated with all the Windows Firewall pop-up and disable the feature, rendering it useless. Also Windows Firewall would need to be configured properly to function best for a user, if novice users are attempting to connect to there workstation machine from home via VPN, the firewall would refuse connection leaving the employee dissatisfied. Perhaps more on Windows Firewall would have been less of a bore.

9. As usual team three presents a lab report for lab five that is complete and within the guidelines of the requirements. That is not to say that their report is not without issue. Team three’s abstract while explaining that was going to be performed in the lab, and not sounding like the lab design guide objectives, is not long enough. The syllabus states that the abstract for each lab report needs to be two paragraphs, and anything else will be considered poor scholarship. Team three regularly misses that point. The introduction provided by team three does a good job of explaining some of the background information to the information that will be provided as part of their lab report. In team three’s literature review their opening paragraph gives a good idea of the steps that have already been completed by team three in previous labs, and how they relate to this lab. In the actual literature review provided by team three there is a very high level of cohesion between the articles, and the discussion gives the reader a good insight into the state of the current literature as it relates to the topics discussed. The methods section as presented by team three does explain in a scholarly manor the strategy and technique used to answer the questions presented by the lab design. They do mention how their chosen security guide does not address Windows Firewall. This information belongs in the findings section and not in the methods section of the lab report. The findings and results section presented by team three do a very good job of explaining what the team found in regards to running their selected exploits based on their security guide. They also compare their results to two of the security databases team three reviewed in the previous lab. It is obvious that Windows did divulge three open ports, which is something it should be doing if those ports are open. I do have a question about the other items NMAP discovered. I question if NMAP gathered the info about the MAC address, and fingerprint from the VM itself or from the VMware vSwitch. It is not a secret that once “inside” VMware the treatment of packets and network info is not that well known. Also since this was VMware workstation, that might make the fingerprinting and MAC address even simpler to discover. In team three problems and issues section, I question a machine power off affecting the data link layer. Just turning the power off in the typical modern day server would not disable the NIC; it would still function for thinks like an IPMI controller or wake on LAN potentially. Unless the power was physically pulled from the server or power failed, I think this is a layer 3 issue. The tables presented by team three are rather complete, and I like the references between tables. That breakdown serves to keep the tables clean and easy to understand, and to relate all work between the two. The conclusions drawn by team three are accurate based on the methods they stated.

10. @jeikenbe: What is the purpose of the abstract? I think you misunderstood the lab.We were to discuss the effect of patches and roll-ups, not to study them in depth.

    @jverburg, mvanbode: good points all around.

    @ tnovosel: no, we meant the opponent defends many possible targets, some strong, some weak. If other people agree with us, what does that tell you?

    @prennick: If a machine is powered down as part of an attack on availability it’s an attack. you are correct, it should have been layer one.

    @chaveza: You are abosolutly right about Windows firewall. It was mentioned here in spite of the fact that it is not formally part of the document for specifically those reasons. What part of our lab bored you? What could we have done to make it more exciting?

    @nbakker: good point about Nmap. I’m honestly not certain. as I mentioned above, I think powering off is a layer 1 issue. I don’t see layer 3. Can you explain?

11. It has been our general strategy to respond thoughtfully to criticism and questions which show insight and indicate more than a trivial examination of our work. I must confess, however, that I cannot hold my tongue with respect to the often seen criticism of our choice of Abstract/Introduction any longer. To answer any criticism in the past or future, I lay out this argument, which is what drives our choice in paper organization.

    We have from the very beginning attempted (unsuccessfully, in some regards) to create our entire lab report according to APA style rules. The APA style manual fifth edition defines an ‘abstract’ to be a “…brief, comprehensive summary of the contents of the article” (p. 12). Additionally, the abstract “…should not exceed 120 words” (p. 13). Finally, the guide asserts that “the body of the paper opens with an introduction that presents the specific problem under study and describes the research strategy” (pp. 15-16). So this is the reason our papers have been structured in such a way: an abstract is ‘not’ an introduction, and in reality should be no more than one paragraph in length if one were to abide by the style rules. Additionally, a separate introduction section is required to be stylistically correct.

    It was hoped that other members of the class were capable of divining this for themselves, and that they would see that an ‘abstract/introduction’ format more than fulfills the requirements of the lab write-up, even though it is broken into two different sections. While most reviewers have apparently made this deduction, a stubborn few remain which have not. For those pedantic enough to insist that “the syllabus calls exactly for this,” I present a word-for-word outline of the syllabus ( pp. 5-7) :

    The sections of the lab exercises are as follows:
    Abstract
    Literature Review
    Methodology to answer the research questions
    Findings in answering the research questions
    Issues or problems on accomplishing the lab
    Conclusions
    Design methodology
    Steps of the process
    Issues or problems
    Conclusions

    I ask: do you follow the syllabus exactly as described? Does the layout even make sense with redundant sections? It appears that every group has been making some assumptions with regard to this ‘official’ layout: so why specifically attack our group for making these choices? I realize that criticism of this nature is easy and requires little thought: however, we have valid reasons for our choices; so please, examine the content and put a bit of additional effort into criticizing that instead.

    @ jeikenbe: Your criticism of “not including security updates or service packs” may be valid, but we believed that the topic should only be addressed if a “recommendation of installation” was contained in the security document under review: we could locate no specific instructions with regard to this. It is likely Microsoft recognized that different enterprise deployments necessarily exist at different patch levels (installing security updates often breaks critical business applications, so some installations always remain at a much lower patch level than what is current). It appears that this document attempted to address security through basic configuration settings alone. Perhaps we should have mentioned this issue in our report. As for describing patterns in the results: we did not find this requirement listed in the lab instructions, and so did attempt to include it in the write-up. I think it is obvious that OSI layer seven is by far the largest target area according to our results table.

    @ jverburg: You are correct about the MSDN issue; most of the information actually was referenced on TechNet. I am at heart a programmer, and nearly all the things I use from Microsoft come from MSDN. I incorrectly grouped Microsoft TechNet in with MSDN. The criticism involving the vagueness of the descriptions: you are essentially correct about this, also. Our security document discussed almost nothing involving the listed Group Policy changes; they were included in table form and as policy kits only. We made the decision to forgo detailed explanation of every single indicated change, and rather to concentrate on researching and testing the most promising vulnerabilities indicated by groups of changes. We believed that this would be the most efficient way of meeting all of the exercise requirements.

    @ mvanbode: With respect to single quotation marks, you may have a point. It is a stylistic choice, and it is perhaps overused. As I am the one who is guilty of the behavior described, I can say only that I was instructed in a recent course on research writing ‘not’ to use italics, but rather single quotes for emphasis. Additionally, you are quite mistaken on the use of italics for article names, as the APA style guide reads: “Use double quotation marks…to set off the title of an article or chapter in a periodical or book when the title is mentioned in the text (p.82). Your insistence that we did not “answer… [your] question from last time” is actually fairly comical, as you never actually asked a question: you simply accused us of plagiarism. No, we do not plagiarize other’s writings or research; we simply take general knowledge and philosophically examine the logical implications within our experiment. No concept discussed is specific to one source; the military analogies are general concepts which appear in many writings, including works by such authors as Sun Tzu, John Keegan, Tom Clancy and David Drake. It is our own work: we do not take allegations of plagiarism lightly, and we are certain that they should not be lightly made. If we have committed any errors in these exercises, it is in being too willing to present our own ideas without consulting pre-existing research in the area under question.

    @ tnovosel: Apologies if the statement on the ‘opponent’ was not clear. This simply attempted to describe the phenomenon of attacking many defended positions, all of similar configuration, with the defender’s own standardized attack countermeasures in hand. As these countermeasures address areas of weakness known to the defender; these same weaknesses are easily inferred by the attacker via examination of the ‘critical’ procedures to strengthen the positions. If it can be determined that some defensive position has not followed these instructions, then the smart aggressor will first probe for the flaws which the defensive countermeasures are designed to correct. I think this also explains what we meant by “areas of weakness implied” by the security document: corrective measures imply that flaws must exist; these flaws are what we attempted to ascertain with our research. This is the same goal as all other groups, just presented in a different way.

    @ shumpfer, prennick, nbakker with regard to OSI layer two and power down: I am pleased to see questions raised about this issue. Foremost, with regard to power off being a vulnerable area: ‘anything’ can be used as a weapon, and therefore a means of attack. If an action is intended to cause damage, and it indeed does; then a wise system administrator would, with the benefit of hindsight, classify the area affected by this action as vulnerable. There are certain situations which exist where a machine can be made to reboot in an endless cycle, which usually ends with the physical failure of components: the ability to initiate this cycle is part of power state function, and so is a very real attack based on ‘power down’ functionality. Although this sounds like a physical, or layer one attack, the OSI model applies only to networking implements proper: as nothing has been physically changed with regard to physical network topology, I would still consider this a layer two issue, or a disabling of NIC functionality.

    With respect to OSI classification, it is at first unclear which layer is correct, as it can vary with configuration. I agree with the assertions that in some cases, the NIC is not really ‘dead’ and is still responsive to MAC based communication. Certainly, it is incapable of negotiating IP traffic, so layer three seems like the safe choice. However, such things as Wake on Lan (WOL) and the Intelligent Platform Management Interface (IPMI) are not ubiquitous. Both WOL and IPMI must be specifically enabled in the BIOS, and though I have no statistical evidence to back my position up, I suspect a large number of machines worldwide are not configured to have the NIC ‘alive’ in power state S5. In view of the power cycle attack described, coupled with theoretical common configuration issues, I must still advocate layer two for this vulnerability. I noticed my partner feels it to be layer one: as no ‘physical’ reconfiguration of the network actually occurs in a shutdown attack, I am not comfortable in including it here. A really excellent discussion by all; I would be interested to see more comments on this.

12. It is interesting Mr. Decker that only you have said anything to the effect “I ask: do you follow the syllabus exactly as described? Does the layout even make sense with redundant sections? It appears that every group has been making some assumptions with regard to this ‘official’ layout: so why specifically attack our group for making these choices? ” It is interesting because you are exactly right. The syllabus was changed but in the cut paste changes the information after reasons for deduction were never removed. Only you brought up the error. It was a mistake on my part that nobody mentioned. I thought it was interesting. The previous section descriptions are from the APA5 manual as modified for the lab exercises. The second “should have been deleted” section are what most under graduates see.

Comments are closed.