<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
	<id>https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Miranmirza</id>
	<title>Soma-notes - User contributions [en]</title>
	<link rel="self" type="application/atom+xml" href="https://homeostasis.scs.carleton.ca/wiki/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=Miranmirza"/>
	<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php/Special:Contributions/Miranmirza"/>
	<updated>2026-05-14T01:21:59Z</updated>
	<subtitle>User contributions</subtitle>
	<generator>MediaWiki 1.42.1</generator>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20663</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20663"/>
		<updated>2016-02-04T13:42:06Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Topics &amp;amp; Readings&#039;&#039;&#039;&lt;br /&gt;
*Ethical Hacking&lt;br /&gt;
*Security mechanisms in operating systems&lt;br /&gt;
*Danger of root&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Ethical Hacking&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Red team&#039;&#039;: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.&lt;br /&gt;
&#039;&#039;Blue team&#039;&#039;: defence team.&lt;br /&gt;
&lt;br /&gt;
The naming convention comes from US politics where the red team gets it&#039;s name from the &#039;evil&#039; communists and blue represents the &#039;good&#039; Americans.&lt;br /&gt;
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.&lt;br /&gt;
&lt;br /&gt;
A separate question: &lt;br /&gt;
How much does this actually improve security? &lt;br /&gt;
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. &lt;br /&gt;
But do actual people doing ethical hacking on software actually improve software then?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Security mechanisms in operating systems&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.&lt;br /&gt;
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)&lt;br /&gt;
Diagram detailing the separation of root into three roots.&lt;br /&gt;
&lt;br /&gt;
[[File:DiagramOS.png]]&amp;lt;br&amp;gt;&lt;br /&gt;
&#039;&#039;Diagram detailing the separation of root into three roots&#039;&#039;&lt;br /&gt;
  &lt;br /&gt;
&#039;&#039;&#039;The Danger of Root&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.&lt;br /&gt;
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.&lt;br /&gt;
&lt;br /&gt;
We need even finer grain control though, however most software developers don&#039;t want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.&lt;br /&gt;
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Conclusions&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don&#039;t know how to do it, but it&#039;s because we don&#039;t want to commit to the correct way of doing things which is why it&#039;s all ugly, it&#039;s like Xwindow which draws windows and elements but delegates the elements to the operating system.&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=File:DiagramOS.png&amp;diff=20662</id>
		<title>File:DiagramOS.png</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=File:DiagramOS.png&amp;diff=20662"/>
		<updated>2016-02-04T13:41:05Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20661</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20661"/>
		<updated>2016-02-04T13:40:50Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Topics &amp;amp; Readings&#039;&#039;&#039;&lt;br /&gt;
*Ethical Hacking&lt;br /&gt;
*Security mechanisms in operating systems&lt;br /&gt;
*Danger of root&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Ethical Hacking&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Red team&#039;&#039;: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.&lt;br /&gt;
&#039;&#039;Blue team&#039;&#039;: defence team.&lt;br /&gt;
&lt;br /&gt;
The naming convention comes from US politics where the red team gets it&#039;s name from the &#039;evil&#039; communists and blue represents the &#039;good&#039; Americans.&lt;br /&gt;
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.&lt;br /&gt;
&lt;br /&gt;
A separate question: &lt;br /&gt;
How much does this actually improve security? &lt;br /&gt;
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. &lt;br /&gt;
But do actual people doing ethical hacking on software actually improve software then?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Security mechanisms in operating systems&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.&lt;br /&gt;
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)&lt;br /&gt;
Diagram detailing the separation of root into three roots.&lt;br /&gt;
&lt;br /&gt;
[[File:DiagramOS.png]]&lt;br /&gt;
  &lt;br /&gt;
&#039;&#039;&#039;The Danger of Root&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.&lt;br /&gt;
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.&lt;br /&gt;
&lt;br /&gt;
We need even finer grain control though, however most software developers don&#039;t want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.&lt;br /&gt;
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Conclusions&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don&#039;t know how to do it, but it&#039;s because we don&#039;t want to commit to the correct way of doing things which is why it&#039;s all ugly, it&#039;s like Xwindow which draws windows and elements but delegates the elements to the operating system.&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20660</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20660"/>
		<updated>2016-02-04T13:40:19Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Topics &amp;amp; Readings&#039;&#039;&#039;&lt;br /&gt;
*Ethical Hacking&lt;br /&gt;
*Security mechanisms in operating systems&lt;br /&gt;
*Danger of root&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Ethical Hacking&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Red team&#039;&#039;: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.&lt;br /&gt;
&#039;&#039;Blue team&#039;&#039;: defence team.&lt;br /&gt;
&lt;br /&gt;
The naming convention comes from US politics where the red team gets it&#039;s name from the &#039;evil&#039; communists and blue represents the &#039;good&#039; Americans.&lt;br /&gt;
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.&lt;br /&gt;
&lt;br /&gt;
A separate question: &lt;br /&gt;
How much does this actually improve security? &lt;br /&gt;
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. &lt;br /&gt;
But do actual people doing ethical hacking on software actually improve software then?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Security mechanisms in operating systems&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.&lt;br /&gt;
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)&lt;br /&gt;
Diagram detailing the separation of root into three roots.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  &lt;br /&gt;
&#039;&#039;&#039;The Danger of Root&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.&lt;br /&gt;
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.&lt;br /&gt;
&lt;br /&gt;
We need even finer grain control though, however most software developers don&#039;t want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.&lt;br /&gt;
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Conclusions&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don&#039;t know how to do it, but it&#039;s because we don&#039;t want to commit to the correct way of doing things which is why it&#039;s all ugly, it&#039;s like Xwindow which draws windows and elements but delegates the elements to the operating system.&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20659</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20659"/>
		<updated>2016-02-04T04:23:48Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: &lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Topics&#039;&#039;&#039;&lt;br /&gt;
