Why am I receiving HTTP GETs for a domain I don't own? I am running a Centos7 web server. I noticed a few strange HTTP GET requests like these:

94.185.83.100 - - [29/Feb/2016:23:29:00 +0530] "GET http://testp1.piwo.pila.pl/testproxy.php HTTP/1.1" 404 390 "-" "Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/31.0"
185.25.151.159 - - [01/Mar/2016:07:36:40 +0530] "GET http://testp1.piwo.pila.pl/testproxy.php HTTP/1.1" 404 390 "-" "Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/31.0"

I have no connection to the domain piwo.pila.pl. How did it end up in my Apache access_log?
In the error_log document, the same document is given under my web root, i.e.: [Mon Feb 29 23:29:00.175813 2016] [:error] [pid 11382] [client 94.185.83.100:43718] script 'myWebRoot/testproxy.php' not found or unable to stat
Is this expected behavior? That the access_log keeps a record of the exact request while the error_log tracks the same request but translated to a URL on the file system?

Your website has been hit by an automated script that looks for open proxies on the internet. The url it's trying to access would record a successful proxied request and add your server to a list.


How Does Telegram's Identity Verification Work? Note: please refrain from commenting on Telegram's design of OTHER parts, as it will distract from the stem of the question.

Background:

Signal (Previously, "TextSecure" app) uses specific "Your identity / Their identity" type of verification to verify a secure channel.

Telegram, on the other hand, displays a picture of pixel-like array with different colors and a set of alpha-numeric characters under it, different from each secure channel (i.e. "Secret Chat"); if these pictures or alpha-numeric characters match on both ends of the parties' phones, then the Secret Chat is "200% secure" [sic].

QUESTION:

In Telegram, how is the verification picture generated? What makes it secure? And what makes MITM on key exchange "200%" impossible when that picture is matching on each phone?

Merit of question:

Signal clearly displays the fingerprint of my own key (which I have on my own phone) making this very sensible, as if it matched what THEY saw as my fingerprint, then it's physically and technically impossible that a MITM happened.

What in Telegram's design ensures this same outcome as with Signal?

UPDATE:

This question needs an answer as, indeed, now even Whatsapp (using "TextSecure" encryption protocol) displays ONE set of numbers that has to be matched on both ends of the conversing parties.

WhatsApp derives the QR code (and the numerical representation) from the user identifier and the 32-byte public Identity Key of both parties. I guess that some deterministic algorithm decides, witch of the two identifiers comes first (e.g. they could be sorted lexically).

This allows both clients to display the same image and numerical representation, whilst providing the same security as for example Signal, where both fingerprints are displayed individually.

Telegram uses a slightly different approach, because it computes a new secret chat key for each new secret chat (even if you are already participating in an active secret chat with the same person). Therefore, every secret chat with the same person should display a different 2D code and in my understanding it should also frequently change.
This is due to the fact that the secret chat key is computed using Diffi-Hellman and is regenerated every 100 messages or at least every week, to provide some sort of forward secrecy.
Both participants of the secret chat should see the same 2D code (which is some sort of graphical visualization of the secret chat key), since the secret chat key is a shared secret between both participants.

I am not completely certain about the Telegram part, because I don't use Telegram myself.

The information is taken from the WhatsApp security white paper (April 2016) [1, page 8] and the Telegram API documentation [2].

[1] https://www.whatsapp.com/security/WhatsApp-Security-Whitepaper.pdf

[2] https://core.telegram.org/api/end-to-end


Security of online storage of KeePass-like files A common advice for storing passwords is to store them into an encrypted file, for example by using a dedicated software such as KeePass2. To keep this file in sync between several computers, the advice goes, the file is put on an online storage such as Dropbox. I have seen this solution proposed many times as an alternative to using browser plugins such as LastPass -- and perhaps is it indeed a superior solution.

In this scenario, I think, the online storage itself is not considered secured -- it is supposed to be either hackable, or itself actively eavesdropping.

Yet from what I understand from some answers read here, it is not safe to encrypt several files with the same key. And of course, a file containing passwords is deemed to be updated regularly.

So my question is, should we consider that having access to a (large) history of an encrypted file when this file is encrypted with the same key is a security flaw? Is this a general rule or are there encryption algorithms for which this is not that a problem? What about KeePass(2) more specifically and what to think about the advice above about online storage of kdbx files?

it is not safe to encrypt several files with the same key

