Can we use AWS Device Farm to test anti-virus application by installing real malware on rented devices?
AWS's AUP includes the following wording:
You may not use, or facilitate or allow others to use, the Services or the AWS Site: ... to violate the security, integrity, or availability of any user, network, computer or communications system, software application, or network or computing device;
So with regards to installing malware or exposing the devices to live virus or malware payload, the answer is an unequivocal no.
However, I would imagine that as with standard EICAR test strings, you could test file contents for various pattern matches and remain within the bounds of the AUP, ie by including a substring of a particular known malicious payload to test detection. The moment you allowed known malicious code to execute you would be in violation of the AUP, and depending on AWS's inbuilt scanning they may detect and block your access proactively regardless.
So to summarize, the answer is no, you'd need to build your own lab on your own equipment to do testing of this nature.
Related
I'm thinking about creating EC2 instances that run industrial software. This EC2 instance should be able to receive data from Serial COM port. Is it possible to connect things like this, with eventually a serial tunneling or anything else ?
There are two parts to the answer to this question.
Yes, absolutely, this is possible in theory.
...but it might not be practical or possible for the specific purpose/application/device that you have in mind.
Terminal servers are a simple illustration of the principle. Note that in this sense, I'm not referring to a Windows Remote Desktop "terminal server," but to the generic device commonly called a terminal server which, in its simplest form, is a physical device that speaks a serial protocol such as RS-232 on one side, and TCP on the other side. RS-232 is the wire protocol of a PC "COM" port.
But a computer, configured with appropriate drivers, can have a "virtual" COM port that appears -- to software on the computer -- as an interface just like a physical COM port, but the driver for that COM port, instead of providing the software with access to literal hardware is in fact managing a TCP connection, tunneling the send and receive bits from the COM port back to the physical port on the terminal server.
The terminal server could be an actual, dedicated terminal server device, could be a full size PC, a microcontroller with network capability, a Raspberry Pi with a USB-to-Serial adapter... there are a lot of potential variations.
Problems to consider:
A lot of older industrial software seems very poorly written. This is my impression, anyway. The implementers, perhaps working at the edges of their expertise, having made certain design assumptions that work on physical COM ports but may not be compatible with such a deployment. This is less likely to be true if the systems are newer, and run on a modern OS, but back in the early days of Windows and before, this was a real mess.
License key dongles, if present, might rely on peculiarities of physical COM ports that are difficult or impossible to virtualize. The terms of the software license may constrain you from doing this.
Some equipment may be unnecessarily sensitive to the delay that is introduced by the distances involved. There are, for example, 22 ms of round-trip time in the Internet path between one of my facilities and the nearest AWS region. At 9600-8-N-1 that is the time to transmit ~23 bytes, and that's best case -- the virtualization layer and encryption will add more. The machine or the software may or may not be well-written enough to accept that kind of delay, which does not occur on a physical, local COM port.
If the machine is being controlled (not simply observed) then you need to absolutely ensure that you are not creating a safety hazard by separating the machine from its software through a virtualization layer.
"Sharing" control of a machine by software on multiple EC2 instances seems like it might be implied by your illustration, but this potentially adds an entirely different set of complexity.
In theory, yes, it's possible. I mean, even Windows remote desktop allows you to share a local COM port with the remote system, allowing remote software to access and control your local device.
In practice, this potentially requires a lot of attention to a large number of factors that vary by operating system as well as by the specific peculiarities of the devices and software in question.
EC2 connectivity is through the network interface, so I don't think a direct connection like the one you are asking is possible.
However, if you are talking about industrial devices supporting automation, chances are you can use MQTT or at least a MQTT bridge. If that's the case, you can take a look at AWS IOT Core
With AWS IOT Core you don't only get bidirectional connectivity between your devices and AWS, but also powerful analytics, device registry and management, and full integration with the AWS ecosystem.
I am a newbie to AWS and cloud computing in general, so I apologize if this question is foolish.
I am currently working on developing an app for Amazon Echo that would allow it to remotely control a PC (i.e. change volume, pause a movie, etc.). My problem is that I do not know how to communicate between my Amazon Lambda service and my Windows Application.
Any ideas?
There are potentially some problems with the way you have posed the question -- how to communicate between a Lambda Function and a Windows machine could involve a number of different solutions, but what you are looking for (as far as I can tell) is a more specific -- yet simultaneously more generalizable -- solution.
Are you trying to actually make an Alexa skill that users could use, or just something for yourself? It makes a big difference, because for just yourself there are a number of hacky solutions you could implement, like port forwarding and dynamic DNS, which fail dramatically if you try to do them in the real world. You need another component -- some kind of real-time push messaging -- that bridges between an "agent" in your Windows app and requests emitted by your Lambda code.
Your actual problem to solve is not so much how to communicate between AWS Lambda and a Windows Application, but rather one of a need for understanding how a platform like Alexa needs to communicate with a "smart home" device, specifically an entertainment device.
It is a relatively complicated undertaking, because -- fundamentally -- there is no way of communicating directly between Lambda and an arbitrary device out on the Internet. Dynamic IP addresses, network address translation (NAT), firewalls, security considerations, and other factors make it impossible to reliably initiate a connection from a Lambda function (or indeed from any Internet connected device) to any other arbitrary destination device. Most devices (my phone, my Alexa-controlled light switch, my Windows laptop) are running behind a boundary that assumes requests are initiated behind the boundary. When I open web sites, stream video, etc., I initiate the request and the response returns on the channel (often a TCP connection) that I have created, from behind my boundary (e.g. the router in my cable modem) that doesn't allow external initiation of TCP connections. They are bidirectional once established, but must be initiated from inside.
Of course, you can statically "poke a hole" in your router configuration by forwarding a specific TCP port to a specific internal (usually private) IP address, which works as long as your Internet provider doesn't change your IP address, and your internal device doesn't get a new IP address... and there'a UPnP NAT Traversal, which seems like a good solution until you realize that it is also terrible (though for a "hobbyist" application, it could work).
While this is a long and complex topic, the short answer is that Alexa, via Lambda code, is only capable of initiating connections, and your device, wherever it may be, is only capable of initiating connections -- not receiving them... and thus you need some kind of "meet in the middle" solution: something that allows the device to maintain its "connection" to a central "service" that can coordinate the interactions on demand.
For example:
AWS IoT Core is a managed cloud platform that lets connected devices easily and securely interact with cloud applications and other devices. AWS IoT Core can support billions of devices and trillions of messages, and can process and route those messages to AWS endpoints and to other devices reliably and securely. With AWS IoT Core, your applications can keep track of and communicate with all your devices, all the time, even when they aren’t connected.
https://aws.amazon.com/iot-core/
The client initiates the connection (e.g. via a web socket) to the IoT platform, and maintains it, so that when a message arrives at IoT, the service knows how to deliver that message to the client when it's received. ("even when they aren't online" refers to the "device shadow" capability, which allows you to programmatically interact with a proxy for the device, e.g. knowing the last temperature setting of a thermostat, and asking the thermostat to change its set point when the connection is re-established at some future point).
Or, potentially something like this:
Firebase Cloud Messaging (FCM) is a cross-platform messaging solution that lets you reliably deliver messages at no cost.
Using FCM, you can notify a client app that new email or other data is available to sync.
https://firebase.google.com/docs/cloud-messaging/
Both of these potential solutions solve the problem by "knowing how to contact" arbitrary devices, wherever they may be... and I would suggest that this is the core of your actual need.
There are a lot of alternatives for such a "service," including roll-your-own websocket or HTML EventSource implementations with servers... the purpose of this is not product recommendations but rather to give you an idea of what you would need for such a scenario -- an intermediate platform that can be interacted with by the Lambda code, which also knows how to communicate with "agent" code running on the device... because both Lambda and the agent need to initiate the communication channels and thus additional components are required to bridge them together.
We're trying to set up a Windows Continuous Integration server in the cloud that has software with a particularly difficult licensing scheme (a certain embedded software compiler). This compiler either lets the user run with a dongle, or node locks the software to run on a specific set of hardware. Seeing as how we can't exactly ship off a dongle to Amazon to plug in to our machine for us, we want to use the node locked licensing scheme with this software.
However, in order for this license to remain valid, my EC2 instance needs to have a set of "static" hardware IDs. We don't actually know which hardware IDs this software will look for (and they won't tell us), but I'd like to know which hardware IDs I should expect to change with instance restarts, and which hardware IDs, if any, I can lock down through proper configuration of my EC2 instance.
For example, I already know that I can lock down the MAC address of the Network Interface using Amazon's Elastic Network Interface (ENI). Is there any other configuration I can do, or need to do, in order to get a set of static hardware IDs?
We have never transmitted, processed or stored credit card information in the past as we did everything via PayPal so we never needed to be PCI compliant.
However, we are launching a new online store and by having a seamless checkout where credit card information in processed without redirected to PayPal, we need PCI compliance now.
We are going to consult a Qualified Security Assessor Company to guide us through getting and maintaining PCI compliance. However, I wanted to get a decent idea of what i'm looking at before consulting them, before they try to sell you every service in the house that you may not need.
In terms of PCI compliance, I understand it needs to be done on the software and hardware level and meet the 12 points + required. We are going with Magento Professional as it has a PCI compliant payment system, and we are going with a PCI compliant web hosting company (dedicated server). But in terms of software, do you need PCI compliance on EVERYTHING? Or just the software that transmits, store and processes credit card information?
For example, according to Magento, the Payment Software is PCI compliant, while the Magento Platform is not. So this allows you to make changes, modifications and customisations to Magento without affecting the PCI compliance of the payment software.
In other words, i'm asking, do you only need PCI compliance on the source code/software that deals with transmitting, processing and storing credit card information? These 'Qualified Security Assessor Companies' give the impression that all source code needs to be checked for PCI compliance, which is impossible!
For example, in the case of Magento, can I make changes and modifications to it and still remain PCI compliant? So long as the payment module is untouched since it is PCI compliant and the web hosting, server and OS is PCI compliant?
I mean the php, javascript, mysql stuff that does not deal with credit cards don't need to be compliant do they? they will be on the same server of course.
The basic answer is that it depends. In general, only the source code that deals (or can deal) with the sensitive and protected data of PCI needs to be PCI compliant. However, this means that if other areas of your code have access into the secure areas, you need security there as well. If another area of your application were to be vulnerable to SQL injection, for instance, it might compromise your credit card systems. That is why some people will lean towards PCI compliance for all software. There has to be some assurance that a poorly-written piece of software can be exploited to compromise the safety of the data.
I say it depends because there is always some room for interpretation by those doing the inspection. However, the good news is that of all the standards, PCI seems to be the most direct and specific about what you need to do and what you cannot do. Here is more information about what PCI says directly:
https://www.pcisecuritystandards.org/documents/infosupp_6_6_applicationfirewalls_codereviews.pdf
The basic issue here is to be sure that the site cannot be exploited anywhere. If you develop sufficient "firewalls" between your application areas (credit card data versus normal website), it will go a long way towards showing that you only need to scan some code. Also, as the above document states, you don't have to do a source code review in order to be PCI compliant. However, your application needs to be extensively tested to be sure it is safe from typical vulnerabilities.
I can't speak to the legal details of PCI compliance, but if I were an auditor of your system I would squawk very loudly if any non-certified code runs as the same userid that runs the certified code.
I'd also look pretty closely at what setuid/setgid executables are on the system, what runs as root or with elevated capabilities(7) that could influence the PCI-compliant software, and I'd probably demand mandatory access control tools such as AppArmor, SElinux, TOMOYO, or SMACK, and an appropriate configuration that prevents tampering with the PCI-compliant portions of the server by untrusted execution domains.
What would be the simplest way for an application I'm writing to block all Internet access on a Windows machine?
More details:
Windows: XP or higher
Application: A basic Win32 app written in C/C++.
Blocking: It needs to be able to block and unblock at will, ideally in a way that the user can't easily reverse. (By, say, right clicking on a network connection icon in the system tray.) Also, ideally, I'd like the method it uses to allow access to be restored should the user restart Windows or reset the machine, though I'd also be willing to have the app auto launch with Windows and unblock access upon startup if the machine was reset while in a blocked state.
Internet access: Primarily, I'd like to block conventional browsers from hitting conventional http/https sites. Secondarily, it would be nice to block IM clients and client-side social networking apps. It would also be nice, but not required, to still allow local networking for file sharing, etc. (Note that only the first requirement is absolute.)
Final notes: This is not meant to be a security utility, nor will its relationship to the user be adversarial (as, for example, with a parental control utility) so it's not important for it to use a scheme that can't be worked around by a determined user. (Consider that I intend for a reboot or reset to clear the blocking. This means that any workaround a user might discover that would take more effort than this is okay.)
Thanks!
p.s. I suspect that the Windows Firewall API won't work for me because this needs to work for users that haven't enabled the firewall or don't have admin privileges, but I'll be thrilled if I'm corrected on this.
It sounds like you're intending to run applications that you don't want to access the internet. Perhaps you could run them inside a virtual machine such as VirtualBox with networking disabled.
You could do it with a Winsock SPI. The Windows SDK has a sample (under Samples\netds\winsock\lsp) which implements what is called a layered service provider which allows you to hook all the user mode functions provided by Winsock and reject/modify the calls to block network access or redirect traffic to different locations. All installed winsock applications will be affected, so in your code you could have policys for what applications can go out and the like and disabled/enable on the fly. Now a determined person could find ways around this but it would be a pain.
That said this isn't trivial to do but the sample should get you most of the way there.
You cannot effectively or practically write your tool with only a user mode application.
What you need to write is a network I/O stack filter driver. This done by writing a Windows Driver. This is different from a Windows Win32 application. Drivers run in kernel mode and applications run in user mode.
On Windows Vista and later, the kernel mode Network Programming Interface (NPI) is designed for this. This is the same API that Windows Firewalls use. These are sometimes called the Winsock kernel (WSK) APIs.
In effect, you are writing a network firewall (more or less)
here are some links
Introduction to Winsock Kernel (WSK)
Windows Core Networking Blog
The Network Programming Interface Docs on MSDN
Note, your will likely need at least two components
Your driver
A Graphical application that a person can use to control your tool
If you want to do any monitoring, you will likely need a user mode service that collects data from your driver. This works better than trying to do this in the driver. In general, you should do the minimal amount of work in the driver.
A few notes:
You need to be very conscious of security when writing this kind of software. This is very much non trivial. Software that is network facing has the highest security requirements.
Be cognizant of performance.
Your driver and/or service must be aware of the context of a calling application. This is also a security boundary. For example, an application not running as administrator should not be able to control your driver.
take a look at firewall sourcecodes