*Ethical Hacking&lt;br /&gt;
*Security mechanisms in operating systems&lt;br /&gt;
*Danger of root&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Ethical Hacking&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Red team&#039;&#039;: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.&lt;br /&gt;
&#039;&#039;Blue team&#039;&#039;: defence team.&lt;br /&gt;
&lt;br /&gt;
The naming convention comes from US politics where the red team gets it&#039;s name from the &#039;evil&#039; communists and blue represents the &#039;good&#039; Americans.&lt;br /&gt;
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.&lt;br /&gt;
&lt;br /&gt;
A separate question: &lt;br /&gt;
How much does this actually improve security? &lt;br /&gt;
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. &lt;br /&gt;
But do actual people doing ethical hacking on software actually improve software then?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Security mechanisms in operating systems&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.&lt;br /&gt;
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)&lt;br /&gt;
Diagram detailing the separation of root into three roots.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  &lt;br /&gt;
&#039;&#039;&#039;The Danger of Root&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.&lt;br /&gt;
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.&lt;br /&gt;
&lt;br /&gt;
We need even finer grain control though, however most software developers don&#039;t want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.&lt;br /&gt;
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?&lt;br /&gt;
&lt;br /&gt;
Conclusions: almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don&#039;t know how to do it, but it&#039;s because we don&#039;t want to commit to the correct way of doing things which is why it&#039;s all ugly, it&#039;s like Xwindow which draws windows and elements but delegates the elements to the operating system.&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20658</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20658"/>
		<updated>2016-02-04T04:05:23Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: Blanked the page&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20657</id>
		<title>SystemsSec 2016W Lecture 6</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_6&amp;diff=20657"/>
		<updated>2016-02-04T04:05:04Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: Created page with &amp;quot;&amp;#039;&amp;#039;&amp;#039;Topics &amp;amp; Readings&amp;#039;&amp;#039;&amp;#039; *Ethical Hacking *Security mechanisms in operating systems *Danger of root   &amp;#039;&amp;#039;&amp;#039;Ethical Hacking&amp;#039;&amp;#039;&amp;#039;  &amp;#039;&amp;#039;Red team&amp;#039;&amp;#039;: when you hire a team to formally eval...&amp;quot;&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;&#039;&#039;&#039;Topics &amp;amp; Readings&#039;&#039;&#039;&lt;br /&gt;
*Ethical Hacking&lt;br /&gt;
*Security mechanisms in operating systems&lt;br /&gt;
*Danger of root&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Ethical Hacking&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;Red team&#039;&#039;: when you hire a team to formally evaluate the security of a system (or company). For example, penetration testers.&lt;br /&gt;
&#039;&#039;Blue team&#039;&#039;: defence team.&lt;br /&gt;
&lt;br /&gt;
The naming convention comes from US politics where the red team gets it&#039;s name from the &#039;evil&#039; communists and blue represents the &#039;good&#039; Americans.&lt;br /&gt;
Another form of ethical hacking is a person who finds code bounties (a person who actively goes off and finds exploits to make money for companies). They report on bounties to corporations so that they can close off the exploits and improve their systems.&lt;br /&gt;
&lt;br /&gt;
A separate question: &lt;br /&gt;
How much does this actually improve security? &lt;br /&gt;
The three letter security people try to do attacks to figure out when physical attacks (such as terrorism) occur. &lt;br /&gt;
But do actual people doing ethical hacking on software actually improve software then?&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Security mechanisms in operating systems&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
MULTICS has elaborate security mechanisms but they are largely unused. UNIX on the other hand has much simpler security measures but they end up being used. UNIX however has some downfalls against certain threat models including the rogue root threat models. Another attack model UNIX is vulnerable to is physical attacks.&lt;br /&gt;
The idea of a root account is too powerful, what we need in a secure operating systems is using separation of powers (where root is subdivided into various users that have different permissions)&lt;br /&gt;
Diagram detailing the separation of root into three roots.&lt;br /&gt;
&lt;br /&gt;
&lt;br /&gt;
  &lt;br /&gt;
&#039;&#039;&#039;The Danger of Root&#039;&#039;&#039;&lt;br /&gt;
&lt;br /&gt;
Why is root so powerful then? On a UNIX system, the root has the ability to modify files (permissions, metadata and contents, read/write/etc.), the root user can also perform user management, process management , file system management, network management, kernel module injection, boot manager, software management, hardware configuration.&lt;br /&gt;
We can subdivide root in terms of capabilities, which is the classic way we deal with the problem of a rogue root. From a practical point of view, this is important to prevent privilege escalation attacks. Modern Linux operating systems will not check for root privilege, rather they would check for specific privileges.&lt;br /&gt;
&lt;br /&gt;
We need even finer grain control though, however most software developers don&#039;t want to deal with this which is why Linux has the LSM system (it has a mechanism for doing secure models to extend the operating system). There are hooks added throughout the Linux kernel that will override the default behaviour of the Linux kernel. However, we need to be mindful that any code injected into the kernel can be dangerous. The NSA developed a system called SELInux (Security Enhanced Linux). SELinux had finer grain security measures and they wanted mandatory access control (MAC for Linux). The reason why SELinux is so nasty to deal with is because it bypasses the Linux model of having files and replaces them with entities which allows for much finger grain control but no one seems to understand it.&lt;br /&gt;
To what extent do we need customisable security policies? Phones for example have very locked down security policies like iOS is mostly closed off. Android has more flexibility by installing programs. So do we need more customisable security policies?&lt;br /&gt;
&lt;br /&gt;
Conclusions: almost everyone gets security policies wrong, most people mess up the permissions, but really if you need that level of fine granularity then just mess with the code. We have security policy languages not because we don&#039;t know how to do it, but it&#039;s because we don&#039;t want to commit to the correct way of doing things which is why it&#039;s all ugly, it&#039;s like Xwindow which draws windows and elements but delegates the elements to the operating system.&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20578</id>
		<title>SystemsSec 2016W Lecture 5</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20578"/>
		<updated>2016-01-22T03:32:32Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: /* Physical attacker, unauthenticated */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Class discussion: threat models and attacker goals&lt;br /&gt;