This statement isn't fully true.
It is indeed not a good practice to encrypt many files using the same (data) key, but it is still absolutely acceptable, as modern ciphers resist attacks even if gigantic amounts of data encrypted with the same key are provided (whole drives aren't enough).
What can get wrong with encrypting multiple file with the same piece of data is to re-use the IV, which will indeed lead to severe attacks.

  So my question is, should we consider that having access to a (large)
  history of an encrypted file when this file is encrypted with the same
  key is a security flaw?

No.
If your password is strong enough, KeePass does an excellent job at protecting the database. The above IV flaw is mitigated by KeePas by simply renewing the IV each time the database is saved. Hence the passwords are safe, no matter how many versions are available.
In general: Key reuse is only an issue if you think you may loose the key. IV reuse is much worse but can easily mitigated, which is often done.

  Is this a general rule or are there encryption algorithms for which
  this is not that a problem?

This is a general rule (that ciphers are immune to such attacks), which is only violated by really bad ciphers, which can be attacked by having enough known plaintext (look at FEAL for example).

  What about KeePass(2) more specifically and what to think about the
  advice above about online storage of kdbx files?

As far as I can tell KeePass is really secure and protects database effectively. Storing the kdbx files online isn't a security risk, as the password protects the database and it prevents you from actually loosing the database.


Modify Javascript Variable with URL Exploit Is it possible to set a javascript variable through the URL?

Here's an example of the code I'm trying to modify:

<script type="text/javascript">

var x = 0;

</script>

Is there a way to modify that variable through a browser, for instance, www.somewebsite.com + (something that changes 'x' variable)?

Related on Stack Exchange:https://stackoverflow.com/questions/39023761/modify-javascript-variable-with-url

No, this is not possible without an XSS vulnerability. If such a thing were generally possible, XSS would run rampant and you could execute any arbitrary code on any page, which would be bad.

Now if the code had a reflected XSS attack vector, or an DOM-based XSS attack vector, the the URL could be used to deliver a JavaScript payload. Of course, this would only be possible if the server-side or JavaScript code had such a security vulnerability (if your code makes that possible, then you should fix it).


Can a file .exe.part already have caused damage? If on a Windows machine, an antivirus program has found a Win32:Rootkit in a file ...\Temp\...\xy.exe.part, could the file possibly already have caused damage or not given that it seems to be an "incomplete" file?

I'll agree with @Adnan but I will make a bit longer answer just to explain you what can happen and what is not possible.

Short answer is no.

Long answer, no, but maybe. As you may know, the *.exe.part is un-executable until renamed to executable PE (exe, cpl etc.). Try it out. Create a new file on desktop called "test" and change files extension to .exe.part. Now try to run it. Is it executed? I don't think so. It will ask you for software you want to run or open the file with.

Considering above, you are safe but there still might be chances to cause a damage to a system in next case. If connection is established, an attacker maybe already compromised the system with another malware which will hook the process of downloading and rename the file to *.exe. If file is successfully renamed, it will execute the same. Note that this may not be possible because .exe.part did not finish full structure of PE file (it's still in downloading process) plus you were saying something about anti-virus that will detect the infection while downloading. The chances of happening this to someone are pretty low. The only generic trojan that could do something like this is probably Carberp and attacker would not execute this type of action as most of trojans and malwares already offer hidden UrlDownloadToFile function which downloads file with out your knowledge of specific action.

As written above, you safe but there is always a way of security disclosure.


Is it possible to determine if the BIOS has been modified between two points in time? Is it possible to determine if the BIOS of a computer has been modified between two points in time from that computer while it's running ?

Effectively I'd like to be able to gather the equivalent of cryptographic hash snapshots of the BIOS (or as much as I can) via the local host operating system (ideally an answer for Linux would be great but any would work) or via something like IPMI without rebooting the computer.

I know there's also an issue of not being able to trust the computer itself but I'm just looking for basic functionality.

Note: I'm not looking to prove that the computer wasn't shipped with an infected BIOS or anything just that no new changes have occurred between something like 1pm and 3pm.

If your board is compatible you should be able to use flashrom with the -r arg to backup the bios to a file. You can then use md5, sha256, etc to grab a hash which can later be compared.

//baseline.sh
//first make your baseline bios checksum with
flashrom -r ./bios.bios
sha256sum bios.bios > bios.checksum

//check.sh
//now periodically check again
flashrom -r ./bios.bios
sha256sum bios.checksum -c
//if your output looks like "bios.bios: FAILED" you have a problem.


Is it insecure to provide a hash of an AES password? I have made some software that encrypts and decrypts files using AES. I was wondering if it is safe to write a hash of the password to the file so that the program can check if a password is correct. The reason I am worried about this is because, without the hash, for a file that takes ten seconds to decrypt, one million attempts at cracking the encryption take ~115 days. Whereas, with the hash, regardless of the size of the file, one million attempts will take roughly 5 days if one attempt takes 0.5 seconds (much more than reality). This is a huge difference, hence my concern: Is it less secure to write the hash of an encrypted file's password to the file?

For password-based encryption, you need to:

transform the password into a key suitable for the encryption algorithm (a process called key derivation);
use that key to encrypt the file.

Assuming that everything about the encryption phase was done properly, and the used algorithm is not weak, then the most direct attack route is the password: the attacker will try potential passwords, applying key derivation then decryption, to see if the result "makes sense". The important point here is that the attacker does not need to decrypt the whole file to see if it looks like the expected cleartext or not; for instance, if the attacker infers that the file is a JPEG picture, then he just needs to decrypt the first four bytes to see if these yield the expected starter sequence for such a file (FF D8 FF E0). Even if the honest user wants the complete file, and thus will need to decrypt it whole (implying I/O for reading the file and writing it back), the attacker is in no way constrained to do the same during his attack.

Therefore, you MUST NOT assume that the whole-file decryption speed makes the attack slower or faster. In that sense, providing a "fast" test for password correctness will not make things easier for the attacker either.

However...

You must take care to do things correctly. First and foremost, the easiest way to design a secure format for password-based file encryption is to use an existing format for password-based file encryption, that has already been designed, analysed, implemented and tested. A reasonable candidate is then OpenPGP, and (in particular) its open-source implementation GnuPG.

If you still insist on doing your own design and then implementation, then you must understand that the core of your security will reside in the key derivation process, also called password hashing. There is a lot of theory and practice on the subject, so I suggest you start by reading this answer.

Now, if you got your password hashing right, with all the iterations and the random salts, then you could envision a process where the password is derived into a key K of, say, 256 bits (32 bytes). Then split that key into two halves K1 and K2 (128 bits each). Add a copy of K1 into the encrypted file header, to test for password correctness; and use K2 (not K1 !) for actually encrypting the file. This is safe as long as the password-based key derivation function is secure as a key derivation function.

Of course, if you need encryption, then (presumably) there are attackers, and attackers are, on the whole, known to be naughty. They don't play by the rules. Most notably, if they can see encrypted files, then chances are that they can modify encrypted files. To reliably detect such modifications, you will need a MAC, and then things become complex. Potential for catastrophic design error is high.


How to review code for backdoors? I have a codebase that needs a code review to evaluate it for backdoors.

The code is far too big to review it all, how would you recommend approaching the problem.

It is a java web application with an oracle database, the code is customized from a product that is exceedingly large.

The customizations cover almost all of the codebase, but I can identify the customised code automatically.

The bottom line: You are screwed.  If you are concerned that one of the developers deliberately hid a backdoor in that codebase, you have no realistic hope of telling whether a backdoor is present.  Life sucks.

Comment: Some folks here are suggesting you can check for a backdoor by reviewing the code, or using static analysis tools, or somesuch.  Don't believe it.  They are fooling themselves if they think that this is likely to detect a deliberately hidden backdoor.  In my opinion, those answers are overly optimistic and are likely to give you a false sense of security.  (I know I'm going to make myself unpopular by saying this and dissing other commentators, but I feel a responsibility to give you my honest, frank advice.)

Advice and mitigations: As for what you should do, I think you need to tell us more about the function of that piece of software, how it relates to your business, and what are the consequences if it does have a backdoor.  Here are some generic mitigations you could consider, which might or might not be relevant to you, depending upon the circumstances:

Risk transfer. Require the supplier to provide a warranty that the code is free of backdoors, with major financial penalty clauses if any are found.  (Note that, if a backdoor is present, the chances are finding it are pretty low, so the penalties if one is found have to be increased proportionally to the inverse of the probability of detecting it.)
Isolation. You could try to isolate the effect of a backdoor, so that it can only affect the functioning of this piece of software and has limited opportunity to attack other systems of yours.  You could run it in a virtual machine, firewall it off from your networks, etc.  You could potentially also firewall it off from the network, to make it harder for a bad guy to activate the backdoor.
Monitoring. In some cases, it may be possible to perform external monitoring to detect illicit activity.  For instance, in a slot-machine joint, you could monitor the amount of money taken in, the amount paid out, and statistically, those two should bear a strong relationship; if you see pay-outs that exceed the expected amount by over five standard deviations, that might be a good reason to get concerned.  As another example, at a bank, you may be able to use double-entry book-keeping and track some aggregate metrics, such as the rate of consumer complaints and how often consumers dispute charges.  These kinds of monitoring techniques are highly specific to your particular business, but can potentially be effective at detecting shenanigans.

Keep in mind that none of these are likely to provide a really good defense against deliberate backdoors, and they may or may not be applicable in any particular situation, but if you're lucky, they might be better than nothing.


buffer overflow attack scripts I saw various different scripts for a buffer overflow attack. Many of the scripts include lines that look like this:

char code[] =
"\xdb\xd7\xd9\x74\x24\xf4\xb8\x79\xc4\x64\xb7\x33\xc9\xb1\x38"
"\x5d\x83\xc5\x04\x31\x45\x13\x03\x3c\xd7\x86\x42\x42\x3f\xcf"

This one is from the CastRipper [.m3u] 2.9.6 stack buffer overflow exploit. Can someone explain what this bit is? And what exactly it's doing?

It looks like Linux header files I've seen on forensic tools.

It's actually byte code.

  Bytecode, also known as p-code (portable code), is a form of
  instruction set designed for efficient execution by a software
  interpreter. Unlike human-readable source code, bytecodes are compact
  numeric codes, constants, and references (normally numeric addresses)
  which encode the result of parsing and semantic analysis of things
  like type, scope, and nesting depths of program objects. They
  therefore allow much better performance than direct interpretation of
  source code.

It's a compiled program which is made out of instructions the CPU directly understands. It's often used to exploit vulnerabilities by making the vulnerable running program execute this program by overflowing it's buffer and making the return address the address which is the first instruction of the byte code program. Often you try to spawn an interactive shell with, in this case it's called shellcode.

  In computer security, a shellcode is a small piece of code used as the
  payload in the exploitation of a software vulnerability. It is called
  "shellcode" because it typically starts a command shell from which the
  attacker can control the compromised machine, but any piece of code
  that performs a similar task can be called shellcode. Because the
  function of a payload is not limited to merely spawning a shell, some
  have suggested that the name shellcode is insufficient.1 However,
  attempts at replacing the term have not gained wide acceptance.
  Shellcode is commonly written in machine code.

There's a good book about the subject named the Shellcoder's Manual.


Defeating Browser Fingerprinting by spoofing the browser user agent and VPN I don't want any website to identify me and to know what is my geographical location.

As far as a website is concerned, I am always a new visitor  who never visits it prior. If I leave the website, power down my browser, restart the browser and then come back, then I am a new visitor, not a returning one.

A way to do this is to go online only on a clean FF/Chrome browser inside a bland Windows 7 VM, but this seems to me quite heavy-handed.

From what I know, I will need to at least been able to spoof/hide these information from the websites:

User Agent
HTTP_ACCEPT Headers
Browser Plugins
Time Zone
Screen Size and Color Depth
System Fonts
Supercookies
HTML5 Canvas Fingerprinting

Is there any other information that I should hold away from the websites?

I am thinking using Firefox Private Mode, inside a VPN tunnel with randomized IP when I do my browsing. To defeat browser fingerprinting, I will install a agent spoofer plugin. True, websites know that I am using this plugin, and they might even get suspicious, but I am still a new visitor every time I return to them, and there is no way for them to identify me as one single unique visitor.

Is my technique solid enough for me to remain anonymous to the websites that are most zealous about collecting personal data, and are as mighty as Google or Amazon or Facebook?

If no, what are the other measures that will work?

Tor could be a solution for you, if you could compromise some of the browsing speed.

Tor tries to implement many countermeasures for your anonymity theft.
I would recommend that just using Tor is not enough please read the Tor FAQ for further details.

Update:
Apart from that I would say you have to change your browsing habits too in order to stay anonymous! This is what Tor also says.

Tor normally discourages visiting websites that has lot of active contents. For eg: Video streaming websites like youtube. The reason for this can be understood by reading the FAQ of Tor stated as below:

  active content, such as Java, Javascript, Adobe Flash, Adobe
  Shockwave, QuickTime, RealAudio, ActiveX controls, and VBScript, are
  binary applications. These binary applications run as your user
  account with your permissions in your operating system. This means
  these applications can access anything that your user account can
  access. Some of these technologies, such as Java and Adobe Flash for
  instance, run in what is known as a virtual machine. This virtual
  machine may have the ability to ignore your configured proxy settings,
  and therefore bypass Tor and share information directly to other sites
  on the Internet. The virtual machine may be able to store data, such
  as cookies, completely separate from your browser or operating system
  data stores. Therefore, these technologies must be disabled in your
  browser to use Tor safely.


How can we revoke all ssl certificates issued for our domain? After having the hostmaster@domain.com email compromised, we found that someone issued a

Domain Validated SSL certificate for our domain.
Now we want to have all such certificates revoked.

Is there a way to find all certificates issued to our domain by different SSL providers?

Partly solving the underlying problem, you may use Public-Key-Pins header to restrict which certificates are valid for your domain (so a stolen certificate could only be used by a man-in-the-middle if used on the first connection to your site).

You can also use Public-Key-Pins-Report-Only to get notifications for failed Pin validation.

Both headers are defined in draft-ietf-websec-key-pinning.

I'm afraid that for actually figuring if the attacker requested more certificates, you would indeed have to ask all CAs (it would make for a great blog post if you really go this route, though).


Replace hashed password by public key generated from password I don't like my server having access to plaintext passwords. Instead of SRP, OPAQUE or another PAKE that needs several rounds, I was thinking I could take the username, server url and password, run a hardened hash like scrypt and generate a private/public key pair.
When registering the account, the client send the public key to the server, which stores it in lieu of the salted hashed hardened password verifier.
When doing a new (HTTPS) request, the client takes the current time and signs it with the private key it can regenerate.  The server checks that the signed time in the request is close to its current time, similar to aws checking HMACs.
Maybe the generated key pair could even work as a client certificate.
Am I missing something?

In theory, this is certainly possible - see this answer about doing the key generation. However, bear in mind that you're going to have to do all of this (hashing and key generation) on the client, which has several undesirable characteristics:

It's done in JS, which is slower than native code even on modern JIT-compiled engines, and you're doing two different things (password hashing and key pair generation) that are already slow.
It needs to work exactly the same on each client, and there's no standard JS API for generating a key pair from a given high-entropy seed (or for executing scrypt, for that matter), so you're going to have to supply all the relevant JS code yourself (and ensure it works correctly on all browsers that you support, with polyfills if needed for any library functions) rather than just calling a built-in API.
Since the hashing is done pre-auth, there's no secure way for the server to supply a salt (that an attacker couldn't get), so you're stuck with salts that might be unique (like username/email address) but are not secret and thus the password hashes can be pre-computed for users of interest. (On the plus side, the extra step of generating a key pair from this hash output provides an additional time cost against brute-forcing attacks).

