Good evening,
I’m glad to have met everyone on Thursday night. I really enjoy our first class.
Here are the slides from last night: Operating-Systems-Week1
I have reviewed the video and only saw two pop-ups of the class recording. I think I answered all the questions. If I missed anything please let me know via e-mail or posts to the site. I have also reviewed the WebEx recordings, but it did not record any of the chat sessions.
Please review the the items from slide 12 “In The News” and post thoughts from the overview we have talked about on Thursday. Take one of the three items from the news and think about how you would use one item we talked about to secure a target OS. If you don’t feel comfortable with the OS being reviewed in the three articles I posted you may select one of your own from the news article.
Also review the video link on how to install Windows 7. (Note: that Chrome works best when watching linked videos, Safari does not work)
The below video show you how to install Windows 7 on VMWare Fusion (On Box Link: Install Windows 7)
The below video shows you how to install the main set of patches for Windows 7 (On Box Link: Install Windows 7 Patches Main)
The below video shows you how to install ‘Cygwin’ to watch the WindowsUpdate.log (On Box Link: Install Cygwin)
Download this zip file and Place files into a folder structure Windows_LinkedPS_Scripts and Share the folder to the Guest OS via VMWare to have it work with the below video: PS_WU_Setup
The below video shows you how to setup PowerShell to watch the WindowsUpdate.log (On Box Link: Set-Up PS to Watch WU)
Download: Windows 7 Pro 64-bit SP1, VMWare Fusion or Workstation. Make notes of the license keys. Please use the links from the class syllabus on how to install VMWare Fusion or Workstation. If you have any issues we will work on them in our next class.
To download Windows : Temple Download site
VMWare: Temple Download Site for VMWare
Here is what I put into the form to get the download.
You will need to also get VMWare Workstation or Fusion.
Sev Shirozian says
RE: https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
After reading the online post on krebs on security, “Hacked Cameras, DVRs Powered Today’s Massive Internet Outage”, I think one of the best ways to have soften the blow with this would have been if everyone used egress filters as much and ingress filters preventing those IoT devices from free reign on anything on the Internet. Even if the IoT devices got compromised, the network or firewall could have prevented the communication from those IoT devices to DYN or anywhere on the Internet. Another way to prevent a massive attack like this is if the vendors as part of setting up the IoT devices made it a step during setup or configuration to change default passwords on the IoT devices. That could have also mitigated back actors from accessing wide open devices connected to the Internet.
– Sev Shirozian
MARK HEIER says
Sev,
I like the fact that you are suggesting somewhat of a defense in depth concept here. Sure the first thing that could have helped prevent this was changing the default passwords. I think it’s a good recommendation for the vendors to incorporate this practice during the initial set up process. By incorporating these simple procedures as you recommended it could have been a huge deterring factor for the adversary. Raising situational awareness of these sorts of issues with everyone from the vendors to the end users will be clutch as we move forward in an attempt to prevent future recurrences of this event.
Jason A Lindsley says
I’ve visited the Temple download site, but I’m not finding any of the Windows versions available. I’ve used this site several times to download multiple versions of Windows and office products, but I’m not sure why there are no Microsoft products available to me. I contacted support, but is anyone else having this issue?
Thank you,
Jason
Andrew Szajlai says
https://computerservices.temple.edu/educational-discounts-computer-equipment-and-software
Scroll down-to: “Microsoft’s Imagine Subscription Program” You will need to get an account from the site; They have moved the link from last year. Let me know how that works for you.
Brock Donnelly says
I was able to get into the Imagine link but the oldest version of windows available to me was Windows 8. Did anyone find Windows 7 when they logged in?
Patrick DeStefano (tuc50677) says
I’m having an issue where it says my account is expired and unable to download VMware, but not having the issue with Windows.
Patrick DeStefano (tuc50677) says
Although, I’m not finding any links to download Windows 7. The only things I’m seeing are for Windows 10.
Duy Nguyen says
Hi Patrick,
You have to call Fox IT Support, I had the same problem.
215-204-3847 (9am to 5pm)
Andrew Szajlai says
We are going to use Windows 10. I have not had luck finding a Windows 7 version. We can use the current videos for Windows 7 and will work to fill in the gaps as we need.
Patrick DeStefano (tuc50677) says
Thanks Duy! I’ll have to give them a call tomorrow.
Vince Kelly says
Review the items from slide 12 “In The News” and post thoughts from the overview we have talked about on Thursday. Take one of the three items from the news and think about how you would use one item we talked about to secure a target OS
After looking at the dirtyc0w video, my responses to the question are below. I was also a bit confused about the terminology that was used so I put that question at the bottom of this post – maybe someone can explain it to me?
RESPONSE TO THE QUESTION:
Of the seven OS security strategies mentioned in the lecture (slides 61 through 63), I would think that several could be applied to prevent or at least detect dirtyc0w activity. Depending on the circumstance and practicality, many or all of these approaches might work. I tried to put them in order of usefulness (in my opinion) as HIGH, MEDIUM or LOW probability for each. Again, their application/effectiveness would be situationally dependent.
1) SYSTEM HARDENING (HIGH PROBABILITY): This would be the best solution (in my opinion). Simply removing the C compiler from the system or severely limiting user access to the compiler would prevent diryc0w.c from being compiled into an executable. While it is true that an attacker could move a compiled version of the executable over to the machine, they would need to have gained access to the system and have permissions to deploy code (which is a MUCH bigger problem than the dirtyc0w threat in my opinion).
2) APPROPRIATE PERMISSIONS (MEDIUM to HIGH PROBABILITY): Since this is a Linux only attack, (ESXi hypervisor, Windows OS are not impacted see – https://kb.vmware.com/s/article/2147515) restricting the use of Linux, hypervisors and/or guest VMs to a very small people (who absolutely needed access) would be one way to do it. This solution is obviously a bit hash, but it would have limited the spread of this exploit nonetheless.
3) BASELINES (HIGH PROBABILITY): If an initial baseline on critical system files (like the linux system group file) was performed initially, then important information would be available to detect the activity – e.g., changes in file size, creation date, last modification date, etc. running a simple diff utility would quickly identify that the critical files that dirtyc0w had changed had been tampered with.
4) PATCHING (HIGHEST PROBABILITY): According to the youtube video and the following article; https://www.theguardian.com/technology/2016/oct/21/dirty-cow-linux-vulnerability-found-after-nine-years As of October 2016, the dirtyc0w exploit had been around for more than 9 years as was well understood by many in the community. It is believed that it only became relevant because of the ever increasing speed of today’s processors – the dirtyc0w exploit is based on overwhelming the kernel by flushing the system write cache so much that it would (inadvertently) write a given string into a file without regard for file system permissions. A patch was made to the generic Linux virtual memory management code to change the way that it handles page table entry – page table entries is what dirtyc0w would keep flushing so that the kernel would become overwhelmed. Specifically, the change allowed the Linux memory manager to wait until a previous cache flush had completed before acting on another flush request. The point here is that any Linux system that had been configured to automatically apply distribution patches would have been protected from the exploit as soon as it had become available.
5) LOGGING (MEDIUM to HIGH PROBABILITY): If the dirtyc0w exploit was used as a mechanism to add/elevate the attacker to root privileges, then there is a high probability that the attacker would have generated at least one Linux invalid login message which would have been logged (e.g.,one common message that occurs for a failed login attempt is; “attackerName is not in the sudoers file. This incident will be reported!”). Also, if an appropriate baseline had been established before the attack and a cron job to diff the files existed, then the file changes would also have been logged.
6) ANTIVIRUS (MEDIUM TO HIGH PROBABILITY): I would think that a small process with two only threads that are thrashing memory and spewing out cache flushes at an extremely high rate would seem suspicious to any behavior based malware detection system -i.e. one thread declaring that 100 bytes of the exact same spot in memory is no longer needed and can be released over and over again and then the other thread opening up its own process memory and writing it out to a copy 100,000,000 times would/should raise at least some sort of warning by a HIDS/Antivirus/malware program – especially if the software had signatures for that sort of pattern already (and again dirtyc0w had been out there for over 9 years). The point is that I’d think that at least SOME sort of (behavior based) HIDS/AV/Malware system would pick up the activity and at least log it.
7) FIREWALL (LOW PROBABILITY): A standalone Firewall would probably not have caught dirtyc0w because they only look at TCP and UDP port activity. An application firewall might detect it but I’d think that could have issues as well.
CONFUSION/QUESTION ON CALLING dirtyc0w A PRIVILEGE ESCALATION METHOD:
How exactly would dirtyc0w be used to gain wider access to a Linux OS? The video explained that dirtyc0w can be used to write bytes into a file but it left out the real value of dirtyc0w’s use as a tool to gain wider access to the system.
I bring this up because I’m a bit confused about some of the terms/terminology that have been bantered about so (I think) understanding them requires an understanding of the exact privilege escalation process.
I’ll explain the escalation process and then describe what I’m confused about.
A good demonstration of applying dirtyc0w to do privilege escalation is at this video:
https://www.youtube.com/watch?v=0ngLWxkntRE
The escalation process is an attempt to add yourself to the sudo/root group that’s configured in the Ubuntu group file that’s located in /etc/. To get to that file you need to do the following:
– nano anyFile <– just open an editor for temporally storing our strings
– cat /etc/group |grep sudo <– list out the group file. This is where the sudo group def will be
– cut & paste all of the entries in the group file into the editor session you just opened
scan down all the entries in the list until you see a line that starts with something like the following:
sudo:x:27:someUserName
– add your username on the end of the line, (don’t forget the comma), it should look something like the following:
sudo:x:27:someUserName,attackersUserName
– Copy that entire list into the paste buffer
– Now that we have the modified group file contents in the paste buffer, we are done with the editor session – no need to save anything.
– Open the dirtyc0w.c source code file (you can use any editor for this – nano, vim, etc)
– We want to replace the code in dirtyc0w that pulls in the command line argument with a string that contains what the modified group file entries that we currently have in the paste buffer. To do this:
– Find the line in the source code with the following string declaration statement:
str(char *) arg <–this is a C typecast of the variable called 'arg' it tells us the cmd line argument is a string
– Replace that statement with the pasted contents that you have in the paste buffer like so:
str=” PASTE THE CONTENT OF THE MODIFIED GROUP FILE BETWEEN THESE QUOTES “
– Now compile the dirtyc0w code:
gcc dirtyc0w.c –o dirtyc0w -lpthread <– this compiles the .c file and creates the dirtyc0w executable
– Finally, just execute dirtyc0w
./dirtyc0w /etc/group “foo”
Here’s the breakdown of the line:
./dirtyc0w <– statement that executes the program you just compiled
/etc/group <– is the directory where we will find the group file (that we will replace)
“foo” <– is an arbitrary command line argument that dirtyc0w expects – (we changed this in the source code but we still need to provide it at execution time)
This will replace/overwrite the existing sudo (root) line of text with a new line containing your user name added to the sudo group. You should now be able to log in to root using you own username.
My confusion with the terminology is this: It doesn’t seem to me that dirtyc0w is actually a privilege escalation method at all. It seems to me that dirtyc0w is just a file manipulation utility that gets MISUSED to escalate privileges.
I know that this may sound like quibbling but I think there is a distinction to be made here. To me, ‘privilege escalation’ attack implies something more direct – like code that could decrypt the contents of root passwords for example. In other words, dirtyc0w only BYPASSES the current privileges assigned to the Linux file system – it doesn’t do anything else. So for example, I couldn’t use it to directly change the contents of another process’s memory or to copy packets that are streaming into a TCP listen port.
My point here is that dirtyc0w is a useful utility that can be used to ULTIMATELY escalate privileges but labeling it as a ‘privilege escalation’ method seems wrong to me. If you do that, then you’d also need to call the text editor that was used to create the strings and the C compiler that was used to generate the executable as ‘privilege escalation methods’ as well – right?
I guess it just comes down to the distinction between the word ‘tool’ and ‘method’
Jason A Lindsley says
Hi Vince,
What a thorough post! Nice work.
I think the key in why it is referred to a “privilege escalation” exploit is because of this statement you made: “This will replace/overwrite the existing sudo (root) line of text with a new line containing your user name added to the sudo group.” Since you are a non-root user and you were able to use this exploit to gain root access under your own name (without the root password), I can understand why it is considered a “privilege escalation” exploit. Many exploits only allow you to gain access to the command line with minimum privileges, but if an attacker can combine those exploits with dirtyc0w, they can cause some serious damage.
Vince Kelly says
Thank you Jason. Completely understand and agree Jason – I guess its more a issue of quibbling/semantics. I don’t believe that dirtyc0w is a privilege escalation method at all, its simply a tool that can be used as part of privilege escalation – right? In other words, dirtyc0w itself doesn’t ‘do’ the privilege escalation any more than the C compiler does – but in the case of dirtyc0w you need both to actually accomplish the exploit (the dirtyc0w source code and access to a gcc compiler). We don’t refer to the C compiler as a privilege escalation exploit so why should we assign the same label to dirtyc0w. True, it was expressly created for that purpose (and the C compiler was not) but i think that’s beside the point – you could use dirtyc0w for any number of useful (and ethical) things.
Again, this was just more quibbling than anything else;)
Frederic D Rohrer says
Article: 10 things to know about the October 21 IoT DDoS attacks | by Stephen Cobb
https://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/
Brief:
On 10/21/2016 a large number of infected IoT devices were used to DDOS the major DNS provider Dyn. The attack made it hard or impossible to resolve addresses to some major websites because they relied on Dyn’s primary and secondary DNS servers. The malware “Mirai” also attacked OVH with at least 1.1 Tbps (which I remember as the day OVH started charging for DOS mitigation).
Cause:
Many IoT devices were sparsely secured or not secured at all. Attackers were able to crawl the internet looking for public devices –such as IPcameras and routers– and take control of the devices using default credentials.
Response:
Most IoT devices are likely based on a single-tasking OS and based on an embedded Linux. The devices are operating with hardware that is specifically designed to perform its task and likely has minimal overhead. However many of these operating systems are based on web technology because UI and UX programming is faster in web languages and easier to integrate into the IoT household. IoT also tends to use UPnP aggressively, communicating externally for features that the owner might not be aware of.
The attacker simply needs to scan the global IPv4 address space (only 4,294,967,296) for known open ports. Then the attacker can use default credentials and take over the device. Malicious code would be run on the existing web platform and simply send SYN requests to the target computer. (https://gist.github.com/zachary822/937ac765cc7d6ffbde06 will send a SYN packet only using JavaScript as long as the raw-socket package is included)
Appropriate Permissions: The first step to securing an IoT device is to establish appropriate permissions. It should start with changing the default credentials. This would force the attacker to try a different attack vector, and if this was the automated attack from October, thwart it completely. In addition to this, separate users should be created for administrator and viewer access. Some IoT devices have the ability to restrict functionality by user account.
Limit Services: Unused features should be disabled to prevent the device from acting unpredictable. If these customizations are not available then one can consider flashing the firmware with a more secure variant, such as OpenWRT for routers (if the hardware permits it).
Firewall: All incoming connections in a home network should be blocked by a firewall. Only established connections need to be allowed, unless access to cameras is required from the outside. In that case strict rules should be set to only allow the actual picture feed to pass on a higher port, and NAT should be set manually to forward to the needed devices only.
MARK HEIER says
Frederic,
Great post. This unfortunately was an attack that could have been prevented or at the very least mitigated to reduce the overall impact that was seen. Having default passwords in place as you pointed out is almost like an invitation for the adversary to exploit them. I also loved your mention of properly securing incoming connections in a home network as this is generally something that most individuals aren’t mindful of. Manually setting NAT would be a great deterrent however as we all know the majority of people aren’t very tech savy when dealing with the home networks. This will be a continued challenge as we move forward and can hopefully raise some situational awareness of the real time threats that are out there.
Brock Donnelly says
This is a good list of what we should do, but what can we do when manufacturers with a minimal overhead don’t include a way to change default credentials. In response to telnet and SSH on these devices:
“The issue with these particular devices is that a user cannot feasibly change this password,” Flashpoint’s Zach Wikholm told KrebsOnSecurity. “The password is hardcoded into the firmware, and the tools necessary to disable it are not present. Even worse, the web interface is not aware that these credentials even exist.”
We are at a point where we need a governing organization to impose rules and regulations.
Fred Zajac says
The attacker simply needs to scan the global IPv4 address space (only 4,294,967,296) for known open ports.
Check this out. Can be done is seconds!
Censys.io
Patrick DeStefano (tuc50677) says
Hi Frederic,
I’m in complete agreement with your assessment. While automation is becoming more and more popular to increase efficiency and reliability for executing processes for companies to do good, it also has the same perks for those who wish to do harm. There’s no way a fraudster or hacker can take over millions of devices like the situation here without automation. The good thing about this method of attack for the users, is that if the vulnerability being exploited is found early enough, the OS can be patched or a user can manually update the password or other functionality so that the malicious automated script fails and moves on to its next target. That being said, if a hacker is attempting to access the device manually and they are skilled enough, they will see this and attempt to get in a different way.
Satwika Balakrishnan says
I would like to add my following views in addition to the ones mentioned by Frederic regarding the October 21 IoT DDoS attacks.
I believe that the increasing number of Internet of Things(IoT) with very limited or no security measures at all and also not so well educated end users of these products make these devices a more attractive target for creating botnets than the conventional devices.
1. Since DDoS infection happened mainly because of the use of default passwords on these devices, one suggestion would be to compel the end users to change the password during the first login itself before they navigate to making any further configuration of the device.
2. PATCHING: According to my understanding, patching is often neglected in most of the IoT devices by the manufacturers as well as end users. Most of the IoT devices run on antiquated versions of Linux and so becomes even more vulnerable from the security point of view. Although some of these devices may receive patches from the vendors, most of the manufacturers do not even create patches for these devices since, often these devices are developed with cost optimization in mind. Thus, they become highly vulnerable to any malware infections or security breaches. Also, the end users should be well educated about the product and they should be advised to check with their vendors periodically for updates.
3. SYSTEM HARDENING: I understand that many of the IoT devices may not be capable of running an AV, but it is more important to have security within the host itself. Manufacturers must have checks to ensure that their device/system abides by the system hardening guidelines. For example, the ports must be enabled only when required by the end user. Also, aborting services and applications that are running in the background and are not necessary for the device operation.
4. LOGGING: This would apply best in an enterprise situation. The IT or respective department in an enterprise should maintain access logs of their IoT in a secured location. Monitoring these logs will help them identify in case their devices are compromised. However, this method may not be the best option in the case of large enterprises with infinite number of IoT devices.
MARK HEIER says
Satwika,
I like the fact that you opened with the fact that we are dealing with a lot of not so well educated end users utilizing these types of products. Hopefully as we move forward with this challenge we can raise awareness and learn from this unfortunate and mostly preventable incident. I also liked that you suggest as a mitigating factor for the issue with default passwords being used that the users could be prompted to change them upon the first login. This is the standard in the majority of organizations and rightfully so. Something as simple as this could have deterred or at least slowed the adversary from gaining access. Patching is also a huge issue. Think of how many people probably hit “remind me later” when the notification pops up that there is a new update available. Hopefully moving forward from this with a heightened level of awareness for folks it will make people think twice about delaying running those updates.
Frederic D Rohrer says
Satwika, I agree with your additions. I love that you mention patching. I never considered that myself, but keeping the firmware and software up to date is essential. I think that most end users never consider applying patches to their devices, because the devices are so out of sight (and out of mind). I believe the expectation that “It just works” applies to the user mentality here. Because of that mindset many customers do not see security as a feature but as a chore. I do not believe that this mentality will change since the attackers are usually smart and never affect the IoT device’s functionality.
Fred Zajac says
Satwika & Frederic,
I agree patching is a very big deal, but what if the IoT manufacture didn’t provide enough space for constant patching? Example: Hardrive limit.
The patching will crash the hard drive at some point because of the file additions. Also, as you mention in a previous post,
The manufacturer may have used a very basic OS, that can’t handle certain operations. Even logging in. They may only have the ability to use one username and password, that can’t be changed.
The end results from patching could crash the device and make it unusable.
I would be very upset as a consumer if I purchased a “smart” appliance and the internal hard drive crashed because the “.net” or “iOS” update was too big.
In my opinion, the manufacturers pushed out these products way too fast, in hopes to cash in on the “make my life easier” train, but forgot to install seat belts. I doubt if people are going to repurchase a new IoT device, so they will be sitting there for the pickings.
Patrick DeStefano (tuc50677) says
Satwika,
I agree with everything you mentioned. One of the biggest vulnerabilities I’m seeing in society today is that there is literally half of the population from a generation that didn’t have anywhere near the amount of technology we have today when they were growing up. This is leading to a large amount of the population being technologically illiterate and when they try to bring these new technologies into their lives, they don’t know how to handle everything that comes with it. Hell, just the other day, my mother called me and was asking how to update her iMac because her TurboTax software gave a notification that she was using the old version and it needed an update before she could do her taxes. Education of the public is the most essential solution that needs to be addressed.
MARK HEIER says
I will be discussing Professor Avi Rubin’s presentation from Ted Talks.
Professor Rubin briefly outlined some of the vulnerabilities present in cardiac devices, cars, P25 walkie talkie radio’s, and smart phones. He highlighted the fact that a determined hacker can stop, start, speed up, change your name, etc. on a pacemaker after a result of reverse engineering to figure out how to get into the now continuously evolving wireless technology. He talked about smart phones and the many different ways they are vulnerable. I’m sure this makes most people for likely not to hit “remind me later” on their iPhone when the software update notification pops up. Companies are constantly attempting to push out patches to shore up holes for the latest discovered vulnerabilities. The 2 examples that were mentioned that I was the most interested in though were the radio transponders and automobiles.
I was particularly interested to see the same radio’s being discussed that I’ve been using in the military for as long as I can remember. While he did mention that often people aren’t talking encrypted on them as they should be, there are a lot of potential ways that a hacker/adversary could deny or degrade their availability and obviously compromise sensitive information being discussed.
His mention of the different wireless communications all tied together in a car and the multiple ways that potential hackers can get in and take over control of the car also caught my interest. Not because I haven’t heard about these vulnerabilities before, but because I was fortunate enough to take place in a similar test a few years back onboard the USS SPRUANCE, an Arleigh Burke Class Guided Missile Destroyer.
Being in the military for the past 14 years and counting I can’t help but think of the first and most important type of protection we discussed in class being Physical or “Hardware” Protection. The whole defense in depth concept which I’m used to is running through my mind. In this instance, whether we’re talking about physically restricting access to devices or disabling ports i.e. USB (standard policy in my organization) I believe physical protection can apply in some facet across all areas of the spectrum we’ll be discussing. Another thing we are big on in the Navy is patching. Routinely running scans and being certain that the most current patches have successfully applied to all devices is one the best ways to deter hackers and adversaries from getting access in the first place. Scan Patch Scan. Lastly, it wasn’t mentioned in this particular Ted talk, but it was up on the screen towards the end, Stuxnet. That is something I wouldn’t mind spending time discussing.
Jason A Lindsley says
Our organization is also currently heavily focused on vulnerability and patch management right now. The traditional model requires periodic scans and typically manually patching servers that have the highest vulnerabilities. We are shifting to automated patching capabilities that will be used to patch systems uniformly and in an expedited manner. This method will still require testing patches in lower environments to ensure they do not break the application or system that the OS supports, however TS people need to be able to continuously regression test their applications as security patches are applied so that they are prepared as the patches are automatically deployed through higher environments, including production.
Cloud computing is facilitating this automation across the industry as it allows you to deploy patches and configuration changes across the footprint (rather than one by one).
Fred Zajac says
We are using Patch Management for our clients using a third-party product. If you are interested in the product, let me know and I will give you info.
Anyway,
One of the things you mention is patching causing issues with applications. This is something we run into from time to time from our clients. Another issue we have is patching software that was installed on only 1 or 2 machines, and never used again. These patches are more difficult to identify and could leave the network vulnerable to penetration. In small business environment, many times employees can download what ever, where ever. The Scan, Patch, Scan is great advice, and don’t just focus on Windows Patching. Patch everything!
Brock Donnelly says
Physical security falls short when it comes to pacemakers. The common connections to the pacemakers recalled during this time communicate through bluetooth, or at least an earlier version of it. It was so new that security was an afterthought. yes another one of these mishaps.
check out these three reasons as to why pacemakers are vulnerable to hacking:
Three key issues hold back cyber-safety:
1. Most embedded devices don’t have the memory or power to support proper cryptographic security, encryption or access control.
2. Doctors and patients prefer convenience and ease of access over security control.
3. Remote monitoring, an invaluable feature of embedded devices, also makes them vulnerable.
http://theconversation.com/three-reasons-why-pacemakers-are-vulnerable-to-hacking-83362
Patrick DeStefano (tuc50677) says
This vulnerability with pacemakers really got me thinking. What other types of technology has been developed and is still in production today which doesn’t have the ability to have updates pushed and may have antiquated security vulnerabilities present? I’m sure there are tons of iot devices which were developed throughout the years before security became as pressing of an issue as it is today. Security Cameras, older ATMs, cash registers, other types of medical devices/monitors. Although a lot of the technology is newer and updated here in the US, we also need to keep in mind the technology in less developed areas of the world which may also be vulnerable and not have the ability or knowledge available to be patched.
Vince Kelly says
Mark,
First, thank you for your service. Totally agree with your assessment. In addition, what was worrisome to me was the observation about exploits that fall outside of the orderly scanning and patching process – for example the iPhone leveraging a nearby accelerometer to detect what someone typed. I seem to recall several years ago during the cold war that the CIA had invented a method of pointing a laser at a window in order to measure vibrations cause by someone in the room talking. It was said that they could pick up extremely high quality recordings of conversations that occurred in a Russian Embassy. I think his statement “…anything that has software in it is going to be vulnerable – its going to have bugs…” should be expanded to something like, “…anything that has a devious and imaginative human intellect at work against it is going to be vulnerable…” ;):)
Duy Nguyen says
https://www.npr.org/2017/01/13/509355546/what-happens-when-hackers-hijack-our-smart-devices
Based on the Avi Rubin presentation of hackable devices, all devices seem to have vulnerabilities no matter what. No system/device can be 100 % threat-proof. Access to these systems varies from wired, wireless or even Bluetooth connectivity.
There can be a variety of mitigation techniques that could be used to reduce or mitigate these risks either protective or detective techniques. Since most or all devices are not 100% threat proof, there should be more focus on detective techniques such as IDS or strong IPS system. There are of course many preventative techniques such as patching vulnerabilities, firewall, updated antivirus, creating secure accounts, and baselines/ or standards.
MARK HEIER says
Duy,
I agree with your statement that no system/device can be 100% threat proof but there are many things that we can do to help mitigate most of these vulnerabilities. Staying up to date with the most current patches and incorporating recommended best practices will certainly help. We are challenged with this task which is an ongoing issue that will only grow more complex as we witness the advances in technology.
Patrick DeStefano (tuc50677) says
Assignment: Please review the the items from slide 12 “In The News” and post thoughts from the overview we have talked about on Thursday. Take one of the three items from the news and think about how you would use one item we talked about to secure a target OS. If you don’t feel comfortable with the OS being reviewed in the three articles I posted you may select one of your own from the news article.
Selected Topic: IoT DDoS Attack
These articles actually opened my eyes to this type of hacking and how thee seemingly innocent and simple devices can actually be linked and used for such malicious purposes.
As it stated in the articles, these devices seem to come standard with default usernames and passwords. One of the first controls we could use to enhance the security of such devices would be to require users to update the username and password to meet certain standards (Mixture of uppercase & lowercase, Mixture of numbers and letters, Minimum length, etc). By not allowing any user who is attempting to setup such devices to proceed without doing this, it would make it much more difficult to breach.
An additional level of controls which could be added would be surrounding software & security updates/patches. Speaking from the perspective of the company designing the widget, we should add a rule in the programming that requires users to install the latest patches as they become available in order to continue use of the device. If users neglect the update/patch, after a specified number of days the device automatically disconnects to all internet other than the path to download the patch.
MARK HEIER says
Pat,
By forcing the users to change their default passwords during the initial login it will certainly make the systems more difficult to breach. I really liked your idea to have a rule programmed in place that requires users to install patches as they’re available and for the device to disconnect at a set point if it’s not updated. This would be a great way to force updates being installed in a timely manner and ensure that the latest security updates are applied. I think the end users might complain a bit initially however, part of the battle moving forward will be educating them on the importance of these sorts of things.
Patrick DeStefano (tuc50677) says
I completely agree Mark,
Change is always going to cause some friction and growing pains. Even in the workplace, I’m sure we all know of times when processes keep changing and we all get frustrated (because of course, we just mastered the old process). The key here is proper and effective communication. Everyone wants to be in control of their own lives. In order to get people to agree that the change is necessary, Communication and education about the reason for the change and why they decided to change the processes the way they did. All too often, change is pushed on people without any explanation and, in my opinion, that is one of the main reasons why there is so much friction with change.
Brock Donnelly says
IOT DDoS attack
¤ http://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/
¤ https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet- outage/
I remember when this attack transpired, it effected a few services at Temple as well as a large amount of services that the Temple community uses. It was quite the talk in the news and many were looking towards Russia. To date no official perpetrator has been identified but there are multiple theories and accusations to hacker groups and even script kiddies. Who cares.
The underlying issue here is the total lack of thought on securing online devices. XiongMai Technologies failure to secure their entire line of down stream components for DVR and IP cameras. XiongMai Technologies and other irresponsible manufacturers should be held accountable for this attack. Financially.
Appropriate Permissions or rather inappropriate permissions and absentmindedness is what caused this massive DDoS attack. The Mirai uses a list of default users and passwords. Only 61 combos make the list, mostly likely 60 of the are only effective, I believe the last one on the list may have been more of a massage. https://www.csoonline.com/article/3126924/security/here-are-the-61-passwords-that-powered-the-mirai-iot-botnet.html
Default passwords should go the way of the dinosaur. The answer may not be simple but random pass combos could be sent in every box. Procedural changes as tp the first log on, forcing password creation could be an alternative.
Here is where we are really screwed when it come to the already compromised IoT devices, many will go with no fix, because there is none. They will remain a danger until they are unplugged. Some of these passwords are unchangeable, the tools to make changes are not included or available and the tools the hackers are using are simple text-based interfaces with already released code available for copying.
Fraser G says
Article Picked:
https://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/
I would use the following to help secure IoT devices (and I do right now actually)
-Scrutinizing all incoming and outgoing network traffic via a firewall
-Logging
I run a couple of different pieces of software, as well as my own internal ad-blocking DNS server on an rasPi (pihole). The Pihole logs DNS of all of my Alexa devices at home when they try to ping home to Amazon. I have only the ports they need to use open in my firewall. I can see when new traffic comes up via my router/firewalls UI.
Having visibility into what traffic is going across my network is fantastic, and having a log of everything allows me to set benchmarks and scrutinize traffic.
Most people won’t know how to do this, and many of them won’t care if their IoT device is a zombie launching DDoS. Looking in the future, most people will end up using whatever their ISP provision to them. These all-in-one devices can do a couple things alright but nothing specific very well. I’d like to see more consumer protection via trade groups and legislation that will set a better baseline. Same goes for IoT devices! The landscape is changing so fast and manufacturers are racing for market share that security is an afterthought. This will change once a critical install point is reached, and their is a major cyber security incident.
If you really want to go down the rabbithole, check out Internet Chemotherapy Janitor:
https://ghostbin.com/paste/q2vq2
MARK HEIER says
Fraser,
I liked how you mentioned that in the future we can expect that people will still be using whatever their ISP gives them. You’re correct in the regard that they can do a few things alright but nothing really good. The key as you recommended is a better baseline which can hopefully zone in a little more on the security perspective as we already know that 99% of people will not be scrutinizing their devices in the same manner you are. This is why a baseline approach that gets pushed out would be a good start. As Pat DeStefano recommended, configuring new devices with a rule that requires users update them as the newest patches become available would be a great addition to a hardened baseline. The legislation thing you mentioned is a whole separate beast though. Unfortunately it will probably take something much worse happening until that takes place.
Brock Donnelly says
I’m impressed to see the level of at which you went to secure your Alexa devices. You must be of a very small percentage. I take a different route. I don’t have any IoT devices in my residence. Well thats a lie. I would like to say I don’t have any but a I did get into some LIFX bulbs when they were introduced. Their system for securing their hardware is well thought out, which is possible why the crowd funding campaign took over 1.5 years to fill.
Take a look at their process:
“LIFX defends against these attacks with a layered system of defences.
First the LIFX cloud.
We don’t have default credentials on our bulbs. We have our own Public Key Infrastructure (PKI) to authenticate our cloud to our bulbs. This PKI infrastructure allows us to protect the CA private keys by keeping them out of reach and allowing us to only publish the public key component of this system. This allows us to revoke and rotate the operational side of the infrastructure. In the event that any of these keys were compromised we would make sure to contact everyone we could and publish information on how we are mitigating it and repairing from it.
For the infrastructure that receives public connections (not from our bulb or app) we use standard TLS certificates from public CAs to secure all traffic between us and end users.
I can recommend the Coursera introduction to cryptography course if you want to learn more of the theory on this topic. It’s really quite good.
We also have proactive monitoring and alerting on our cloud services. We develop our software with best practices and security in mind and we are frequent readers of OWASP and other security publications.
We do review the ways we handle these keys (and our development practices and reporting procedures) periodically and welcome suggestions and bug reports. We have internal procedures for security bug reporting.
On to the device side of things.
All firmware updates already take place over the secured PKI systems described above. In addition to this firmware updates are signed by our firmware team and the signature is verified in both the updater inside the app and in the bulb itself. Our bulbs also inadvertently benefit from the environment they run in. Due to the heat involved in our bulbs our SOCs are very minimal and don’t have an excess in compute power or storage. While this is not something that makes it more secure it does make it harder to effectively use a compromised bulb in the event that exploits or effective attacks on our updating method are found.
This is not to say that there are not steps that you should consider taking for your LIFX cloud account.
Log in to https://cloud.lifx.com28 and make sure you periodically check that you don’t have unwanted services or devices authorised on your account.
Make sure you use a long and complex password.
Do not share your personal access tokens.
Revoke and Rotate access tokens periodically.”
https://community.lifx.com/t/how-do-we-protect-against-iot-ddos-attacks-like-mirai/1858/4
Shi Yu Dong says
Assignment: Please review the the items from slide 12 “In The News” and post thoughts from the overview we have talked about on Thursday. Take one of the three items from the news and think about how you would use one item we talked about to secure a target OS. If you don’t feel comfortable with the OS being reviewed in the three articles I posted, you may select one of your own from the news article.
Article: 10 things to know about the October 21 loT DDoS attacks
According to the “10 things to know about the October 21 LoT DDoS attacks”, it describes that most of the loT devices were not secured at all for both company and customer personal information. Due to this vulnerability, the attackers were able to crawl the loT devices and public devices such as personal routers with a weak default password. The article also mentions that there are multiple surveys shows customer doesn’t rely on loT devices security about their personal identifying information.
Based on this October 21 loT DDoS attacks, I think that the major issue of this attacks is that company don’t have enough knowledge of how to secure their devices. With unsecured devices like a router that connects to the internet, it allows attackers easily implement the malicious code on the personal devices and stop all the services which will cause the disruption of legitimate internet activity. In order to prevent those attacks happening, both companies and customer need to ensure that all default password of router changed to a strong password which can prevent hackers can easily hack the router. In addition, all the loT devices should constantly update with any security patches as soon as patches become available.
Patrick DeStefano (tuc50677) says
I agree! With all the older technology out there which was introduced before security became as big of a concern as it is today (and some that is still being put into production), its imperative to educate companies developing theses products as well as the users on the proper ways of protecting the devices. Firewalls, password updates, security updates, etc, should all be implemented together to properly secure these types of devices.
Richard Mu says
In listening to the NPR recording of Avi Rubin’s TED Talk”
https://www.npr.org/2017/01/13/509355546/what-happens-when-hackers-hijack-our-smart-devices
It is difficult to be able to protect all IoT devices that are being released at an alarming rate. In the TED Talk, Rubin points out the vulnerabilities in smart devices that operate wirelessly. Covering from healthcare, automobiles, and even phones, Rubin discusses the vulnerabilities that were found in various tests and the potential threats.
Recently in September of 2017, it was found that there was a Bluetooth vulnerability named BlueBorne found: https://www.theverge.com/2017/9/12/16294904/bluetooth-hack-exploit-android-linux-blueborne
In some of the devices that Rubin discusses about uses Bluetooth. Although it is impossible to secure every smart devices, the next best option is to be constantly have these devices updated with the latest firmware that often comes with security patches.
MARK HEIER says
Richard,
As you pointed out, this technology is being released at an alarming rate. It is difficult enough trying to keep up with the current technology in terms of mitigating the vulnerabilities as they appear let alone maintaining pace with the new ones as they hit the streets. Couple that with the fact that security is often an after thought as companies try to push out the newest tech before their competitors with little to no regard for the potential ramifications of doing so. It is up to us to work to mitigate these vulnerabilities as tech continues to evolve as well as raising user awareness along the way. Needless to say, we certainly have our work cut out for us.
Vince Kelly says
good points. I wonder how long before the ramifications of having lax IoT security begin to manifest themselves in unexpected ways – Insurance companies refusing coverage to an company because it hasn’t upgraded it’s old SCADA controllers, 4th amendment issues with a law enforcement agency hacking into a driver-less car in order to determine where a person was at a particular point in time and how long they were there?, etc, etc.
Manogna Alahari says
I agree with all the basic rules for securing IoT as posted on the website https://krebsonsecurity.com/2018/01/some-basic-rules-for-securing-your-iot-stuff/ and every software design should strictly adhere to cyber principles.
On top of that, I strongly believe any software that is being developed should be “secured from design”. What I meant by this statement? “if I were a software engineer or an architect (a long way from now), securing the software right from the design phase, would be one of my primary design principles.
From the Denial of service attack to the Dyn impacting many clients, I strongly believe that DNS servers should have taken proactive measures on such kind of vulnerabilities.
Below are few what I can think off additionally
1. SECURE FROM DESIGN – think about security right from the application design phase.
2. LOAD TESTING – DNS servers should have been tested with a high load in their lower environments (performance), to ensure they can manage heavy traffic.
3. DNS servers on CLOUD – cloud has capabilities of autoscaling when the traffic exceeds the threshold additional servers automatically spin up.
4. FAULT TOLERANCE- DNS servers should also think about fault tolerance. Automatically diverting faulty traffic or vice versa
Mustafa Aydin says
About the October 21 IoT DDoS attacks:
According to the discussion points that we talked about in last class regarding operating system security, I would like to highlight the following:
Patching
Many of the devices used in the attack were unpatched. Unpatched devices are resource of serious problems because hackers are constantly evolving their attacks by using these devices. Patching would be the important step to reduce the vulnerabilities in system and prevent any possible external attacks.
System Hardening
Another vulnerability found in many of the devices used in the 10/21 DDoS attack was default passwords. Some of the devices used in the attack had hard-coded credentials. But other devices, such as routers, allow people to change the device’s credentials. Changing login credentials would have potentially reduced the size of the DDoS attack.
Limit Services
As we learned in last class, not all services need to be enabled for a device to perform its job. In the case of the 10/21 DDoS attack, the United States Computer Emergency Readiness Team (US-CERT) recommended top four actions. One of them is disabling Universal Plug and Play (UPnP) on routers unless necessary. UPnP is a set of networking protocols that permits networked devices to seamlessly discover each other’s presence on the network and establish functional network services. Turning off the protocol reduces the risk of having router being used as part of a botnet.
Jason A Lindsley says
Nice post Mustafa – Has anyone ever tried one of the Mirai scanners that are available such as this one?
https://www.incapsula.com/mirai-scanner/
The scanner checks ports 22(ssh)/23(telnet) to see if it can connect to any IoT devices. I gave this a try, but it did not scan successfully. I got the message “a device being scanned is infected with Mirai or because there are no vulnerable ports on your devices” The support page says it is likely the latter, but I would need to restart all of my IoT devices to make sure. Restarting the devices disables Mirai’s blocking capability to enable a valid scan.
Restart all of my IoT devices?! Sounds like a weekend project!
Jason A Lindsley says
For Week 1 “In the News” I selected “IOT DDoS attack.” and I read the following:
https://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/
https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-outage/
I agree with others that a Defense in Depth approach is required to protect against the IoT DDoS attacks mentioned in these articles. This approach includes a secure perimeter and network IDS/IPS systems that would detect and block this malicious traffic. In addition, many companies use DDoS cloud mitigation services (e.g. Akamai) to inspect incoming traffic and prevent traffic that is intended to disrupt service.
When it comes to securing the OS to prevent it from becoming an agent for the BOTs such as Mirai, there are several foundational practices that you can follow to ensure that you are protected:
– Change Default Passwords – This is the most basic and effective way to defend against BOT attacks. Whatever device you place on your network, it is critical that you change the default passwords that are used by the vendor.
– Apply Patches and Firmware updates – Routinely check your devices to confirm that they are still under support by the vendor and that you have the latest patch or update installed. Also, only buy or install devices from vendors that have a reputation for strong security practices and automatic updates.
– Scan your devices – Use an vulnerability scanner (e.g. Nessus) to periodically scan your devices and detect vulnerabilities. Research any vulnerabilities that are detected to understand the risk and the ways that you can remediate or mitigate the risk. Vulnerabilities can typically be addressed through patching, configuration changes, or removing unnecessary software.
– System Hardening – Remove unnecessary services. For example, many vulnerabilities exploit the SMB service in Windows or Linux environments and often show up in scans. Since I don’t use SMB on my network for anything, I simply disabled the service and my scans were then clean. If you follow a system hardening procedure to set secure configurations, remove unnecessary services and applications, and close ports you will reduce the attack surface of your OS.
Again, there are many layers of security that should be applied to defend against these attacks, but these are very important foundational steps to securing an OS to reduce your risk of becoming an agent for IoT DDoS attacks.
Zirui You says
I would like to talk a little about the IoT DDoS Attack.
http://www.welivesecurity.com/2016/10/24/10-things-know-october-21-iot-ddos-attacks/
https://krebsonsecurity.com/2016/10/hacked-cameras-dvrs-powered-todays-massive-internet-
outage/
The rapid development of IoT makes cyber criminals happened way more often than years before. To prevent the losses from an IoT DDoS attack, people should keep learning from the occurred DDoS attacks, and the rising displayed cyber firepower. The 10 things in the news we should keep in mind, but it will never end up to the 10. There are lot more things we should discover from the broad impact of IoT, and the vulnerability of operating systems and devices. The vulnerable device is one of the most important reasons which lure the attackers targeting and embed the malware to. As the words of outside source I get, “Embedded devices are often designed to be plugged in and forgotten after a very basic setup process. Many don’t get any firmware updates or owners fail to apply them and the devices tend to only be replaced when they’ve reached the end of their lifecycle. As a result, any compromise or infection of such devices may go unnoticed by the owner and this presents a unique lure for the remote attackers.”(Symatec) Therefore, take lessons from the number of vulnerable systems and devices may benefit people in the future.
Outsources reading: https://www.symantec.com/connect/blogs/iot-devices-being-increasingly-used-ddos-attacks
BIlaal Williams says
The most important step in preventing DDOS attacks like the one that took place on 10/21/16 in my opinion is security awareness. This awareness must be adopted by both manufacturers and consumers. With the popularity of IOT devices growing at a rapid pace, more and more devices in our environment have an IP address. As the quote Avi Rubin used at the end of the Ted Talk states, “just because you can connect something to the Internet, does not mean you should.” Every device that is given access to the Internet increases the attack surface and could introduce new vulnerabilities into a network.
Manufacturers must be aware of the dangers IOT devices can bring to a network and must embed security in their production using secure SDLC which ensures that security assurance activities such as penetration testing, code review, and architecture analysis are an integral part of the development effort. Manufacturers should also be responsible for informing consumers of the risk a IOT device could bring to the consumers network environment. Much like the warning instructions included on devices to prevent physical harm, manufacturers should include warnings to inform the consumers on making their IOT devices more secure such as changing default usernames, passwords etc.
Providing consumers with information to make them security aware is much less difficult than getting them to adhere to these practices. That’s why I feel manufacturers should do as much as possible on their end to produce devices that are secure by design. As more devices get hacked, secure software engineering is becoming a necessity, manufacturers must act proactively to cyber security issues to remain competitive.
Joseph Feldman says
Topic: IoT Security
I was unaware of the scale and methods used for the attack on Dyn using unsecured IoT devices. The majority of these devices are unsecured and use factory default settings and usernames and passwords. That first thing to implement on these devices to make them more secure would be to change the default username and passwords to make them less accessible to those trying to use them maliciously. Also set permissions and limit services on the devices inbound and outbound communications and who and what they can connect with. Also a lot of these devices are still vulnerable to known exploits that have been used in past attacks. This is where patching comes in to play to make sure users devices are secured and they can configure their device with ease so that it is secure on their network and from these vulnerabilities. Another possible solution is to provide a low level type of antivirus system as these IoT devices are getting infected by malware or to use an encryption method for all incoming and outgoing data. This problem with IoT security has been gaining traction lately as more attacks have leveraged unsecured IoT devices across home networks in the US and I think this is only the beginning which is why it is important these IoT devices are set up securely with other measures to enhance or fix current security issues.
Brock Donnelly says
Sadly patches for some of these IoT devices is not possible and we will have to wait for them to “time out” in this world. Most of these devices are from lower end manufactures that are not worried with security but rather profit and cost. One of the articles I read about his from Krebs stated that the firmware from one manufacturers is not upgradable and the default password could not be changed. It is forever hackable. Time to throw it out. Enforcing a global standard might be the only future solution for prevention. As of now companies will have to look into DDoS protection.
Brock Donnelly says
Global Cybercrime Costs Top $600 Billion
https://www.darkreading.com/attacks-breaches/global-cybercrime-costs-top-$600-billion-/d/d-id/1331106
Well I don’t think you have to worry about the job sector in cyber security. As it turns out, cyber crime is costing $600 Billion, with a B, annually. This is a 20% bump since 2014 per a study by McAfee and CSIS. In another report from Cicso based on 3600 CISO interviews the average cost of an enterprise cyber victim cost $500,000 with 8% of the victims reporting cost over $5 million. The article reminds us that this is just an estimate and that victims underplay their value or fully realize the extent of their breach so this number could be even higher.
Cybercrime cost money or else why would their be an interest in it? With the increase in ransomware, cybercrime-as-a-service, Tor, Crypto currencies and other new malicious malware the need for cyber combatants is also growing. According to McAfee and CSIS, intellectual property theft accounts for at least 25% of overall cybercrime costs. Intellectual property theft is likely prevented with a little proactivity. Chief scientist at McAfee, Raj Samani:
“The net result is that many organizations continue to view cybercrime as a somewhat abstract issue. “I am constantly told ‘this does not impact me,'” “Yet cybercrime impacts every one of us.”
I found this startling:
In last year’s report, one-third of those who suffered a breach reported a revenue loss of 20%.
20% could be the end for a company on the edge of bankruptcy
Patrick DeStefano (tuc50677) says
Brock,
I like the approach you took with making the financial case for cyber security enhancements. The more knowledgable cyber criminals are becoming, the more reason for companies to invest in proper security controls to protect their assets as well as their clients/customers. That 20% revenue loss is a scary number for any company. With so much of the US economy based on small and medium size businesses, that could essentially put some companies out of business if they don’t have a large enough profit margin and just starting out.