&lt;br /&gt;
==Local attacker==&lt;br /&gt;
&lt;br /&gt;
==Administrative attacker==&lt;br /&gt;
&lt;br /&gt;
=== Group 2 ===&lt;br /&gt;
==== Members ====&lt;br /&gt;
* Kyle T.&lt;br /&gt;
* Tarek K.&lt;br /&gt;
* Jakub L.&lt;br /&gt;
* Stefan C.&lt;br /&gt;
* Matt G.&lt;br /&gt;
* Remi G.&lt;br /&gt;
* Ibrahim M.&lt;br /&gt;
&lt;br /&gt;
==== Scenarios ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #1: Disgruntled Ex-Employee(s?) - Sony Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Disgruntled ex-employees with active administrative access and knowledge of internal system architecture.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Full client information specifically financial billing information. &lt;br /&gt;
*** Showcase that Sony does not take security seriously.&lt;br /&gt;
*** Denial of service for PSN users.&lt;br /&gt;
** Means: It is rumored that ex-employees with active logins managed to access the data.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #2: Current &amp;amp; Ex-Employee(s?) - Ashley Madison Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Employees with active administrative access.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Force Ashley Madison to shut down. &lt;br /&gt;
*** Expose the true ratios of male/female user base and fake accounts.&lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #3: Military and Government Secrets&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Whistleblowers (Chelsea Manning, Edward Snowden)&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Publicize and expose questionable practices and information to the general public.&lt;br /&gt;
*** Sway public opinion  &lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #4: This Wiki&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: MediaWiki CMS&lt;br /&gt;
** Attackers: Students with editor privilege on the wiki.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Modify or delete other groups&#039; entries.&lt;br /&gt;
** Means: Full access to edit the page using credentials given by the professor.&lt;br /&gt;
&lt;br /&gt;
==== Attack Strategies ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Weaknesses&#039;&#039;&#039;&lt;br /&gt;
** Employee turnover&lt;br /&gt;
** Disgruntled current and ex-employees&lt;br /&gt;
** Economically vulnerable administrators (easy to bribe)&lt;br /&gt;
** Blackmail&lt;br /&gt;
** System Administrator neglect and/or incompetence&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;How to Attack?&#039;&#039;&#039;&lt;br /&gt;
** Social Engineering&lt;br /&gt;
** If there are no safeguards in place, simply having admin access is enough to wreak havoc&lt;br /&gt;
** Installing backdoors to keep access to system&lt;br /&gt;
** Installing malicious updates and programs on users computers to siphon data and/or monitor.&lt;br /&gt;
** Remote monitoring of all users (including those with higher priviledge), using all available peripherals (webcams, microphones, keyboards, etc...)&lt;br /&gt;
** Denial of Access&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
=== Group 3 ===&lt;br /&gt;
====Members====&lt;br /&gt;
* Dania Ghazal&lt;br /&gt;
* Ankush Varshneya&lt;br /&gt;
* Olivier Hamel&lt;br /&gt;
* Michael Lutaaya&lt;br /&gt;
* Ryan Morfield&lt;br /&gt;
* Daniel Vanderveen&lt;br /&gt;
* Jess Johnson&lt;br /&gt;
&lt;br /&gt;
====Example Scenario====&lt;br /&gt;
&#039;&#039;&#039;Targeted System&#039;&#039;&#039;&lt;br /&gt;
* CIA database - find out who killed Kennedy?&lt;br /&gt;
&#039;&#039;&#039;Attackers&#039;&#039;&#039;&lt;br /&gt;
* remote authenticators&lt;br /&gt;
* contractors (non CIA)&lt;br /&gt;
&#039;&#039;&#039;Goals&#039;&#039;&#039;&lt;br /&gt;
* “exfiltrating data”&lt;br /&gt;
* exfiltrate the CIA database to find out who killed Kennedy&lt;br /&gt;
&#039;&#039;&#039;Means&#039;&#039;&#039;&lt;br /&gt;
* someone at the CIA left a node.js server running in the background :)&lt;br /&gt;
* ssh credentials&lt;br /&gt;
* use outdated emacs (implementing a root privileged mail daemon) to inject a password into etc/passwd to escalate attacker’s privileges&lt;br /&gt;
* look around the system for more vulnerable/outdated services to exploit&lt;br /&gt;
* generate a race condition to create a file that you know a root user would create, then let the root user put their “sensitive data” into attacker’s file (such as files in /temp)&lt;br /&gt;
* social engineering - submit a help ticket to someone within the CIA to gain higher privileges for a seemingly innocent reason&lt;br /&gt;
====Attack Strategies====&lt;br /&gt;
&#039;&#039;&#039;Where are the Accessible Weaknesses?&#039;&#039;&#039;&lt;br /&gt;
* outdated services&lt;br /&gt;
* any service that lets attacker execute a task as another user&lt;br /&gt;
&#039;&#039;&#039;How Do You Attack Them?&#039;&#039;&#039;&lt;br /&gt;
* user privilege escalation&lt;br /&gt;
* abusing service vulnerabilities&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, unauthenticated==&lt;br /&gt;
* Abdul Bin Asif Niazi&lt;br /&gt;
* Dusan Rozman&lt;br /&gt;
* Sam Whiteley&lt;br /&gt;
* Jake Brown&lt;br /&gt;
* Nicholas Laws&lt;br /&gt;
* Miran Mirza&lt;br /&gt;
&lt;br /&gt;
Typically targeted systems include: portable systems such as laptops, smartphones, tablets, USB keys, card systems, banking machines.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Attack strategies:&#039;&#039;&#039; &lt;br /&gt;
* Duplicated cards&lt;br /&gt;
* Card Readers&lt;br /&gt;
* RFID readers: can be used to duplicate RFID data and steal NFC enabled bank access systems&lt;br /&gt;
* Radio-Frequency generator used to unlock different cards&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sort of attacks that can happen:&#039;&#039;&#039;&lt;br /&gt;
* Man in the middle attack on physical phone lines, people can access phone conversations by inserting some sort of hardware in a SIM card or a landline.&lt;br /&gt;
* Using the USB auto install feature to spread attacks, exploit this vulnerability to install software. An attacker can plug a USB thumb drive into computer and install software in order to escalate privileges.&lt;br /&gt;
* Phishing attack, a user can install some sort of software to reroute traffic through their system in order to collect data. A user can physically rewrite the hosts file on  system to tamper with the DNS on the system and steal data.&lt;br /&gt;
* For secured areas such as labs a vulnerability would be the door which requires some sort of card based authentication, since this can be stolen it is vulnerable.&lt;br /&gt;
* Bank Machines: a lot of bank machines have a USB port in the bank and thus can get software installed on them. People can also install a card reader on top of the card slot to collect card numbers and other sensitive data.&lt;br /&gt;
	&lt;br /&gt;