So, all of this is possible. It is arguably a bit of a hack; there's no inherent browser support for what you're trying (even when it was recommended, the <keygen> element didn't allow supplying the seed entropy, and the built-in JS crypto API doesn't support that either) and you're kind of re-inventing public-key auth in a slightly weird way (using passwords for client-side key re-derivation, rather than just moving around a client certificate+private key). It doesn't add a lot of security either, as the scripts that do all this hashing and deriving and signing are going to be served by the server so an attacker with access to the server could slightly modify the scripts to steal the passwords/keys anyhow. But it could be done.
EDIT: You tagged this question "web-application" and referred to HTTPS, so I assumed your client was running in a browser. For a thick client, this is much less of an issue; not only do you have a much richer (and usually more performant and better-defined) API to draw upon, it's harder to surreptitiously serve the user maliciously modified code.


chrome app (javascript) - storing encryption password in memory I'm building a chrome app that encrypts user messages on the client.
The encryption is performed using the forge js library.

I want to ask for the encryption password once, and use it to encrypt all messages in that session.
I have no user management.

Currently I'm storing the password as cleartext in a js variable, which is visible to anyone who opens the Developer Tools.

What's a better way to store the password for the duration of the chrome app being open?

Have a look at this answer. What follows from the answer is the variable stored by your chrome app cannot be accessed by any other page without changing this yourself - everything produces by your app is stored in its own environment. This is applicable to both variables and data storage.

This implies that your app would be as safe as Chrome's environment, which is likely to be the best you can get.

Regarding the password showing up in your browser's Dev Tools: this behaviour is inescapable, as you are using JavaScript for encryption which requires you to at some point load the password as a variable. You could of course try to conceal the password by applying a one-time pad on the password. In this scenario you would store the one-time pad and the encrypted password as variables; the original password can be derived using those two variables. Note that this doesn't make the way you store the password any safer, it solely hides it for the human eye.


How to execute a command directly on the host system through docker.sock in a Docker container? I've been studying Docker security and examining ways of escaping from container to host.

Suppose Docker sock (docker.sock) is mounted into the container at /var/run/docker.sock, so that Docker client (docker) can send commands to Docker daemon (dockerd).

To execute commands on the host, I could run another container and mount /etc/ into it (read-write) to schedule CRON jobs; is it possible to mount /etc/ into the current container?

What other methods are there for executing commands on the host through docker.sock?

The best way that I've found to execute commands on the underlying host with an exposed Docker socket is Ian Miell's most pointless docker command ever

The command looks like this :-

docker run -ti
    --privileged
    --net=host --pid=host --ipc=host
    --volume /:/host
    busybox
    chroot /host

and will essentially drop you straight into a full root shell on the underlying host.

To break the command down

--privileged will remove the default Docker security layers like Apparmor and capability restrictions.

--net=host --pid=host --ipc=host runs the process in the host's namespaces instead of a separate set of namespaces for the contained process.

--volume /:/host mounts the host root filesystems as /host inside the container

then

chroot /host as a command changes the root to that /host directory.

If you're running via Kubernetes, you can use The most pointless Kubernetes command which effectively does the same thing (assuming the cluster doesn't have a restrictive Pod Security Policy in place).


Minimum credential for WMI parameters Monitoring? I'm developing a big project to monitor a remote machine's performance parameters like CPU, memory, disk space, and etc. through C# WMI. I want to use the minimum possible credentials to connect the remote machines since I don't want to bother my client to ask for the superuser credentials. While it is true that if I disabled the firewall, and used an account with Administrator privileges, WMI would work fine. However, this would greatly increase my threat profile.

So, my main question is what is the minimum system vulnerabilities that we can expose for the remote machine for such monitoring?

WMI sits on top of DCOM which sits on top of RPC.  So you'll have to expose the Windows RPC ports, which is a non-starter if you're trying to monitor servers across the Internet -- nobody should expose those.

But assuming you're monitoring across a LAN, then you'll need whatever DCOM rights are necessary on that machine, and then enable WMI for remote queries (which I think can be any account).  As far as I know though, remote WMI queries are disabled by default, so your users will have to get their hands dirty.  There is a little FAQ about that here:
http://www.poweradmin.com/help/enableWMI.aspx


Laptop camera app permissions I have a laptop with Windows 10. If I go on settings and then privacy there is a list of apps with the information about their permission to use my camera (I'm talking about the built-in camera, not an external device). If I disable all of them then should I be secure about the fact that there is no way someone is spying on me? If not, what could I do?

There are 2 levels of access

Software:
The only thing that the Windows 10 Privacy settings protect against are the Windows   API calls for Webcam.
So if you only use official microsoft apps and or apps from the windows store you are indeed safe from abuse (they all utilize UWP that uses sandboxing and in there you need to use the tools that also show up under the privacy settings of windows).

If you use any Virtualization / custom build / non-store applications than all of those could utilize the low level syscalls to talk with the camera directly bypassing the lockout windows has on the webcam.
Hardware:
If you use any recent AMD / INTEL CPU that has any of the remote management tools in them (Intel AMT wiki) than not even your OS has final control over your hardware, the Management tool does. This means that anyone with access to it has complete control over your system and there is no defense possible besides completely disabling this system (not easily doable on all hardware)

In short it depends highly on what level of "certainty" you want to have, and what type if risk you are willing to take.


TLS: Clarification on trust in the certificate trust chain Suppose I have the following trust chain in my trust store:

ROOT_CERT
|
|---INTERMEDIATE_CERT_1
     |
     |---INTERMEDIATE_CERT_2

I know that any certificate that is signed by INTERMEDIATE_CERT_2 will be trusted - but are the following statements also true:

a) Any certificate directly signed by ROOT_CERT is trusted?

b) Any certificate directly signed by INTERMEDIATE_CERT_1 is trusted?

Yes to both.

Usually you will only have the root in the trust store and the entity providing the leaf cert will also provide the necessary intermediate certs, and the verifier will build a chain linking the leaf to a trusted root ("the" trusted root if only one root is trusted).

Of course the certs need to have the correct key usage constraints etc. e.g. a certificate only used to sign OCSP responses cannot issue certificates, etc.


Using xarp on a network I am slightly worried about getting into trouble...

I have installed Xarp and when I opened it, it started listing IPs. I am on a public network, so would it get flagged on the administrator's side??

As far as the network is concerned, no, you do not need to be concerned.  XArp listens to ARP broadcast packets which are sent to your machine, it does not generate traffic (emphasis mine):

  XArp will inspect every ARP packet and report attacks against remote
  machines. Some inspection modules can only work for the local machine
  (e.g. StaticPreserve), but most modules will not need any local
  information. They monitor each ARP packet and can thus detect ARP
  attacks against other machines. Be sure to deploy XArp on a machine
  that sees all network traffic from the whole subnet. XArp can only
  monitor and inspect packets that it can see.

Depending on your environment, it is possible that your Administrator does see programs; for example, many anti-virus packages will alert upon security tools.  However, I would think XArp is unlikely to trigger alerts, it's a purely defensive tool with no offensive capabilities.


Same User, Different Access Points, different passwords? We have a system (e.g. purchasing) where there are multiple access points.  One is a back-end desktop application only accessible by employees within the LAN, the other is an Internet accessible Web Application by a subset of employees as well as customers.  Both require authenticating with a Username and password.

The Web Application requires a stricter password policy than the back-end application, however we want to allow the Employees to access both with at least the same Username (at the moment they log in as a different user).

Should we be requiring the employees to use different password when logging in via the Web Application?  Or should we use the same password but require the stricter password policy for the subset of employees for the back-end application as well?

Why do you have a password policy in the first place ? It is to avoid passwords which are "too weak" (in the sense of: "too easily guessed"). Do weak passwords suddenly cease to matter on the Web site just because the very same username+password also provides access to the back-end application ?

If the password policy on the Web site is to make any sense at all, then it must apply to all passwords which work on the Web site.

On the other hand, a stricter policy for the back-end than for the Web site may make sense: passwords which grant access to both are, technically, "more powerful" passwords, so it is conceivable that they should be "stronger". But that's a hand-waving argument.

