How To Protect Tomcat 7 Against Slowloris Attack

A CVE has been assigned specifically for this issue as it applies to Apache Tomcat: CVE-2012-5568. More appropriate references there than the one you were given.

The Tomcat developers do not consider this to be a vulnerability, and have no plans to fix.

Potential solutions:

Use firewall rules to prevent too many connections from a single host. This will mitigate run-of-the-mill Denial of Service attacks but not distributed ones (DDoS).

  Here is an example of an iptables command which can be used to limit the number
  of concurrent connections that can be established to port 80 from a single
  client host:

  # iptables -A INPUT -p tcp --syn --dport 80-m connlimit --connlimit-above 50 -j REJECT

https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2007-6750

This would, however, have side-effects if many users were legitimately connecting from a single IP (e.g. mega-proxy), so the number of connections would need to be tuned reasonably - dependant on the traffic expected.
Unfortunately, the best option is to place the Tomcat service downstream from a web server that can better handle HTTP connections, such as Apache. Then use an Apache solution such as mod_reqtimeout or mod_antiloris.


Is there any write-once USB stick/pendrive?

You can take a hash (with for example SHA256) or a signature of the data you sumbit. This will be an electronic proof of (un)tampering. You can mandate a notary to keep a copy of the data and its hash or signature, to have a dated proof.
Even if you sumbit your data on a write-once medium, like a CD-R for example, nothing technically prevents the recipient to make a copy of the data then alter it. Its supporting medium can be copied too.


Can I trust Post-Quantum VPN for protection against quantum computers?

It seem a but premature to make a VPN decision based on post quantum protection considerations, at this time.  I think much more important questions would be, company reputation and past actions.  None/few of the major trusted VPN providers, I see have that as a feature and my speculation is that any services using the new crypto is likely still experimental, Microsoft just began looking into it about year and a half ago.

In summary,  I would not use post-Quantum Crypto at the moment, and re-evaluate in the future.

To evaluate traffic from a vpn, you need to review your network traffic.  I would start by looking into wire shark.


How to ensure security in desktop application using WebSockets locally?