&#039;&#039;&#039;Scenarios:&#039;&#039;&#039;&lt;br /&gt;
* A user gets physical access to a device using sort of card access and then physically destroys a computer (a literal denial of service attack).&lt;br /&gt;
* An attacker swaps a keyboard for a keylogging keyboard and uses it to steal sensitive data. They are exploiting the fact that users won&#039;t notice the change&lt;br /&gt;
* A user can exploit the reset feature on a router in order to gain access to it&#039;s settings, they can then go on to flash the firmware and infect all connected devices on the network.&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, unauthenticated==&lt;br /&gt;
* Samuel Prashker&lt;br /&gt;
* Daniel Lehman&lt;br /&gt;
* Roman Chametka&lt;br /&gt;
* Derek Aubin&lt;br /&gt;
* Gilbert Lavergne-Shank&lt;br /&gt;
* Xiusan Zhou&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Scenarios&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;#1 - DDOS&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Web servers, or any machine connected to a network&lt;br /&gt;
*** Attackers: Angry trolls, political warriors&lt;br /&gt;
*** Goals: Denials of service, anger your target, hurt their financials, prove a point&lt;br /&gt;
*** Means: LOIC, Chinese Botnet with Bitcoin&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Exploitable communication paths (example: ping, login spam)&lt;br /&gt;
**** In the case of a router, overpowering a signal by replacing it with your own higher powered signal&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Over the network&lt;br /&gt;
**** Over the air (wireless signals)&lt;br /&gt;
* &#039;&#039;&#039;#2 - Packet Sniffing&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Phones, servers, any networked device that can be sniffed&lt;br /&gt;
*** Attackers: Exfiltrators who want getting data, corrupting data &lt;br /&gt;
*** Goals: Exfiltration of data, snooping for data over the air&lt;br /&gt;
*** Means: Packet sniffing tools, Wireshark, &lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Wireless signals would be easy to monitor&lt;br /&gt;
**** Mission security (Msec)&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Wireless: Network cards, monitoring tools for over the air analysis&lt;br /&gt;
**** Wired: Anywhere along the line to be able to hook in a middleman&lt;br /&gt;
* &#039;&#039;&#039;#3 - Remote program already running on their service/server&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: People (social engineering), known exploits (0days)&lt;br /&gt;
*** Attackers: Blackhat hackers, whitehat hackers&lt;br /&gt;
*** Goals: Exfiltrate, corrupt, deny access, destroy, ransomware, (whitehat only: protect!)&lt;br /&gt;
*** Means: Exploitable software, social engineering&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses?&lt;br /&gt;
**** Stupid people, exploitable equipment known to be accessible to 0days, leveraging bugs&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Social networks, email, phone calls, deployed payload&lt;br /&gt;
** &#039;&#039;&#039;Point is you&#039;re trying to get someone to install software for you, or exploit software to inject the payload on the targeted system&#039;&#039;&#039;&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20577</id>
		<title>SystemsSec 2016W Lecture 5</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20577"/>
		<updated>2016-01-22T03:30:42Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: /* Physical attacker, unauthenticated */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Class discussion: threat models and attacker goals&lt;br /&gt;