My advice is the following: if the Web application and the back-end application grant access to the same data, then the password policies should be identical for both. I.e., enforce the stricter rules everywhere. If you can force customers to follow these rules, then surely you can do the same with employees ?


Bash attack. Am I vulnerable? Someone, today, appears to have tried to attack my VPS. I checked my logs and saw this:

54.251.83.67 - - [26/Sep/2014:17:07:02 -0400] "GET / HTTP/1.1" 200 1437 "-" "() { :;}; /bin/bash -c \"echo testing9123123\"; /bin/uname -a"

Am I vulnerable? If not, how could I tell if I was? I updated to the latest update earlier before the above happened and did a test which came back as an error.

You can't tell from that log entry if you're vulnerable or not.  If you're not vulnerable, there may be a corresponding entry in Apache's error log with lines similar to

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'

However, the error message will only show up if your site's root webpage can be used as an attack vector.  If you're serving a static page, or a dynamic page that doesn't invoke Bash, there will be no error message.

Basically, the best evidence that you're not vulnerable is that you updated before the probe attempt took place.


Is microsoft.com not using TLS/SSL? On my way to Microsoft to download "security essentials", I noticed that the download page isn't a secure site. Is this legitimately the case, or an indication that I may be compromised in some way? (Some kind of name resolution hijack?)

It appears that Microsoft.com does indeed run using standard HTTP rather than HTTPS (TLS/SSL secured). However, their website can be accessed using HTTPS if you enter: https://www.microsoft.com. This causes the main page to display over a secured connection.

