Port scanning is more akin to taking a walk around the neighbourhood and trying every handle of a door and every window to see if it's open, to see if the neighbours have left anything available for future investigation or exploitation/theft.

The walk you describe would be more of a ping sweep - just see if the host is up (or house exists).

Regarding legality, intent plays a big part, and whether you have permission of the target (white-hat vs black-hat). Consult a lawyer.


Physical storage characteristics are not part of the definition of PKCS#11. PKCS#11 is an API: it defines the behaviour of the library with regards to function calls, not with regards to actual technology. A purely software PKCS#11 library, with all keys in RAM, is perfectly possible (and that's exactly what the Firefox Web browser is using internally).

With CKA_TOKEN enabled, the key is supposed to be permanent, i.e. you will find it back after opening a new session. It does not necessarily entail any kind of protection, either while being used or while stored. There is another attribute that is called CKA_EXPORTABLE, that declares whether the key may be exported or not; but, there again, it does not qualify attacks, only what you will get if you call the export function. Depending on how the PKCS#11 library is implemented, all keys may float in RAM at some point.

If you want to know where exactly your key will be, then you will have to look at the documentation for the device or system for which you have a PKCS#11 library. If the device is a HSM and the HSM documentation guarantees that private keys stored in the HSM never leave it, then you know that they won't be copied in the RAM of the PC -- not because of any PKCS#11-related attribute, but because the HSM makes it so. The PKCS#11 library is merely a consumer of the HSM services.

That being said, it is possible to make some inferences. For instance, if your crypto device is a smart card, then its I/O capabilities are very limited (9600 bauds is typical) so chances are that any bulk encryption (AES) provided by the PKCS#11 API would be handled in software, so your secret unwrapped AES key would really be somewhere in the RAM of the PC.


How are server overload and DoS/DDos different?

Denial of Service is a broad term, describing attacks that "make a computer resource unavailable to its intended users" (Wikipedia). Overloading a server is a form of DoS, but there are many other forms. You might be able to achieve the same goal by using up the server's maximum number of possible concurrent connections, not overloading the server, but using up a resource. Or by abusing a memory corruption bug Wikipedia that makes the server software crash.

So, by protecting your server against overload, you protect it against one form of DoS.


Is there a way to configure WPA2-PSK to provide Forward Secrecy?

Forward secrecy is achieved by using ephemeral keys. That's the point of it: you get forward secrecy by using encryption keys which cannot be stolen afterwards because they were never stored on a physical medium; they were stored in RAM only, and have been destroyed after usage. They're gone.