&lt;br /&gt;
==Local attacker==&lt;br /&gt;
&lt;br /&gt;
==Administrative attacker==&lt;br /&gt;
&lt;br /&gt;
=== Group 2 ===&lt;br /&gt;
==== Members ====&lt;br /&gt;
* Kyle T.&lt;br /&gt;
* Tarek K.&lt;br /&gt;
* Jakub L.&lt;br /&gt;
* Stefan C.&lt;br /&gt;
* Matt G.&lt;br /&gt;
* Remi G.&lt;br /&gt;
* Ibrahim M.&lt;br /&gt;
&lt;br /&gt;
==== Scenarios ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #1: Disgruntled Ex-Employee(s?) - Sony Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Disgruntled ex-employees with active administrative access and knowledge of internal system architecture.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Full client information specifically financial billing information. &lt;br /&gt;
*** Showcase that Sony does not take security seriously.&lt;br /&gt;
*** Denial of service for PSN users.&lt;br /&gt;
** Means: It is rumored that ex-employees with active logins managed to access the data.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #2: Current &amp;amp; Ex-Employee(s?) - Ashley Madison Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Employees with active administrative access.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Force Ashley Madison to shut down. &lt;br /&gt;
*** Expose the true ratios of male/female user base and fake accounts.&lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #3: Military and Government Secrets&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Whistleblowers (Chelsea Manning, Edward Snowden)&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Publicize and expose questionable practices and information to the general public.&lt;br /&gt;
*** Sway public opinion  &lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #4: This Wiki&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: MediaWiki CMS&lt;br /&gt;
** Attackers: Students with editor privilege on the wiki.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Modify or delete other groups&#039; entries.&lt;br /&gt;
** Means: Full access to edit the page using credentials given by the professor.&lt;br /&gt;
&lt;br /&gt;
==== Attack Strategies ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Weaknesses&#039;&#039;&#039;&lt;br /&gt;
** Employee turnover&lt;br /&gt;
** Disgruntled current and ex-employees&lt;br /&gt;
** Economically vulnerable administrators (easy to bribe)&lt;br /&gt;
** Blackmail&lt;br /&gt;
** System Administrator neglect and/or incompetence&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;How to Attack?&#039;&#039;&#039;&lt;br /&gt;
** Social Engineering&lt;br /&gt;
** If there are no safeguards in place, simply having admin access is enough to wreak havoc&lt;br /&gt;
** Installing backdoors to keep access to system&lt;br /&gt;
** Installing malicious updates and programs on users computers to siphon data and/or monitor.&lt;br /&gt;
** Remote monitoring of all users (including those with higher priviledge), using all available peripherals (webcams, microphones, keyboards, etc...)&lt;br /&gt;
** Denial of Access&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
=== Group 3 ===&lt;br /&gt;
====Members====&lt;br /&gt;
* Dania Ghazal&lt;br /&gt;
* Ankush Varshneya&lt;br /&gt;
* Olivier Hamel&lt;br /&gt;
* Michael Lutaaya&lt;br /&gt;
* Ryan Morfield&lt;br /&gt;
* Daniel Vanderveen&lt;br /&gt;
* Jess Johnson&lt;br /&gt;
&lt;br /&gt;
====Example Scenario====&lt;br /&gt;
&#039;&#039;&#039;Targeted System&#039;&#039;&#039;&lt;br /&gt;
* CIA database - find out who killed Kennedy?&lt;br /&gt;
&#039;&#039;&#039;Attackers&#039;&#039;&#039;&lt;br /&gt;
* remote authenticators&lt;br /&gt;
* contractors (non CIA)&lt;br /&gt;
&#039;&#039;&#039;Goals&#039;&#039;&#039;&lt;br /&gt;
* “exfiltrating data”&lt;br /&gt;
* exfiltrate the CIA database to find out who killed Kennedy&lt;br /&gt;
&#039;&#039;&#039;Means&#039;&#039;&#039;&lt;br /&gt;
* someone at the CIA left a node.js server running in the background :)&lt;br /&gt;
* ssh credentials&lt;br /&gt;
* use outdated emacs (implementing a root privileged mail daemon) to inject a password into etc/passwd to escalate attacker’s privileges&lt;br /&gt;
* look around the system for more vulnerable/outdated services to exploit&lt;br /&gt;
* generate a race condition to create a file that you know a root user would create, then let the root user put their “sensitive data” into attacker’s file (such as files in /temp)&lt;br /&gt;
* social engineering - submit a help ticket to someone within the CIA to gain higher privileges for a seemingly innocent reason&lt;br /&gt;
====Attack Strategies====&lt;br /&gt;
&#039;&#039;&#039;Where are the Accessible Weaknesses?&#039;&#039;&#039;&lt;br /&gt;
* outdated services&lt;br /&gt;
* any service that lets attacker execute a task as another user&lt;br /&gt;
&#039;&#039;&#039;How Do You Attack Them?&#039;&#039;&#039;&lt;br /&gt;
* user privilege escalation&lt;br /&gt;
* abusing service vulnerabilities&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, unauthenticated==&lt;br /&gt;
Abdul Bin Asif Niazi&amp;lt;br&amp;gt;&lt;br /&gt;
Dusan Rozman&amp;lt;br&amp;gt;&lt;br /&gt;
Sam Whiteley&amp;lt;br&amp;gt;&lt;br /&gt;
Jake Brown&amp;lt;br&amp;gt;&lt;br /&gt;
Nicholas Laws&amp;lt;br&amp;gt;&lt;br /&gt;
Miran Mirza&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
Typically targeted systems include: portable systems such as laptops, smartphones, tablets, USB keys, card systems, banking machines.&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Attack strategies:&#039;&#039;&#039; &amp;lt;br&amp;gt;&lt;br /&gt;
	• Duplicated cards&amp;lt;br&amp;gt;&lt;br /&gt;
	• Card Readers&amp;lt;br&amp;gt;&lt;br /&gt;
	• RFID readers: can be used to duplicate RFID data and steal NFC enabled bank access systems&amp;lt;br&amp;gt;&lt;br /&gt;
	• Radio-Frequency generator used to unlock different cards&amp;lt;br&amp;gt;&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sort of attacks that can happen:&#039;&#039;&#039;&amp;lt;br&amp;gt;&lt;br /&gt;
	• Man in the middle attack on physical phone lines, people can access phone conversations by inserting some sort of hardware in a SIM card or a landline.&amp;lt;br&amp;gt;&lt;br /&gt;
	• Using the USB auto install feature to spread attacks, exploit this vulnerability to install software. An attacker can plug a USB thumb drive into computer and install software in order to escalate privileges.&amp;lt;br&amp;gt;&lt;br /&gt;
	• Phishing attack, a user can install some sort of software to reroute traffic through their system in order to collect data. A user can physically rewrite the hosts file on  system to tamper with the DNS on the system and steal data.&amp;lt;br&amp;gt;&lt;br /&gt;
	• For secured areas such as labs a vulnerability would be the door which requires some sort of card based authentication, since this can be stolen it is vulnerable.&amp;lt;br&amp;gt;&lt;br /&gt;
	• Bank Machines: a lot of bank machines have a USB port in the bank and thus can get software installed on them. People can also install a card reader on top of the card slot to collect card numbers and other sensitive data.&amp;lt;br&amp;gt;&lt;br /&gt;
	&lt;br /&gt;