That said, their security essentials page (http://windows.microsoft.com/en-us/windows/security-essentials-download) is not accessible using HTTPS and results in a 404 Not Found error (if your browser even lets you open it).

I do not know why Microsoft would use standard HTTP instead of secure HTTPS, but it appears that they do. It seems like a poor set-up on their part, but I do not believe this means either you or they are compromised.


Manage SSL certificates for a multi-tenant website We have given customers the option to allow custom domains which ultimately point to our server by changing the CNAME.

Some of our customers would like to have SSL enabled to their domain but I am wondering how to manage certificates for them. I am aware about SNI which helps to have multiple certificates for the same IP-address but I still need to buy a certificate for every custom domain and upload it manually.

Is there a way we can automate the process/manage the certificates in better way?

You have the options of using let’s encrypt and certbot which automates this process somewhat, as Steffen pointed out in the comments.

Keep in mind that both let’s encrypt and SNI may result in problems with older browsers and operating systems, because some do not support SNI and some do not trust let’s encrypt.

Another (for this Szenario not appropriate) way is to get one certificate for all subdomains, but that’s not meant for this case and will lead to many more problems.


Compromise of a Public JS Library I was listening to a podcast about cybersecurity, and I heard that a public JavaScript library was compromised by attackers who injected a credit card scraper into the library, and then every site that used that library was now a source of credit card info for the attackers.

I was thinking, how would that even work? And if you did do it, wouldn't it be immediately noticed by the people running the library that there was JavaScript code sending data to someone? How could you protect against this attack?

The attack you are referring to is known as Magecart, which targeted scripts for Magento. This attack compromised thousands of sites, including British Airways and Ticketmaster, and others. It was used to steal credit card information of hundreds of thousands of users of these sites. See https://www.csoonline.com/article/3400381/what-is-magecart-how-this-hacker-group-steals-payment-card-data.html for more info.

The attackers launched the attack by modifying javascript scripts hosted on third-party sites (such as Github and various CDN's) that the victim sites incorporated into their own sites.

Preventing this type of attack is rather simple. This is exactly the type of attack that Subresource Integrity is designed to defend against.  It works by including the hash of the javascript file, in the integrity attribute of the script tag that references the javascript file hosted  on the third-party server.  When the browser downloads the script file, it takes a hash of the downloaded file, and checks that it matches the reference hash in the integrity attribute.  If there is a mismatch, then that could mean that the script has been tampered with, and the browser aborts the loading of the script.

  And if you did do it, wouldn't it be immediately noticed by the people
  running the library that there was JavaScript code sending data to
  someone?

Probably not. Many sites incorporate scripts that run in the user's browser, and send data to servers (via XHR, Ajax, etc.) routinely.  Unless users were using the developer tools function in the web browser to monitor the browser's network activity, or run some other network monitoring tool, it is unlikely that they would have noticed anything unusual.


Is there any danger from CSRF if a webservice doesn't impact server data? I've been reading about CSRF and how it works, and, if I understood correctly, the 'only' thing an attacker can do is force the user to perform actions he didn't intend.

I understand the danger if we have a service such as /moneytransfer?from=user&to=attacker.

However, if a service merely updates the user's cookie values, then CSRF would give nothing to the attacker, correct?
Is there some danger of the attacker to glimpse cookie OR response content without XSS? Would CSRF protection even be needed in such a case?

EDIT

I apologize, I'm afraid I didn't make myself too clear...

Let's say I have a cookie with a session ID. Each time the user accesses the service:

foo.com/getSession?user=jon&password=pass

... he gets back a cookie with Auth-Cookie=#SessionId.

For authentication, instead of the cookie, the server would expect the session in an HTTP Header, such as:

HTTP-AUTH: #SessionId

In such a case, a call to the /getSession service by an attacker would simply give the user a new session cookie.

In a scenario like this, would CSRF ever be a danger?

(This is all hypothetical, I know there are much better ways to make authentication. I'm a newcomer to security, and I'm just really trying to understand the limits of CSRF, and which types of service would need protection).

The attacker is still able to make POST requests if he can inject some javascript, therefore retrieving the response to the /getSession. Please take a look at OWASP and this Blog post to learn how to prevent CSRF attacks.


Can most mail from *.ru be considered spam? Is it safe to assume that most, if not all, emails from a *.ru domain may be considered spam?  From a log of 30000 emails from *.ru, its all been spam (over two months).

It might be that 99.99% of your mails are from a .ru domain.

However wether you can block it depends on the 0.01% that are not spam.   What do you want to do with them and most importantly what does it cost you to lose that message.

If this is a local site for an area in another country far away from Russia then it might be a small inconvenience to you and you lose contact with someone. However if you are a site covering a more widespread are and say need to do business in Russia losing these emails might have a measurable cost in reputation if not money. In this case I think you have to ask the business owner how much it would cost to lose that contact and also tell them how much it would save to filter out the .ru domain an let them make a business decision.


Managing and storing lots of SSH keys in the cloud I have a pool of cloud servers (~50) that need to talk to many other remote cloud servers (~4000) using SSH. Each remote server has its own SSH key, so we need a place to store all of these remote servers' SSH keys securely. How should we go about storing these keys without saving them all over?

What is the best way to securely store lots of SSH keys in one place and make our servers ask for them at run-time?

You have to make important distinctions: there are public keys and private keys. When "stored securely", they call for different notions of "securely".

Each SSH server owns a public/private key pair. Each server should generate its own key pair, and the private key should never leave the server itself. The public key is public, meaning that everybody can learn it. When you connect to the server, that's one of the first things that the server tells you: its public key. It shouts it all over the network. When dealing with SSH public keys and their storage, the question is really that of integrity: a given SSH client must remember the public keys of all the servers that it wants to talk to (the $HOME/.ssh/known_hosts file with usual Linux SSH clients); the attacker may want to include a fake public key in there, in order to run a fake server.

Each SSH client may own a public/private key pair: such a key pair will be used for client authentication by the server. If you use password-based client authentication, then the clients don't have such key pairs. If you use key-based client authentication, then each server must know the public keys of "authorized clients" (the $HOME/.ssh/authorized_keys for Linux SSH implementations).

In your case, you have 50 SSH clients talking to 4000 SSH servers. Therefore, using the normal SSH model, you would have to ensure that:

Each of the 50 clients knows a copy of the public keys for all 4000 servers.
If using key-based client authentication, each of the 4000 servers must know a copy of the 50 client public keys.

Given these figures, the relevant files will be bulky, and key management will be a problem (if you add a new client, the new client's public key must be imported into 4000 servers, with protected integrity). Public-Key Infrastructures were invented to solve that problem. A raw, "official" OpenSSH instance does not know how to use X.509 certificates; however, a modified version exists (see also that previous question). With an X.509-aware SSH code base, you could run your own Certification Authority (e.g. the open-source EJBCA), and issue certificates for your clients and servers. That way, SSH client and servers will send each other their certificates when needed, dynamically. Each machine will only have to store its own private key and certificate, and also "know" the CA certificate (in the relevant "trust store"). Adding a new client or a new server to the mix then is just issuing a certificate, and the management problem is solved (or, rather, moved around: now you have a PKI to handle).


Doubt on Android permissions mapping with UIDs/GIDs Reading the book: Android Security Internals I'm reading at Chapter 2 - Permission Management paragraph that permissions are assigned to application at install time by the packet manager with a mapping like Apk's UID <-> Permissions.

Later in the book (Permission Assignment - Permissions and Process Attributes paragraph) I read that

  If additional permissions have been assigned to the application, they are mapped to GIDs and assigned as supplementary GIDs to the process.

And, since android.permission.INTERNET permission is associated with inet GID:

  any process for an app that has been granted the
  INTERNET permission is associated with the supplementary GID correspond-
  ing to the inet group

But I was asking me if this is always necessary.

Imagining a case where you install APK X declaring android.permission.INTERNET permission in AndroidManifest.xml, since mapping of permissions with UIDs is done at install time, PacketManager should be able to map the permission directly with the APK's UID instead of adding inet GID to your APK package.. So I'm wondering why it has to be that:

  any process for an app that has been granted the INTERNET permission is associated with the supplementary GID correspond- ing to the inet group

Anyone can clarify me this?

Things usually needs permission because the permission protects a shared resource. When there is shared resource in a Linux based system, that shared resource is usually assigned a name by the kernel as an object in the filesystem. For example, as regular file, Unix socket files, device files, or special files in sysfs/procfs. A lot of native system daemons in Android are represented as a socket in /dev/socket, and hardware device drivers represent themselves to userspace applications as device files. These sockets/device files are used by applications to talk with a native system daemon or a kernel driver.

The filesystem in a Linux (or any Unix-based system) is essentially a namespace that user space applications can use to refer to kernel objects, and the kernel enforces Unix file permission to control access to interact with these kernel objects. In Unix file permission, each objects in the filesystem belongs to exactly one Owner UID and Owner GID.

If you were to assign the permission object directly to the UID, then you would have needed to create one socket file for each user/application that needs to talk to the underlying shared resource. When you add more applications to the system and when the system is updated to add/remove a daemon, you'll need to recreate those socket/device files for each combination of system service and applications. This would have been clunky and error prone.

Instead, because permissions are assigned indirectly via GID, what happens is that multiple applications can all talk to the same socket file. The system daemon would only need to listen on one socket file, but only applications whose supplementary group includes the socket file's GID would be able to talk to that daemon or kernel driver. This file permission mechanism is enforced by the Linux kernel.

Note that the Android framework also contains a number of higher level permissions that are enforced by the permission system, at system applications level, rather than by the kernel. These application level permissions works differently than the kernel level permissions, they query the Android package manager and/or an application code to decide whether or not to grant permission. What's described in the previous paragraphs applies to permissions that are enforced at the kernel level, not these application level permissions.


HSTS bypass with SSLstrip2 + DNS2proxy I am trying to understand how to bypass HSTS protection. I've read about tools by LeonardoNve ( https://github.com/LeonardoNve/sslstrip2 and https://github.com/LeonardoNve/dns2proxy ).
But I quite don't get it.

If the client is requesting for the first time the server, it will work anytime, because sslstrip will simply strip the Strict-Transport-Security: header field. So that's OK.
If not? What happens? Will the client automatically try to connect to the server wih HTTPS? In that case, MITM is useless, isn't it?

Looking at the code, I kinda get that SSLstrip2 will change the domain name of the resources needed by the client, so the client will not have to use HSTS since these resources are not on the same domain (is that true?). The client will send a DNS request that the DNS2proxy tool will intercept and sends back the IP addres for the real domain name. At the end, the client will just HTTP the resources it should have done in a HTTPS manner.

Example: From the server response, the client will have to download mail.google.com. The attacker change that to gmail.google.com, so it's not the same (sub) domain. Then client will DNS request for this domain, the DNS2proxy will answer with the real IP of mail.google.com. The client will then simply ask this resource over HTTP.

What I don't get is before that: How the attacker can HTML-strip while the connection should be HTTPS from the client to server?

To answer the original question - most people never type https://example.com directly. They rely either on links (click here to access our secure login server) or on redirects (type "gmail.com" in the browser, and you will be automatically redirected to a secure site).

This is where SSLStrip comes in: it intercepts the original, unsecured HTTP reply, and replaces <a href="https">; links with HTTP (insecure) versions. Also, it changes redirects ("Location:" headers) that point to HTTPS URLs.

With SSLStrip2, this goes a bit further (intercept, redirect to an invalid subdomain, use DNS interception to actually provide a valid IP for that subdomain).


ruby on rails pentesting web applications I am currently testing a RoR web application, but I am honestly at a bit of a loss, I have never gone up against a RoR application before and I was wondering if there were any specific tools I could use to attack this RoR site (I have full permission, all legal).

any tools or tutorials for basic RoR pen testing?

There's a number of areas that you can focus on with rails apps, depending on the level of access you have.  Some initial ideas

If you have source code access (and I would highly recommend it), you can use Brakeman to find some issues.
Even if you can't get source code access, you may be able to request the output of the 'rake routes' command which should give you a picture of all the possible routes in the app.
OWASP have a good doc on rails security which has some good starting points.
I'd always try changing extensions on requests (e.g. from html to xml or json) as rails tends to have different code paths for different formats and this can expose security issues.
if you can find the version of rails in use (in the Gemfile in the application root), review for known CVEs (there have been a few)
As rails apps generally have an MVC structure, they can have quite predictable URL paths, so if you're black-boxing, then things like /users/1/edit (replace users with other plural nouns) can produce interesting results
Always decode the cookies to see if there's any secret info in there (there shouldn't be).


Requirements for a smartphone anti-theft App I recently installed Cerberus in my [personal] Android device to get some protection against theft (I'm not really interested in protecting its data, but rather in increasing the odds the device will be eventually recovered). But I'm worried that using this App (or similar others) might expose me to a greater risk of losing control of my own device, either by accident (bugs in the Cerberus system) or mallicious activity (attackers taking control of Cerberus' website).

Clarification: the question is not about how to physically protect the phone, but rather about the digital risks I'm taking when employing a computerized solution to said problem (with the constraints that this scenario impose - attacker with physical access to device, no guarantee of internet connection, etc).

Please note that I'm not requesting a shopping recommendation, but rather trying to work out all the details I should be aware of when looking for (or maybe even developing) a solution. I know compromises will be made, but I'd rather not be more lax than necessary in the digital aspects while I try to harden the physical ones. And the issues are not necessarily about Android, it should apply to any mobile device.

Details

Feature: allows remote control of the device by sending it SMS commands.

Why it's necessary: it might be the only way to reach the phone if internet is disabled.
Concern: the password is sent in the SMS body.
Mitigation: change the password every time this feature is used (after the device recovery).

Feature: allows remote control of the device by using a web-based interface (the user can enable internet access by a SMS command if necessary).

Why it's necessary: a server is needed to do the hard-lifting - communicate with the device, collect its info and do something with it (usually e-mail it to the legitimate owner). While simpler commands might be possible without it (ex.: enabling the GPS and sending coordinates back by SMS itself) others are not, due to the message size (ex.: taking a picture or recording a short video with the front camera while the thief is trying to operate the phone and e-mailing it to the owner).
Concern: if the server has enough credentials to authenticate itself with the device (otherwise it couldn't control it), then if the server is compromised the device becomes vulnerable to several attacks (locking the legitimate owner out of his device, tracking it, or wiping all its data).
Mitigation: a) using a server that you control, not a third-party; b) using some kind of OTP that the user must provide, so the server can't do anything if the user is not in charge; c) disabling features with damaging effects (i.e. enable finding the phone disregarding the privacy risk, disable wiping the data disregarding the data theft risk, etc).

AFAIK these two features are the only ones that could be problematic, but if anyone has more info about things I should be careful with, it will be welcome. As an additional clarification, I'm aware that someone with physical access to the device - and enough knowledge - might be able to get rid of the App (though this one in particular was designed to survive even a factory reset). But I'm assuming it's not a trivial task, if I'm mistaken - and trying to recover the stolen device is in fact pointless - I'd like to know it so I can abandon this idea altogether.

There are documented cases where the theft recovery tools were used against a legitimate user, so your concern is justified.  In general, if I was designing such a system, I would want the password to take control of the phone to only be known by the user and not stored on the service provider's system.

I would also want the password to be used to generate time based and one time use codes to send via SMS so that the phone would never respond to a replay and would not send the password clear.  Since a phone has a reliable time source (the cellular network), it should be possible for the phone to keep a good time sync with the server for this purpose.

It would still be potentially possible for the device to be hijacked, but it would require then require the user to allow their device password to be compromised.


Testing your site for the heartbleed vulnerability? I've seen a number of articles on the heartbleed vulnerability that suggest testing your site to see if it was affecting using Filippo Valsorda's testing page which can be found here:

https://filippo.io/Heartbleed/

When I put the URL to my site into here it says everything is good.  Is this sufficient for determining if one's site is vulnerable or should I be doing something else?

The SSL Labs test will give you the most information about your site, including heartbleed status:
https://www.ssllabs.com/ssltest/analyze.html?d=

This site has worked pretty well for me in testing specifically for heartbleed:
http://possible.lv/tools/hb/

Lastpass uses some other assumptions about previous information to make pretty good guesses:
https://lastpass.com/heartbleed/


Verifying that an Android banking app checks that the certificate is trusted I have a closed source banking app on my unrooted Android phone. I'd like to verify the following:

The app uses SSL to communicate with the server
The app verifies that the SSL certificate of the server is trusted

To this end I set up a VPN server with racoon and xl2tpd. I am sniffing the network traffic using wireshark and can thus verify that the app uses SSL.

For the second point, I was thinking I could simply set up a web server with a self-signed certificate for bank.com, make my phone use that one, and see if it complains. Of course, my server won't respond adequately, but I'm hoping I will see Untrusted certificate as error message in the app rather than Unknown error occurred.

I edited /etc/hosts to let bank.com have 127.0.0.1 and set up my server. However, my phone still uses the actual IP. So, apparently, xl2tpd doesn't use /etc/hosts. How can I let xl2tpd think bank.com is at 127.0.0.1?

Or, alternatively, how do I verify the second point above, if there is a better way?

A proxy is better for that. I think if you configure this proxy but skip the SSL cert configuration you should get your answer.


What's the idea behind requiring users to change password periodically? Possible Duplicate:
  How does changing your password every 90 days increase security?

Some sites require users to change their password every x days. For example, at least 3 online banking system requires me to do that. Does this mean the admins assume the password could be hacked within the x-day period?

Isn't regularly changing passwords riskier than having one permanent strong password? For example, if you change your password regularly then it means there is a higher chance you will forget it and now you have to store it somewhere (aside from your mind, like a physical paper hidden "under your pillow" or a secret folder in your computer) therefore it increases the possibility of password leakage. Well as if you have just one really strong password hidden in your mind, it can't be leaked.

For simplicity, this question is assuming an average user doesn't know or want to use password storage apps like Keepass since it has its own drawbacks like password portability/computer crash/etc.

While I see your point, having a compulsion to change your password at regular intervals of timing is a good and mandatory method for security within most banking applications. Allow me to explain why.

The main reason people get hacked online is because of vulnerabilities where their password is either phished from them, key logged or too easy to brute force. This also includes conditions wherein due to the manner in which the user accessing the system, other individual(s) are aware of his log on credentials.

In all such cases, changing your password helps a lot. Logs generated by key loggers are enormous. If a mass key logger has affected someone, hackers generally take time to process those logs. Changing your password regularly has a fair chance of ensuring that by the time the hacker attempts to log in with your credentials, the password has changed.

Also, most applications set out alerts when a password is changed. As a result, if a hacker does get control of your account, he could only access it without your knowledge so long as as the password remains constant.

Of course, this is not the best method of delivering security. I personally believe that 2 Factor Authentication is a more safer and user convenient method then prompting the user to change his password which can lead to him forgetting it or storing it insecurely.


File upload security in webapp - overview of setup For a webapp based around user uploaded pics, I want to check that I'm doing things sufficiently securely. Below is an outline of the current setup.

Of course only registered users can upload, but I know that doesn't mean anything.
The site is exposed via nginx.
The machine on which the webserver is hosted only accepts incoming connections from the nginx machine.
The image upload link (nginx directive) is rate limited (in a way that generously accounts for a legitimate user spike).
The webserver accepts only jpg/png/tiff/webp image formats (it derives the mime type using the magic library).
Both nginx and the webserver have a limit on the accepted file size.
All uploaded files are saved using a filename which is a hash of the contents.
By default, they are saved with only rw permissions, not rwx.
The images are stored on the same system as the webserver.
They are saved directly to the final location (there's no intermediate staging location) but the images are not available for viewing until a specific database column is updated (see next point).
A periodic virus scan is completed on the newly uploaded files (and any malicious files are removed to a different directory to which the servers have no access) and then the aforementioned database column is updated to make the files available for viewing.
Lastly, a tiny amount of random noise is added to each image by doing something like magick image.jpg -evaluate Add 0.1 image.jpg

What vectors am I missing? The goal is not to protect against a state actor, but to have reasonable protection against the average (or even somewhat skilled) malicious irritant.

I think the only way to answer this is through a collaborative commenting effort, so here goes a community wiki:

Of course only registered users can upload, but I know that doesn't mean anything.

Agreed.

The site is exposed via nginx.

Which means you have the actual web application running behind that – make sure that your adapter (WSGI? fCGI?) is securely set up.

The machine on which the webserver is hosted only accepts incoming connections from the nginx machine.

clever move!

The image upload link (nginx directive) is rate limited (in a way that generously accounts for a legitimate user spike).

Make sure this doesn't make it easier to DoS-attack your site.

The webserver accepts only jpg/png/tiff/webp image formats (it derives the mime type using the magic library).

magemagick is a very well-maintained library, but it's also a very large attack surface, and there's been a lot of critical breaches happening through it. Using a much more restricted library for validation might be a good choice.
ensure that uploaded file extension always matches the detected format, and the file can be properly decoded as such. You can also consider stripping various metadata, like EXIF tags - basically, add a processing step, that takes only what's necessary (only image data) and save as a new file, with this step running as much isolated as possible (so RCEs in image decoding libraries won't get attacker any much access). After this, ensure that nginx always responds with the correct Content-Type and all the safety headers, X-Content-Type-Options etc.

Both nginx and the webserver have a limit on the accepted file size.

good.

All uploaded files are saved using a filename which is a hash of the contents.

Make sure to salt that hash; hashes are crackable (within limits), and you don't want an attacker to control the file name of their uploads. Don't just use MD5, but a less broken hash.

By default, they are saved with only rw permissions, not rwx.

Save them with read permissions. Once they are saved, they never need to be modified again.
Also, use SELinux (or your server OS'es equivalent) to make sure your web application can only write and read that directory, never execute files in it.

The images are stored on the same system as the webserver.

Might very quickly become a scalability issue: Server software would these days preferably run on fast reliable storage media (SSDs with hot fallover), whereas your user pictures would sufficiently be stored on cheap storage media with slow backups (i.e. if two hard drives fail at the same moment, OK, you'll need 15 minutes to restore from your redundancy and might lose a couple minutes of new user images).

They are saved directly to the final location (there's no intermediate staging location) but the images are not available for viewing until a specific database column is updated (see next point).

A periodic virus scan is completed on the newly uploaded files (and any malicious files are removed to a different directory to which the servers have no access) and then the aforementioned database column is updated to make the files available for viewing.

There's no computational advantage to doing that periodically instead of instantaneously after uploading the file. So, do it instantaneously, and keep your storage load constant as possible. Running the antivirus as a daemon avoids having to load up the virus definitions into memory for each scan.

Lastly, a tiny amount of random noise is added to each image by doing something like magick image.jpg -evaluate Add 0.1 image.jpg

That is a very compute intense step, which uncompresses images, adds noise, and that's the worst part, which in case of JPEG leads to maximum quality loss if you want to keep the original file size. (noise is very hard to compress, unless it's so weak that it actually gets compressed away and the resulting image is actually as if you never added noise.)
I don't see any security advantage of this step.
Further points

Containerize your web application.
Use a separate logging server
Monitor for sudden increases in storage consumption – in case someone abuses your site automatedly e.g. to host pictures for their own gain


How to Combine RSA and AES for Steganography Project I wanted to have some knowledge about cryptography and steganography so I decided to write a steganography application with using LSB technique and for message encryption I wanted to combine RSA and AES. But I need some advice about my logic. After doing some research I decided to encrypt client message before embed it into picture so,I will generate 128-bit Private Key with RSA and with this key I will XOR some secure random number then I will use its output as a AES Key then I will encrypt the message with AES algorithm. My question is we cant create a key which has length of 128-bit in RSA so how people who used hybrid cryptosystems can combine those two algorithms which are AES and RSA.

I would say don't do it, it looks like someone else is already working on an openssl steganography implementation on github. If you are using pictures for your steganography they are sort of already a shared secret (if someone has the original picture they can see yours has modified LSBs) so you could pick an easier shared secret cryptosystem.


Minimum size of input text box required for XSS attacks I have below code to accept User login ID as input from User.

<input name="userName" type="text" id="userID" maxlength="8"/></td>

Maximum number of characters that a end user can input is 8 here.
If one has to carry out XSS attack like this by entering below code in input box,

<script type="javascript>hello</script> ,

which cannot be entered because of maxlength restriction, can I be assured that XSS attack of this category cannot be done?

In general, if input is restricted by maxlength, what is the minimum maxlength once should give to restrict XSS attack?

Your solution doesn't prevent any XSS attack.  The HTML input tag attribute maxlength is an instruction to the web browser, that a malicious attacker can trivially change in any modern browser by dynamically altering the DOM.

<input name="userName" type="text" id="userID" maxlength="8"/>

Your sanitation routines have to be done with server-side code.  That is this type of sanitation could be done if you truncate any input that's longer than ~8 characters when in your server-side code (not in the HTML attribute that a client can easily modify).  Beware that html/js is quite forgiving (and you'd have to test all browsers), so once you get to lengths of more than len(<script>) ~ 8, I think this mechanism likely could fail for some clever use with some bad browsers.

However, this is still an inane route to preventing XSS (unless the only data your application will ever take and possibly ever display back to any user is 8 characters and your server side code truncates this user input at ~8 char). You really need to either:

Run through a well-known HTML sanitizer/purifier that you didn't write yourself or
First escape all the special html characters in user input ("&'<> to their HTML escaped versions: &quot;&amp;&apos;&lt;&gt;) and then apply rules of a safe lightweight markup language (like reddit markdown) to only allow safe things like links [links](http://example.com) (checking the protocol is in your safe whitelist e.g., http/https/ftp) or italicized (*italicized*) or bold (**bold**) text.


Anomaly detection in HTTP REFERER I'm trying to put some anomoly detection in place and I'm looking at referrer data (I know that this is optional, and can be fudged in some circumstances). But I'm seeing too many cases of what I believe to be false positives.

From rfc2616:

The Referer[sic] request-header field allows the client to specify,
for the server's benefit, the address (URI) of the resource from
which the Request-URI was obtained

I take this to mean that the referer should be populated only when the request is generated from a link, form submission, ajax request, or related content explicitly containing the target URL. i.e. if the user navigates to my site using a bookmark, manually entered address or via another page site (not counting the possibility that this might issue a 30x redirect) then I shouldn't see the page they were on previously.

But I see a large number of cases where the URL supplied as the referrer has no link to my site. Further, many of these referrers are reputable operations (including large banks) who should be protected against XSS type attacks, therefore it's unlikely that the cases I see were due to the user accessing a modified page.

I am aware that there are long outstanding issues on iPads and iPhones (CVE-2009-2797, CVE-2008-3171) which give rise to this behaviour (before I started filtering these out, ipads and iphones were disproprortinately represented in the output) however I am seeing these oddities for MSIE, Firefox and 26, and very occassionally Google Chrome.

I've been unable to replicate the behaviour on Firefox (same version as reported from my production data) using

a simple href (referer is prev page)
a form (both GET and POST) (referer is previous page)
a change to window.location via javascript (referer is prev page)
an img ref (referer is prev page)
bookmark (no referer)
manually entered location (no referer)

I've not looked at Greasemonkey type scripts - can anyone advise if these will give rise to this behaviour? I don't see any evidence of pre-flighting which would imply a CORS.

Is there something else I am missing?

It's a common method of (SEO) spamming to give fake referrers with the hope of being listed in some place or another, this might explain some of the entries.


Security implications of having files owned by the apache user? Currently running a LAMP instance that developers are using for a variety of webapps.  I have the following scenario:

Multiple developers need access to create and modify files under /var/www/html
The developers need to be able to access each other's code in case they are out on vacation, sick, etc.

My thoughts were the following:

For each web application (directory) under /var/www/html, recursively change the owner to 'apache' and the group to a 'developers' group.  Set the permissions at 570.
For each file under /var/www/html, recursively change the owner to 'apache' and the group to a 'developers' group.  Set the permissions at 470.

Keeping the files and directories as read-only to the Apache user is a good security practice, but is having such files owned by the Apache user a bad one?  My concern was around what would happen if Apache got hit by a 0-day vulnerability or something of the sort.

If anyone has a more elegant way to do this, I'm interested in hearing it as well.

Restrict the daemon with MAC

No matter how you cut it, wrapping Apache in a mandatory access control layer like AppArmor or SELinux is a good first step. That will allow you to restrict the daemon's allowable operations even if otherwise has permissions to do so. That will prevent Apache from ever modifying your files.

Use version control with automatic checkouts

If every developer has access to git and the production branch is automatically checked out by the web server when it is updated, you will have control and history of everything that is loaded as well as instant verification that everything is what it should be.

Permissions

The downside of making Apache the owner of the files is that Apache could theoretically chmod those files. For that reason, making the data directory and files within owned by another user has a benefit unless you expect Apache to alter the directory. If you do, try to separate directories for expected dynamic content and content that Apache should never update.


VirtualBox 3D acceleration security risk I have VirtualBox running a windows 7 VM on it and the performance is really choppy, likely because of the 3D acceleration.

However I read through VirtualBox's security page, and it states: "Enabling 3D graphics via the Guest Additions exposes the host to additional security risks".

Now I am wondering how likely it is for malware to exploit this security hole? and if it's something I should even be worrying about?

'How likely' is kind of a hard question to answer. But I am going to try and analyze the risk to give you a feel for the 'likelihood'.

The main problem here is that your host machine (clean) is giving to the guest (potentially infected) unsupervised, direct access to the hardware drivers, in this case OpenGL and Direct3d. This access is only as safe as the drivers the guest can access.

Unfortunately, those drivers are not always secure and bugs in drivers are found very often. This should probably help us estimate the 'likelihood' of such malware.

To complete your understanding, consider the market for virtual machine escaping malware. At the last Pwn2Own competition, VM escape exploits fetched $105,000 to the winners. And that's for a reason. Escaping from a VM means you can compromise the underlying host, which defeats the whole point of virtualization (at least for security reasons).

So I'd say it is very likely malware will target drivers that reside in the host.


How to secure handshake system-to-system in RESTful API calls without user/pass? I have system X from another department in our company that sends basic user info (not passwords) to my system using RESTful API. Both systems are using subdomains of the same domain but reside on different servers/networks. I just want to confirm that the incoming API request to my system is validated as coming from system X.

In almost all of the articles/questions I've run across talk about user credentials auth, but these don't apply to my situation because I don't want to push creds across for each request/response.

Is there/what would be a good secure method to achieve this handshake without user/pass/oauth?

Here are my "off the top of my head answers", which may change after I give it more thought.

1) I'm not sure if there is much point to a salt here.  In normal usage a salt protects a leaked password database against rainbow attacks.  That certainly isn't relevant here, and moreover I don't think there is any other reason for the salt.

2) Hashing also doesn't add a whole lot of security, I think.  Hashing is used to hide a secret during storage, not transit.  If you hash it and pass along the hash, then that means your hash effectively is your secret, and a stolen hash is no less dangerous than a stolen secret.  Therefore, in a very real sense, you might as well just send the secret itself, especially since it will change regularly.

In summary, you effectively have two defenses in place: a shared secret (which changes), and IP white-listing.  Your shared secret is going to be primarily vulnerable to things like replay attacks or request eaves-dropping: if anyone happens to see it in transit, they will know the secret until it next changes.  You mentioned this is system-to-system, so depending on whether or not your systems are in the same security zone will probably determine whether or not such a request needs to happen over TLS/SSL.  If these systems are communicating between data-centers, you'll probably want to be communicating exclusively over TLS/SSL.

Your second level of security is via IP white-listing.  This is primarily vulnerable to IP spoofing, which, depending on your network setup, may or may not be be an issue.  I'm sure there are more options as well, but I'm not a network expert.

For a completely different approach you can try implementing a handshake.  The basic idea is that when server A sends a request to server B, server B validates the request by contacting server A directly, passing it the full request that it received, and getting back a YES/NO response (the "no" obviously being returned if server A did not send the request in question).  Only once it receives the "YES" does it actually process the request.  This takes more effort to setup and also takes more network/server resources, so may not be preferable depending on your application needs.  The advantage is that it rules out IP spoofing, and also makes the secret exchange unnecessary.  However, it may not prevent more direct network attacks (i.e. MITM and the like).

Edit to add:

The handshake idea isn't actually my own.  I've used that general flow in my applications to validate server-to-server notifications.  The idea itself I stole from paypal (it is how they validate their IPNs), although it probably isn't originally their idea either.  I point this out simply because it is a practice that has been in use for a long time, so you can both read their documentation to understand the flow and (potentially) look for information about past security issues that may have arisen due to that flow.  Presumably though, since paypal relies on it for a critical part of their payment infrastructure, it is fairly secure:

https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNImplementation/


How to find IPS events in sonicwall syslog I have a sonicwall os firewall, and the security dashboard shows about 9 intrusion prevention events in the last month. Most are called "Suspicious CIFS traffic 4".  I have syslog servers setup with facility local 0 for remote centralized logging.

I can't see any sign of the IPS events in syslog. I see nearly everything else I can think of, every connection open/closing, websites blocked due to content, bad password attempts , Smurf amplification attempts blocked, etc...

My only guess is I need to change the facility setting, but the few hits I find seem to say use the one I have.

Is sonicwall keeping those events out of the syslog to force me to buy their logging tools? Or am I just being dimmer than usual?

Silly me.

I had "Low Priority" events not being logged.
For those who might be having a similar experience,
I had forgotten that there were so many events logged (browsing activity, etc...) that it didn't seem warranted to keep the low priority events being logged.  That said, I'm not sure why things like This "IPS Detection Alert: FILE-TYPES-HTTP Image -- JPEG 1A (HTTP Download)" would be considered a low level intrusion, but I'm not a firewall expert.  On the dashboard, they seem to be categorized differently than the Suspicious CIFS that I was looking for in the first place.  I find that a little frustrating and curious, but no point in venting here.

The Suspicious CIFS is considered a Low Priority threat according to sonicwall.com


Is there a way when using WIFI to know the specific users computer ids? When you use WIFI is there a way to know the other users computer ids and MAC addresses? What other WIFI users can know about you when you share same WIFI?

By computer ID, do you mean name/NETBIOS name?  This could be known, along with the MAC, a couple of different ways:

Using the AP software/webUI itself. The management console may already provide this information to you.
If you run switches that are fully manageable, you can track down what MAC addresses are connected to the port from which your AP is plugged into.
Third-party tools and software could also provide this information for hosts that are connected to your network.

Anyone connected to your AP would be able to run any number of networking tools to try and find information about the devices on the network. Once someone is connected to your network, they are able to then run attacks and reconnaissance against your network. So a knowledgable user could gain a substantial amount of data or do a lot of damage if your network is poorly designed or secured.


SQL injection with "INSERT" statement I am currently studying the most basic SQL injections that are possible. Pure and solely for the purpose of teaching myself the basics before advancing to more advanced ones. I am recreating this situation with the following statement:

$result = $dbConnect->query("INSERT INTO UserTable VALUES (NULL,'$name','$email', '$userName', '1')");

I have a few questions regarding this statement (I know this is bad practice but I want to start as basic possible).

Is it possible to inject something into this even if it's in an if statement?
How can you escape out of this query?
Is there a possibility to echo the whole statement so you could get more intel in the php used, meaning that the whole result query is being echo'ed due to the injected code?
If this has a potential SQL injection situation. Are there any people dumb enough to code this way?

Thanks in advance!

Is it possible to inject something into this even if it's in an if statement?

Yes. With multiline queries, a simple '; drop table usertable;-- works. With single line queries, ' (select abc from def),0)-- can work, though with some more nesting you can run pretty much anything.

How can you escape out of this query?

Simply escaping everything won't work, as this may change the meaning of some of the characters. You have to be careful.
Stuff like mysqli_real_escape_string() are also vulnerable. Use prepared statements.

Is there a possibility to echo the whole statement so you could get more intel in the php used, meaning that the whole result query is being echo'ed due to the injected code?

Sure, store the string first and then echo it. But that may be worse, it's best if the attacker can't see anything. It's preferable to log the queries.

If this has a potential SQL injection situation. Are there any people dumb enough to code this way?

It's not so much dumbness as cluelessness/carelessness, but yes. MySQL injection is one of the most common web vulnerabilities out there.


If I am able to generate the same public key as someone else, do I also get the same private key? I have a very basic understanding of the asymetric encryption. I have a couple of simple questions. I know I can generate a key pair, of public and private keys.

If by co-incidence my public key that is generated is the same as a public key of someone else. Does this mean we will also have the same private keys?

Second related question.

If the answer is yes to the first question. Then, is it in theory, possible to have a huge database of all known public keys and keep randomly generating key pairs and checking against the database if any of them match.

Breaking one specific key, is very hard. But is breaking any key also hard?
If someone tries to find a match with publicly known key they could somehow break one or a handful of them. If not, what stops this from happening.

Thanks! : )

Breaking any key from a set by random guessing is indeed 'easier' than breaking a specific key, but not enough to make a difference.

How many known keys there are depends on who does the knowing, but if consider available from public servers on the Internet, several projects have collected more or less all SSL/TLS and/or SSH keys on public Internet servers for various kinds of investigations; see https://www.factorable.net for one good example. This takes some work and a bit of time, but is quite possible. They reported 12 million in 2012; adding a generous allowance for growth and rounding up, call it about 32 million (2^25). This is not large at all for modern database systems and computers, although e.g. storing it on paper cards in an old-style library catalog would be costly.

As per the link in Crypt32's answer, the chance that a randomly generated RSA 4096 key matches a particular target is about 1 in 2^4070; with 2^25 targets, it improves to about 1 in 2^4045. Both of these are astronomically unlikely -- literally so; if you used all the energy in the universe the chance of hitting any target is still much less than the chance of your house being hit by dozens of independent asteroids within one second.

Even for RSA 2048, which is much more common today, you improve from 1/2^1005 to 1/2^980 -- still not enough to matter.

ECC, on the other hand, is much smaller because it isn't subject to math-structure attacks like RSA. For the commonly used ~256-bit curves (secp256r1, secp256k1, X25519/Ed25519) the universe does contain enough energy to break some reasonable number of keys, though the Earth doesn't. And for Bitcoin addresses, which run the secp256k1 key through a (net) 160-bit hash, it is quite possible someone will find a duplicate within not too many millenia, though probably not within your lifetime (or mine).


How do I educate others about social engineering? One of my friends used to boast about how long his passwords are. One day, I decided to play a prank and social-engineered it out of him. I was pretty surprised as to how effortless the entire procedure was, and how oblivious others can be.

Many of my acquaintances don't seem to understand the dangers of social engineering and focus more on cryptographic security.

How do I teach others about social engineering: both as to what it is, and how to avoid being tricked?

When I've been asked to setup some presentations about security awareness, I've always used something that is familiar to the user base to demonstrate weaknesses that can be exploited.

Let's take a simple organization, Acme. Acme has about 200 employees, a robust IT infrastructure, top-of-the-line firewalls, secure applications, a smart CISO, etc. Their wireless is WPA2 with RADIUS Auth which uses the user's AD credentials. They also use Outlook Web Applications (OWA) a lot.

If this was an organization I was demonstrating an attack to, I would first set up a phishing site that looked just like the OWA installation. It's ridiculously simple to do with something as accessible as wget, or you could use Trusted Sec's Social Engineering Toolkit to set it up. Once you do that, change the login form so that the username and password entered goes to your own database/file store—or, you can once again use SET's credential harvester. Optional: Buy a domain, such as acme-corpwebmail.com or something like that.

The next thing to do is send a sample email to yourself. It can be something along the lines of how there's an IT upgrade and people need to validate their accounts—focus on the email being believable, with good English, something that can be trusted, even. Log in with the credentials, and show that they get captured.

Use the same credentials to log in to the corporate network (since it is AD credentials after all). Now an attacker has access to everything an ACME employee has access to, and he hasn't even broken an application or entered the building. He can be sitting outside the parking lot the whole time.

Want the extra effect? Make this whole thing a really cool video. It's not hard to do, even if it takes a little extra time.

Once you show how an attacker can get in, focus on what the employees need to do to protect themselves—i.e., make sure that the email is from who it claims to be from. If in doubt, ask the person if they sent an email—it's okay to waste the person's time if it means being safe. If the link is external to the organization, ask the person/the security team before clicking on it. If it is external and asks credentials, assume it is malicious unless told otherwise.

From personal experience, I can tell you that this has been very effective—it makes an impression on people, even if it builds paranoia in some—and a certain level of paranoia is always good. :)