You need to be able to distinguish between the trusted client and the untrusted third party in order to block the third party. This means that you somehow need to find out when the trusted client connected and when the connection does not come from the trusted client. This means you need some form of authentication but it does not need to be some setup with users and passwords or similar. How this authentication is done depends on your specific setup, i.e. it might simply be a specific IP associated with the correct client, it might be a token only the trusted client knows, it might be authentication based on a certificate (i.e. mutual authentication in wss://) etc.


Hide ports being knocked during Port Knocking

Obviously this is a bit of a frame-challenge, so I understand if you don't like this answer.  However:

The biggest advantage (in my mind) of port knocking is that it automatically filters out all the bots on the internet that go around randomly trying to brute-force every SSH server they find.  It can also be helpful in that it provides a small additional layer of protection against 0-day vulnerabilities in the SSH server (if no one knows your server is there then they can't attempt a 0-day, even if you are vulnerable).  However the point in both of these cases is the same:

Port knocking is most effective as a way of filtering out drive-by attacks against your server

Once you talk about a directed attack (i.e. someone with a MITM observing the port knocking process), then port knocking will definitely fail as a security method.  Even if there was a way to hide the port combinations from a dedicated attacker, the fact that they are specifically targeting your organization means that your port knocking security has accomplished its particular job.  It is simply supposed to keep out drive-by attackers, and it does as much.  Attempting to extend it to cover more targeted attacks which this security method wasn't originally designed for is probably going to cause you more trouble than it is worth (in the implementation and support of new security feature, and the risk of accidentally locking yourself out).

Can you hide the port knocking sequence from a MITM attacker?  I'm pretty sure the answer is no, although I'm not ready to make a definitive statement there.  Either way though, I think you're going to make a big headache for yourself to attempt to mitigate an attack vector with a defense mechanism that wasn't really designed for it.  As a result, I think you're better off finding other ways of securing your servers and keeping your port knocking simple.  You're probably already doing this, but simply turning off password-based authentication and allowing authentication via private-keys only is usually the first and most effective security measure for an SSH server and (IMO) a more effective way of blocking out drive-by attacks than port knocking.


Would it be possible to store Kerberos tickets on a YubiKey?

This is a weird/bad idea.

You'd likely better off somehow integrating the YubiKey with RFC4556 aka pkinit.

  Abstract
    This document describes protocol extensions (hereafter called PKINIT) to the Kerberos protocol specification.  These extensions provide a method for integrating public key cryptography into the initial authentication exchange, by using asymmetric-key signature and/or encryption algorithms in pre-authentication data fields.


What to do when a conference uses HTTP and stores passwords in plaintext?

Make sure they aren't part of the network of predatory publishers
(such as W.A.S.E.T or O.M.I.C.S).
You should email the conference organizer to alert them to these issues. If there is a national organization behind it consider checking to see if the issue is endemic and if so alert the national governing body of that organization as well.

Note* be prepared for them to not be thankful for your help.


How can I migrate from filter-on-output to filter-on-input?

Filter on output is the preferred method of XSS defense.  One reason why this method of XSS defense is popular is because it is not dependent on data in your database conforming to an arbitrary encoding set.  Filter-on-input means that the view of the application must trust the database,  as it is assumed this data has already been "filtered".   If the database is compromised with SQL Injection,  an attacker could introduce tainted data to the database.  Here is an exploit I wrote that uses SQL Injection to obtain persistent-XSS on a filter-on-input application,  persistent-XSS would not have been possible on a filter-on-output paradigm.

Filter-on-output is also a more secure approach to XSS defense,  and I'll give you an example in PHP.

Lets say we have a PHP application that uses htmlspeicalchars($var, ENT_QUOTES); blindly, on all input.  The classic case of an attacker introducing  would be prevented in most cases (a decode operation such as base64decode() performed after the htmlspeicalchars() would result in tainted data).  However,  this blanket security measure does not prevent all XSS in the application, most importantly it won't prevent XSS in DOM events.  For example:

Or here is another example,  where javascript:alert(1) is the payload:

go back

Not all data is used in the same way,  therefore its impossible to apply a blanket security measure.  URLs conform to a different XSS rules than that of event handlers, and both of these are very different from the general case of XSS.

So how do you migrate from a filter-on-output to filter-on-input?  DON'T.  The best way to prevent XSS is using a XSS-aware tempting system such as Twig.  XSS is problem with the view,  so you need a view that is secure.


Good (manual) system to come up with passwords for a wide range of requirements

An option (not saying it is great) is to combine the idea of the strong core with the notebook option.

Say you have a core like: secu_ritYstAcke_xChang_e01

You change this depending the requirements (say change 0 -> a, 1 -> b if numbers aren't allowed), the _'s you fill in from the notebook.
The notebook contains entries like: (doesn't need to be 3 times 6 chars or have the same pattern each time)

CompanyX : abc123, xyz!*@, (#*987

So the resulting password for CompanyX would be:

secuabc123ritYstAckexyz!*@xChang(#*987e01

I believe it clearly can satisfy constraints 1, 2 & 3.
For constraint 4 as long as both your "core" and "notebook values" are strong enough having 1 password exposed shouldn't dramatically increase the risk to the rest of your passwords as any of those characters could be "core" or not. Though it definitely redures the strenght.
Assuming you change your "core" part often enough constraint 5 should be met as well. Sure the "notebook values" remain the same but given that the "core" changes completely it should keep a good amount of entropy.

The notebook will represent a physical risk of course but in and of itself it shouldn't be enough, one would need one active password for it to completely break the system.

I would however definitely argue to use this system for as few systems as possible (only those where you can't bring your phone AND can't access the internet) and use a password manager for the rest as such method is a lot safer.


How is data Encrypted and Decrypted from a database with PHP Sodium

If you have information that is encrypted, you can not search inside of it without decrypting it first.

If the information that you're using to search for something is not sensitive, such as a user ID, message ID, or otherwise only tangentially related to your sensitive information, then use that information as an index for your encrypted data.  A popular choice is an auto-incrementing primary key.

If the information that you're using for the basis of your search is sensitive, then your index should be implemented through a cryptographic hash function.  Keep in mind that, while hash collisions are rare, the fact that unrelated plaintexts will have hashes that collide is an important feature of cryptographic hash functions.  After you've found candidate row, you need to verify it.

You're definitely not going to be able to do any full-text searches of the encrypted data without decrypting every row.  Construct your indexes wisely.


Difference between cyber security and information security?

These terms have been used synonymously over the years, but in practice, they are starting to get differentiated.

IT Security policies tend to cover secure policies around the "information technology" itself, the systems that serve and process information. Servers, networks, etc. In some organisations, there would be nothing about end users in these policies and only the IT staff would read them, for instance.

Information Security policies are about the wider security of information, no matter what form that takes. So, that would include paper copies of data in warehouses, as well as databases, cloud services, etc.

Cyber Security policies is the newer term, and tend to cover the information that is served and processed for/by the public and 3rd parties in a digital form. Basically, any data that travels over the Internet. "Internet security" used to be the term used, but that got confused with just user security awareness and how to browse safely, so this other more generic term has gained popularity in use. I am unaware of any formal definition of "cyber", but this is how it is used in practice. Some older information security professionals still roll their eyes at the use of this buzzword in official documents.

But, an organisation can define their terms however they choose to. These policies will include some section explaining what the policy covers, its scope, and where it applies.


Help on interpretation of FIPS-140 paragraph

I think it means that if you store the key in plaintext form inside the cryptographic module, then you have to make sure that no one else can access the place where the key is stored in the cryptographic module.  For instance, it needs to be stored in private memory that only the cryptographic module can access, and that others are prevented from accessing.  This means that there are security expectations for key storage.

I think the part that has confused you is the difference between storing a key in internal memory of the cryptographic module (which others can't access) vs exporting the key to the outside world.  There is supposed to be a security perimeter around the cryptographic module that prevents others from tampering with or examining its internal memory.  If the key is stored unencrypted in internal memory, then the internal memory has to be designed so that it cannot be accessed by anyone/anything else than the code of the crypto module.

I don't think it's exactly right say that keys can be stored in plaintext and still be acceptable by the standard.  In particular, I don't think it's accurate to say that you can store the keys however you want.  As I understand it, FIPS doesn't let you store a key in plaintext anywhere you want; it would be a security risk to have an unencrypted key laying around in unprotected storage.


How long are password hashes stored locally?

Your understanding isn't quite right.  If a domain user is authenticating to a domain member server using Kerberos then their password hash won't be sent there.  Kerberos only requires the hash to be sent to a domain controller, which maintains the domain account database.  And technically the hash itself isn't even sent to the DC.  Then Kerberos issues a service ticket to the user and the user sends that ticket to the member server to prove their identity.  So user credentials are never added to the local server account database (SAM) due to logins.

Depending on whether you are worried about cached credentials being temporarily stored in memory on member servers there are some other scenarios where a user's password hash might be transmitted to that server.  But password hashes will only ever exist in local account databases if they were specifically added with accounts created by an Administrator.


Attacks on keys generated with low entropy

Entropy will basically define the maximum number of different states you random number generator may have at a given moment (more information on the subject can be found here). The higher the entropy is, the higher possibilities there are.

The main problem with low entropy is that the random number generator will have less different possible states to switch over, therefore it will begin to repeat itself.

The main way to detect such issue is to try to detect such repetition. A common issue for instance may affect session ID: an attacker may request a lot of session ID from the server (or nonce from the AP in the case of the Wifi access - did someone talked about WEP?) and analyse if the server can be tricked into generating the same ID twice. If another flaw allows it, he can also cause several quick application restart to analyse the first ID generated.

A very good, historical example of entropy issue affects Debian (and its numerous derivative). During two years, they broke Open-SSL random number generator limiting the ssh-keygen command (used among other thing to generate keys used to authenticate people on servers and authenticate the server itself to avoid Man-in-the-Middle attacks) to 32 767 different keys. As a result of this:

A server affected by this issue could be immediately identified since he will present the public part of one of these vulnerable key to authenticate itself: the private par being known by the attacker a wide range of attacks become available,
If one user uses such vulnerable key to authenticate itself (the server itself does not need to be vulnerable), an attacker could gain access to his account just by trying each key from the set which should be relatively fast.

As a final word, you must not rely on the fact that low entropy "looks like" good entropy and that you do not know yet a way to detect it. This is called security through obscurity and it does not bring any good security. Indeed, the fact that you do not know such a way do not mean that nobody else does, and if one single attacker does the consequences could be catastrophic (I guess WEP people initially considered their system to be secure...).

For your concerns regarding VM's entropy, you may be interested in this discussion. Basically, a simple yet efficient fix consists in "seeding each VM with a seed obtained from some other random source elsewhere; this is as easy as writing some file into /dev/random" (quoted from Thomas Pornin's answer).


SameSite cookie attribute and Synchronizer Token Pattern

if it is supported should we implement Synchronizer Token Pattern to prevent CSRF attacks?

No! However, you absolutely shouldn't be using GET like request methods for state changing actions.

  Will SameSite prevent at least same CSRF attacks as Synchronizer Token Pattern?

Yes! Since it omits sending cookies (flagged SameSite) to requests originating from 3rd domain, Cross-Site requests cannot make authenticated requests. This, thus, prevents CSRF. However, SameSite cookies don't block all kinds of GET requests. Link prerender requests, for example, are some exceptions and probably will not be added to the list. Therefore, it's very crucial not to use GET requests for state changing actions.

  Is the CSRF attack possible if we use only SameSite setting (without Synchronizer Token Pattern) in a browser that supports the setting

Short answer: No
It's possible to overwrite cookies. This, however, doesn't make it vulnerable to CSRF. To overwrite a cookie, an attacker must supply a value. In this case, if s/he already knows the cookie value, s/he already has access to victim's account.
However, On-Site Request Forgery (as mentioned in comment) is always an exception.

  What is a possible attack scenario?

There aren't any unless combined with ither vulnerabilities.

Edit:
Plugin initiated requests (Flash, PDF, etc.) might not act as you expect. They may or may not SameSite cookies. Therefore, atm, use tokens along with SameSite cookies.


How can an internet contest verify unique votes with only an email as an input parameter?

I was thinking about tracking IPs, but many computers can be a part of a single network. Is there anything more specific than an IP that is unique to each computer, that is also accessible over a network?

The first thought that comes to mind will be making use of cookies to track the users. Of course, that can be easily removed. Perhaps something like the evercookie? Hmm.

  Also, how can you stop people from entering multiple valid personal email addresses (for example, I have a spam email address that I give out at stores, a university email address, and then an old one I don't use, but they are all valid!).

Without tying the email address to something else, this is quite impossible. A possible thought that comes to mind would be invalidating any email address submitted through a computer with a previously used IP address or cookie. This isn't impossible to evade but it might deter the less tech-savvy or determined cheats.

  Could the contest be illegitimately won by someone who is IP spoofing?

It depends on the scale of the contest, but most likely yes. Another possible scenario would be using botnets to game your contest.

What are some of the other possible measures you can take?

Does your contest involve a physical prize? If so, physical addresses might be quite a good way to weed out cheats. It's far easier to come up with 15 different valid email addresses than physical addresses eh?

How valuable is your prize? How far would the cheat be willing to go to game your contest? Obviously the measure you will want to implement depends on the value of the prize in question.

In your scenario,

  A website is running a week-long contest where users are allowed to vote once per day. There are no accounts or logins necessary to vote, all you need to supply is a valid email address.

It doesn't appear that there is much you can do to stop a determined cheat.


Correct. The relevant standard is the X.509 spec in RFC5280:

  4.1.2.5.  Validity

  The certificate validity period is the time interval during which the
     CA warrants that it will maintain information about the status of the
     certificate.

Basically, as the certificate requester, you have absolutely no say in the validity period of your cert, this is 100% at the discretion of the CA.

To get an intuition for why this makes sense, consider the other use that X.509 was designed for: S/MIME email certs in a corporate environment. Clearly your corporate sysadmin gets to choose how often you roll over your keys, not the end-user.

This philosophy applies to web TLS certs in that CAs have a responsibility not to issue certs valid for a longer period that it will take to crack them (imagine someone requesting a 10-year cert for an RSA-1024 key). This responsibility is governed in part by the CA/Browser Forum. For example, see this CA/B requirement:

  What are in the Baseline Requirements?

  Validity period for certificates issued after July 1, 2012 must not exceed 60 months and issued after April 1, 2015 must not exceed 39 months.

In practice, each CA has a fixed validity period for all certs it issues, though some CAs will issue longer certs at an increased price.


Does symmetric encryption provide data integrity?

Symmetric encryption does not provides integrity. The amount of control that an attacker can have on encrypted data depends on the encryption type; and some specific details of some encryption modes can make the life a bit harder for the attacker if he wants to make surgical modifications. With CBC, the attacker can flip any bit he wishes, provided that he does not mind transforming a dozen other bytes into random junk.

There are recent encryption modes which combine symmetric encryption and checked integrity (with a MAC). These modes ensure both confidentiality and integrity. AES-CBC is not one of them. If you want an encryption mode with integrity, I recommend EAX.

Update: concerning your experiment: CBC is a mode where the source data length must be a multiple of the block cipher block length (16 bytes, for AES). Since an arbitrary input message may have any length, some padding is added: a few bytes, with specific contents such that they can be unambiguously removed upon decryption. In your case, OpenSSL is complaining that, upon decryption, it does not find a proper padding structure. However, if the attacker does not alter the last 32 bytes of the encrypted data, the padding will be undamaged, so alterations of all but the last 32 bytes will remain undetected. And even for the last 32 bytes, there are ways to evade detection with a not-so-small probability.


They might do it already, there is a known technique to dedicate malicious and powerful nodes to the network to be able to take control of some of the traffic.
Tor does not advertise itself to be able to protect against adversaries that have control over a fair part of the internet. While there are techniques to check the validity of the nodes if you have control over the internet(a fair part of the network) you can de-anonymize nodes.
Under Tor's website, the FAQ page :
What attacks remain against onion routing?

it is possible for an observer who can view both you and either the destination website or your Tor exit node to correlate timings of your traffic as it enters the Tor network and also as it exits. Tor does not defend against such a threat model.
In a more limited sense, note that if a censor or law enforcement agency has the ability to obtain specific observation of parts of the network, it is possible for them to verify a suspicion that you talk regularly to your friend by observing traffic at both ends and correlating the timing of only that traffic. Again, this is only useful to verify that parties already suspected of communicating with one another are doing so. In most countries, the suspicion required to obtain a warrant already carries more weight than timing correlation would provide.
Furthermore, since Tor reuses circuits for multiple TCP connections, it is possible to associate non anonymous and anonymous traffic at a given exit node, so be careful about what applications you run concurrently over Tor. Perhaps even run separate Tor clients for these applications.

About Tor network takedown:
They may not have enough incentives to block the whole system. After all it's a highly decentralized, international network of nodes. If you shut down a node, another one will pop up so it's not trivial to take the whole thing down.
There are also obfuscation techniques Tor uses to hide itself from ISPs and censorship systems. They can't flip a switch and then Tor is down.
About adding malicious nodes to decrypt the traffic, it's not trivial either. You don't need any relay node, you need an exit node to get access to unencrypted traffic (Another layer of encryption may still be present, e.g. HTTPS). Tor also monitors exit nodes for malicious activity and actively blocks them. I'm not saying your provided scenario is not possible, I'm just saying it's not trivial.


What is the relationship between the GPZ research titles and Meltdown and Spectre?

If I understand you correctly you ask how the three issues shown by GZP map to the names Meltdown and Spectre. You'll find the answer at the beginning of this post from Google Zero Project:

  So far, there are three known variants of the issue:

  Variant 1: bounds check bypass (CVE-2017-5753) Variant 2: branch
  target injection (CVE-2017-5715) Variant 3: rogue data cache load
  (CVE-2017-5754)

  Before the issues described here were publicly disclosed, Daniel
  Gruss, Moritz Lipp, Yuval Yarom, Paul Kocher, Daniel Genkin, Michael
  Schwarz, Mike Hamburg, Stefan Mangard, Thomas Prescher and Werner Haas
  also reported them; their [writeups/blogposts/paper drafts] are at:

  Spectre (variants 1 and 2) Meltdown (variant 3)


How do I encrypt a private key before sending it to another person?

This is the wrong approach. Rather than attempting to encrypt private key, let the user of the key generate their own private key and give you the CSR, this massively simplifies key management.


How CA ensures that a certificate request is coming from me?

Different CAs have different methods, and each CA has different methods based on what level of trust you are paying to have. (such as Extended Validation to get the green address bar)

The little fly-by-night CAs have a base level verification where you just give them an e-mail address and they send you an e-mail there, thereby validating that you really own the e-mail address associated with the certificate. These usually cost $15-$30, and are promoted as instant verification.

Standard CA validation involves providing a phone number for at least one contact at your company. The CA first looks up the phone number to verify that it belongs to the company the cert is registered to, then checks by calling and having the contact answer the phone and agree that they know of this cert request.

Higher level verifications involve faxing company documents (business license, registration, etc)

...so to keep it short, it depends on what kind of trust you pay for and which company is sticking their neck out for you.


Does a DDOS attack on an application using CDN have to first bring down all the involved CDN servers to affect the application's availability?

Will such a DDOS attack have to completely bring down all the CDN servers serving this application's content before impairing the origin server completely?

The CDN provider might decide that this attacks is too costly and too much impacts other clients protected by the CDN that it will no longer serve your domain. In this case your domain will not be directly brought down by the attack passing through your system but will be unreachable anyway.

Apart from that your application might have bugs which make it possible for already few requests to cause a large load - like causing lots of requests to the database or algorithmic complexity attacks. In this case only a few requests will be enough to cause a high load and will make your server unreachable. While WAF capabilities in a CDN might protect against some known attacks like this it cannot protect against arbitrary bugs in the application.


Buzzfeed just downloaded a binary file to my PC, unasked

You could try (if you haven't already done so) Virustotal, which provides a service for scanning URLs or files for threats.


How to secure a fresh Ubuntu 16.04 install

The CIS benchmarks provide very clear instructions on what should be made to secure most known systems.


Would it be possible for shellcode to call non exported functions in a dll?

Not only can it be done, but calls can be made into the middle of functions.
https://en.wikipedia.org/wiki/Return-oriented_programming

I believe it's even possible to call into the middle of multibyte instructions (on x86) which results in a completely different interpretation of those instructions.

So yeah.  There are tools for that.


Can malicious code trigger without the user executing or opening the file?

There are a few cases where simply downloading a file without opening it could lead to execution of attacker controlled code from within the file. It usually involves exploiting a known vulnerability within a program which will handle the file in some way. Here are some examples, but other cases are sure to exist:

The file targets a vulnerability in your antivirus which triggers when the file is scanned
The file targets a vulnerability in your file system such as NTFS where the filename or another property could trigger the bug
The file targets a bug which can be triggered when generating a file preview such as PDF or image thumbnail
A library file (ex. dll) could get executed when saved to the same directory where an application vulnerable to binary planting is executed from
The file is a special file that can change the configuration of a program such as downloading a .wgetrc file with wget on Linux
…and more


Why does Google SSL cert change so frequently?

The answer is likely that they simply have different certificates on different servers on their network, and you get routed to a different one every so often.

This is a common practice to simplify deployment and increase security - they then don't have to make a copy of the same certificate to every machine and load balancer in their (global) network. When you're at Google's scale, this is a good thing. Every copy of a certificate increases risk of compromise, but if a compromised certificate is only used on one, two or a handful of servers they can just revoke it and move on.

It is also why they have their own (intermediate) CA, so that they can issue themselves new certificates as necessary.

See also Facebook doing the same thing.


I don't mean this to sound harsh, but this is part of my day job, and to be honest I don't think you have the experience or scope necessary to pull something like this off successfully by yourself while achieving any sort of meaningful result.

DLP is a HUGE domain. You haven't even been given any clear direction in what it is you need to be catching which makes this all the more difficult. Stolen internal sales leads or books of business? PII? HIPAA? PCI? You might not pass an audit of the latter two rolling your own solution (talk to your auditor BEFORE you start development).

And neither of your triggers will catch anything but a rogue spambot running on your network. In my experience people that exfiltrate data know they're doing something bad and take at least ONE step to cover it up. They're also not going to suddenly start sending 100x more emails than they usually do. At best using a regex for socials or A/R numbers might catch some accidental cases of Outlook autocompleting the wrong address and the sender sending it without looking.

How are you going to distinguish 16-digit card numbers from any other 16-digit sequence?
You could catch them all, but who is reviewing these false positives? Is anybody? If you don't have the budget for a commercial solution, do you even have analysts that are going to review anything you find?
Word documents. Are you capturing and/or reading through those?
Text files or docs renamed as something else?
Images. Are you performing OCR on all outbound images?
Alternate data streams/stego?
If I export cardholder information to a PDF and stick it in an encrypted zip file, would you catch that? What if I stuck that encrypted zip inside another encrypted rar? You'd have to decrypt at least one layer of zip/rar file and parse a PDF to catch it. You could block all binary attachments, but when they turn to an alternate channel to send it out another way, will you catch that?
You want to catch social security numbers? How are you going to distinguish those from mistyped phone numbers? Is 273-555-1010 a phone number or a social? How about 123769931? The same regexes will catch either.

Keep in mind none of these cases involve a change in velocity or attachments, as you're proposing you'd look for. It's just one malicious email among many benign ones I'll send that day. Maybe yours is different but in my experience most people aren't dumb enough to just dump PII into the body of an email and send it; 90% of the time it's encapsulated in at least one other format (pdf, txt, doc, doc inside zip, zip inside rar, etc).

Your question specifically pertained to email, but you also need to consider people using Facebook messaging, Dropbox, USB sticks, etc. to exfiltrate data...otherwise you might as well not bother. Email is just one tiny vector.

Don't mean to dump on you, just pointing out some of my own experiences with this field in the hopes it spares you some headache. You have no idea what you're getting into if you have no budget for tooling. DLP is one of the few areas I truly believe commercial solutions can do far better than rolling your own.


How does the Dell Sonic wall Authentication works?

It does work by either having a meta refresh, or a JavaScript, that continually send request to hold your session alive.

Basically, it works by having a session identifier, that is a random string. This session identifier might be valid for lets say 3 minutes.
Each minute, that webpage will either execute JavaScript code, or do a meta refresh, causing the page to get a new session identifier that is valid for Another 3 minutes.

The reason it knows you have closed the window, is that the session will no longer be renewed, thus your session will expire.

The reason of using such a system, is to prevent people from spoofing MAC-adresses and IP-adresses to "steal" a other's login session.

The popup is often delivered over HTTPS, so once the original user stops using the session, theres no way for the attacker to keep the session alive.

In some cases, a interlock scheme is used instead of HTTPS (or sometimes in combination), which consist of a JavaScript which is constructed to do some Exchange of secrets with the server each session renew, in a way so it requires a MITM attack to subdue the system.


Scan Novell NetWare backend with Windows servers and clients

It depends if you want to do an unauthenticated (black box) style scan or internal audit type scan.  Some scanning tools can check to see if you are missing any patches, in that case you will need to have local credentials for the windows systems.  You will need to use an account that is present on each Windows system with proper rights.

So yes, you could use the workgroup credential to scan the workstations and you don't necessarily need to join the Netware tree.


How effective is mobile phone verification in stopping fake user registration?

There's three parts to this:

Cost to legitimate users
Cost to attackers
Value you are protecting.

Losing legitimate users.
It has a cost to legitimate users. Sometimes the message does not get delivered in time, or at all. This may lead to some users turning away from the service. This is a loss to you; you have lost a potential customer or user.
How big problem this is depends on your service and user base. If it's a web shop with lots of competitors, this could be very real. If it's a professional service for the only of it's kind software, it's less of a problem.
Cost to attackers
Getting a new phone number will cost me 3-4$ and some time. If what I'm after is worth more to me than 3-4$, I will get a new SIM card. If it's to protected against automated spam bots on a forum and similar, it will be somewhat more effective, as the value of their registration tends to be fairly low, so they'll not go trough the hoops just to register on your forum software.
What are you protecting?
What are you protecting? Why is fake users a problem for you?
Broadly speaking, this could be to protect against their actions, e.g. placing fake orders at a web shop, or it could be protecting against spam. If it's effective will depend on if it's a targeted attack or a general, automated, attack. Targeted attacks that go after your website is much harder to protect against.


What security implications should I consider in relation to mcollective?

For reference, PuppetLabs have their own security documentation for the product. I assume you've read it, but for the convenience of future data archaeologists it's here.


Security implications of a missing SCSV, but with only TLS 1.2 allowed

Since the SCSV is merely a method to prevent downgrading and your server does not support any other protocols to downgrade to, I do not see any downside to that.

Correct me if I am wrong, but the SCSV would be for nothing with TLS 1.2 allowed only anyways.


Can Cookies Without the Secure Flag be Stolen, even when only accessed via HTTPS?

Yes.

HTTPS prevents MITM attacks. Consider:

1) you visit https://secure.example.com/ which drops a cookie on your browser

2) you then visit http://www.google.com/ however a MITM inserts

3) MITM sniffs your cookie from the request on the iframe

Or even if you (deliberately) navigate from https://secure.example.com/ to http://secure.example.com/ then the attacker doesn't even have to inject any HTML to sniff the cookie.

And then there's also the possibility of session fixation - where even if the cookie dropped by https://secure.example.com/ has the secure flag set, that's no use if it sends back a session id it received in a non-secure cookie (again set via MITM).


Does Docker affect the quality of cryptographic operations?

The response is NO, the crypto operations in general are generated by libraries like openssl, libsodium and so on, no by a docker. The only case that came to my mind is that your docker uses old libraries that have vulnerabilities or issues.


Why modern php web application requires to specify the application's url?

speaking specifically for moodle, it's used to allow changing the path dynamically based on config. This lets you host a site at, ex domain.com/moodleroot instead of just domain.com, allowing one server to host many copies of moodle. If you don't need that capability, it's not worth the hassle of re-interpreting relative URLs. It also allows isolating parts to use a different root/server, for testing purposes w/o bringing down a live system; the path can be altered/interpreted for just the one user running tests.

I don't see any big security implication one way or the other though, it's more of a deployment matter.


Microsoft has had a horrific security track record.  But the real problem in 2011 isn't operating systems,  its web applications and web browsers.   You should explore projects like Damn Vulnerable Web App, OWASP WebGoat  and especially Google Gruyere.  You can find pre-built VM's for all of them,  and Google is hosting theirs so you don't have to install anything.


Users are tracked because the collected information can be sold.

A major reason why data is collected from users is due to the simple fact that people will pay for the data. There are many companies that broker collected data, such as Intellius, to virtually anyone with a deep enough pocket. What buyers do with this personal information, however, is up to the buyers. Many use it to serve ads. Others use it to learn more about their target demographic. Still others may use it for private investigation, or in flesh search engines. And, of course, governments use it for surveillance.


While it may deter very amateur hackers, the concept of security by obscurity is very seldom effective at providing actual security.

A far better approach would be to restrict the admin page to an IP (yours).

Also, I assume you are using wordpress or some other content management system. My two best recommendations for improved security would be to keep the system updated and keep a secure master password.


is it safe to use archive.is (webpage capture) to open a potential malware domain?

Is this procedure safe for a macOS user?

No it's not. And archiving malicious stuff online is bad.

  Is it possible to get somehow infected?

Yes.

Best case scenario: The URI point to an ad for generating money on click (Not harmful).
Worst case scenario: The URI point to a well crafted RCE script, that install a RAT. Welcome to the attacker's botnet.


Is it safe to browse the internet with unpatched iPhone with iOS 13.1.3?

iOS 13.1.3

iOS 13.1.3 includes bug fixes and improvements for your iPhone. This update:

•   Addresses an issue that could prevent a device from ringing or vibrating for an incoming call

•   Fixes an issue that may prevent opening a meeting invite in Mail

•   Resolves an issue where data in the Health app may not display correctly after daylight savings time adjusts

•   Fixes an issue where Voice Memos recordings may not download after restoring from iCloud Backup

•   Addresses an issue where apps might fail to download when restoring from iCloud Backup

•   Fixes an issue that can prevent Apple Watch from pairing successfully

•   Resolves an issue where notifications may not be received on Apple Watch

•   Fixes an issue where Bluetooth may disconnect on certain vehicles

•   Improves connection reliability of Bluetooth hearing aids and headsets

•   Addresses launch performance for apps that use Game Center

For information on the security content of Apple software updates, please visit this website: https://support.apple.com/kb/HT201222

Honestly, this information is just a search away. Most of the updates mentioned in this version are not directly related to fixing any such vulnerabilities/exploits as you mentioned. In such events, major security patches are usually deployed in a short span of time.

It is not dangerous to use your current version but I recommend you to use the latest version software when possible.

Even though some of the new features may not prove to be necessary, sometimes the small bug fixes/security patches can save you a lot of trouble in case of any unfortunate security breaches.


Cannot get access into a vulnerable Windows 2000 (MS03_026)

Run the command

meterpreter > load stdapi

and then run the commands you are trying. If the stdapi extension itself fail to load, it means the payload didn't run successfully. The reason might be AV or another host protection or the SMB service itself might be too unstable. Restart the machine if you have attempted the exploit multiple times and then try it. Also, set the correct target using the set target option in the msfconsole.


How do I capture Wifi traffic in the wifi channel spectrum?

I'm assuming you want to sniff 802.11 traffic, right?

Use Wireshark in Monitor Mode. When you're the menu, there should be a cog. Tick the box near Monitor, then start sniffing. You should see beacon frames and things. Also, I've written a little guide below to help you decrypt the traffic.

[Disclaimer: Please use this for educational purposes. I am not responsible for any damage you use this for. Sniffing 802.11 packets is legal as long as it has no criminal intent.]

To decrypt the traffic, you must have an 4 way handshake (EAPOL) and the WiFi password. See some things below.

Tip: Preferences > Protocols > IEEE 802.11 > Decryption Keys > (+)
The key type would be WPA2 or WEP for example. The key would have the SSID and the password.

For example, you would have it in the format of PASSWORD:SSID. Make sure to enable decryption!


Somebody hacked my router and changed my wifi SSID

There are two different passwords that access different functions.  If an attacker has the admin password, then he / she can change the SSID, WiFi password, and any other settings on the WiFi router.

To fix:  ensure your WiFi security setting is WPA or WPA2.  Then change the WiFi password to a long one (at least 12 characters, more is better) with special characters and numbers (such as #, $ %, !, 1, 6, see for example Is there any point in using 'strong' passwords?).  Also, make sure the admin password on the WiFi router is changed from the factory default.  This admin password is different than the WiFi password.  It should also be a long complicated password, but do NOT make it the same as the WiFi password.  The WiFi password is the one you give to friends and family to access your WiFi.  The admin password should be kept with you only, or people you REALLY trust, as it can be used to change WiFi settings.  Once this is done, change the SSID back to one you like.

Also, make sure to disable the feature called Wi-Fi Protected Setup (WPS).  See http://www.howtogeek.com/176124/wi-fi-protected-setup-wps-is-insecure-heres-why-you-should-disable-it/ for details on why WPS is not recommended.

If the attacker is still able to change the SSID and any passwords, your system is more deeply compromised and I would recommend contacting a computer expert or store who can help you clean your system.  They can also give you advice on if there is anything local law enforcement can do, as your attacker is likely committing a crime.


What does the 'Sign' and "Add to recipients' means in GPG keychain?

I will reply only to the Sign part. Not sure about the 2nd part.

Signature and encryption are not related. You can have the content uncencrypted+signed, or encrypted+signed.

A digital signature is an additional piece of information which confirms that the initial content is generated by the person who has the key, and thus that it has not been tampered with during its transfer to the recipient.  -- Much like a normal human signature on a document.

The "signer" generates a signature by hashing the initial content using the key he/she posseses. Then the content is sent accompanied with the signature. Each signature is unique, as it depends both on content and key. If the content is altered, the signature is not valid any more and has to be regenerated (using the key).

The receiver gets the content and the signature separately. Using his/her key, he/she rehashes the content and creates a signature. If the signature the receiver created is identical to the one the signer has sent, then the receiver is certain that the content has not been changed in the way. This is called signature validation.

If somebody intercepts the transmission and modifies the content (encrypted or not), then the signature validation will fail, because the interceptor cannot create a good signature, as he/she does not have any of the keys.


Rotating TLS Certs used with Public key Pinning

can I change the private key without changing the public key?

No. You can reuse the same private and public key for another certificate but you cannot switch only the private key and use the same public key. If this would be possible then pinning to a public key for security would also not make sense.

  What would be the point of rotating the cert only to update the expiry date?

What is the point of ending a certificate in the first place? To have the ability to create a new key and maybe adapt to a better key algorithm if needed. And because the owner of a domain might change so the previous owner (who has the private key) should no longer be able to (mis)use a certificate for a domain it no longer owns.

Of course, this could be done with certificate revocation. But revocation does not scale since more and more revocation information would have to be stored and checked. An expiration thus provides a way to cleanup older revocations (since the certificate is expired anyway) and with a short expiration it also limits the impact if revocation is not properly checked in the first place - as it is unfortunately the case with most uses of TLS.

Thus, it is not necessary to create a new key with each certificate but it is good to have the option to create a new key if necessary.

  ...  but then is it recommended to have a long expiry date on the next rotation?

It is better to have short expiration but change the key only when needed. And in case of public key pinning one should also have at least a second key which then gets used for the new certificate in case the first key was compromised.

  When keys are rotated (say I leave the public and private key the same); is there anything mathematically or from an encryption perspective that changes if only the expiry date has changed?

I'm not sure what you mean. There are no changes to the keys but the certificate is newly signed by the issuer to proof that the existing information in it are still valid. Thus at least the expiration time and the signature on the certificate has been changed.


First I would citate @TeunVink 's pretty comment. I don't have anything to give it to...

  There's a difference between the bluetooth protocol and its
  implementations. You get patches on the bluetooth implementation in
  Windows 10, that doesn't have to say something anything about how
  secure the protocol is. It could be that the patch provides security
  fixes for the implementation, but also additional functionality for
  specific devices for example.

...except my own findings from a microsoft ex-employee:

  Full Disclosure: I worked at M$ from 2014-2015.

  MS has some very talented programmers. They're not very common, but they exist. The problem is that the entire company is completely
  and totally focused on developing an absurd number of new features and
  products, giving them completely unrealistic deadlines, and then
  shipping software on those deadlines no matter how half-assed or buggy
  it is.

  The idea is that everything is serviceable over the internet now, so they can just "fix it later", except they never do. This
  perpetuates a duct-tape culture that refuses to actually fix problems
  and instead rewards teams that find ways to work around them. The
  talented programmers are stuck working on code that, at best, has to
  deal with multiple badly designed frameworks from other teams, or at
  worst work on code that is simply scrapped. New features are
  prioritized over all but the most system-critical bugs, and teams are
  never given any time to actually focus on improving their code. The
  only improvements that can happen must be snuck in while implementing
  new features.

  As far as M$ is concerned, all code is shit, and the only thing that matters is if it works well enough to be shown at a demo and
  shipped. Needless to say, I don't work there anymore.

Having many patches doesn't surely mean they are all security patches. They can be much probably mainly compatibility and stability improvements.

Microsoft has a strategy that they try to unify their Windows and Windows Mobile development, which means they try to develop both products from the same source tree. It means, improvements to the bluetooth stack of the Windows Phones can also affect the bluetooth also on the desktop OS - they are probably the same source code.

The main security concern behind the Windows Bluetooth implementation are coming most probably from the Windows Phone - on desktop machines, it isn't even turned on most commonly.

Only these reasons I wouldn't say that bluetooth, as protocol would be inherently bad. It is much more probable, that its Windows implementation has more probably compatibility problems (with earlier software / windows versions) and may have also other problems, partially security-related ones.


Yes.

In your case, one of the servers plays the role of a SSL client. It initiates a SSL connection and sends mail to another server that plays the role of a SSL server.

From the document that you mentioned in your post:

  All versions of OpenSSL are vulnerable on the client side. Only 1.0.1 and above are currently known to be vulnerable on the server side.

Since you are using OpenSSL 1.0.1 and above on both servers, both of them are vulnerable and the system as the whole is susceptible to OpenSSL MITM CCS injection attack.


Do common malware compromise recovery partitions?

Worse! I can't find it but the other day I read about a UEFI hack that installs a rootkit in your UEFI - the bootloader. If that is possible, you can reinstall your system and still get infected.

But this is not common - yet. And I believe these rootkits are not easily made, probably need to be modified for many different systems.


How should I secure a contact form that appears on every page of a website?

This is a good summary article on CATPCHA:

http://www.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/

I think you are right not to use CAPTCHA. Research has show that CAPTCHA can lower your conversion rates by 3% and potentially up to 30%. Even employing someone to manually filter or using mechanical turk, yourmaninindia.com etc maybe cheaper and better for your customer experience

Good passive measures:

The Roboo script. Demoed at Blackhat this year and gives you some DOS protection as well.
Adding a honeypot hidden field that should never be completed. You can use Javascript to fill this in automatically on legitimate form submissions and validate server side.
Velocity measures such as how fast the form is submitted.

All these are not perfect, can cause problems for disabled people and can give you false positives. If you are still getting an unacceptable amount of spam or robot usage then use the most popular and free option Re-Captcha. Ideally combine this with the passive steps above to only present the CAPTCHA if you suspect a bot submission (i.e. an adaptive approach not presented every time to users). Yes Re-Captcha has been broken in research labs with as much success as 25% using OCR techniques but it is still enough to deter dragnet bots seeking unprotected targets (running faster than the guy running from the bear). Also you are helping Google translate the worlds books and until duolingo.com comes up with its next innovation that is not a bad thing.


Is it dangerous to receive mail as root?

Only my own opinion, but this a more of a matter of educating admins. We know that every admin should have their own unpriviledged account, and only switch to root mode for administrative tasks requiring it.

In addition, the smarter the mail reader, the more complex and consequently the higher risk of security flaws => no mail in root's box will prevent an admin to use the last beta but so cute version of [insert your prefered reader here] with root priviledge.

For example in a default FreeBSD installation, many crontab jobs send their output into root's mailbox. It is simply expected that the admin will not add clever rules there and will just use the good old standard BSD mail program to read it.

TL/DR: my opinion here is that it is just an additional defense line to prevent usage of a security broken mail reader as root - not even speaking of automatic mail processing as root...


using temporary tokens for secure communication with IFRAME

You can make the requests to the child app directly from the wrapper's server code and drop the use of the iframe. The child app should only allow access from the main application server.

This would also result in a better user experience, because you would have a better, uniform design.


NoSQL is vulnerable the same way SQL databases or LDAP databases are vulnerable like. When a language is used to program an application and you interface to a database, you will need to put information into the database.

The danger with any of the products is that a user can include code instead of information. This is not dependent on the type of database or language used.

When you get user-input you need to make sure that you sanitize it to prevent code inclusion from happening. The problem with NoSQL databases is that often there are not yet or not deeply enough tested API's for your language available. This means that you will need to write it yourself. This is dangerous as there might always be something you look over the head. I want to refer you to OWASP - Insecure Direct Object References

I know there have been concerns about, for instance MongoDB, on the standard authentication mechanism that is being used towards the database itself. This is more an issue of not exposing your database itself to untrusted sources directly. For instance this is as if you would allow a user of your website to directly connect to your MySQL database. While this may still have a great impact, the likelihood of getting your database compromised like this is low and does not depend on your webapplication.


Is it safe to implement 15 bytes password reset tokens?

Let's say you want to be extra careful and hash the token in case of a database leak (tokens should expire anyway, but maybe some are still valid shortly after a leak). You also don't want to have any useful information in the token since emails aren't difficult to intercept, in fact, you don't even want to have an incrementing reset token id because someone could see how many tokens have been issued (what they would do with that I don't know, but maybe you're a bit paranoid).

So to have some way to tie it to a user while still hashing it, you decide to take a 256 bit value generated by a CSPRNG, split it in half, use the first 128 bits as an identifier, and the 2nd 128 bits as the token. Both halves are included in the reset token url, the database stores the first half in plaintext, and hashes the second half before storing.

So you've got a 256 bit value now, how do you encode it in the url? If you want to only use letters and digits, you'll need ln(2^256) / ln(36) ≈ 49.5, 50 characters. So there you go.

I'm not saying everyone using a long reset token is doing it this way, but this is a reasonable thing to do that would require a longer token.

Does this mean a 15 character token is bad?

Not really. It's only got about 77.5 bits of entropy (assuming it's generated by a CSPRNG, which it needs to be), which is a bit low, but if you're not worried about an offline attack (hopefully your reset tokens are short lived), that's perfectly reasonable. It just means there's also a reasonable way to come up with a 50 character reset token. And really, what do 35 extra characters in a url hurt?


HTTPS in captive portals and the Apple Captive Network Assistant

I'll let someone else answer about how the iOS captive portal interface displays certificate status and whether the captive portal is served over HTTPS, but I do know a solution.

When connecting to an open Wi-Fi, dismiss the captive portal sheet then click on the network entry's "i" icon on the right in the Wi-Fi network list. That will display properties for the network and will include a "Auto login" toggle which controls whether iOS tries to detect and handle the captive portal. Turn it off. That way, iOS will connect to the network and you'll be able to use the standard Safari browser to log in to the captive portal, which displays a lock icon if the page is served over HTTPS.

An even better solution would be to push your public Wi-Fi provider into using EAP to authenticate users instead of horrible and insecure captive portals.


what's the absolute worst damage javascript could do to a client?

The intended reach of Javascript is limited so it can not access the desktop nor any files in your computer.  The security of your computer is limited to how up-to-date the browser is (patching etc), and the associated Plugins.

On the other side, "bad guys" try to find holes in technology and use that knowledge to gain access to something they otherwise wouldn't.  When this happens, and the vendor is aware of it, a patch is released.

A few bad things Javascript can do:

Javascript alone might allow all the information of a poorly written website to be sent to a "bad guy".  This is called XSS / CRSF.
It can also cause your logged in account to make changes to websites (editing financial data of a different unrelated site) without you knowing.
Finally in regards to your local computer, the exposure depends what add-ins are installed (Flash, etc).  If the client has an old version of flash installed, then your whole PC can have malicious software installed on it, or have security dialogs altered to confuse even an educated/informed user.


Is it possible to deny Permission access and other Settings using Screen Overlay in Android?

First, a user should be reviewing permissions for an app. I would never authorize an app to do stuff like overlays or camera access without a good reason; the only permissions I grant are those I expect. Even if the app did get camera permission, there's always increasingly aggressive actions the user could take to resolve the situation.

Keep popping up in Settings to try and stop me? I'll just uninstall you from the Home screen. Try to block my home screen? I can always turn on Safe Mode, then uninstall you. If even that fails, I can just format my device, since I keep cloud backups of my data. Unless the device is in developer mode, I'm fairly confident that there's no such thing as an app that can subvert control of the phone so severely that the user can't fix it.

That said, I've also found no evidence that Android "protects" apps, even the Settings screen, from being overlaid, so a novice might have some trouble getting rid of an app that's gone this far. I'm pretty sure that a savvy user, such as myself, would be able to gain control no matter the situation, but an average user might need technical support.


Does Oracle's GuardedString protect sensitive data against heap or memory dumps?

Some deeper look into the actual implementation will help an attacker understand the data structure of a memory dump, and from what I found in EncryptorImpl there has been put no effort into obfuscating the key storage mechanism to prolong the time needed for reverse-engineering the secret. So no, this is not an effective measure against exposure of memory.

Let me provide a better usage scenario for this class:
As the key variable is private, at least it's very unlikely a developer would find his way around responding with the key by accident to an attacker (e.g. due to a bug in the control flow of a web service request handler), so there is some use for this class in ensuring the code can only help decrypting by actually decrypting in the background instead of handing out a key. After the program is stopped / taken offline, an attacker won't be able to decrypt secrets anymore, and all decryption that happened until then (when the attacker was using the program as a kind of oracle) had a chance to be logged, which can be relevant in a post-mortem analysis to figure out what data has been compromised.


CSRF tokens in file that we can upload a file

The <input /> should be inside the <form></form>.
As the <input name="token_form" /> is currently outside the <form></form>, the token is not sent when you submit the form.


When can the exploit for CVE: 2006-7098 be used?

"Local attacker" means local to the machine. The official CVE states "local users" which is even more specific. Futhermore, this looks like a Debian-only (perhaps systems build on Debian as well) issue. It also looks like this problem was the result of applying a patch to Apache. So you'll need the right version of Apache as well.

Of course, the right solution is to use a supported version of Apache and apply all security patches promptly.


What to do with an APK file containing Swf.Exploit.CVE_2015_0323-1 and ELF File?

You should NOT.

First, you don't know if the file is trustable, you got it from some "source". It is never advisable to install APKs from untrustworthy sources, especially on your primary device.

Second, it contains a known vulnerability.

Third, it is an offline game, and it requires full internet connection(it may be because of ads, but you never know what all it is transmitting and receiving).

Fourth, you have a pretty much old version of Android, and it is not up to date with all the security patches.

UPDATE: If the app has permission for writing/modifying files on your device's storage, the files might remain even after uninstallation of the app.


Security Implications of Google's Two Step Authentication’s Backup Codes

Think of it as writing your log in password in a piece of paper since they both serve the same function. The risks associated with it are related to physical access to where the print out is stored, accidental snapshot (office pictures) and the like, in some odd cases even a print queue could allow to print a second time.

At the same time think of storing sensitive information in usb sticks, you may consider encrypting the files or the entire usb drive, but you are still prone to losing it.

Shoulder surfing is also a risk, if you need the piece of paper 5 times a day that's 5 times a day someone can be looking over your shoulder and writing down a couple of digits.

You are right in that this method of authentication is less secure, Im sure they faced a scenario where this was necessary but I would say unless you yourself are faced with that specific situation going with 2-step authentication methods is in general safer. For example, if you use your phone to receive a token, an attacker would need access to your phone, and would need to unlock your phone, which although not impossible it adds an extra layer of complexity.


Drawbacks to only using TLS 1.2 ciphers in OpenSSL

At the moment, the only drawback is compatibility. But if that's not an issue for you then you're golden.


I think I found the answer (at least as theoritical). According to the paper written by Andreas Westfield, F4 and F5 solve this problem by mapping even negative coefficients to a steganographic, odd negative coefficients to a steganographic zero. Through this map, not only embedding 0's cause to shrinkage but also embedding 1's. Thus the shape of histogram will be preserved.


Is shadow-stack using for anti-BufferOverflows only?

Intel CET protects against Return Oriented Programming, not buffer overflows per se. Its job is to make sure that each RET instruction returns to the same address that its corresponding CALL instruction came from, and that's it. To do this, the hardware maintains a memory section called the "shadow stack" that is out of reach of the program itself. Each CALL instruction pushes the appropriate return address onto the shadow stack, and each RET pops the top value off the shadow stack and crashes the process if that value is not equal to the return value on the actual stack.

Return Oriented Programming is a way to get around DEP (or NX) technology. Since with DEP you can't just inject executable code any more, you can instead use ROP to overwrite return addresses and string together fragments of the program's own code in an order that makes it do your bidding.

Buffer overflows are used to inject payloads into a process's memory space, and those payloads can certainly be ROP payloads. But there's no fundamental relation between buffer overflows and Intel CET.


can my internet provider see my communications?

The answer is no they cannot, but yes they can.

You have to accept that there is a yes and no to this question, SSL should protect your communication from snooping even from an ISP but if an ISP wanted to do something similar to a MitM they could do so with a fair amount of ease but I will put this down to "similar stuff"....

To reexplain SSL The client and the webserver exchange certificates which are normally signed by a 3rd party to validate that the webserver you are connected to is the genuine one. This SSL checking is to ensure you are connected to the real server and not an attacker, this rule applies to a MitM attack even if done by an ISP you would have to be over an insecure (http, port 80 etc) connection for them to be able to read it. The rules that apply to the rest of the world apply to an ISP they have no special power really, just maybe more resource and a better tactical point in the network infrastructure. so if you are on https your traffic is encrypted and cannot be read.


A zero-day attack is an attack that relies on an undisclosed vulnerability in the design or implementation of a system in order to violate its security.

Most commonly, such attacks consist of using zero-day exploits to access information systems or execute code on privileged systems. Such exploits are called 'zero-day' because security administrators have had no time to mitigate them between the moment they were disclosed and the moment they are used to perform attacks.

In contrast, the typical responsible disclosure procedure involves privately contacting software vendors and exposing the vulnerability to them, and leaving them reasonable amounts of time to fix the vulnerability and distribute the fix to their clients and users. This process can require coordination between multiple software vendors and distributors so that they all release and distribute fixes or patches on the same day. Indeed, releasing a fix helps attackers understand the existence of a vulnerability in the first place, and teaches them how to attack the systems that have not been patched yet.

This is where 1-day or n-day exploits kick in: now that vendors have admitted to a fault and started repairing it publicly, attackers can write exploits that target those systems that were not yet updated since the time of disclosure. The term 1-day or n-day indicates that a delay of 1 or more day / n days has occurred between the time of disclosure and the time a system is attacked. The goal of vendors, distributors and administrators is then to patch systems as quickly as possible to avoid n-day attacks.


Is it a security concern to publish the current boot_id?

There is nothing unique to that ID which would make it any more confidential than any other randomly-generated boot identifier. That is to say, if you use it in a way that turns it into sensitive material, then exposing it is of course a bad idea. If all you're using it for is checking if the machine has rebooted, then there's no reason it needs to be secret. It is generated by the kernel completely randomly.

From lib/uuid.c in the Linux kernel, the following function is used to obtain random UUIDs:

void generate_random_uuid(unsigned char uuid[16])
{
    get_random_bytes(uuid, 16);
    /* Set UUID version to 4 --- truly random generation */
    uuid[6] = (uuid[6] & 0x0F) | 0x40;
    /* Set the UUID variant to DCE */
    uuid[8] = (uuid[8] & 0x3F) | 0x80;
}
EXPORT_SYMBOL(generate_random_uuid);

The kernel uses this function to generate a random UUID the first time kernel.random.boot_id is read and saves the result, returning it for any subsequent reads for the duration the system is up.


How to exploit RCE vulnerability for machine on local network

It could be that some of the outgoing traffic from the server is blocked. Upon gaining a RCE there are various techniques to check if you can get a connection back:

Try ping yourdomain.xx - Check if your domains DNS query is executed by the victim server, if it is, that means you can setup a shell through DNS. You can use a tool like https://github.com/iagox86/dnscat2, or just manually exfiltrate data with DNS TXT records.
If for some reason that doesn't work, you can check if outbound 443 port is open by doing a simple wget https://yourdomain.xx/curl -k https://yourcomain.xx. You can use a tool like https://github.com/EmpireProject/Empire.git to eastablish a shell, remember to setup a certificate as well.
If that fails, than you can just check for other open ports ports here's a nice list of reverse TCP shells http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet, but I would advise against using them if you are traversing a perimeter firewall and public network, they get detected/blocked easily.

In summary:

Check what you can reach
Use that to create a shell
Do whatever you came to do

*This is not intended as a deep dive explanation, but just as an example of some of the techniques you can use


How does Kerberos independently setup K(A,S) and K(B,S) securely?

For users, the keys are derived from the account password (using the principal & realm names as salt). When you set or change the password on your account, the KDC stores keys derived from it. When you log in using kinit, the Kerberos client derives the same key as the KDC has.

For services, the keys are randomly generated on the KDC, and provided to the service in a "keytab" file out-of-band. Usually the key generation is done via Kadmin RPC secured using an admin's user credentials (and optionally delivered via HTTPS, SFTP, USB stick, etc.)

  And how does Kerberos ensure that 'A' is who they say they are?

Just like many other systems, it assumes that only the account owner knows the secret key – therefore whoever knows the secret key must be the account owner.

Note also that since the service itself has K(B,S) it can craft "fake" tickets for A→B; sometimes that's considered a feature.


Security feature: Preventing javascript from closing the window

The reason this limitation is enforced, is that the SOP policy does not apply to window.close(), instead, you can actually close any window. It would be impossible to apply the SOP policy to window.close() as normally, each window in a browser process is isolated from each other to prevent certain cross-boundary attacks, thus even your "own windows" would be in a different SOP scope.

A common process where this are used, is in a payment process, where the webshop site popup a window for payment, and then when the webshop site detects that payment is complete, the window is closed.

To prevent abuse of this feature to for example close down other site's windows, the limitation is set that only windows opened by a script may be closed.

In the circumstances you want to log out or move away a user from the page, the normal action is to enforce non-cacheability and then use window.location.href instead to move the user to a "logged out" page.


Can a router detect transitive/cascaded telnet sessions?

No, the firewall logs will show 2 TCP sessions:

A session from x.x.x.x to y.y.y.y
A session from y.y.y.y to z.z.z.z

You are opening a remote shell session on y.y.y.y and using that to connect to z.z.z.z,  there isn't anything on the firewall that is going to automatically tie these 2 connections together. A competent and curious firewall engineer would certainly be able to join the dots though, as there are logs for the incoming and outgoing sessions, and system logs on the firewall itself that will show the logins.

I hope you aren't doing anything you shouldn't be.


Is NTLM (over HTTPS) on IIS a good idea for a Internet-facing website

Secure HTTPS
Using HTTPS is great though a secure protocol and cipher must be used. There are a number of vulnerability scanners that will test this. Here are two examples:

Qualys SSL Server Test
Nmap ssl-enum-ciphers

NTLMv2 is Fine
You didn't specify whether NTLMv1 or NTLMv2 was being used. If the former (NTLMv1), this would definitely be a finding and cause for concern. There's no reason for that protocol to be in use nowadays especially on a public facing application. NTLMv2 is perfectly fine and some may consider it more secure than alternatives since it works on a challenge/response where the actual password isn't even sent to the server. As an example, Microsoft SharePoint and Exchange can have publicly facing components using NTLM authentication.
Difficulty with Windows Authentication
No Kerberos
NTLM authentication is the default authentication method when the application is configured to use Windows Authentication. This is because Kerberos requires extra configuration steps and the client needs access to the Kerberos infrastructure (i.e. Domain Controller). This would be fine if the web application is only accessed from the LAN or via a VPN. However a public facing web application doesn't make this a feasible option.
Lacking Session Management
Windows Authentication lacks control over session management. Take for example an app using Forms Authentication, the session cookie can be expired after a specified time or extended on each request. This isn't the case with an application using Windows Authentication. Failure to properly terminate a session would definitely be a finding.
No Branded Login Page
The Windows Authentication login box is the generic window provided by the browser. Many prefer to provide the user a "Branded" login page as it allows the user to be more aware of what application they're about to log into. Checking the URL bar to ensure the location is accurate and certificate is valid (e.g. colored green). This leverages end-user education on phishing prevention and good security awareness. Depending on your environment, this could be a finding.
No Brute Force Protection
Generally there are two methods to protect a website against brute force login attempts: MFA and captcha. Be default, a web application using Windows Authentication doesn't support MFA. You may find an provider that leverages a module to achieve this but I'm guessing you're not using one of those providers. Regarding captcha, there is no way to implement that. This requires one to monitor the web application for brute force login attempts.
To address this, I wrote a PowerShell module WebsiteFailedLogins. From the README:

This PowerShell module was created to identify the following scenarios affecting IIS hosted websites.

Brute Force Login Attempts - excessive failed logins from a single IP address and often targeting a single account.
Password Spraying Attempts - excessive failed logins from a single IP address using a single password across multiple user accounts.
Distributed Login Attempts - either of the above techniques being sourced from multiple IP addresses.

It leverages Microsoft Logparser and a configuration file to parse the target website's IIS logs. When a threshold is met or exceeded an alert is generated via standard out, email, and/or written to a Windows Event Log. No changes are needed on the webserver. This module can even run on a separate system where there's access to the IIS logs.

Older Framework
This isn't necessarily a finding. Run Windows Update, or whatever product you use to manage Security Updates, on the server running IIS. If there are missing updates then it will obviously be a finding. Check CVE's for any addressing the web application CLR. Chances are, if there are no missing security updates there will not be an open CVE.
Check Supporting Components
If you're concerned about an older framework, this leads me to believe the application itself is dated. Look into supporting components like jquery to ensure they're not using an insecure version. This may reveal a finding.
Alternative - Forms Authentication
With HTTPS configured to use a secure protocol and cipher, the best alternative is Forms Authentication. While the login credentials are transmitted in clear text; secure HTTPS mitigates this. It also achieves:

Better Session Management
A Branded Logon Page
MFA or Captcha Integration

This approach will require a retooling of the web application. Two caveats to be aware of include:

The web application must use a secure method of authenticating credentials on the backend. Whether its Kerberos or LDAPS, just be sure the credentials are not shared in an insecure manner on the backend.
Access must be tested to ensure resources are not accessible via insecure methods. For example, by default MVC applications would use a static handler to improve performance when serving .js and .css files thus bypassing the authentication requirement. In some instances these resources should be accessible to authenticated users only.

Alternative - SSO
The best method to address these authentication issues is to implement a Single Sign-On (SSO) provider. It will still require the web application to be retooled for the new authentication method. However, long term this is the best approach as it centralizes authentication for the enterprise.


This is a trade-off between usability and security and therefore there is no "right" answer. However, there are a few guidelines.

PCI DSS says 15 minutes at most:

  For a sample of system components, inspect system
  configuration settings to verify that system/session idle time out
  features have been set to 15 minutes or less.

ASP.NET has a default timeout of 20 minutes.

For PHP the default timeout is 24 minutes, but this is almost certainly by accident.

Some web applications (Facebook, Gmail) don't have an idle session timeout at all. If you want an idle timeout, around 15 or 20 minutes seems reasonable.


How to set up a multi-developer environment with emphasis on source code security?

Firstly, you need to weigh up the cost/benefit of what you're trying to achieve.

Generally preventing code theft by developers is a very steep uphill battle, but fortunately I don't think it's a very common problem. I can't think of many prominent examples of code theft except in some cases where very specific proprietary algorithms are involved, or perhaps an employee jumping ship to a client and taking their code with them.

In terms of physically restricting access to code, really the only viable way is to restrict access to repositories. Even then, that will only be significantly effective if your application architecture in such that entire components can be operated as separate services and high risk employees can work on low risk components which might interact with the high risk components as a "black box" without having to give them access to the code.

It sounds like a high risk employee jumping ship with the project they're working on is your biggest threat and fundamentally they need access to that code to do their job so there's not much you can do about that.

The threat of legal action or damage to their professional reputation usually provides enough incentive for developers to do the right thing. Perusing these controls is probably a more practical approach. Endeavouring to hire trustworthy employees should also be obvious.

With regard to your deployment process specifically, it's pretty bad from both a security and operational standpoint. It seems you're without any form of version control, and I'd be shocked if you weren't frequently overwriting each others changes accidentally and trying to figure out who changed what without any way to know for sure.

It's typically considered good practice for:

Your developers not to have direct access to your production servers except via an automated deployment process that takes code from version control where changes will be attributed to a specific developer
To have a discrete deployment (as oppose to incrementally changing files) sourced from an explicit version control version
For developers to have unique accounts, and typically their version control access dictates access to the production servers via their ability to commit code which will then be deployed automatically

There's plenty of resources on implementing version control and deployment management so I won't go into it too much further.


Standards for secure key backup of master keys with secret sharing

A complete solution in the context of HSM must be HSM-specific because you do not want any piece of secret to ever go through the RAM of a PC, let alone its hard disk. The HSM should include a smart card reader, or establish a secure tunnel (encrypted and authenticated, à la SSL) with a hardware module which includes a smart card reader. The host PC, for a HSM, is used as a network router and an electrical source, nothing more. You use a HSM precisely because you cannot trust a PC for the secret values you are dealing with.

Under these conditions, there is little reason that a standard may have evolved, and indeed none has, except for the usual smart card basics (card size, connector emplacement, encapsulation of commands within APDU). For a HSM to have a secure backup method, it must be something "homebrew", directly integrated in the HSM.

Moreover, any certification for the HSM (e.g. FIPS 140-2 level 3) must cover that backup system as well. Consequently, you cannot slap a system with smart cards on an existing HSM and still claim that "this is certified".

Thales "nShield" HSM include such a native support for smart cards with a quorum. The actual secrets are encrypted files (what Thales calls a "security world") and the "administrator smart cards" collectively contain a master key which is sufficient to decrypt these files.


How to remove tcp header of packets captured with dumpcap?

The "garbage" prefixing the data you are interested in are the protocol layers (ethernet, ip and transport headers)

When you save the data captured with dumpcap, you are also recording these protocol layers.

To filter them away to only view the TCP data, you need to process your data through a program. Tcpflow is a tool that can extract data from tcp packets.

Take a look at this question, which is essentially the same you are asking.

In your scenario, you would want the command to be something like:

tcpflow -C -r <your-pcap-file>


The safest way to access GMail on mobile devices

All of these apps will use SSL in some flavor (probably https)  to contact Google.  Google doesn't provide another interface for good reason.

Everything can be compromised.  You can be hacked though your browser and it doesn't matter what device you are using.   Once the attacker is on your machine it doesn't matter if your email is encrypted.  The attacker can wait until you decrypt it,  or just take your password.


If the ssdeep value of two files are pretty close to each other, is it guaranteed that the file contents are pretty close to each other?

It is not guaranteed but it is very likely. See also the original ssdeep paper where it computes the chance of two random files having the same or similar signature. It is not zero but is close to zero.

  Or is it that when ssdeep is completely dissimilar there is no chance that the file contents are similar?

This depends on what is considered similar. If one for example recodes a UTF-8 file to UTF-16 one might consider the content still similar since it is just differently encoded, but the ssdeep hash will be very different.

If one instead treats the data as octets without any specific semantics and views the similarity as the amount of insertions or deletions, then a very different ssdeep value will mean in most cases a high number of insertions or deletions.

But one can probably create some input where a small change will lead to a large ssdeep difference. This is the case where the small change would lead to a critical change in the length to the signature so that it is considered too small with the original block size in on of the inputs which will cause a recalculation with the block size halved, leading to a very different signature.


There is no best practice for writing down passwords (or credentials in general). This mostly depends on your own company and how you decide to write them down, I don't see any reason to have rules in place for standardized credential writing. The advise in general is to not write down credentials at all. If you must write down credentials, there are a couple steps you can take to improve security.

Use two factor authentication so that if credentials are leaked, your accounts are still somewhat secure;
Make sure to have a standard when it comes down to writing down credentials and the disposal of papers with credentials on it. You can for example have a standard paper for writing down credentials and a special bin to remove then;
Fold paper with credentials on them so other people cannot as easily read them by looking at them from a distance.

One of your main problems will be a violation of 'clean desk policy' which you can look and why it is important and things like bin diving.


Nothing unusual. What happened here was that a non-blocked loaded the blocked page inside a frame. This can cause the blockpage to inherit the favicon and title from the non-blocked page. This is not a security risk because a fake page could aswell spoof the favicon and title anyways instead of inheriting it from a Another site.

Clearing the cache does in most time solve the problem.


Is this code vulnerable to DOM based XSS jquery animate?

The code snippet you shared above is not vulnerable to DOM-based XSS. jQuery version 1.12.4 is not affected by the selector XSS bug. I highly recommend using http://research.insecurelabs.org/jquery/test/ to determine if a specific version of jQuery is affected by any publicly-disclosed vulnerabilities.


How safe is accessing HTTP traffic(non-SSL) when using VPN and connected to public WiFi?

If the concern is just as far as the WiFi hotspot and the users who are connected to it, then as long as you are connected to the VPN, the traffic should be encrypted and cannot be viewed by any other WiFi user.

There are some concerns however, on the type of VPN used, which encryption method it is using, and so on. Also, I think the biggest concern would be if the VPN gets disconnected without you knowing, which would automatically fall back to unencrypted WiFi traffic.

Depending on your OS, you could configure it to stop all traffic if VPN is not connected at any point of time.


Is storing session data in the DMZ ok in an n-tier enterprise web application?

Ultimately, this comes down to the level of risk you are prepared to carry. To assess that, you need to understand the impact of each risk being realised.

In this case, if there is relatively little impact if the session data is breached - which is to say that an attacker couldn't use the session data to mass exfiltrate personally identifiable data or create costly errors - then you are probably OK to keep it in the DMZ with the application.

If the session data would give access to credit card or other financial information, addresses, medical data, ... - especially for multiple users, then I'd say that was a significant risk and I would want to see it better secured.


Why can the validity of an SSL certificate exceed the registration period of a domain?

There's just no way to fix it. Even if the registration period is two years and a one year certificate is issued, you could still sell or drop the registration next week. There's nothing the certificate authority can do about that. (Well, I suppose they could monitor the registrations and if there's a change in registrant, they could revoke the certificate. I've never heard of any CA doing that though.)


What is the best option for setting up a several sites supporting SSL on the same IP?

From what I've seen "Server Name Indication" is the main way to achieve this at the moment.

One of the downsides is that older browsers won't support this so depending on the site it may not be a possibility for it to be used.

Edit: Just to update following @D.W.'s and @Piskvor's comments looks like there's a list of supported and unsupported browsers on the linked Wikipedia page now.

All popular browsers support SNI, including all versions of Internet Explorer on Windows Vista and later. Internet Explorer 6, 7, and 8 on Windows XP were the main browsers that did not support SNI, but they no longer receive security updates since April 2014.


Can secret GET requests be brute forced?

You are essentially asking if it is safe to pass secret parameters in a GET request. This is actually classified as a vulnerability. It is not feasible to brute force a sufficiently long pseudorandom string, assuming the server simply returns a static 404 response whenever an invalid path is specified, but there are numerous other security issues in practice that make this a dangerous technique:

Logging software often logs GET requests in plaintext, but not POST.
Using GET makes CSRF trivial* when processing active content.
Referer headers may leak secret values to other websites.
Browser history will retain secrets passed in GET requests.

Your second example has /admin/ in it. This implies to me that knowledge of this path alone would be sufficient to authenticate to the server in an administrator context. This is very insecure and should not be done anymore than /?password=hunter2, a major web security faux pas.

Instead, secrets should be sent in a POST request. If this is not possible to do or if your threat model is exclusively to prevent brute force of the URL (for example, password reset links which are promptly invalidated after they are used), then it should be safe if done carefully. I am not aware of any side-channel attacks that would provide a method to obtain the string faster than brute force.

* Avoiding parameterized GET requests does not prevent CSRF attacks, which is a common misconception as there are various ways to similarly abuse POST (fake forms, etc), but passing secrets in GET does make CSRF easier.


SFTP -What is Public Key is Duplicated on another server

Underneath the hood SFTP uses SSH but the same principles apply.

Generally, it is impossible to derive the public key from the private key. Hence we're allowed to share/publish the public key without any fear of the private key being compromised. You will use your Private Key to authenticate yourself to ServerA, and ServerA uses your pre-loaded publickey to ensure it really is you.

However, to answer your question, You will also authenticate serverA by checking its SSH key fingerprint. Basically the first time you connect to ServerA, you'll be prompted to save its SSH key fingerprint (which is a hash of serverA's public key). This will be saved locally on whatever client application you're using.

If someone managed to copy your public key -- and someone manage to hijack the dns/ip of serverA, and route all traffic from you to it -- you'd still be warned that the servers underlying public key has changed, and you should proceed cautiously. You might think "well what if the hacked serverA and got it's public key as well"

If they hacked serverA to the point where they could get the public/private key pair of the server -- they most probably already have access to your files as well :)


Getting a manual security code review done - What to watch out for?

Realizing that you even have such a question already puts you ahead of the game.
I would also add:

  (C) He's not very good at reviewing code, so you'll only get "low hanging fruit"
  (D) He's really a pentester, that thinks its "oh so easy" to branch out into code, so you'll get similar results as a pentest, only traced to the actual code.
  (E) He's a developer, without much understanding of security, but knows some bad code.
  etc...

Point of the matter is, it seems that he's not being very transparent with you - so it doesnt really matter which option it is. Even (A) My code has no problems is not worth very much, unless he can back it up with proof of which problems your code doesn't have (sic).
And no, running an automated tool does not count as a security code review, as you apparently felt, correctly.

So, to your questions:

1. What should you ask him to do "Security code review". He should be telling you what he will do, and/or recommend what else you need (this could/should be a pretty long list). Of course, you can/should give him more input, such as what your application does, who has access, how sensitive the data is, etc etc. But even if you don't, he should ask for this information. Without it, it's simply not a professional-level code review.

2. How do I cross-check his work - I would say that in general, there are 3 possiblities:

Learn enough about the subject to understand what he claims to be doing, and to ask the hard questions - or get somebody who does (Always true when dealing with provider of a service you don't quite understand...)
Have another consultant do a competing review - even if only on a subset of the application.
(And this is the good one) Perform an external blackbox penetration test. This is the best way of validating the code review. Of course, have someone else do the pentest, and compare results. Note that not all vulnerabilities found in pentest are relevant to be found in a code review, and vice versa, but it should give you some indication.


OpenVPN error=unsupported certificate purpose

I just had the same issue and wanted to share my 'solution'.
I was stupid enough to have ./easyrsa sign-req server client01; which produced the same error:

TLS: Initial packet from [AF_INET]***:***, sid=*** ***
VERIFY ERROR: depth=0, error=unsupported certificate purpose: C=.., ST=.., ...
OpenSSL: error:***:SSL routines:ssl3_get_client_certificate:certificate verify failed

Setting it to ./easyrsa sign-req client client01; resolved the issue...


What attacks are httpOnly cookies intended to prevent?

The httpOnly flag prevents javascript from accessing the values of cookies.  It's intended to reduce the impact of cross-site scripting attacks, by preventing access to sensitive data, such as the session token.  Relevant attacks would be the cookie theft, and session hijacking attacks which rely on values from the cookie.


Would it be possible for me to gain access to the computer by impersonating the legitimate keyboard in some way?

Probably.

But there are a few question you need to ask yourself here:

Is the computer generating the PIN or is the keyboard?
Does the PIN change? If yes, how often?

If the PIN does not change, it doesn't really matter what device generates the PIN and all you have to do is obtain/crack it.

After you obtained the PIN you will need to knock the other keyboard offline (or when the user is not in the room) in order for the PC to connect to your keyboard.