&#039;&#039;&#039;Scenarios:&#039;&#039;&#039;&amp;lt;br&amp;gt;&lt;br /&gt;
	• A user gets physical access to a device using sort of card access and then physically destroys a computer (a literal denial of service attack).&amp;lt;br&amp;gt;&lt;br /&gt;
	• An attacker swaps a keyboard for a keylogging keyboard and uses it to steal sensitive data. They are exploiting the fact that users won&#039;t notice the change.&amp;lt;br&amp;gt;&lt;br /&gt;
	• A user can exploit the reset feature on a router in order to gain access to it&#039;s settings, they can then go on to flash the firmware and infect all connected devices on the network.&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, unauthenticated==&lt;br /&gt;
* Samuel Prashker&lt;br /&gt;
* Daniel Lehman&lt;br /&gt;
* Roman Chametka&lt;br /&gt;
* Derek Aubin&lt;br /&gt;
* Gilbert Lavergne-Shank&lt;br /&gt;
* Xiusan Zhou&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Scenarios&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;#1 - DDOS&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Web servers, or any machine connected to a network&lt;br /&gt;
*** Attackers: Angry trolls, political warriors&lt;br /&gt;
*** Goals: Denials of service, anger your target, hurt their financials, prove a point&lt;br /&gt;
*** Means: LOIC, Chinese Botnet with Bitcoin&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Exploitable communication paths (example: ping, login spam)&lt;br /&gt;
**** In the case of a router, overpowering a signal by replacing it with your own higher powered signal&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Over the network&lt;br /&gt;
**** Over the air (wireless signals)&lt;br /&gt;
* &#039;&#039;&#039;#2 - Packet Sniffing&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Phones, servers, any networked device that can be sniffed&lt;br /&gt;
*** Attackers: Exfiltrators who want getting data, corrupting data &lt;br /&gt;
*** Goals: Exfiltration of data, snooping for data over the air&lt;br /&gt;
*** Means: Packet sniffing tools, Wireshark, &lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Wireless signals would be easy to monitor&lt;br /&gt;
**** Mission security (Msec)&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Wireless: Network cards, monitoring tools for over the air analysis&lt;br /&gt;
**** Wired: Anywhere along the line to be able to hook in a middleman&lt;br /&gt;
* &#039;&#039;&#039;#3 - Remote program already running on their service/server&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: People (social engineering), known exploits (0days)&lt;br /&gt;
*** Attackers: Blackhat hackers, whitehat hackers&lt;br /&gt;
*** Goals: Exfiltrate, corrupt, deny access, destroy, ransomware, (whitehat only: protect!)&lt;br /&gt;
*** Means: Exploitable software, social engineering&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses?&lt;br /&gt;
**** Stupid people, exploitable equipment known to be accessible to 0days, leveraging bugs&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Social networks, email, phone calls, deployed payload&lt;br /&gt;
** &#039;&#039;&#039;Point is you&#039;re trying to get someone to install software for you, or exploit software to inject the payload on the targeted system&#039;&#039;&#039;&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
	<entry>
		<id>https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20576</id>
		<title>SystemsSec 2016W Lecture 5</title>
		<link rel="alternate" type="text/html" href="https://homeostasis.scs.carleton.ca/wiki/index.php?title=SystemsSec_2016W_Lecture_5&amp;diff=20576"/>
		<updated>2016-01-22T03:27:46Z</updated>

		<summary type="html">&lt;p&gt;Miranmirza: /* Physical attacker, unauthenticated */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;Class discussion: threat models and attacker goals&lt;br /&gt;