If you want to take it to the next level, I really do recommend checking out what SET has to offer. Dave Kennedy and all the others who have worked on it have done an absolutely amazing job on the tool, and it provides all the tools necessary to teach people about social engineering.


what are the consequences of increasing the "--risk" option of sqlmap? I use sqlmap to test the services of my company.

I tried increasing the value of its "--level" option, but I do not find clear descriptions of the tests added with an increased "--risk" value.

So, what do  risk level 2 and 3 tests do, and what are the risks of running them?

Level

By default sqlmap will test all GET and POST parameters specified, however in some cases you might want to test additional entry points such as HTTP headers. It is possible to specify it with specific options, but the most straight forward technique is to use the --level option. There is 5 levels available in sqlmap (default being level 1). Level 2 adds HTTP Cookie header testing, level 3 adds HTTP User-Agent/Referer headers. I can't provide to you more info about higher levels because there is no more info about them on sqlmap wiki.

Risk

Regarding the risk. There are 3 risk values. The default value is 1 which is innocuous for the majority of SQL injection points. Risk value 2 adds to the default level the tests for heavy query time-based SQL injections and value 3 adds also OR-based SQL injection tests.


Tutorial Video Protection on a Tablet I am planning to start tutorial videos.  I thought of buying a tablet and then putting the videos on the tablet.  My major concern is that the students shouldn't be able to copy the videos. They should only be able to watch the videos. They shouldn't be able to screen record the tablet too.  I want my videos to be watched by only the students who buy it.

