April 22, 2025

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

  1. The abstract for this group covers about everything that this lab accomplishes. One thing I did not see was the examination of patches and the types of tools that could be used in the exploit of that vulnerability. The abstract also could have done a little bit more explaining of what the purpose of this lab was and what it was trying to accomplish. In the literature review the group gives a nice overview of the articles explaining that the articles given in the lab all relate to vulnerability assessments and how important they are and how they make protecting a network more efficient. I would not say that all the articles relate to this thought. Take Viruses 101 (Aycock, Barker, 2005), this article was more about how to create a course on a subject that is looked at as being taboo. The article relates to the course in that this course is a very controversial course like the virus creating course in the paper. The group goes on giving a review of each paper in a list fashion. The group looks at each article separately, does not relate the article adequately to the other articles, and relate each article to the current lab. Each explanation of the article summarizes the paper, but gives no, or very little, information on the paper like the research question, research data, errors or omissions, or how they relate to the current lab. The method section of this group’s lab covered all the main steps involved in this lab. I did not see anything missing from the explanations of how they were going to accomplish this lab. In the findings when they created the table, the change was listed, but the vulnerability that the change was supposed to fix was not mentioned until after the table. At the beginning of the results the group states that all of the changes are related to the technology aspect of McCumber’s cube. I disagree, in that any changes made in the policies should still remain in the policies aspect of McCumber’s cube. The next section of the results gives a description of the changes in the document that the group selected. Each change is placed into a category of ether: Domain Level Policies, Audit Policies, User Rights, Security Options, Event Log, or Computer Configuration Settings. It seemed redundant to list explanations of each change and then give them in the table also. As mentioned earlier the group then gives a description of the vulnerability that the change is supposed to fix after the table. It was hard to relate some of these vulnerabilities to what changes were done. In the next section of the results the group talked about how a system is still vulnerable, even when the updates are loaded, until a restart of the system is done. Also the group mentions problems with patches causing secure systems to become unsecure. They also mention that the patching server needs to be very secure, because an attacker that compromises that server could distribute a malicious patch to all the computers on that network. The table the group put together did not make a lot of sense. The table gives some tools for attacking vulnerability update methods and processes. The lab asked for the actual issues that were patched by the updates. The way the group did this section is a subject that does need to be examined and addressed, but I do not think this is what the lab was asking. The group could have given more details on what was discovered when testing the vulnerabilities in this section. The group had some issues with testing the patch vulnerabilities that they mention in the issues section. The group’s conclusion mentions that the group learned some ideas of how to use a security document to reveal vulnerabilities in a system. The group also mentions that all the vulnerabilities attack the technology aspect of McCumber’s cube, because it is directed at securing an operating system. I have to disagree with this because even though it is changing settings on an operating system, the changes in the policies are also changing how an organization handles a way of doing a specific task.

  2. The abstract is merely a restatement of the lab objectives from the lab assignment. A little more detail would be useful. The literature review started out well with identification of a common idea running through all of the articles but ended up being another list of assigned articles with summaries of each. Each article is handled only by itself and is not tied to the lab exercises in any way nor are they compared or contrasted with each other. The citations are confusing for each of the summaries. Instead of providing page numbers for the section being discussed, it’s just the same in-text citation over and over. The first one can be done with author, year, and page number, subsequent ones until you cite another reference can be done with just page numbers. This makes it much easier to read and cross check what is being referenced with the source material.

    For the methodologies, I’m interested to know a little more on why automatic updates were addressed. The way it’s mentioned in the write up, it seems that this is separate from the handling of the security guide. Why was this done? The mention of the final part of the lab, testing the various tools against the virtual environment was far too brief. There was a process for identifying tools that should work vs. tools that did work. Was this done at all? Where were the tools from?

    The first sentence of the findings section is confusing. Did you actually make the suggested changes from the guide on your virtual machine? I didn’t see anything referencing that activity in the methodologies. The layout of the findings from the document clearly follows the order found in the guide, while this makes it easier for the write up, some of the items from the guide that didn’t necessarily expose vulnerabilities were mentioned as well, the Kerberos policy settings for example. This reads more like a list of the settings and mentions of vulnerabilities if there were any instead of a carefully selected list with context. The audit policy section mentions a DoS based on filling up the log files, is this the only vulnerability that could result from turning on too much auditing? What about obfuscation of the actual activities? In the mention of changing the system time, is “mess up” the best way to state what an attacker might be doing by changing the system time? The vulnerability from loading and unloading device drivers was missed I believe, while “dangerous changes” could be made, the fact that driver installs are done with SYSTEM level privileges was not mentioned.

    The list of 99 vulnerabilities after the table seems out of place and redundant. Weren’t these discussed before? Some of the vulnerabilities in the list are new, why weren’t they mentioned previously? The mention of automatic updates as a vulnerability seemed as out of place as it did in the methodologies. Why isn’t this mentioned above with the other vulnerabilities? Why were the tools meant to test the vulnerabilities discovered in the lab exercises only targeted at the automatic update process?

  3. Team one provides an uneven effort with a wealth of information on portions of the lab, and almost nothing in others. They gloss over sections of the write up, giving minimal effort in some places and even less in others.

    The abstract is well written and summarizes the document appropriately. The literature review should be more than just a list of articles. It should be one cohesive section. Your group’s introduction paragraph states that the common elements shared by all articles are the necessity of vulnerability testing, the efficiency of automated tools, and the need for IT professionals to perform the tests, but this is not the case. This leads me to suspect that proper attention was not given to the literature. Your review summarizes each of the articles briefly but lacks any analysis whatsoever; giving more proof that there was either a lack of attention or a lack of comprehension.

    The group’s methods section is vague. I understand that it’s difficult to explain research methodology. Where did you look for your document? How did you decide on it? Where did you research automatic updates? How? How did you test the tools? How did you select which tools will be tested? Details like these will help flesh out the section, and provide a more rigorous report.

    The Findings section is weighty, with a large amount of information considering the sparse literature review and methods sections. The team’s take on automatic updates is very insightful, especially the methods for exploitation. A minor criticism here is the steps for testing the concept are not located in the methods section. It may feel awkward to place them elsewhere, but they are not findings. This is the only test you run. Why? There are other tools that were listed in your document in order to take advantage of other vulnerabilities. Why not test those? Your issues section states that there was some difficulty with testing the other variations on automatic update vulnerabilities, but doesn’t mention anything else.

    The team’s conclusion wraps up the lab well. It explains what the group learned. I disagree with the assertion that the attacks cannot be directed against humans or policy and procedures just because the guide is designed to secure a single technology (in this case an operating system). While there may be no direct links, is it possible there may be an indirect method? For example, if strong passwords are required, and a corporation indeed does use them, doesn’t that strengthen the argument for a social engineering attack?

  4. In examining team one’s work, I found the literature review to be well crafted with respect to writing style. I also found interesting the way this team grouped the discussion of their findings, with general headings and a running prose summarizing areas of vulnerability. Also, the tables presented were neatly laid out and fairly easy to read. Finally, the vulnerability listing appeared to have a reasonable degree of detail, similar in depth to other teams’ listings which examined Windows 2003 Server.

    Unfortunately, these positive qualities are muted by a fair number of serious flaws in this lab write-up. While the literature review was well written, it did not do much more than briefly summarize each article. Absent was any real critique of concepts, and no application to the current exercise was really entertained at any point. Certainly, this is a well discussed error at this point of the semester; so nothing more need be said except: “You should know better by now.”

    Another point of criticism: the report was relatively disorganized, specifically in the ‘Methods’ and ‘Findings’ sections. The ‘Methods’ section was rather short, and some of the material which should have been in this section was located in the ‘Findings’ section. For instance, the description of how update vulnerability was tested should have been relocated. Additionally, the table heading ‘Tool Name’ seemed ill-chosen in the first table; something like ‘Vulnerability’ would have made far more sense: this was somewhat confusing. Also, the hundred or so item list in the ‘Findings’ section was presented without explanation or title. These appeared to be areas of vulnerability, but they were introduced abruptly to the reader with no lead in: rather confusing. The aforementioned list items were not associated with any OSI layer classifications, nor were McCumber cube coordinates determined: this was an omission according to the requirements of the laboratory.

    This team at times seemed to discuss settings with more of an emphasis on ‘how to prevent attack and why’ rather than ‘how to use this for attack.’ There can be no doubt that these were the recommendations in the security document examined; however, it appears that relating how this team would attack the area in question would be more appropriate to the exercise at hand. For instance: “Guest account can allow an unauthorized user to gain access and should be disabled or renamed.” Helpful information in securing a system; but wouldn’t something like “Use of default guest account to gain access” be a more meaningful description?

    Finally, the listing and discussion of the ‘update vulnerability’ testing seemed an afterthought and poorly conceived. Throwing a table together which was entirely redundant in the ‘Tool’ category, with little more than generic attack tools listed seemed spurious. Additionally, the question must be asked: why would a test against a Windows XP Service Pack 0 host be run when it was asserted that “this group will be focusing only on Server 2003” with regard to the security document? Without any rationalization for why this exercise was done, it just seems that this team was grasping at straws, as in reality ‘nothing’ concerning Windows Server 2003 vulnerability was tested within the scope of the exercise. Was it found that no vulnerabilities could be exploited with regard to Server 2003? It appears an explanation would have been in order.

  5. In the abstract, when team one stated “In this lab our team will examine leakage through the process of engineering”, did the team mean reverse engineering? The remainder of the abstract gave a brief overview of what will occur in the laboratory assignment.

    In the literature review section, team 1 gave brief summaries of each of the articles, but did not relate them to each other, describe the methodology used, point out any errors or omissions, or relate them to the laboratory assignment.

    In the methodology section, group one informed the reader that they chose the document, Solutions for Security and Compliance: Threats and Countermeasures Security Settings in Windows Server 2003 and XP.

    In the findings section, I could not figure out why group 1 placed changes under the heading that was labeled tools. Most of the changes were changes in policy or in configurations. I was not sure how the list of 99 exploits fit directly with the table. Other groups had created a column in the first table for exploits and described what could happen if the recommended change was not acted upon. In the second table, what specific areas of the vulnerable update did the tools affect?

    Team one stated “This exploit worked because the update had not yet been applied. For the Software Update Services attack, the group was unable to perform the attack because the group would have to actually write a virus (which is beyond the scope of this lab) as opposed to using provided exploit code, such as the code used in Metasploit in the previous test.” However, these statements seemed contradictory. Did the group mean that theoretically the exploit would work or did the group find from elsewhere that id did indeed work? If you did not try it, how did the team come to this conclusion?

    In the issues section, team one stated “The only issues experienced with this portion of the lab were the tests. The first test could not be tested because it requires specific environmental circumstances, such as Microsoft releasing a vulnerable update. The last test could not be performed either, due to the complexity of the attack. A new exploit or tool must be created for that attack to work properly.” I noticed that my group and other groups as well also ran into the same problems. Script kiddie’s tools are not sufficient enough for exploiting the vulnerabilities in specific services or programs.

    In the conclusion section, I had to disagree with the statements “All of the vulnerabilities found in the documentation, lie within the technology dimension of the McCumber cube. This is because the security guide is for operating systems, and therefore can’t attack humans or policy/procedures.” Changing the requirements for a password would be a policy that must be agreed upon before it could be implemented via a technology.

    In the references section, look into APA 5 procedures for citing an on-line reference. This may help the team in the future.

  6. Team 1 begins with an abstract stating that “this lab will allow us to gain an understanding of the reverse engineering process”. This statement is a bit broad since reverse engineering may apply to a mechanical device, electronic component or software. Perhaps a better way to state it may have been “this lab will allow us to gain an understanding of the reverse engineering process with respect to determining system vulnerabilities by analyzing vendor security configuration documentation”. This statement would have been more specific and more descriptive of the purpose of the lab.

    Team 1 proceeds with a review of the literature that was assigned for this week’s reading. They state that the common threads throughout our assigned readings is “vulnerability assessments are a necessary process” and “that using automated tools to do so was a much more efficient way”. Ironically, this week’s laboratory assignment was “Exploits Without Tools”. I found that the common thread between the laboratory assignment and the readings was using analysis to determine vulnerabilities outside of the penetration testing environment, rather than relying exclusively on the use of tools. Team 1 proceeded to list each document in the assigned reading list and give a short synopsis of each one. None of them included an explanation concerning how they fit the “common threads” that Team 1 stated in the first paragraph of the literature review. They also did not find any application of the readings to our current laboratory assignment.

    In the next section Team 1 describes the methods used in this assignment. They discuss using Solutions for Security and Compliance: Threats and Countermeasures Security Settings in Windows Server 2003 and XP as their document that they plan to analyze, and state that they decided to focus their analysis on the Windows Server 2003 issues. They discuss analyzing the changes identified in the document and placing the changes on the OSI 7-layer model according to the layer that would be affected by the change. They stated that the changes would also be placed according to its McCumber Cube classification. They decided that all of the changes should be placed in the technology section of the McCumber Cube. I believe it could be debatable whether enforcing password history, age, and minimum length would be classified as technology or human factors in the McCumber Cube model.

    In the findings section, Team 1 begins by stating “each change/ configuration was made for a reason”. This assessment is a bit obvious. Why else would they include it in the document if there were no reason to do so? Team 1 listed each configuration change that had been recommended. They included a brief description along with an explanation concerning what the change is supposed to accomplish. They also classified the changes according to change type. This section was very easy to read and informative. They used bold fonts for the title of each change. That made locating a particular change extremely easy.

    Team 1 included an interesting discussion concerning problems with automatic updates. One problem is that it often takes a system restart for the change to take effect. If the update is designed to correct vulnerability, then the system remains vulnerable until the user reboots the system. They demonstrated this using the Win32 Bind Shell exploit by obtaining a remote shell in the time between the download of the update and the reboot of the system. They also discussed what could occur is the update itself caused vulnerability. Since the updates are automatic, several systems could be made vulnerable within a short period of time, and remain vulnerable until the next update.

  7. The team starts with their abstract and states that they are going to be working on an approved topic but they never say the topic just what they are going to identify. Then they go onto the literature for this week’s lab and start with an overall summary and what the articles are going to be about. For some reason the team decided to split the articles again instead of keeping a cohesive literature review. The previous week they had a good cohesive literature review that talked about the subject, how the content relates to the course, and even had some arguments. This week it was lacking most of what they got right the previous week. Yes they did explain what happened within the articles but it did even have the reviews thoughts on the literature and opinions of their own. Next was the methodology section. In this section they described what they where actually going to be doing for the lab in more detail. Here they provided the information that they where going to be looking at Solutions for Security and Compliance: Threats and Countermeasures Security Settings in Windows Server 2003 and Windows XP. They then stat after examining the document they will determine where each “change” falls into the OSI model. At first glance the wording for this was confusing and may have thrown off some people reading the lab. They then state they are going to have a list for the exploits that where found in the document and to test potential vulnerabilities. The next section they described their findings after looking over what they had before the table and looking at the document that they where using for the lab, there were some items missing. They explains some of the vulnerabilities and the changes needed, but not all of the vulnerabilities where explained in this fashion. Next they had their tables list the tools and where they fall on the OSI 7 layer model and the McCumber coordinates but the tools are not tools they look like resolutions to the issues. These might have been better classified as resolutions instead. After this they then list exploits of the systems, which had no explanation before the list which throws the reader off. It was not a bad list it just came out of nowhere. They then list vulnerabilities and tools but they left out the OSI seven layer model part of the second table. Then the team went on to explain issues that they had and then went onto their conclusion. They stat that no one in their group had thought about using a hardening document as a way to attack an un-patched system. So my question is are the member of this group starting to think more about how an attack might think when look at the past labs and what has been done so far. Does this make the team more paranoid now and will make them think twice about everything now?

  8. The team starts out with a strong abstract and talks about how they did in the lab.
    In the findings section the team has a sub-section labeled Domain Level Policies. In this section the team talks about changes to password history, password age, password length, storing password, and Kerberos policy. The team says to change the password history to 24 to ensure the password reuse problem is solved. Also the maximum password age should be changed to 90 days. With this combination users would be able to reuse a password 2,160 days or almost six years later, after the first use. If this is such a problem why not increase the number of password history from 24 to 34? This would increase to over eight years, by this time most users would have forgotten there original password.

    The Audit Policy paragraph seems to be written in a way to scare administrators to keep audit policies off. Is audit policy unimportant and easily exploited to DoS attacks? What is the purpose for audit policies and would there be an environment that audit policies would not be exploitable to a DoS attack?

    User rights, how much rights should non-administrative users be given? This topic can be highly debated over the amount to access to give users. If privileges to users are not enough, it can become difficult for users to complete tasks such as adding a printer or update a plug-in to properly view a website containing important information. A user may need to add a network share because of a promotion or added to an existing project, what is the turn over time for an administrator to add that users to the share, what is the cost of this turnover because security was stepped up so high? A feature this team has enabled is Force logoff when logon hours expire. Is this saying that employees do not work overtime? What about employees need to come in later for what ever personal reasons but is staying later for make-up the hours? What about users that are doing work at home and VPN into the company to retrieve information off the employee’s computer? Deciding when a user is going to able to access there computer can be tricky to decide exactly.

  9. In lab five, team one begins by explaining their lab report through their abstract. That abstract does not fit the requirements of the syllabus, as it is not two paragraphs. The abstract also seems to read like the objectives of the lab as defined in the lab design guide. Team one’s literature review starts with an introduction as a method to tie together the assigned readings for the week. However beyond that there is no cohesion between the reviewed articles, rather a heading and then a synopsis of each article. This forms really just a list of articles with APA style citations. This literature does not improve the lab report, but rather detracts from it, and is a move in the wrong direction for team one. As there are only two labs left team one needs to improve in this aspect. It seems that team one didn’t even bother to answer the literature review questions that were outlined in the syllabus for the course. Team one’s methods section is also lacking. There is no clear definition of the strategy or technique used in the completion of the lab. This does not an academic or scholarly methods section make. While the methods section does explain the general process that team one followed in the completion of the lab, there is not enough information in those methods for an independent group to recreate the lab experiment and draw the same conclusions as team one did. In their findings section they do not cover what the findings are in answer to in the beginning and that leaves one wondering as they go directly into explaining what the changes in their source document represent. They depend on the information covered in the lab design document to give the reader that information which seems to be lacking. I seem to be confused as to their layout of information provided in the finding section. Team one explains what table 1.1 is used to represent, but that is really about it. Team one then goes right away into a list of polices hat contain bolded words that I can only assume represent changes that their source documents recommends. Team one then presents table 1.1 which explains where each tool lines up to the OSI model and McCumber Cube. Since this lab was titled exploits without tools I find it suspect to have a table with the word tool as a heading. While I agree with most of the entries that team one makes for their application layer information, I disagree with their lower layer information. Disabling remote desktop is not a layer three setting, nor are SMB shares. After table 1.1 they list 99 different settings that seem to be derived from the list presented before table 1.1. And then another table that has little information provided as to its use. Both tables also do not belong in the findings section, but rather a tables and figures section which would referenced in the findings section. Finally, the conclusions drawn by team one are high level, but based on their methods section, accurate.

  10. @jeikenbe I can see your side of the comment about policies attacking the policy dimension of the McCumber cube. I have always taken policy to mean something else, such as computer use policy, or HR policies, not specifically policies on computers. I can’t attack policies on a computer if there is no computer. If a company does not use computers, I can still attack the policy dimension through HR.
    @jverburg Automatic updates were addressed because they can be used as an attack vector. If we weren’t so worried about the consequences of automatic updates, then some companies wouldn’t test them first before deploying to client computers.
    @mborton The document was found using Google, since our group was the last one to post the document, we chose this document since no other group used it, and it was actually a companion to 2 documents that other groups used. I see your point about the social engineering, and after thinking about it I would agree with you.
    @gdekkerj Tool name was a poor choice of words. The table had the OSI layer and the McCumber cube coordinate.
    @nbakker “This does not an academic or scholarly methods section make” This does not make a good sentence. I think the table has findings does in fact belong in the findings section. I find it difficult and annoying to have to read, then scroll down and back up, again and again, when a team mentions something in a section and points to another piece of the report. I think having the tables where the discussion is makes for better reading.

  11. @mvanbode – I think you’re confusing Automatic Updates as a potential source of service interruption due to consequences of the patches and using the updates as an attack vector. There are a multitude of things an attacker would need to do that should be mentioned in order to use automatic updates to distribute malicious code. Compromising the server and forging the signature on the update packages to name a few.

  12. @mvanbode

    Hmm…fair enough; I’ll modify my criticism appropriately: many of the items of the list are not associated with OSI layers or McCumber cube coordinates. A quick count of the table shows 33 items; where are the rest of the 99?

Comments are closed.

Related Stories

blog_EDU23

A story about public education and outcomes

Sam September 13, 2024
CMPNG197

High-tech lay offs as an indicator of future tech companies demise or failure

Sam May 25, 2023
GNEWS095

Reading and irony

Sam February 16, 2023

You may have missed

blog_SBUS015

How High Tariffs Could Drown the Mid-Tier Yachting World and Leave American Cruisers Stranded

Sam April 5, 2025
SBUS001

The Hidden Storm: How Trump’s Latest Round of Tariffs and Economic Shifts Are Sinking the Mid-Sized Yacht Market

Sam March 29, 2025
IMG_5437

Sailing Through the Ages: How Cruising Has Changed Over the Last 20 Years

Sam March 27, 2025
IMG_8204

Plot twist: Same song second verse – chemo cycle 3

Sydney Liles March 26, 2025