&lt;br /&gt;
==Local attacker==&lt;br /&gt;
&lt;br /&gt;
==Administrative attacker==&lt;br /&gt;
&lt;br /&gt;
=== Group 2 ===&lt;br /&gt;
==== Members ====&lt;br /&gt;
* Kyle T.&lt;br /&gt;
* Tarek K.&lt;br /&gt;
* Jakub L.&lt;br /&gt;
* Stefan C.&lt;br /&gt;
* Matt G.&lt;br /&gt;
* Remi G.&lt;br /&gt;
* Ibrahim M.&lt;br /&gt;
&lt;br /&gt;
==== Scenarios ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #1: Disgruntled Ex-Employee(s?) - Sony Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Disgruntled ex-employees with active administrative access and knowledge of internal system architecture.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Full client information specifically financial billing information. &lt;br /&gt;
*** Showcase that Sony does not take security seriously.&lt;br /&gt;
*** Denial of service for PSN users.&lt;br /&gt;
** Means: It is rumored that ex-employees with active logins managed to access the data.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #2: Current &amp;amp; Ex-Employee(s?) - Ashley Madison Hack&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Employees with active administrative access.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Force Ashley Madison to shut down. &lt;br /&gt;
*** Expose the true ratios of male/female user base and fake accounts.&lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #3: Military and Government Secrets&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: Service &amp;amp; Database servers&lt;br /&gt;
** Attackers: Whistleblowers (Chelsea Manning, Edward Snowden)&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Publicize and expose questionable practices and information to the general public.&lt;br /&gt;
*** Sway public opinion  &lt;br /&gt;
** Means: Ex-employees with full administrative access to databases.&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Scenario #4: This Wiki&#039;&#039;&#039;&lt;br /&gt;
** Targeted System: MediaWiki CMS&lt;br /&gt;
** Attackers: Students with editor privilege on the wiki.&lt;br /&gt;
** Goals: &lt;br /&gt;
*** Modify or delete other groups&#039; entries.&lt;br /&gt;
** Means: Full access to edit the page using credentials given by the professor.&lt;br /&gt;
&lt;br /&gt;
==== Attack Strategies ====&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;Weaknesses&#039;&#039;&#039;&lt;br /&gt;
** Employee turnover&lt;br /&gt;
** Disgruntled current and ex-employees&lt;br /&gt;
** Economically vulnerable administrators (easy to bribe)&lt;br /&gt;
** Blackmail&lt;br /&gt;
** System Administrator neglect and/or incompetence&lt;br /&gt;
&lt;br /&gt;
* &#039;&#039;&#039;How to Attack?&#039;&#039;&#039;&lt;br /&gt;
** Social Engineering&lt;br /&gt;
** If there are no safeguards in place, simply having admin access is enough to wreak havoc&lt;br /&gt;
** Installing backdoors to keep access to system&lt;br /&gt;
** Installing malicious updates and programs on users computers to siphon data and/or monitor.&lt;br /&gt;
** Remote monitoring of all users (including those with higher priviledge), using all available peripherals (webcams, microphones, keyboards, etc...)&lt;br /&gt;
** Denial of Access&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
=== Group 3 ===&lt;br /&gt;
====Members====&lt;br /&gt;
* Dania Ghazal&lt;br /&gt;
* Ankush Varshneya&lt;br /&gt;
* Olivier Hamel&lt;br /&gt;
* Michael Lutaaya&lt;br /&gt;
* Ryan Morfield&lt;br /&gt;
* Daniel Vanderveen&lt;br /&gt;
* Jess Johnson&lt;br /&gt;
&lt;br /&gt;
====Example Scenario====&lt;br /&gt;
&#039;&#039;&#039;Targeted System&#039;&#039;&#039;&lt;br /&gt;
* CIA database - find out who killed Kennedy?&lt;br /&gt;
&#039;&#039;&#039;Attackers&#039;&#039;&#039;&lt;br /&gt;
* remote authenticators&lt;br /&gt;
* contractors (non CIA)&lt;br /&gt;
&#039;&#039;&#039;Goals&#039;&#039;&#039;&lt;br /&gt;
* “exfiltrating data”&lt;br /&gt;
* exfiltrate the CIA database to find out who killed Kennedy&lt;br /&gt;
&#039;&#039;&#039;Means&#039;&#039;&#039;&lt;br /&gt;
* someone at the CIA left a node.js server running in the background :)&lt;br /&gt;
* ssh credentials&lt;br /&gt;
* use outdated emacs (implementing a root privileged mail daemon) to inject a password into etc/passwd to escalate attacker’s privileges&lt;br /&gt;
* look around the system for more vulnerable/outdated services to exploit&lt;br /&gt;
* generate a race condition to create a file that you know a root user would create, then let the root user put their “sensitive data” into attacker’s file (such as files in /temp)&lt;br /&gt;
* social engineering - submit a help ticket to someone within the CIA to gain higher privileges for a seemingly innocent reason&lt;br /&gt;
====Attack Strategies====&lt;br /&gt;
&#039;&#039;&#039;Where are the Accessible Weaknesses?&#039;&#039;&#039;&lt;br /&gt;
* outdated services&lt;br /&gt;
* any service that lets attacker execute a task as another user&lt;br /&gt;
&#039;&#039;&#039;How Do You Attack Them?&#039;&#039;&#039;&lt;br /&gt;
* user privilege escalation&lt;br /&gt;
* abusing service vulnerabilities&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, authenticated==&lt;br /&gt;
&lt;br /&gt;
==Physical attacker, unauthenticated==&lt;br /&gt;
Abdul Bin Asif Niazi&lt;br /&gt;
Dusan Rozman&lt;br /&gt;
Sam Whiteley&lt;br /&gt;
Jake Brown&lt;br /&gt;
Nicholas Laws&lt;br /&gt;
Miran Mirza&lt;br /&gt;
&lt;br /&gt;
Typically targeted systems include: portable systems such as laptops, smartphones, tablets, USB keys, card systems, banking machines.&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Attack strategies:&#039;&#039;&#039; &lt;br /&gt;
	• Duplicated cards&lt;br /&gt;
	• Card Readers&lt;br /&gt;
	• RFID readers: can be used to duplicate RFID data and steal NFC enabled bank access systems&lt;br /&gt;
	• Radio-Frequency generator used to unlock different cards&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Sort of attacks that can happen:&#039;&#039;&#039;&lt;br /&gt;
	• Man in the middle attack on physical phone lines, people can access phone conversations by inserting some sort of hardware in a SIM card or a landline.&lt;br /&gt;
	• Using the USB auto install feature to spread attacks, exploit this vulnerability to install software. An attacker can plug a USB thumb drive into computer and install software in order to escalate privileges.&lt;br /&gt;
	• Phishing attack, a user can install some sort of software to reroute traffic through their system in order to collect data. A user can physically rewrite the hosts file on  system to tamper with the DNS on the system and steal data.&lt;br /&gt;
	• For secured areas such as labs a vulnerability would be the door which requires some sort of card based authentication, since this can be stolen it is vulnerable.&lt;br /&gt;
	• Bank Machines: a lot of bank machines have a USB port in the bank and thus can get software installed on them. People can also install a card reader on top of the card slot to collect card numbers and other sensitive data.&lt;br /&gt;
	&lt;br /&gt;