Could anybody help me out with this?

You should try the kiosk mode of the tablet of your choice. This will lower the risk that your students will be able to copy the files from the device.

To avoid tampering you could seal your devices. Sure they still would be able to break into the device but at least you would be able to sue them afterwards if the seal is broken.

Last you wont be able to protect the content to be recorded by a second device.


Is AIK from the TPM publicly accessible? I don't understand very well the concept of trusted platform module. from what I understood AIKs are sent to servers for authentication. Does that means that id two computers are communicating they could learn each other's AIKs?
Does TPM publish any information at all by default whenever starting communication?

Actually, AIK's are not sent to generic servers for authentication. There is an extra level of indirection: the AIK is used to sign a CK (certified key), and the CK is used for authentication. See TPM: signing key or Attestation Identity Key? But if a computer with a TPM authenticates using the TPM to some remote server, then the remote server does learn the AIK. (The public key, of course — an AIK is actually a key pair and the private part never leaves the TPM.)

Note that an AIK does not identify a TPM in a way that allows tracking it across different usages. A TPM can generate multiple AIK's. The expectation is to generate a separate one for each service that the computer is enrolled in (e.g. one to validate connections to the enterprise network, one to authenticate to a bank, etc.). Different AIK's from the same TPM cannot be identified as related (unless the AIK enrollment service did a bad job).