The fine details: this definition extends to whatever can be rebuilt from stored and exchanged values. For instance, in WPA2-PSK, there is an initial shared secret (the password), which is stored, and the encryption keys are generated from that stored secret and random values; the random values are not stored, but are exchanged as cleartext, so the attacker would have seen them and could have stored them. Therefore, WPA2-PSK cannot achieve forward secrecy, because stealing the shared secret (the password) allows unravelling traffic which was captured beforehand (provided that the attacker recorded the whole conversation between client and access point, beginning with the four-way handshake.

Note that WPA2-PSK suffers from an additional issue which is that the shared secret is a password, thus potentially breakable through exhaustive search. This is because passwords with a lot of entropy are hard to remember and type for humans, so usual passwords have low entropy. Forward secrecy is nominally about an attacker stealing a stored secret after the deed, but when the secret is subject to exhaustive search then the theft can be pure computational enumeration, without requiring the purloining of the physical piece of hardware. WPA2-PSK uses the password only through PBKDF2 with 4096 iterations, in order to make exhaustive search on passwords 4096 times slower. Nevertheless, even with a big, fat, completely randomish password (63 printable characters allow for encoding a lot of entropy), forward secrecy would not be achieved because that password is still stored in the entrails of the access point and the client systems.

To get forward secrecy, you need some tools from asymmetric cryptography. The usual method is to have some Diffie-Hellman key exchange algorithm; any pre-shared secret would then be used only for authenticating the exchange elements. This can even be made robust against offline dictionary attacks through Password Authenticated Key Exchange: PAKE protocols combine a key exchange (like Diffie-Hellman) and a password in order to do mutual authentication in a way which does not reveal to attackers anything which can be used to "try passwords at home" (roughly put, there is no password hash which can be observed by attackers). In any case, there is no asymmetric cryptography at all in WPA2-PSK, only hashing and symmetric encryption, so no forward secrecy.


What mechanism enforces user permissions in Unix/Linux?

Linux user permissions are just a form of ACL, stored as data structure as part of the file system. They're enforced by the operating system, but not in any solid sense - a file system driver or OS that doesn't recognise Unix-style permissions will just ignore them. The same goes for Windows file permissions, which are ignored on Linux systems.

Transparent file-system encryption is done via a key stored in the users database, which is in turn encrypted by the user's password. When the user logs in, the password is used to decrypt the key, which can then be used to decrypt the file data.


Is it possible to take over a Windows server through Oracle?

You can execute shell commands in PL/SQL is the scenario here. These will run with the privilege of Oracle, which might be LocalSystem. Obviously you will want to secure against this by restricting privileges to create stored procedures, running Oracle as a less-privileged user, and so on.

Once someone has an account then it’s the same as any other breach, they can do anything their new account can do.


If you don't trust sandboxed iframes, you could also use separate hostname for each package. E.g configure virtual host with *.previews.specialdomain.tld, and show each preview on different autogenerated hostname. You can then offer link to preview with

<a target="_blank" ...

That way, users will see the preview as a full page instead of iframe, and they get back to your original view after closing that (or by switching to previous tab/window).

Even though Google is convincing author for Caja framework, it seems unlikely they really can prevent all security vulnerabilities and not to break the JS code in some cases.


Recommendations for Changing the Default Shell For Service Accounts

The only true technical reason I'm aware of is the possibility of malicious file substitution.  Consider an attacker who finds a way to write to arbitrary files.  If they can overwrite /sbin/nologin or /bin/false with a copy of /bin/bash, then they can conceivably find a way to log in as a service user and continue to elevate their privilege from there.

However, /dev/null cannot be trivially replaced in such a manner, for various reasons:

It's a device, not a flat file
Anything written to it disappears, so a simple overwrite won't work
If someone did replace it with /bin/bash, it might then in turn be overwritten by one of the many programs that use /dev/null as a bit sink, thwarting the attacker
If someone did replace it, it could break some system functionality in a way that will alert the administrators that something is wrong, much more so than replacing 'nologin' or even 'false'.

There is also a non-technical reason, which is that many administrators are bound by tradition and/or the habits they learned long ago, and /dev/null was once a more common choice for this use (I'm pretty sure /sbin/nologin didn't exist 20 years ago).  Make of that what you will.


Will this system stop scalping and only let users by a maximum of 25 tickets per person?

Virtually everything you've described is susceptible to a smurf attack.  Cell phones are too cheap relative to the profit to be made.

A burner phone costs $40 cash. If tickets cost an average of $100 and I can scalp them for an average of $200, I stand to make $2460 on that $40 investment.  For $400 I can buy 10 phones, and make $24,600.  (I might have to hire 9 people to help me, but I can do that by offering $100 each for 30 minutes of work.)  Plus, I can reuse the phones for the next hot ticket.

If you really want to limit scalping, you can do it the old fashioned way:  open a box office, have people stand in line to buy tickets, and don't sell them online.  Attackers will ignore you and go for the easy online targets they already know how to exploit.  Of course, so will your customers.

EDIT:  I'm not saying that there is no way to protect an online environment from attacks; what this is concluding is that cell phones are inadequate sources of unique identities for this problem.  I also am not saying there is an easy or even a possible solution.  Approaches might include:

Find a more effective way to identify your users so you can better enforce the limits.
Reduce the per-purchase ticket limit to increase the cost-per-user to the attackers.
Raise ticket prices to the point where scalping is too risky to be profitable.

Something else to do is accept that scalping will exist no matter what you do, and explore other ways to offset the problems scalping causes:

Offer additional value to official ticket buyers by way of purchase-time-only perks, like access to an exclusive music videos that can only be downloaded from your site within one hour of the ticket purchase.  (Think of download/access codes to a site like Vudu or Netflix.)
Offer unrelated additional perks with rapidly expiring real-time value, such as a code redeemable for a restaurant meal that has to be used within 24 hours of purchase.

Be ever aware that scalpers will simply hire more smurfs when there is profit to be made.  They'll probably resell the restaurant codes, for example, but advertising this would help build resentment against buying scalped tickets, reducing their appeal.


my daughter just clicked a link she got on twitter and want to know is it safe and what does it do

— removed due to site policies regarding these kind of questions (there off-topic)


How similar are bots regarding their HTTP GET request?

If the requests generated by the botnet have a distinguishable pattern from legitimate traffic, then you can manually write rules in the firewall or web server to block these requests. A more advanced product could figure out those patterns and block them automatically.

http://code.google.com/p/mod-dosblock/ is an Apache module that helps against denial of service by allowing you to write rules about the HTTP headers and about the rate those requests come in.

The quality of the denial of service tool, meaning how well it simulates legitimate traffic, would make the detection easier or impossible.


Apache webserver behind firewall is a victim of proxy abuse and cannot use fail2ban to solve it

Evaluate mod_security - see https://www.modsecurity.org/about.html.

I don't know off the top of my head if there are rules to help with OP's problem - if there are, of course, use them.  If not rules are easily written.  Disable rules that are not applicable to reduce the negative performance impact the module will cause.

An additional benefit would be that of the overall Web Application Firewall framework.  You may find you need additional protections which Fail2Ban may not help fulfill.


Could this login form be "hacked" to allow access?

Well, with this, you can easily login with just the email, here's why :

The default query is :

SELECT aes_decrypt(password, 'asdasdasd') AS password FROM users WHERE email='$email';

Which mean, if :

$email = "bob@gmail.com";
SELECT aes_decrypt(password, 'asdasdasd') AS password FROM users WHERE email='bob@gmail.com';

Now, If I do this instead :

$email = "dontcare' UNION SELECT "mypass" AS password FROM users WHERE email='bob@gmail.com' LIMIT 1, 1";
$pass = "mypass";
SELECT aes_decrypt(password, 'asdasdasd') AS password FROM users WHERE email='dontcare' UNION SELECT "mypass" AS password FROM users WHERE email='bob@gmail.com' LIMIT 1, 1

Your code will receive the second query, get the password that will match "mypass", return true, so will auth me for the bob@gmail.com account.

Now, with "just" the code you showed us, an attacker can't display a whole table, but since the author of the code didn't take care of securing user input, I'd say that if it's not in that piece of code, there is a high probability that it's still possible some place else.


security protocol against attacks on SSL/TLS

Where is the additional security in your scheme? The Client supplies the key to the server (or attacker) so it can just be retrieved by an attacker.

Take a step back and explain what attack you are trying to defend against.
And can you explain how your current setup for TLS does not protect you already for this?

If (and I am guessing your purpose here) I am correct in assuming you want to add validation between client and server. This is achieved through something called Client-side certificates.


What the manual is referring to as rounds is probably better called iterations. While it is true that the SHA-2 function internally has a fixed number of rounds (64 or 80, depending on which hash is used), that is not what this manual is talking about. In order to make hashed passwords more secure, programs will often put the password through a KDF function such as PBKDF2, which runs a single hash function many times over to slow down brute force attacks. This is what "rounds" refers to in this context. The higher the round number, the longer it takes for a password to be processed and the more secure it is.


Shrewsoft hasn't been updated in 6 years either, but from your list if you look at OpenConnect CVEs there are a few listed over the years.

There are also various issues listed in Github.  The issues normally centre around DoS for the client from certain responses, or crashes/bugs in the program when making a request.  If your question was whether the encryption offered by a VPN is compromised in older programs, since they use well-defined algorithms that's probably not an issue.  If your question is whether they can be used securely on a system without issue, that's probably not the case since they mostly require root access to create a network interface.

Running any software that is not regularly updated or well maintained increases the number of vectors available for a malicious actor for attack however, so wherever possible using software that is no longer updated should be avoided.  Merely by installing them an issue might be created.


Are the Linux community/universe repositories significantly less safe then the main repositories?

No, it shouldn't scare you if you're worried about safety of packages. Though I do not recommend using it since it's not officially supported.
Universe is community maintained software, that is to say "not officially supported software".

I recommend you read this article so you'll understand the differences between Main, Restricted, Universe, and Multiverse repositories.
Good Luck


No.

Just because a hub's IC is programmable doesn't mean it's up-gradable by the USB interface it hosts. The common interfaces (SPI, ISP) typically used to update firmware are physically distinct from the USB lines. While you can smash open a hub and parasitically rewrite its flash (a lot of manufactures leave the programming/test pads exposed), there's no built in "firmware update mode" to do so over USB, no matter what you stick in the slot.

In theory, it's perfectly feasible to include a USB host interface into the hub's logic board. The hub would insertion-ding twice in windows and show up in device manager if so... But, it would cost extra to build an adapter into the design to provide such an un-wanted and frankly dangerous capability, so a mass-market manufacture would be highly un-likely to do so.


Does HTML Purifier (which converts & to &) prevent HTTP parameter pollution?

HTTP parameter pollution is the process of manipulating a URL in order to bypass parameter validation at the server or WAF. It is for example done by adding one parameter again, i.e. making the query string foo=1&bar=2 to foo=1&bar=2&bar=bad-value.

Note that a polluted URL is still a valid URL and that it might even be intended that way, for example by using web form with multiple input fields having the same field name. Because of this any kind of HTTP parameter pollution protection needs to know what kind of URL or parameters are actually expected.

The use case for HTML purifier is a completely different one: sanitize user-provided HTML before it gets included in some server generated HTML. A HTML purifier has has no idea of how the valid URL in the context of the application should look like and thus cannot help to protect against HTTP parameter pollution.

But using it could actually make the problem worse: for example if the query string of the URL has the parameters foo=1&bar=2 converting this to HTML will result in foo=1&amp;bar=2 which will result in getting a parameter amp;bar=2 extracted instead of the expected bar=2.


Encrypting an email server's local drives or filesystems

The system you're suggesting is fundamentally at odds with itself. If a password is required to access the drive, then it must be accessible during the boot process. Either it must be stored somewhere or it must be entered in by hand.

If you can't reconcile that one point, then you can't do encryption on your server.


How to convert a SSL certificate to an authority?

What you are looking for is to modify the certificate in a way that it contains the ability to be a CA, i.e. set the CA flag to true. Fortunately you cannot simply modify a certificate, because any kind of modification invalidates the signature and thus nobody will trust this certificate anymore. This  is essential because otherwise everybody could just create certificates for sites they don't own and this do man in the middle attacks.


What are the risk implications of not verifying referer header on login form?

A CSRF attack tries to exploit "the trust that a site has in a user's browser" (so says the Wikipedia page, and it is well said). It is about the server accepting a request from the client, on virtue of the request coming with some authentication characteristic which makes the server believe that it comes from the genuine user (which it does) and under the conscious control of the genuine user (which is false). The "authentication characteristic" would classically be a cookie value (acceptable for the server), or HTTPS with certificate-based client authentication.

For a login page, the server does not trust the request from the client. That's the point of a login page: to initialize trust. The login page expects a login and a password precisely because there won't be anything that the request can come with, which will make the server happier and distract it from its intended action, which is to verify the login+password pair. As such, CSRF attacks don't apply to this page.

You can still check the Referer field to check for "fishy business" (if it is absent or wrong, then something is definitely amiss), but it won't really change the security.


Basically, you set up a honeypot, whether you intended to or not. When you port forward, any protection the router provided is bypassed. So:

It's easy, but that's not generally how attackers work. Scanning is easy, and fast. Identifying what software is running is slower, so they tend to look for common flaws. Sadly, default passwords are one of those common flaws, so they probably scanned for boxes running Raspbian, and tried the default credentials on those boxes.

Normally, it would be a really bad idea. However, there is a slight saving grace in that the attacker was hitting a Raspberry Pi. By default, the boot partition is a read-only Fat32 partition in normal use, while the remaining space is a Linux format (probably ext based, but there are alternatives). This means that plugging it into a Windows box is unlikely to result in further compromise through the card. Similarly, any software running on the Pi won't work on Windows. However, any malicious file based attacks could work (e.g. uploading an evil PDF which you then looked at on another machine).
Safest option (Assuming you want to keep the card) is to format it from a live CD. Second safest option would be to access it from a Live CD from a machine with no writable drives and grab any files you need, virus scanning them before allowing onto a clean machine.

Depends on your network. Worst case, all your machines are compromised, all your data has been stolen, and you've been sending out attacks for the last few months. Best case, they didn't get past the Raspberry Pi. No way to tell which is the case without access to your networked devices.

Firewall everything, use strong passwords, ensure any machines which are accessible from the internet can't access the rest of your network. Standard network security stuff, basically.


What kind of encryption is this file using? It used to be plain text

Well, it may be encoded in binary instead of text. In that case, the data would still be there. But if the files are roughly the same size, than that most likely won't be the case.

If it is indeed encrypted and they used something standard such as AES-128, than there is no way to reverse it just using the file. Your only hope would be to extract the key from the app, which is very hard to do on mobile platforms simply because the proper tools don't really exist.

It is hard, if not completely impossible to determine what encryption is used just from the data and without the key.


Fuzzing with SPIKE - the \r\n not being taken into account

When writting my response to you, I remembered what might be the problem and I've tested it and bingo - that's exactly what's wrong.

The problem isn't with a script, but with a generic_send_tcp - this is not acting as it should. If I use the following command line:

line_send_tcp 10.1.1.169 21 ftp.spk 0

instead of

generic_send_tcp 10.1.1.169 21 ftp.spk 0

everything works. So that's it. Thanks.

I guess now we need to ask ourselves why does generic_send_tcp misbehave?


Is it possible to trace a MAC address to an individual?

Technically, it would be next to impossible to trace back a random MAC address to an individual.

Notwithstanding the fact that MAC addresses can easily be spoofed or changed (which means that your defender has bad opsec if they are using the default hardware MAC on the network), they are, at best, linked to a specific network card. This is a single component of the connecting machine which means that to trace it back you'd have to first go to the component's manufacturer before going to the actual device manufacturer. that is, if the part wasn't actually sold independently through a retail channel in which case it would be impossible to trace it.

So, it would be pretty much as hard as tracing back the owner of a car knowing only the serial number of it's tires. It makes little sense in practice but that doesn't stop TV shows and movies from "doing" it.

A more realistic way of identifying the individual behind a specific MAC address would be to take into account the proximity element: MAC address are not carried beyond the local subnet boundary which means the capturing device and the defender's device must share a lot in common. It's not unthinkable to identify the terminal using a specific MAC address on the local subnet based on the network properties itself. For instance, if you're taking about mobile devices, it would be possible to use a directional antenna to locate the device in question (for instance, using something like this).


Plain text password emailed back during registration

You don't know.

You technically don't even know whether the password is stored at all, let alone whether it's stored hashed. Them being able to email you the password immediately after you tell it to them says nothing of storage.


Are paravirtualized drivers a security risk?

Paravirtualized drivers will be a security risk only if the paravirtualization interface is designed in a way to leak hypervisor state or information to the guest. it is no more secure or insecure than having system calls in an OS or having applications talking to device drivers. If you think about it, guest talking to a hypervisor is similar to an application talking to the kernel.
The more entry points you add into the hypervisor, the larger your attack surface and the less secure.


What are examples of code found in Polymorphic anti-virus?

Signatures are only created after a piece of malware has been analysed. So whenever a malware comes out with a different byte pattern, the av relies on behavioral analysis of the malware, like if the malware if dropping a certain registry key or a file with a specific name, hooking a certain api function from windows etc.


Is storing plaintext passwords for email accounts any less bad?

Passwords, should NEVER be stored plain text, regardless what they are used for. People tend to reuse their passwords, meaning a person's email password could be the same for his facebook account or other more critical application. Therefore performing correct password hashing is imperative.


TLS server key: possible to sign another TLS server key?

Certificates have a purpose field. So if you let a well known certification authority sign your server key, the resulting certificate will only be valid for servers.

In order to sign other keys, you need to get a certificate with the certificate signing purpose. In theory there is an extension which limits CAs to a domain, but it is hardly used. Therefore there are very high requirements for CAs.


Is Blowfish validated against any standards?

Blowfish is an algorithm. An algorithm isn't validated against anything. What is validated is an implementation of an algorithm.

Blowfish isn't defined by any text that calls itself a standard, as far as I know. The original paper is the closest thing to an official specification. The author has also published test vectors.

You should not use Blowfish because it is weak for some applications. Better alternatives exist: AES, CAMELLIA, ChaCha... Blowfish's main flaw is that it has a 64-bit block size, which allows some attacks with a cost of only about 4 billion calculations, like Sweet32 for DES.

You should take this particular piece of advice with a grain of salt. Having an implementation that comes with an official FIPS 140 compliance stamp is actually a bad thing! The reason is that getting the official stamp is slow and expensive, and any bug fix requires going through this process again. So having an official FIPS 140 compliance stamp practically guarantees that your code has known bugs.

Additionally, FIPS 140 comes in several levels, and level 1 only states that the implementation performs its calculations correctly when given good input. That's all. Only levels 2 and above include some security requirements. Note that the “2” in FIPS 140-2 is the version of the specification, not the level.

What is important is:

Choose an algorithm that is well-known, and that is codified by some standard. This can be a government standard such as NIST publications, or an IEEE standard, or an IETF RFC, etc. Never use an in-house or recently-published algorithm. Always give the cryptographic research community a few years to try to break an algorithm before you start using it.
Pay attention to the security parameters and security properties (key size, block size, resistance against common attack techniques, …). Some standards permit obsolete or deprecated choices for backward compatibility.
Choose an implementation that has been, at a minimum, functionally validated against official test vectors. Preferably the implementation should come with interoperability tests that run against a well-known implementation such as the one by the author of the algorithm.
Choose an implementation that has undergone a security review.
Make sure that you have a process for keeping all copies of the software updated with the latest bug fixes.


Does Google log my activity on service A when logged in to service B or by IP address?

Google Privacy Preview
"We may collect information about the services that you use and how you use them, like when you visit a website that uses our advertising services or you view and interact with our ads and content. This information includes: "

Device information
Log information
Location information
Unique application numbers
Local storage
Cookies and anonymous identifiers

Yes, Google will be able to log your activity mutually through services. You do not even need to be logged. For example I was searching on Google for "online kids game" for my little cousin to play, later that evening I was using Youtube as usual and I was shown Kids Toys Advertisment for the first time on Youtube, coincidence (I wasn't even logged)? I doubt it.

Check out my answer on this question, I also give deeper details and info on how to protect your identity. Does Google record search / source IP [/ user] pairs?


Why are some DLLs not randomized? What makes it hard to deploy full ASLR for all DLLs?

There is some good information here. Apparently, a DLL can be subject to ASLR only if it is tagged as such, because of "backward compatibility issues". Although a DLL is, by nature, meant to be relocated, I can imagine that some (poorly) written software may do some tricks which rely on the DLL ending up in a relatively small range of the address space (a possible candidate would be some Garbage Collector that needs to distinguish between "pointers to data" and "pointers to code" -- I know that such issues occurred with some versions of Chrome's Javascript interpretor when launched on OpenBSD with Linux emulation).

If Microsoft went to the trouble of implementing an additional flag, then it is plausible, if not probable, that they encountered at least one case of such software that they could not ignore (backward compatibility is very important in the Windows world).

So DLL will allow ASLR to happen if the static linker said so, when the DLL was last built. This is a matter of using the /DYNAMICBASE flag. The documentation states that:

  By default, /DYNAMICBASE is on.

The documentations for Visual Studio 2010 and 2012 contain this sentence, but NOT the documentation for Visual Studio 2008. So one has to assume that most people who use Visual Studio 2010+ produce ASLR-compatible DLL, but most people who use Visual Studio 2008 or a previous version produce DLL which are not subject to ASLR.

In the page I first link above, one of the comments says:

  You can still use the Microsoft linker to do that, after your PE image is built. Use link /edit /dynamicbase (or editbin /dynamicbase ).

So you can "fix" a DLL, but that's assuming that the DLL will not break with ASLR, i.e. the lack of flag was just due to the default configuration of Visual Studio, as used by the DLL vendor.


How to use an OR condition with the content of a snort rule

This concept will do the trick for you.

alert tcp any any -> any 21 (msg:"FTP traffic"; pcre:"/USER|PASS/i"; sid:666; rev:1;)

This is a case-insensitive (/i) Perl Compatible Regular Expression (pcre) match for USER or (|) PASS.

If you want add additional commands then simply tack them on to the end of the regex like...

/USER|PASS|PASV|.../

To my knowledge having an OR operator for content matches is not possible. Instead make two rules (which you indicated you don't want to do).

Looks for USER
Looks for PASS

I have seen many people indicate that using PCRE in Snort is expensive and should be avoided. Supposing it's used effectively I don't think there's a huge issue but have never captured performance metrics since I rarely have used PCRE for rule matching myself. If you do use the above PCRE rule than strongly consider beefing it up with content and flow.  How it's currently written Snort will inspect every packet that matches the header (tcp any any -> any 21)!

http://manual.snort.org/node32.html#SECTION004523000000000000000
http://manual.snort.org/node32.html#SECTION00451000000000000000
http://manual.snort.org/node33.html#SECTION00469000000000000000

Without more details of where you are/where you're trying to get to/what you have available you should also check out the FTP preprocessor to see if it can help achieve your overall goal.

http://manual.snort.org/node17.html#SECTION003210000000000000000


Internal Pen testing - Can't get SMB Relay attack to work?

Close Server service and reboot:

To close it, log in as an administrator, and do the following:

In the run box, type "services.msc" and run the Services console
Scroll down to find the service "Server"
Right-click "Server" and select Properties
Stop the service, and then click the drag-down box in the center, and select Disable.
Restart the system.

Keep in mind that any services that depend on the Server service (e.g. Homegroups, print sharing) will fail. Consider creating a System Restore point prior to making the change.


Online dealer asks for a photo of my credit card and driver’s license, and also all numbers from my card, is it ok?

Run away!

The only information an online shop should need is address (delivery or invoice, one of which needs to match the card), cardholder name, card number, expiry date and CVV on the back.

Your card issuer will handle any additional authentication - and there's new regs coming in over the next few months to tighten up on this - and this does not go back through the merchant.

The only reason I could think of for additional info like drivers licence or utility bill is you're opening a line of credit with them and they're running a credit check, buying age-restricted items or something that needs a licence to purchase.


Are future TLS versions going to prevent traffic inspection?

TLS by itself protects the sniffing and modification of traffic between two endpoints, i.e. client and server. TLS interception just makes two TLS connections where only one was, i.e. client to interception device and interception device to server. This will still work with future TLS versions.

TLS interception is only possible if the validation of the endpoints does not detect the interception (or explicitly allows it). How the validation of the endpoint is done is not part of the TLS protocol itself and thus changes to the TLS protocol will not affect this part. Thus the current mechanisms for SSL interception by using a trusted proxy CA will still work as does SSL pinning if interception should not be allowed. Note that today's browsers will ignore pinning if the certificate is signed by an explicitly added CA, which means that pinning will be ignored when legal TLS interception is used. But this again is an issue of validating the certificate and is unrelated to the TLS version.


Database Security - Encryption & Searching

For the threats you mentioned the encryption of database is not really necessary.

malicious users is a too broad definition. What threats do you expect? For instance, if you mean a threat that the user finds a way to get more privileges in the application than you assigned him or a threat that the user can impersonate him as some other user, then he will get the data that the application provides him, i.e. unencrypted data. Database with data encryption will not change anything.
persistent XSS protection has nothing to do with database encryption. If your XSS protection fails, then the application will execute the malicious action triggered by XSS just like any other action of the user. It does not matter if the database is encrypted or not.
hardware theft is more complicated. If the attacker can boot the OS and if the file system is not protected, then the attacker can put malicious code or crack your application code, launch your application and via application get access to the encrypted data, or even directly get access to data via database API. I would suggest you use an encrypted file system instead and to protect booting (and thus decryption) with a password. And when you create backups (database, configuration, maybe logs), encrypt them, too. Then the usage of encrypted DB will not give much additional security, whereas it will cost you much overhead. That's why you can use any normal database.


The benefits of CISSP Training for a Java developer

It depends on what you're aiming for. The CISSP is said to cover topics "one mile long, one inch thick", so it's everything from malware, organizational stuff, disaster recovery, cryptography, physical security (which fire extinctors for which fires), identity management, even secure deveopment and testing. So it's veeeeeeeeeeeeeeeery broad but every topic is covered pretty superficially.
So if you're aiming for a security career then it is a helpful asset, definitely. But if you are more a technical guy and you want to stay technical then I would do something where you can develop a rare technical competence. the CISSP training book has more than 900 pages. If you want to get the certification you REALLY REALLY need to spend a lot of time on this stuff (I doubt a one week training will be enough).


You need to start with understanding your obligations under HIPAA and HITECH.  After that, you can read Windows Azure HIPAA Implementation Guidance.  You should also refer to 19006 Federal Register /Vol. 74, No. 79, Guidance Specifying the Technologies
and Methodologies That Render
Protected Health Information
Unusable, Unreadable, or
Indecipherable to Unauthorized
Individuals for Purposes of the Breach
Notification Requirements Under
Section 13402 of Title XIII (Health
Information Technology for Economic
and Clinical Health Act) of the
American Recovery and Reinvestment
Act of 2009; Request for Information
, which delineates certain other documents that pertain.

FIPS 140-2 Annex A algorithms (exclusively - 3-key TripleDES, AES (any length), SHA-1 and SHA-2 (any length), and RSA only, unless you really like Skipjack) are a bare minimum.  NIST SP 800-131A offers additional guidance (which boils down to: no more SHA-1, no more RSA less than 2048 bits, no more DSA with a |p| less than 2048 bits or a |q| less than 224 bits).

You should also find a consultant who is an expert in both HIPAA and HITECH, as well as whatever other regulations cover what you're doing.  Highly regulated areas like PHI storage are not places to wander into lightly or blindly.


Yes, these commands are effectively the same:

gpg -c < file > file.gpg
gpg --output file.gpg --symmetric file

First, -c is just a shorthand for --symmetric:

 -c, --symmetric             encryption only with symmetric cipher

Also note that the characters < and > are used in Bash for I/O redirection, they are not part of GPG's option syntax.

What's going on here is that GPG can take input from either stdin or a file specified as an argument. Instead of giving the filename as an argument, < FILE just feeds it via stdin. When GPG notices that input is given via stdin, it will print the output to stdout by default instead of creating a file (unless you use --output). So you can just redirect stdout with > FILE to write the encrypted data to a target file.


Security implications of WAF revealing internal IP addresses

What are the security implications of a web app firewall/load balancer
  revealing internal IPs of the web sites behind it to the outside
  world?

If when you say, "internal IPs" you mean the web server's LAN address (i.e. same datacenter, private networking, etc.), then you have a scenario similar to WebRTC revealing your computer's private IP address.

The greater risk is if when you say, "internal IPs," you mean remotely-accessible (i.e public facing) IP addresses that we just don't talk about and rely on security by obscurity for to conceal and protect. In this case, the attack surface here is your entire web server as it is directly accessible from the Internet, and simply learning its IP address would allow an attacker to completely bypass your web application firewall and any blocking & logging it might have.

For defense in-depth, you might consider the following access controls:

Creating firewall rules on the web server to only allow inbound traffic FROM your load balancer, precluding direct access from any other network/IP, even if it was leaked.
Removing the server's public IP, and only use private networking

Of course, this implies a balance in security vs. maintainability. I would imagine you will still need a way to remote-in (i.e. VPN, SSH, or possibly via infrastructure management software like Chef, Puppet, continuous integration process, etc.) but the point is that you would do so under tighter access control that would render knowledge of your server's IP mostly useless.


Preventing softwares from leaving traces in Windows | deleting the traces easily

You're going to have a hard time doing this - Windows is pretty well known for spraying information about what files you've accessed and the contents of those files all over the disk. For a start, even having it on your system might get it indexed, which means its contents are already copied over to the index database before you've even opened it.

One option for actually opening it is Sandboxie, but even that's not a solid solution if the OS is actively caching copies of it to the volume shadow copy and index databases.

My suggestion would be to set up a Windows VM inside a TrueCrypt container, save a snapshot of that VM, then load the sensitive documents in and read them. Once you're done, revert the snapshot back. If an attacker later compromises your system, they'll only see the encrypted TC volume. If they force you to decrypt it, there's a good chance that the snapshot revert has wiped all traces of the document and your access to it from the system.


If there is a intercepting proxy between the web server and the client, mostly the proxy uses its own signed certificates which the client may or may not trust. Then why don't proxy just take the certificate from server and forward it to client so the client will trust it. Also if the private key is only held by the server, then how come an intermediary give its own certificate and decrypt the message?

If the intercepting proxy uses self-signed (or signed by it's own CA) certificates generated on the fly, the certificate passed to the client won't be trusted, as it has no valid certificate chain. If the certificates or the used CA is trusted by the client (which is often the case in internal networks), all traffic can be sniffed without suspicion by the gullible user. However, you can detect the interception by looking at the certificate (chain) in your software.

If the proxy does not use its own certificate but the certificate of the server, it can't decrypt the traffic. The public key in the certificate always corresponds to one specific private key, which is not known for others.

The server certificate contains a digital signature of the CA (mostly an intermediate certificate), which is a signed hash value. The signature is generate with their private key and can be verified with the public key using the next certificate in the key chain. This can be repeated several time, until a certificate is given, which has no parent and is trusted by the client (Root-certificate)

  The signature hash generated by the private key can be decrypted with a public key. Can't someone decrypt that other then the client and can see the signature?

The signature does not contain any confidential information. Usually the signature is based on a hash value of a file, message or (parts of) a certificate. Everyone with the public key can verify the signature and compare the hash values. If they do match, the signature is valid, otherwise not.

See also What is the actual value of a certificate fingerprint?

  Does the client already has the public key with which it starts the encrypted message or do it first ask the server?

Unless the client uses certificate pinning, it does not have informations about the servers certificate and public key. The server sends the certificate at the beginning of a TLS session.


Does the X-Permitted-Cross-Domain-Policies header have any benefit for my website if I'm not using Adobe products?

You have it the wrong way round. Much like Access-Control-Allow-Origin the purpose is to allow other systems (in this case specifically web-hosted Flash and PDF content) to access your domain. The "remote domain" is you, the "source domain" is who we're defending against.

  When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.

By default, all cross-domain requests will be blocked by Adobe's software, the same as browsers block cross-domain XMLHttpRequest.

An unwanted policy file may find its way onto your site, either by accident or malice. The purpose of adding X-Permitted-Cross-Domain-Policies in this case is to override it, so that the client still blocks unwanted requests.

Microsoft Silverlight uses a different policy file format, but it may also still use this header.

If you allow people to upload files, or are concerned about intruders using a different flaw to get files onto your server AND the content on your domain should not be accessed via other websites possibly trying to impersonate you, then yes X-Permitted-Cross-Domain-Policies will provide a security benefit. The attack is less relevant these days, as any user of modern software first needs to be tricked into allowing Flash or active PDF content.

If your website is just a regular website with nothing that requires a login to access, then you don't need it.


The iOS firmware installation process over USB requires "SHSH blobs" which contain the iOS version string and unique device ID and which are then signed by Apple. The iOS bootloader requires that signature before it will load and execute that code. I assume OTA updates are similar and as a result also require SHSH blobs.

Why is the signed device ID necessary? Ask Apple, not us. Most likely it's a defense mechanism against downgrading to vulnerable firmwares (for jailbreaking) since you need the matching SHSH blobs which Apple no longer signs if a new firmware release is available. This is actually mentioned in your quote, they want so that "an old iOS version from one device can’t be copied to another".


'Ghost' access to a php file on a web server

The IP addresses seem to belong to a plethora pf european ISPs/data centers:

inetnum:        83.31.0.0 - 83.31.255.255
netname:        NEOSTRADA-ADSL
descr:          Neostrada Plus
descr:          Warszawa
country:        PL

inetnum:        178.217.184.0 - 178.217.191.255
netname:        HOSTEAM-1
descr:          HOSTEAM S.C.
country:        PL

inetnum:        91.0.0.0 - 91.23.255.255
netname:        DTAG-DIAL22
descr:          Deutsche Telekom AG
org:            ORG-DTAG1-RIPE
country:        DE

inetnum:        91.78.0.0 - 91.79.255.255
netname:        MTU-PPPOE
descr:          Comstar-Direct CJSC
descr:          Mamonovskij pereulok d.5
descr:          P.O. BOX 38 123001
descr:          Moscow, Russia
country:        RU

This one should be google's

NetRange:       8.0.0.0 - 8.255.255.255
CIDR:           8.0.0.0/8
NetName:        LVLT-ORG-8-8
NetHandle:      NET-8-0-0-0-1
NetType:        Direct Allocation
OrgName:        Level 3 Communications, Inc.
OrgId:          LVLT
Address:        1025 Eldorado Blvd.
City:           Broomfield
StateProv:      CO
PostalCode:     80021
Country:        US

A couple of suggestions, you pasted the url  with the IP parameter set somewhere and it's ended up on a webpage and being crawled as previously suggested. Other examples is that you pasted it somewhere where non public robots are validating the page. Examples of this is antivirus scanners, so pasting it in skype/emails could account for the traffic. Lastly, it could be side effects of having malware on your computer, but judging by the source IPs that hit your page I think that is unlikely.


What methods could be used to host on an infected machine?

Yes, one of you main concerns will be to disable UPnP (Universal Plug 'n Play).

UPnP could allow a malicious program to bypass the firewall entirely, allowing other computers to directly contact a network service hosted on the compromised machine.

UPnP assumes local programs are trustworthy and allows them to forward ports. If malware not being able to forward ports is important to you,
you’ll want to disable it.


Websites Forcing Weak Password Standards (Updated)

If you use the same password for several distinct sites, then you are doing something wrong. Each password shall be site-specific. Therefore, there shall be no reason why the "weaker standards" would have any impact on "all your passwords".

(Similarly, there is no rational reason for changing all your passwords on a regular basis. There is a widespread custom of frequent password renewal, but it is a "common practice", certainly not a "best practice".)

If you have site-specific passwords, then poorly designed requirements will impact that site only. Ultimately, each site maintains its own security, and their "password requirements" are part of it. If a site enforces a maximum password size of 8 characters, then this means that:

The site owner does not have a good grasp of security.
The site is most probably weak in many ways; the weird password requirements are, usually, only the tip of the iceberg.

Thus, concentrating on the password misses the point. That site's security stinks and you can do nothing about it, except isolating the troublesome site, which is done by not reusing passwords.


"openssl crl" verify gives "Error getting CRL issuer certificate"

TLDR: IT'S THE WRONG CERT

The issuer name in that CRL is

$ openssl crl -in file0 -noout -issuer
issuer=/C=IN/O=Gujarat Narmada Valley Fertilizers Company Ltd./OU=Certifying Authority/postalCode=380054/ST=Gujarat/street=Bodakdev, S G Road, Ahmedabad/houseIdentifier=301, GNFC Infotower/CN=(n)Code Solutions CA 2011-1

The subject name in your purported signing cert is

$ openssl x509 -in file1 -noout -subject
subject= /C=IN/O=Gujarat Narmada Valley Fertilizers and Chemicals Limited/OU=Certifying Authority/postalCode=380054/ST=Gujarat/street=Bodakdev, S G Road, Ahmedabad/houseIdentifier=301, GNFC Infotower/CN=(n)Code Solutions CA 2014

These are not the same. The first one is 'Fertilizers Company Ltd.' while the second one is 'Fertilizers and Chemicals Limited' and the year (or year-like number) in CN is different.

In addition, if I ignore this mismatch and check manually, the RSA signature in the CRL does not 'decrypt' (more accurately, recover) to valid PKCS1-v1_5 padding using the key in the purported signing certificate. This means it was signed with a different keypair, which must have a different cert.


What can be done to limit corporate Identity theft?

This is a vary difficult problem from the corporate perspective. I'm assuming
from your question, you are more interested in what the business can do rather
than on what the individual can do.

I think there are two main areas that business should focus on in order to
reduce the risk of their data being compromised and used for identity theft

Staff awareness and education
Increasing corporate capability maturity

The majority of data breaches are initiated through social engineering attacks
against staff. These often take the form of email phishing and spear phishing attacks
against staff. Increasing staff awareness of these types of social engineering
attacks is a good way to reduce the risks. This is why many large organisations
now actually conduct phishing campaigns against their staff as a training
process. For exmaple, Twitter does this as part of the new staff
induction. There are a number of companies, such as Phish5, which provide this
sort of service to corporations.

The other thing which business should do is have clear policy and procedures
regarding data collection, storage and destruction, policy and procedures
relating to data governance, classification and custodianship which makes it
clear who is responsible for ensuring all data meets corporate policy and
procedures.

However, having these policies and procedures is not sufficient. The corporation
also needs to have procedures in place to ensure these policies and procedures
are being followed and that they are reviewed on a regular basis. This is
essentially the capability maturity model (CMM). In this model, a corporation
maturity is measured according to where they sit with respect to documentation
of policy and procedures and level of adherence. The levels, from lowest to
highest tend to be along the lines of

1. Policies and procedures are ad hoc and not documented
2. Policies and procedures are documented, but may not be adhered to
3. Policies and procedures are documented and adhered to, but adherence is
   not verified
4. Documented policies and procedures are adhered to and adherence is
   verified (logged, audited, etc)
5. Documented policies and procedures are adhered to, verified and reviewed
   on a regular basis.

Generally, staff will attempt to do the right thing. However, the right thing is
not always obvious. Having clear policies and procedures will help with this by
providing staff with the necessary information to ensure awareness of the issues
and requirements. This leads to more mature business processes which are less
likely to have inconsistency or rely on assumptions which may not be valid. It
also helps ensure the right culture within the organisation.

Critical to achieving a data aware and mature corporate culture is leadership
and governance. There has to be a determined effort by the executives of the
organisation to establish a culture where client data is valued and protected
and managed in a consistent and safe manner. For larger organisations, this is a
complex and challenging goal and can take considerable effort to achieve.

There is also a need for consumers to become more demanding. Often, corporations
will only improve when it becomes obvious that not doing so will affect the
bottom line. As consumers, we really should look at things like the service
providers privacy policy and be willing to not use the service if that policy
doesn't provide sufficient protection. We should all adopt a proactive position
and refuse to use a service if that service is not willing to demonstrate they
will take sufficient action to ensure our personal data is sufficient
protected. We should demand to know how they will use our data, when they will
destroy our data, what protections they have in place for our data and that they
will inform us of any incident which may have compromised either the
confidentiality or integrity of our data. Unfortunately, too many of us are
willing to give up our personal data too easily.


Why is it bad encrypt to with plain passwords as encryption key?

A distinction needs to be made between the password you provide an encryption tool and the internal key it actually uses.

There is nothing inherently wrong in using a plain-text password providing it is long enough to be unguessable within a reasonable electronic timeframe. The level of unguessability is generally considered the level of entropy in the data set; although even very sophisticated statistical tests can only make educated guesses about actual unguessability (e.g. A truly random string is entirely guessable if everyone in the world has memorised it).

Most encryption algorithms require a fixed amount of internal entropy to work. Your password will contain a certain amount of entropy, usually less than the cipher uses. So your password is usually converted into its pure entropic bits which are then "stretched" across the internal key space in a manner appropriate to the cipher.

The stretching (or shrinking) is also required to ensure that semantic similarity across, say, natural language passwords, does not deform the possible range of cipher-text output. You do not want natural languages passwords (i.e. most passwords) to only produce cipher-text of predictable fraction of all possible outputs; as you could then infer type and even the length of password used.

As an end-user of any competent encryption tool you do not need to worry about this as it occurs behind the scenes. But you will need to know if directly using these libraries.


How and why does case insensitive XSS work, given that JavaScript is case sensitive?

<iMg SrC=x OnErRoR=window.location=123>

The mixed case parts in your example are not the Javascript but the HTML. And HTML is case insensitive

<iMg     HTML img tag (i.e. image), case insensitive
SrC      src attribute for HTML img tag, case insensitive
OnErRoR  onerror attribute for HTML img tag, case insensitive

window.location=123  - Javascript, case sensitive


Looking up the address in the ARIN database the following results are given:

NetRange:       54.192.0.0 - 54.207.255.255
CIDR:           54.192.0.0/12
NetName:        AMAZON-2011L
NetHandle:      NET-54-192-0-0-1
Parent:         NET54 (NET-54-0-0-0-0)
NetType:        Direct Allocation
OriginAS:       AS16509
Organization:   Amazon Technologies Inc. (AT-88-Z)
RegDate:        2013-06-19
Updated:        2013-06-19
Ref:            http://whois.arin.net/rest/net/NET-54-192-0-0-1

OrgName:        Amazon Technologies Inc.
OrgId:          AT-88-Z
Address:        410 Terry Ave N.
City:           Seattle
StateProv:      WA
PostalCode:     98109
Country:        US
RegDate:        2011-12-08
Updated:        2014-10-20
Comment:        All abuse reports MUST include:
Comment:        * src IP
Comment:        * dest IP (your IP)
Comment:        * dest port
Comment:        * Accurate date/timestamp and timezone of activity
Comment:        * Intensity/frequency (short log extracts)
Comment:        * Your contact details (phone and email) Without these we will be unable to
identify the correct owner of the IP address at that point in time.
Ref:            http://whois.arin.net/rest/org/AT-88-Z

OrgAbuseHandle: AEA8-ARIN
OrgAbuseName:   Amazon EC2 Abuse
OrgAbusePhone:  +1-206-266-4064
OrgAbuseEmail:
OrgAbuseRef:    http://whois.arin.net/rest/poc/AEA8-ARIN

OrgNOCHandle: AANO1-ARIN
OrgNOCName:   Amazon AWS Network Operations
OrgNOCPhone:  +1-206-266-2187
OrgNOCEmail:
OrgNOCRef:    http://whois.arin.net/rest/poc/AANO1-ARIN

OrgTechHandle: ANO24-ARIN
OrgTechName:   Amazon EC2 Network Operations
OrgTechPhone:  +1-206-266-4064
OrgTechEmail:
OrgTechRef:    http://whois.arin.net/rest/poc/ANO24-ARIN

NetRange:       54.200.0.0 - 54.203.255.255
CIDR:           54.200.0.0/14
NetName:        AMAZO-ZPDX6
NetHandle:      NET-54-200-0-0-1
Parent:         AMAZON-2011L (NET-54-192-0-0-1)
NetType:        Reallocated
OriginAS:       AS16509
Organization:   Amazon.com, Inc. (AMAZO-47)
RegDate:        2013-07-17
Updated:        2013-07-17
Ref:            http://whois.arin.net/rest/net/NET-54-200-0-0-1

OrgName:        Amazon.com, Inc.
OrgId:          AMAZO-47
Address:        EC2, EC2 1200 12th Ave South
City:           Seattle
StateProv:      WA
PostalCode:     98144
Country:        US
RegDate:        2011-05-10
Updated:        2014-10-17
Ref:            http://whois.arin.net/rest/org/AMAZO-47

OrgAbuseHandle: AEA8-ARIN
OrgAbuseName:   Amazon EC2 Abuse
OrgAbusePhone:  +1-206-266-4064
OrgAbuseEmail:
OrgAbuseRef:    http://whois.arin.net/rest/poc/AEA8-ARIN

OrgTechHandle: ANO24-ARIN
OrgTechName:   Amazon EC2 Network Operations
OrgTechPhone:  +1-206-266-4064
OrgTechEmail:
OrgTechRef:    http://whois.arin.net/rest/poc/ANO24-ARIN

OrgNOCHandle: AANO1-ARIN
OrgNOCName:   Amazon AWS Network Operations
OrgNOCPhone:  +1-206-266-2187
OrgNOCEmail:
OrgNOCRef:    http://whois.arin.net/rest/poc/AANO1-ARIN

It's an amazon hosting service with 287(as of this time) domains hosted on that address. Reading the webmin installation page you must

  Enter the same login credentials that you used to log in to your
  server via SSH. This user must have root privileges via sudo.

Webmin listens by default on port 10000:

https://server_IP_address:10000

It is possible that you installation was discovered by a crawler, and the authentication was bypassed(as the address is the public address of the given work station). Strangely, altering those configurations doesn't benefit any potential attacker. However, since the given address is not related to any utilities that you've used it is recommended that you reinstall and start clean. Optionally you can write an email to the abuse address above, and ask for details on traffic from that box to your own if possible.


How (un)safe is it to protect an admin page with a simple query-string password?

If it is a query string, and I am assuming it is served over a non secure channel the url will be cached in browser history, intermediate caches and passed via refer parameters when navigating to other urls.  It may be acceptable if it is purely to view feedback before you make it public.  If it is more important I would put better controls in place.


How does getting a remote shell via exploiting a vulnerability really work?

Vulnerable programs need to listen to ports in order to access them over the network directly. But, you could gain access to the system through other means then exploit a vulnerable program that does not access the network (e.g. email malware that triggers a vulnerability in a PDF reader)
Knowing how the vulnerable program behaves predictably is the key to finding and exploiting vulnerabilities. In short, you have to already know what will happen in the stack before you send the exploit. That's why, just like all programming: testing, testing, testing.
If you understand BO, then you know that you write to the stack in a place where the pointer will direct the execution. That's how we can execute our code.
Just as in my #1, the vulnerable program does not need to be a network service running on a port. If you want a 'reverse shell', then the code for the shell must include the networking code required to connect back to you.
Yes, and yes. If you do not migrate to another process (either embedding into a running process or a new process triggered by your code), then once the vulnerable program ends, so does your connection. So, migrate.

My answer is a VERY simplistic view of your questions. There is a lot you can do to dig deeper in what I have provided, and even techniques that will contradict what I have said, but these are the very basics.

Simplistic Scenario:

A vulnerable FTP server is running on a port. You discover that a certain FTP command is not properly constrained, so it is possible to send overly large command arguments and write into parts of the stack that the FTP server accesses. You design code (including networking features) that can fit on to the stack space occupied by the FTP program. Then you connect to the FTP server and send the command with your shellcode as the payload. When the FTP server processes the command, it hits your code and processes the payload. Your shellcode executes and creates a networking connection back to your machine.


Is there any MAC like hmac-sha2-256-96 mac in openssh?

No, there is no such MAC. The list of available MACs can be queried using ssh -q mac:

$ ssh -Q mac
hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com

If I see right, you were trying to combine the hmac-md5-96 with hmac-sha2-256, but it does not make any sense.

The last number says the length of the hash (why to specify it twice?), in the MD5 case truncated to 96 bit (out of 128 bit), but in the SHA2 case, the last number simply gives the length of the hash (because SHA2 has variable hash-length, not only truncation as the long broken MD5).


It depends on how it's deployed. Usually you'll have to whitelist specific calls from your application, but at system level you can apply policies that only a subset of the system is confined.

As perfectly stated by Wiki's FAQ:

  Is AppArmor policy Default Deny (White listing)

  Yes, and no. AppArmor profiles are based on default deny, that is the
  rules list what is allowed and everything else is denied. AppArmor
  policy allows specifying rules to deny actions but these are
  convenience function to document known bad behaviors, or to specify
  actions that should never be allowed even if an rule allowing it was
  added to the profile.

  At a system level AppArmor can be consider either default deny or
  default allow depending on how it is deployed. If AppArmor is deployed
  with a complete system policy so that all tasks are confined then
  the deployment can be considered default deny. However AppArmor
  allows policy to be deployed incrementally so that only a subset
  of the system is actually confined, in this case AppArmor could be
  considered to be default allow at the system policy level but anything
  that is confined is confined by policy that is default deny.

  What is Default Deny (White listing)

  Default deny describes the default action applied to a request that
  is not listed in policy, in this case deny. Policy that is based on
  default deny provides a list of actions that are allowed (white list)
  and any thing not listed in policy is denied.

  Default deny is considered more secure than default allow because it
  only allows known good behavior.

source


How does the Yahoo webmail exploit work?

The fake MSNBC page probably contained a Cross-Site Request Forgery (CSRF) attack on the Yahoo webmail.

These attacks exploit web application functions that don't check for user's identity in a proper way, but blindly trust the session cookies. Therefore, if you were logged into Yahoo mail at the time of the attack, the web application had no way of telling whether your requests were legitimate or not, as your browser automatically sends the proper cookies to Yahoo.

You are not noticing anything strange with Yahoo's activity logs because the browser who actually sent those e-mails is yours and the attacker never gained full control of your account (but just of the vulnerable features).

  I have an antivirus/firewall solution which is continuously updated. I have a wireless router with fairly strong security settings on it (not using the defaults or anything), with (medium strength) wireless password, MAC filtering and WPA-WPA2 encryption.

While these security solutions are all fine, they won't protect you from CSRF (or similar web-based attacks). The best defense mechanism in this case is using a script-blocker addon (e.g. NoScript) and only allow trusted domains to execute code.

My final suggestion is to always logout of critical web applications (e.g. home banking) after the use in order to minimize the chances of getting CSRFed and to report the malicious link to Yahoo, hoping they will fix the vulnerabilities.


How to provide user friendly WiFi access to gym members with WPA2 Enterprise?

You could develop a profile which contains the network key, as far as i am aware this means that the key isnt viewable by the user. This could be downloadable from the gyms website member area.

Maybe using apple configurator for the IOS devices?


Malware removal: Iframe injected javascript

It is more likely the attacker has succeeded to install a backdoor. It is by nature hidden, and quite hard to detect and disable.

You need to check some important and classic directories such as the one you use to upload images or other files because you usually trust such directories and never check what is inside them. Also, if your Joomla website has inactivate themes, it is better to delete them because they are targetted by hackers to incubate their backdoors, usually.  Also, you will need to check the source code of your most sensible files (such as configuration files). At the end you will need to change your credentials and ask the users of your website to do the same, but also the credentials you are using to access your server.


Merely checking the MD5 hash of a DLL might not be secure enough, since MD5 is not resistant to Hash Collisions and cannot be consideres safe anymore. An attacker could inject malicious code into an DLL and alter it in a way that the malicous DLL returns the same MD5 hash as the "real" DLL.

As @schroeder mentioned, you probably want to use a signature based approach where only DLLs which are signed with a trusted and known certificate (e.g. by the lead developer) are permitted to be used.

This however leads to a few new problems, e.g. certificate management, trust management, etc.


Are there any risk in serving static assets via compressed SSL protocol from 3rd party domain?

First note that you are not using SSL-level compression, but HTTP-level compression: there is a HTTP header which describes the mode of compression. The compression is applied to the HTTP response body only, i.e. the colors.min.js file, at the exclusion of anything else, in particular HTTP cookies or other such values.

Compression is unsafe when applied on secret values and the attacker has the possibility to get many examples of compressed data with the same secret repeated in all of them, but also with variants. In particular when the attacker gets to insert data chosen by him within the data sequence that is compressed.

In the case you show, there is no secret data at all; the data sequence that is compressed is a completely public piece of Javascript. Compression is abused into attacks by its ability to leak information about data contents through the data length (and the length is not protected by any subsequent encryption). If the source data is completely public, then there is no information to leak, and therefore no attack.

(Though colors.min.js is public, you still want to get over HTTPS, not for confidentiality but for integrity: you want to prevent active attackers from changing the Javascript code on the fly.)

Even if the compressed data was not public, a static file could still be served with compression, because compression is deterministic and would yield the exact same sequence of bytes every time, so, in particular, always the same length -- nothing to learn for the attacker.


Getting reliable checksums

The checksum itself is reliable for what it should be used. But your expectation is wrong.

The purpose of the given hash if not to check against attacks but for inadvertent file corruption (bit flips, missing ends...). It can not be used for authenticity since both the hash and the file are served by the same site and a hacker could simply replace both when hacking the site. For checking authenticity you would need a digital signature signed by the author and not a simple hash.


How can I circumvent the lack of Java updates?

It sounds like you are in a corporate environment with in house or vendor specific applications needed for business. You should be able to use a combination of code signing and whitelisting to setup policies where it will only run the JAVA applets and applications that are authorized. This is not full proof, but may help to reduce infections.

See the JAVA documentation:

  Very High:  You are prompted to accept apps that are signed with a
  trusted certificate. All other apps are not allowed to run. If the JRE
  is below the security baseline, you are given an option to update.


Do XBAP applications have the same vulnerabilities as Java Web Apps?

XABP is documented to run on Firefox too. However, it does not seem to be supported by Chrome, or on any browser when the underlying OS is Linux.

XBAP tries to apply the same model as Java applets, and that is known to be a hard problem, therefore a fair share of similar vulnerabilities can be expected. E.g. such as this one, which is recent (January 8th) and looks scary (complete hijack of the computer by browsing a malicious Web page), but, strangely enough, does not make the news, contrary to Java applet holes. I think it tells quite a lot on the current deployment of XBAP (i.e. almost nobody uses it, even potential attackers).


The SSL protocol is implemented as a transparent wrapper around the HTTP protocol. In terms of the OSI model, it's a bit of a grey area. It is usually implemented in the application layer, but strictly speaking is in the session layer.

Think of it like this:

Physical layer (network cable / wifi)
Data link layer (ethernet)
Network layer (IPv4)
Transport layer (TCP)
Session layer (SSL)
Presentation layer (none in this case)
Application layer (HTTP)

Notice that SSL sits between HTTP and TCP.

If you want to see it in action, grab Wireshark and browse a site via HTTP, then another via HTTPS. You'll see that you can read the requests and responses on the HTTP version as plain text, but not the HTTPS ones. You'll also be able to see the layers that the packet is split into, from the data link layer upwards.

Update: It has been pointed out (see comments) that the OSI model is an over-generalisation and does not fit very well here. This is true. However, the use of this model is to demonstrate that SSL sits "somewhere" in between TCP and HTTP. It is not strictly accurate, and is a vague abstraction of reality.


What is sizeofblock used for in image_base_relocation table?

According to MSDN : (go down to PE File Base Relocations part)

The relocation section is array of blocks, each one contains:

(IMAGE_BASE_RELOCATION, relocations binary chunck)

In order to calculate how many relocations in specific block you need to take SizeOfBlock out of IMAGE_BASE_RELOCATION subtract the size of an IMAGE_BASE_RELOCATION and split by each relocation size (which is sizeof(WORD)=2 bytes):

(Relocation->SizeOfBlock - sizeof(IMAGE_BASE_RELOCATION)) / sizeof(WORD)

hope this help you


Are there any open source firewalls for a VPN server?

Did you try pfsense ?

https://www.pfsense.org/

I implemented it into few companies infrastructure via small appliance.
(you can also DL the iso and install it on your own hardware)

Powerfull, flexible and opensource. I strongly recommend it.


GPG encryption failed - Unusable public key

My guess would be that you are trying to use an ECC key (or subkey). The version of gnupg that comes with Amazon Linux is too old to support ECC cryptography. If you look at the output of gpg --list-key 40BXFE61, you can check for any pub or sub entries that have cv25519 or nistp256 in them, e.g.:

pub   rsa4096/E63EDCA9329DD07E 2011-11-07 [SC]
      DE0E66E32F1FDD0902666B96E63EDCA9329DD07E
uid                 [ultimate] Konstantin Ryabitsev <konstantin@linuxfoundation.org>
sub   rsa4096/0BED129D9916360E 2015-11-02 [A]
sub   ed25519/B6C41CE35664996C 2018-02-09 [S]
sub   cv25519/86D203575A83079D 2018-05-02 [E]
sub   rsa2048/3FF293496E43D963 2018-05-02 [A]

GnuPG 2.0 and earlier only have support for RSA/DSA keys. Unfortunately, there isn't much you can do to support ECC keys on Amazon Linux, short of building gnupg-2.2+ on  your own.


How genuine are password entropy calculations?

"Entropy" for a password is (roughly) a description of how many different passwords you could have obtained. In the case of the "Bible verse" password, the password generation process is a choice among about 33000 possible verses, which means about 15 bits of entropy (because 215 = 32768). Entropy qualifies the process, not the result.

The usual security stance is to assume that the attacker is smart. In particular, he more or less knows what password generation process we used. This makes a lot of sense in corporations and big organizations, where the security administrators publish guidance to users about how to choose a password: it seems fair to assume that most users will follow these rules, especially if the security admins implemented automatic tools to verify (to some extent) that the password follows these rules. For "personal" passwords, attackers may assume that the user is following one of the few "password generation methods" which are published throughout the Internet. Indeed, on this very site, we are discussing password generation methods, and we do it in plain view.

Any reasoning along the lines of "the attacker will surely try random passwords first" or "the attacker will never think of using a sentence from book X" is inherently flawed in the following way: it assumes that the attacker is just a random anonymous hacker who cracks passwords for the fun of it, without knowing who he is attacking. It is a tame attacker who is allowed to try passwords but not to try very hard. It denies the existence of smart attackers who are after you, specifically. Incompetence is the most widespread human trait and many attackers, being people, are afflicted with it; but experience shows that smart attackers exist nonetheless.

The psychological mechanisms behind this are reasonably clear: we want to consider ourselves as "smart". It is a humiliating experience to realize that, possibly, attackers are not only evil and naughty, but also more intelligent than us, and that we will not necessarily be able to beat them in a "battle of wits". This might be the most important insight that apprentice cryptographers must obtain at one point of their learning: we do not defeat the attackers by being smarter than them; we defeat them by throwing mathematics at them. In the case of passwords, "mathematics" are "quantifiable randomness".

Quantifiable means that you can measure how random your password is. "Eight random letters" is highly quantifiable: that's 268 = 208827064576, i.e. about 37.6 bits of entropy. "The attacker will never think of that": how much does this "never" represents ?

To a large extent, this is the same problem as security through obscurity. Which is not recommended for pretty much the same reasons.


What do setresuid() and setresgid() do?
In order to better understand this example, we need to have a look at these two functions and the three parameters they take.
From this answer (and the credentials(7) man page):

On Linux, each process has the following user and group identifiers:

Real user ID and real group ID. These IDs determine who owns the process. To summarize, this is who you are.

Effective user ID and effective group ID. These IDs are used by the kernel to determine the permissions that the process will have when accessing shared resources such as message queues, shared memory, and semaphores. On most UNIX systems, these IDs also determine the permissions when accessing files. However, Linux uses the file system IDs for this task. To summarize, this is what you can do.

Saved set-user-ID and saved set-group-ID. These IDs are used in set-user-ID and set-group-ID programs to save a copy of the corresponding effective IDs that were set when the program was executed. A set-user-ID program can assume and drop privileges by switching its effective user ID back and forth between the values in its real user ID and saved set-user-ID. To summarize, this is who you were before.

Further, it's important to understand the SetUID-Bit. What this does is it runs an executable program with the rights of the owner, not the one who calls it.
A security nightmare
Your question specifically mentions that nightmare is owned by root and has the SetUID-Bit set. What this means is that any user who is allowed to execute nightmare essentially executes it as root. This means that all child processes of nightmare - such as they are spawned when calling system() -  are also executed as root.
But really now, what does setresuid() do?
In this context? Nothing. Since the user is already executing things as root, it doesn't affect the further exploitation in any way.
Could you use /dev/tty?
This question does not make much sense in this context. You have to look at the relevant code snippet to see where the string /dev/tty is coming from.
if (open("/dev/tty", O_RDWR) != -1) {
        fire();
        rax = sub_4008d0();
}

This means the program is trying to open /dev/tty for reading and writing and if that succeeds, calls fire().
By naming a bash function /dev/tty(), you do not get the desired results, as open() requires a path to a file as its first parameter. It's completely independent of bash and has no concept of bash functions.
What about puts()?
Similarly, this doesn't make much sense. strings isn't a magic and doesn't understand context. All it does is look for series of bytes that are printable ASCII characters.
puts() is just a C-function which outputs a string.
What about /usr/bin/aafire?
While I didn't personally try, it seems as if practically /usr/bin/aafire could have been used instead of /usr/bin/sl -al. If this is not correct, please comment and I will edit this part.
Would it still work if a relative path would be used?
Yes, actually even better! system() internally calls sh -c, which has to resolve the $PATH variable to find sl. If the path variable was modified to include . or any other user-writable directory with higher priority than /usr/bin, then I could just symlink ./sl to /bin/bash.
Does it matter what kind of binary/ELF the root SUID file is?
Yes, because the SetUID-Bit gets ignored on shell scripts. It must be a native executable.


Define rules based on API keys (Something like RESTful API)

A1SA2

If no one hacks the https connection the keys are ok
Ex: https://S/req?api_key=A1&contet=action


Can 'cracked' product keys harm the user in any way?

In short: yes. Any software can harm you.

Legally: If the authors of the software find you are using illicit copies of their software, they are at liberty to file a civil copyright infringement claim against you. Software commonly "phones home", even in the form of checking for new updates. They may not go after you if you're a poor individual, but they love taking businesses to court, even if it bankrupts a small business.

Technically: Some authors have even put in attack code that runs if you use their software with a well-known pirated product key. This might be funny (for example, the game Crysis gives pirates a gun that shoots chickens instead of bullets) or it might be serious, like deleting all your personal files.

Morally: The software authors trust you to buy their software legally; you abuse that trust. You trust them to leave your computer unharmed when they find you using an illicit key. What if they abuse that trust? If they delete your entire hard drive when their software recognises an illicit key (regardless of phoning home -- software can have an embedded list of known pirated keys), what are you going to do about it?

Ultimately, your piracy might drive the authors to other means of making money, such as selling your personal information, which harms everybody, including licit users.

Personally, I would recommend you find free software that allows you to achieve the same aim, instead of using cracked proprietary software. Instead of cracked Windows, use Ubuntu. Instead of cracked Photoshop, use GIMP. Instead of cracked Word, use LibreOffice. Instead of cracked Maya, use Blender.


Is there a certification AICPA grants to qualified auditors?

You would be better served by looking for how much experience the person  has in auditing the Trust Principles contained within a SOC 2 - Security, Confidentiality, Availability, Privacy, and Processing Integrity. I am working in the IT Security profession as an IT Auditor and it has been my experience that experience matters more than any particular certification. However, relevant certifications such as CISA or CPA does provide an objective measurement of your expertise

Ideally, the person is a licensed CPA with the authority needed to complete an independent attestation, and depending on the types of internal controls management states to be in place, has special certifications such as the Certified Information System Auditor (CISA) awarded by ISACA.


Camellia and ECDHE_ECDSA -ECDSA in TLS1.2

The cipher suites you're looking for are defined in RFC 6367, as listed in the TLS Cipher Suite Registry. (To find them on the Registry page, scroll down to "0xC0,0x72" or "RFC6367".)

However, you have another problem: OpenSSL doesn't support them. If you really want to use them, you'll have to find a reverse proxy/SSL terminator/web server -- and client! -- that uses something like GnuTLS or PolarSSL.

(I hope someone will add support for modern Camellia cipher suites to OpenSSL, just because I think Camellia is neat, but I'm afraid that someone won't be me.)

By the way, if you meant ephemeral elliptic curve Diffie-Hellman, you meant "ECDHE-ECDSA". "ECDH-ECDSA" is actually a different thing -- also defined for Camellia in the above RFC -- which isn't ephemeral, and which people mostly never use.

In August 2014, support for the eight HMAC-based cipher suites from RFC 6367 was committed to OpenSSL. The GCM suites weren't added, but Camellia is now usable with ECC -- if you run OpenSSL from git, anyway. I don't know what release it will be in. (For all I know, the commit might be reverted tomorrow! In any case, it's progress.)


How can one defend against DoS attacks at the physical layer?

One of the two technologies used in the early 802.11 days was Direct Sequence Spread Spectrum - it had interest in military circles because it spread the signal across a wide range of frequencies with three key benefits:

very low signal base, making it very difficult to identify the signal in amongst RF noise
Resistance to intended or unintended jamming, meaning you would need to jam a wide range of frequencies in order to stop the signal
Sharing of a single channel among multiple users

Another solution is to use highly directional antennas - narrow point to point links require an attacker to get close to that line of sight in order to impact the signal path.

Now this may not be useful for you at a home network level, but for a home network you have very simple options - run ethernet or use powerline technology. Can be deployed within minutes.


What is the solution for handling exceptions in password hashing schemes?

Just to be clear, there is something else called password hashing that is completely different to what you describe, so that is a terminology collision, which is unfortunate.

To handle "exceptions", you must have some storage. One method could be to store (e.g. in a local file) a map from server name to some string, e.g. an integer. The scheme would be:

The local file contains lines. Each line contains an application name (e.g. the name of a Web site) and an integer.
If an application name does not appear in the file, then the password for that application will be a hash computer over the concatenation (in some way) of the master password and the application name.
If the application name appears in the file, then the integer value is appended to the master password in the hash input.

That way, the size of the local file is proportional to the number of exceptions.

There is of course ample room for botching things here. Notably, each generated password may be used as a test for an offline dictionary attack on the master password. So the master password must be stronge (that is, stronger than is usually necessary for passwords).


Can any information leak by sending auto-generated 'Unsubscribe me' email?

Is it possible to retrieve any information from my inbox / sent items using some scripts if I send the unsubscribe mail? If yes, how do we find if any information has been stolen?

People on this forum are generally going to acknowledge that "everything is possible." Instead, we concentrate on what's likely, probable, and worth defending against.

Applications like Outlook and Thunderbird read the link as a URL, and those URLs are linked to applications. mailto: will be opened by the default mail client, http / https will be opened by the browser. These URLs are then parsed, and action is taken on them.

It's the parsing that gets us in trouble. When input is parsed by the application (or the OS), it could be parsed in a manner that exploits some flaw and precipitates a bad result. One example: earlier this year, a flaw was discovered where a link click can crash your system.

So, links can be dangerous. Fortunately, there is a relatively safe way to deal with them: mouse over. When you mouse-over a link, it should display the destination. If it's an http or https or mailto link, then you should be relatively safe (until you're not). If you see a UNC link "\something" in an email, then that's definately not something you'd want to click on. Even an http(s) or mailto link might be suspect depending on the destination.

So the ultimate conclusion is: if you are running an unpatched, not up-to-date operating system and software, then the odds you'll be hit with something nasty from a link (or other sources) is much higher. (Using AV for protection is out of scope for this question, and generally triggers a Holy War. If you have additional questions on that, I'd post it on SuperUser.com).

  Since my connection with the server is open, is it possible to contact the mail server by impersonating as me?

Assuming that you have a vulnerability as discussed above, anything is possible. So, yes.

  If all it does is mark my email as active, what are the consequences of that?

I've dealt with spam extensively. Both in MS Exchange filtering, to Postfix, SpamAssassin and writing milters to filter spam. There are three things that a spammer cares about that will make your address a "value add:"

That the email can be delivered. Deliverability is what these low-life's are selling when they sell your email.
Open rates - that you opened the email marks it active. They do this with email tracking pixels.
Some sort of activity (a click, a purchase, a phish, etc...).

So, your email gets marked as one or more of these - if you're dealing with a sophisticated spammer. However, most spammers are not even sophisticated enough to send RFC compliant email, their database handling skills are basically non-existent.

Chances are: you're already marked as one of the three classifications above. If your email has been breached, bad guys cross reference different breach lists. If the email appears on more than one, (and chances are, that's true too... thanks Yahoo, DropBox, Google, etc...) then you're on a separate, more valuable list.

So what to do?

You have to assume that if you receive an email, you're "active." If you open it to see what it is, you have already been marked as "active+open." So, there's no point in worrying what metadata some bad actor is is collecting on you. Your primary concern is (should be) protecting yourself.

Simple steps to do this:

Just delete obvious spam emails. The unsub links won't work 90% of the time, and when they do work, you've raised your hand as active. (That seems to be worthless to them these days since data breach data is so much more reliable... but why not avoid it?).
In the last year, at one of my sites, I monitored and did frequency analysis on just over 500,000,000 inbound emails over a period of six months. The only factor that increased the frequency of email to a given address was its age. The owner of the company had a 20+ year old email address, and he got the most. The next most senior employee had the next greatest spam level. And so on...
If the mouse-over reveals an https link, manually navigate to the site (in a sandbox) using copy paste, and go to the root of the site to see if it's legit. If so, then unsubs are probably honored.
If it's from a big company, unsubs must behonored (at least in the US). It's probably fine to unsubscribe.

Important

Read the URL carefully and always check the SSL certificate issuer for https links in the emails. Ransomware emails are crafted amazingly well in comparison to the rest of them. I have seen a few come through that were beautiful reproductions of UPS, FedEx, USPS, the IRS, and a few other major orgnization emails. I've seen some that came through that had working websites behind them claiming to be a city municipality complete with contact address, correct phone numbers, Google Maps addins, and what must have been a $3,000 website complete with SSL (signed by a Chinese CA. Pretty sure US municipailties won't be using a Chinese CA). These are sent as RFC compliant, DKIM signed, SPF compliant emails from non-day-old-bread domains in low volumes to keep from getting blacklisted. Spamassassin routinely classifies them as < 2. They either use a compliment domain ("irscompliance.us" instead of the legit irs.gov) or a duplicate letter (like Gooogle vs Google). These are pretty rare, but they are exquisitely crafted. It's almost as if all the spammers who were good at their job have switched to the ransomware industry.


This page should clear things up: https://github.com/diaspora/diaspora/wiki/Prettygooddiaspora

Short summary of the page:

Diaspora is still a work in progress and they are not really sure how to proceed.

What they would like to have is PGP-encrypted messages everywhere, but run into implementation problems and put that aside for now.

What they now use is SSL protected inter-pod communications, which means that the platform is protected against outsiders but if a pod is compromised there are no more protections.

Also as stated elsewhere right now Diaspora is push-only and no mutual authentication takes place. What they would like to do is implement mutual server to server authentication so that they can also use pull methods.


I believe that this is not possible in a failsafe way, unfortunately. Let me explain why.

You want your frontend app to have a way to identify itself to the API. In other words, you want authentication.

But authentication requires the existence of some kind of unique, secret data that the frontend app can use to distinguish itself from other applications. This can be a shared secret (password, "API key"), a private asymmetric crypto key, or something else yet. But whatever it is, it has to remain a secret, since if another app can copy it, it can pass as your frontend app.

So the question is, where are you going to store that secret?

If it is stored inside of the application code itself, or directly accessible to it, then it is vulnerable to reverse engineering or exploits on your front-end app, no matter how many layers of cryptographic indirection you use to hide it. This is the fundamental security flaw that led to the failure of almost all DRM schemes devised to date.

If it is stored on some tamper-proof location of the client machine (e.g. TPM chip, trusted OS key management facility), then the question becomes, how does it get there initially? And how are you going to access it from Javascript code, which has limited low-level OS access capabilities?

If it is stored remotely, then you are only shifting the issue of app authentication elsewhere: how is your front-end app going to authenticate on the remote server? Or in other words, what is preventing another app from accessing that remote server in exactly the same way?

My conclusion is that there is no truly secure way to authenticate a piece of JS software. You'll have to design your API in a fashion that is secure from malicious client input and, if you do want a way to ban compromised clients anyway, provide clients with revocable "API keys" that you can easily ban on the server side, the way most web services (and newer DRMs) do it.


Doesn't Samesite cookie and Sameorigin policy effectively does the same job?

The Same-Origin-Policy does not prevent CSRF attacks. It does not prevent the request from being send and it does not prevent site specific credentials (i.e. session cookie) to be attached to the request. It only prevents cross-origin reading, not cross-origin writing. Thus it is possible to send a fully authenticated request (i.e. with session cookie implicitly attached) cross-site which allows an attacker to do an authorized action on the server side even though the attacker cannot directly get the result of the action (i.e. read the response).
Same-Site cookies mitigate this problem with an additional restriction when a cookie will be implicitly attached to a request. Without same-site property it will be attached to all requests which includes cross-site requests. With same-site property it will no longer be attached to cross-site requests. Thus it is still possible to write cross-site, but not with cookie based authentication information implicitly attached.


Is it safe to allow HTTP for SAML 2.0 Issuer URL?

I believe that technically, HTTP for the issuer URL is OK as the data being
transmitted is less sensitive. However, I would also argue that making it HTTPS
is also fine. In the past, there was a belief that you should only use HTTPS
where you absolutely needed to because of the additional overheads involved and
potential performance hits. With the increase in speeds and processing power,
this argument is no longer as valid (though there are still many sites with an
architecture which relies heavily on caching for performance where HTTPS can
have an adverse overall impact).

I tend to feel that complexity is now one of our main threats. Having an
application which uses HTTP in some contexts and HTTPS in others adds to this
complexity and makes verification more difficult. Much easier to monitor and
varify everything is OK if all you need to do is ensure all connections are
HTTPS rather than also having to check all non-HTTPS connections are OK.