&#039;&#039;&#039;Scenarios:&#039;&#039;&#039;&lt;br /&gt;
	• A user gets physical access to a device using sort of card access and then physically destroys a computer (a literal denial of service attack).&lt;br /&gt;
	• An attacker swaps a keyboard for a keylogging keyboard and uses it to steal sensitive data. They are exploiting the fact that users won&#039;t notice the change.&lt;br /&gt;
A user can exploit the reset feature on a router in order to gain access to it&#039;s settings, they can then go on to flash the firmware and infect all connected devices on the network.&lt;br /&gt;
&lt;br /&gt;
==Remote attacker, unauthenticated==&lt;br /&gt;
* Samuel Prashker&lt;br /&gt;
* Daniel Lehman&lt;br /&gt;
* Roman Chametka&lt;br /&gt;
* Derek Aubin&lt;br /&gt;
* Gilbert Lavergne-Shank&lt;br /&gt;
* Xiusan Zhou&lt;br /&gt;
&lt;br /&gt;
&#039;&#039;&#039;Scenarios&#039;&#039;&#039;&lt;br /&gt;
* &#039;&#039;&#039;#1 - DDOS&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Web servers, or any machine connected to a network&lt;br /&gt;
*** Attackers: Angry trolls, political warriors&lt;br /&gt;
*** Goals: Denials of service, anger your target, hurt their financials, prove a point&lt;br /&gt;
*** Means: LOIC, Chinese Botnet with Bitcoin&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Exploitable communication paths (example: ping, login spam)&lt;br /&gt;
**** In the case of a router, overpowering a signal by replacing it with your own higher powered signal&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Over the network&lt;br /&gt;
**** Over the air (wireless signals)&lt;br /&gt;
* &#039;&#039;&#039;#2 - Packet Sniffing&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: Phones, servers, any networked device that can be sniffed&lt;br /&gt;
*** Attackers: Exfiltrators who want getting data, corrupting data &lt;br /&gt;
*** Goals: Exfiltration of data, snooping for data over the air&lt;br /&gt;
*** Means: Packet sniffing tools, Wireshark, &lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses&lt;br /&gt;
**** Wireless signals would be easy to monitor&lt;br /&gt;
**** Mission security (Msec)&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Wireless: Network cards, monitoring tools for over the air analysis&lt;br /&gt;
**** Wired: Anywhere along the line to be able to hook in a middleman&lt;br /&gt;
* &#039;&#039;&#039;#3 - Remote program already running on their service/server&#039;&#039;&#039;&lt;br /&gt;
** Scenario&lt;br /&gt;
*** Targeted System: People (social engineering), known exploits (0days)&lt;br /&gt;
*** Attackers: Blackhat hackers, whitehat hackers&lt;br /&gt;
*** Goals: Exfiltrate, corrupt, deny access, destroy, ransomware, (whitehat only: protect!)&lt;br /&gt;
*** Means: Exploitable software, social engineering&lt;br /&gt;
** Attack strategies&lt;br /&gt;
*** Accessible weaknesses?&lt;br /&gt;
**** Stupid people, exploitable equipment known to be accessible to 0days, leveraging bugs&lt;br /&gt;
*** How do you access them?&lt;br /&gt;
**** Social networks, email, phone calls, deployed payload&lt;br /&gt;
** &#039;&#039;&#039;Point is you&#039;re trying to get someone to install software for you, or exploit software to inject the payload on the targeted system&#039;&#039;&#039;&lt;/div&gt;</summary>
		<author><name>Miranmirza</name></author>
	</entry>
</feed>