Also, note that the TPM itself does not communicate. The TPM makes integrity measurements of the system state (i.e. it verifies that the CPU and memory are in an approved state), and it holds keys with which it can encrypt and sign these measurements and other data. What gets transmitted over the network is the responsibility of applications running on the CPU's operating system. Choosing which AIK to use for which communication partner is the responsibility of the application (and possibly the operating system's, which performs access control so that applications can only make certain requests to the TPM), it's outside the hands of the TPM.


SSH "on keyboard interactive devices" brute force vulnerability I was researching the OpenSSH brute force vulnerability "onkeyborad-interactive devices", however I am not sure how this command really works

ssh -lusername -oKbdInteractiveDevices=`perl -e 'print "pam," x 10000'` targethost

As far as I investigated it seems that -l parameter is for login, -e is used for execution and pam is plug-gable authentication module that provides dynamical authentication support for system. Perl is programming language.

However i'm not sure what is onkeyboard-interactive devices(I did not managed to find any examples)? And I'm really interested how does this vulnerability opens the loop that can be used? Maybe someone could explain this more briefly ?

`perl -e 'print "pam," x 10000'`

is executed in subshell, prints 10000 times pam divided by comma (,).
The returned string is used as an argument for -oKbdInteractiveDevices= option (see manual page for ssh):

KbdInteractiveDevices
Specifies the list of methods to use in keyboard-interactive authentication.  Multiple method names must be comma-sepa‐
rated.  The default is to use the server specified list.  The methods available vary depending on what the server supports.
For an OpenSSH server, it may be zero or more of: “bsdauth”, “pam”, and “skey”.

This vulnerability is already fixed on most of the systems. But there was bug on server, that didn't check if the "device" was already tried. This allowed to issue much more passwords attempts than if you would have to issue the whole new connection for three attempt (you could do 10000 for exmaple).
For the record, it is CVE-2015-5600 shortly described in this blog post