Information gathering before deploying a Network IPS I understand that most NIPS these days have either rules or signatures built in to them and perhaps gathering information prior to deployment may help in fine-tuning the rules / signature once the IPS has been deployed, up and running.

As such what sort of information do we need to gather prior to deploying an NIPS (e.g. OS-es on a network, network segments)?

Opinions, thoughts and suggestions would be greatly appreciated.

In the ideal situation you would put together a list of all assets and threat vectors on your network, including but not limited to:

Operating system flavors and versions
Applications
Network infrastructure
Anything else plugged into the network

With that you could plow through all of the signatures that are available and include only the ones that apply to you. For instance, if Solaris does not exist on your network, then there is probably no reason to include a signature for CVE-2007-0882 (the telnet auth bypass). In this case you can determine, within some degree of accuracy, which classes of rules need to be enabled before you even insert your first sensor. Keeping in mind that these signatures are constantly being updated and added to, you are better off thinking in terms of types of signature instead of specific signatures.

If you have a tightly regulated network, then go through your CMDB to build out this information. If you don't have a CMDB this might be a good time to get one started. If you are not in a tightly controlled network then you can get started by doing flow analysis or review packet captures. A good vulnerability assessment tool might also help give you a list of what's out there.

In either case, you should assume that whatever picture you develop is incomplete. I would recommend erring on the side of enabling too many rules, and just plan for a pretty intense initial tuning.

Never forget that an IPS/IDS system does have a fair amount of on-going maintenance. As signatures are updated and systems/applications are added/subtracted you will need to evaluate what you're looking for.


Why would legitimate programs have a `jmp esp` instruction? It appears that a common exploit trick is to use stack overflow to overwrite the instruction pointer such that it points to a jmp esp instruction somewhere in the code segment which then executes the arbitrary code of the attacker's choice.

However, I have a hard time understanding what use legitimate programs (which to my understanding are usually not self-modifying and have all of their executable code stored in the code segment) would have in including such jmp esp instructions in the first place.

The instruction jmp esp is encoded as FF E4. It’s not necessary to find an actual jmp instruction, just those bytes in the middle of any other code or data.

This is the basis for return oriented programming (ROP) and these small sequences of useful instructions are often called “ROP gadgets”.

Note this particular technique is easily broken by a non-executable stack. Requiring an executable stack is quite rare (outside specific cases like a JIT compiler) so this is a simple and effective mitigation. To get round this there are techniques like return-to-libc which chain a number of these small ROP gadgets to build a longer sequence of instructions.


DOM XSS attack failing in Firefox I am trying to perform DOM XSS attack to exploit a vulnerability of localhost webpage. I am able to perform the attack successfully on IE-11 and Chrome. But Firefox is preventing me to perform the attack by encoding the script I put in URL. I am performing the attack as explained on official OWASP page.  In order to bypass the XSS auditor of chrome I am following the trick explained in this amazing article (even though he explains Reflected XSS in article but it works well for DOM XSS also). So how can I perform DOM XSS attack on latest Firefox?

Note: I am able to perform Reflected XSS with Firefox (example) but I want DOM XSS specifically where the information is not sent to server.

The reason is simple: Firefox (I think from version 27 on-wards) now encodes (URL encoded) everything and you can now only exploit DOM XSS in Firefox if in the code developers will do explicit mistake of decoding.

You may find this recently published article useful: http://www.lanmaster53.com/2014/3/dom-based-xss-revisited/


Apache redirecting to unsecure port I have setup a test website in order to play around setting up SSL.  The website is setup on a Windows host with Apache 2.2.20 with OpenSSL 0.9.8r, MySQL 5.5.37, PHP 5.3.28.  The URL to the home page of the website is http://example.com/index.php.  Once you get to the index.php page, you are instantly redirected to http://example.com/login.php.

I setup SSL with a self-signed cert.  When I navigated to index.php on https, I get the error stating the certificate does not match the server.  I click on "Continue to this website (not recommended)."  I receive the message "You are about to view pages over a secure connection."  I select ok, and I immediately receive the message "You are about to leave a secure Internet connection."  I select yes I want to continue.  IE errors out and states "Internet Explorer cannot display the webpage."

If I navigate directly to login.php on https, it works as expected.

My question is...  What would be causing Apache to start loading secure and then switching to unsecure?

It is very likely that you're simply doing something like this:

<?php

if ( ! $is_logged_in) {
    header('Location: http://example.com/login.php');
    exit;
}

Just change your redirect url to https, and everything should work as intended.


Are malicious relying parties able to abuse OpenID logins? if I logon with OpenID into a website (crafted by attackers/hackers) I want to know how much damage can they do to me?

Are they able to steal my contact info, name, etc (assuming I'm using Gmail OpenId)

If you authenticate to another website with Google's OpenID system, it will tell them that the person authenticating is in control that particular GMail address. Unless they get in-line between you and another site, they can't perform a MITM attack. They can only effectively take advantage of your credentials if they pretend to be your identity provider and you put your password onto the wrong website.

For a comprehensive look at what can go wrong with OpenID, Google says it better than I do: http://sites.google.com/site/openidreview/issues


Why would I use MAC over digital signature? As far as I've read, there is no benefit of a MAC over a digital signature - except the fact that it is faster to generate and process.

Is this true? Digital signatures (asymmetric encryption) seem to have gotten fast enough that almost every website uses them. So it can't be that big of a drawback nowadays.

Am I missing something important?

Performance alone is a reason to use MAC.

Consider a TLS connection. For every packet, the receiving party needs to verify that the packet wasn't modified in transit by a man-in-the-middle attacker. So for every packet, the sender needs to calculate a MAC/signature and the receiver needs to verify it. If you want, say, a 10MB/s transfer rate and an average of 10kB/packet, that means you only have a fraction of 1ms to calculate or verify the signature. That's too slow for a digital signature.

The amount of time it takes to create and verify an asymmetric signature is small enough to be a non-issue if you do it once when a connection is established, assuming you have high-end hardware such as a PC, server or smartphone (it can be an issue on embedded devices). But it doesn't work if you need to do it once per packet.

A digital signature has the advantage that it can be verified by a party that isn't able to generate a fake signature. This isn't useful in a case like a TLS connection. For TLS, the two parties set up a session key, which is a symmetric key that is generated randomly at the start of the connection. After that, the only two parties that know the key are the client and the server. If the client sees a valid MAC (that it didn't generate itself), it can only have been produced by the server, and vice versa. Similarly, once the session key has been generated, it (and not asymmetric cryptography) is used for encryption.

(Properly speaking, the same key shouldn't be used for different purposes such as MAC and encryption, even if it happens to have the right format. I simplified things a little above. The “session key” is actually some secret material from which an encryption key and a MAC key are derived — or, in some ciphersuites, a single authenticated encryption key is derived, although the AE algorithm then derives two keys internally.)


Is a plain password in the URL a potential security threat? I'm in no way a security expert, in fact I'm just your average Joe with a question.

I was on my car insurance website, I registered and as I logged in I saw my password, not encrypted, in plain sight in the address bar.

Now this (to me) is already a threat (someone could see it over my shoulder if I was in a public space) but I wanted to know if it's a tell-tale sign of a more deep flaw in the security of this website.

If it is (let's say it can be a sign they store, or at least communicate my password, without encryption) how can I defend myself? should I ask them for more information (but I doubt they'll ever answer me).

My passwords are all different but they follow a common pattern, should I be concerned and thus change all of my passwords and the pattern?

This is NOT a duplicate of: Should sensitive data ever be passed in the query string?

In that question it's asked wether it's a good thing to pass informations in the URL WHILE DEVELOPING A WEBSITE or not. Mine asks what to do IF YOU STUMBLE UPON SUCH BEHAVIOUR

This question might be seen as a follow-up but it's not asking the same question

This is a serious security problem. URLs should never contain sensitive information.

URLs show up in your browsing history. So even after logging out it will be trivial to access your account for anyone using the same computer.
Commonly, web servers are logging incoming requests. Also, firewalls or proxies involved in processing your requests might maintain their own log files. In that case your credentials will show up all over these logs, increasing the risk of a leak.
If they show you your password in plain text that probably means they are also storing it unhashed. That means, if there ever happens to be a breach of their database, your password will be disclosed.
Many browser plugins send visited URLs to their servers, e.g. to check them against a list malware sites or just to spy on you. It's bad enough that they are able to track people's browsing behavior. With credentials in the URL it's even worse.
Referer leaks. If they include analytics (I'm sure they do) or embed advertisement, or whenever you click on an external link, your browser typically sends a Referer header which contains the previous URL, thus disclosing your credentials to all these parties.

  should I be concerned and thus change all of my passwords and pattern?

Yes, it's such a blatant flaw that you shouldn't put any trust in their systems. Sticking to your password is not worth taking the risk.
It's their own responsibility to fix the application and as a user there is not much you can do about it. Kindly inform them about the problem and refrain from using their services.


How to store data that the computer can read but not the user? In the TV series The Office, Dwight says he uses a diary to keep secrets from his computer. I'm wondering if the opposite is possible: can my computer create a file that it can read but I can't?

I would guess the starting point would be encryption, rather than permission. But if a file is encrypted, in order to decrypt it again, you need the key stored somewhere, right? If it's stored in plaintext, obviously the user can access it.

So my question (a weird one, I know) is: how might you do this if you wanted to write software that can access data and prevent the user from doing so?

There is two ways this can be "more-or-less" achieved (as the other answers pointed out, there is no 100% safe way, as there is no 100% security in general):

Software obfuscation: it relies on the fact that the execution flow of a program is voluntary and artificially made so cumbersome that it becomes very complex to grasp its logic and understand what is concretely done among (hundreds of) thousands of no-op and misleading operations.

You can find such systems used by DRM enforcement software: the program itself will be able to read the DRM-protected files, but you will not, neither will do any non-DRM compliant software. This is done with the intent to allow you to open a file in a restricted manner (for instance only during a limited period) with no ability to copy it or do any unauthorized actions (printing it for instance).
Specialized hardware storage: some chips allow to store some information with no possibility to read it back, the chip itself will have internally a full access to this information and will therefore be able to provide some services around this information.

This is typically used to store private keys in HSM-like devices: a cryptographic key is stored in a chip, and programs running on the computer can ask the chip for instance to use the key to encrypt some data, but there is no way to read the key itself from the chip. This is used to ensure that even if some malicious person would be able to access the whole computer's content, he will not have access to the protected keys.


Modifying SSL Certificate once created, Multi domain We're developing an application that has the ability to run across multiple top level domains, each with its own sub domain. (www.foo.com, www.bar.com, would each point to the same application on the same server, mobile sub domains pointing to a different application on the same server.)

Reading up on certificate creation for multiple domains leads me to believe that it is possible to do so, having one certificate that would govern each of the domains that are listed during setup.

However, if we were required to add extra domains to that certificate after its creation, would this be possible? Either through some kind of renewal type process? Or editing and reapplying the certificate?

Certificates cannot be edited; they are signed and the signature becomes invalid if you changes the slightest bit in them (literally: there is not a single bit that you can flip without breaking the signature). If you want to "modify" a certificate, then you actually want to obtain a new certificate, with contents that please you more.

Certificates are obtained from a Certification Authority. Since commercial CA make money by selling certificates, I am quite sure that your CA will be thrilled to sell you another one.


Prevent users from easily changing the backend API URL of a desktop application Is it considered a good security practice to prevent users from easily changing the backend URL of a desktop application that connects to a backend server with an SSL protected HTTP API?
One concern is that malicious users could just point the URL to a test server and reverse engineer the protocol.
On the other hand, it should be relatively easy to decrypt the communication with the original SSL protected API backend using wireshark or fiddler.
In summary, is it worthwhile, or best practice, to try to prevent users from easily changing the backend URL?

I do not think it would be a worthwhile time investment from a security standpoint, as it provides no security. As you said, users can just sniff the underlying protocol, hook or disassemble the application.
However, it may be worthwhile be from a QA standpoint. You don't want your users misusing the application, you want them to stay as close to the happy flow path as possible.


How can CVE-2016-2324 and -2315 be mitigated on Mac OS X? The recent git remote execution vulnerability states all git clients with version <2.7.1 are vulnerable and that most linux distributions have included the fixes already.

However, as of today,

$ git --version
git version 2.6.4 (Apple Git-63)
$

on an up-to-date, out of the box Mac OS X dev machine.

Does this then leave most of the developers on Mac OS X that are using the apple developer tools out of the box vulnerable to this attack?

What can be done, other than

manually installing an newer git client or
not using git for foreign repositories at the moment?

Most developers I know who are using OS X are using Homebrew for a variety of reasons; in addition to providing easy installation of tools not available from Apple, the updated versions of Apple-provided tools provide bugfixes and security fixes.  And yes, Homebrew is currently distributing git 2.7.4.


Does microwaving a hard drive erase it? Kind of a silly question, but I'm genuinely curious: (in part because I recently saw several questions that refer to "nuking" a hard drive...) what would a microwave DO to an HDD? Would it erase data on there, or at least corrupt it enough that it's difficult to recover?

In theory, no.

The outer shell is a Faraday Cage, so the radiation from the microwave will not penetrate the shell to do anything to the plates.

But it will render most of the control board unusable. The radiation can damage the controller chips, and arcing can damage the board tracks and passive components. But swapping the control board could make the data accessible again.


Are there any good tools to test the encryption quality of data? I am trying to increase my understanding of data encryption, and I was wondering this. It would be really nice if there were any good tools to test how secure my encrypted data is, for example how long it would take for an average rotten apple spoiling the barrel to decrypt it.

Existence of a tool that can guarantee security of some encryption system would entail proving a number of hard scientific problems, up to and including the famous P vs NP. Right now, no cryptographer has succeeded in proving that secure encryption or hashing can actually exist, let alone designed a tool that could test a given system. All we have are candidates: not functions that cannot be broken, just functions that we don't know how to break, though we have tried hard.

What can exist is a tool that runs some statistical analyses on, say, the output of a purportedly secure PRNG, and declare whether some bias appears. If a statistical analysis tool finds a bias, then it is obvious that the cryptographic algorithm is pure junk. However, if it does not, then it does not prove anything one way or another. Almost any algorithm, weak or not, produces outputs in which  statistical analyses systems won't see anything obviously fishy.

The practical way to assess the security of an encryption system is:

Is the method documented (precisely, down to the bit level, enough to potentially write an interoperable new implementation) ? If not, then it is probably not secure.
Has that documentation been published as a protocol for inspection by cryptographers for at least two years ? If not, then you cannot know if it is secure.
Has the implementation good repute, do developers publish known security issues and produce fixes promptly ? If not, then don't use that tool.


Instant access to application using token in url Is it good idea to give access to the site using token in url, this token can be send via email, some sites have reset password done in this way, but I want give access to the whole site (I think I have seen this kind of sites too).

This question is similar to this Security drawbacks for using short-lived access token in javascript client side . But the token can be outside of the browser.

So my questions is: is it dangers to have short live tokens (like sent in email to reset password) and is it for long live tokens without expiration date (user will be able to find old email and use link in this email - with message that he will be able to use this url anytime - and use the site without login).

This could be done (relatively) safely, but you have to watch out for a few things.

First, you should make sure nobody can access the token from another person easily (doh!). This is harder to do in practice than it seems. For instance, if you are emailing the token in plain text (which you will), you are basically passing the token from smtp server to smtp server you have no control over. EDIT: but the same would also hold for one-time tokens. Using SSL on your server is also a good idea, as that will encrypt the request headers that include the secret string.

Secondly, you should make sure the key is long enough for brute force attacks to take too long. If you combine this with brute-force-detection on your server (the hiawatha webserver can do this out of the box) you should be pretty safe against these.

Third, make sure the key is random! If you are using microtime, this means that an attacker can make an educated guess on the registration time of the victim (most websites have some sort of "registered at" feature), and just test all hashes from timestamps around that time. This reduces the number of hashes to test (for a single, targeted user!) from impractically large to just one million. That might seem a lot, but with one PC, and a 100ms response time this only takes a day. Remember, this is a targeted attack, which makes this very dangerous.

Another option you might implement is to use both the hash of the username, and the access hash in the URL. This way targeting every user at once is not possible.

IMO, when these things are taken into account, getting a token based login can be safer than a "regular" login, where people choose bad passwords and write them down on pieces of paper on their desk.


Automated tools for applying formal methods to verify security policy in existing software I am new to the Formal Methods arena, but I feel I have an educated grasp on its applications. However, I only seem to encounter formal methods as applied to the development process, as the software is created.

I'd like to be able to apply formal methods on existing software to test whether it adheres to role based access controls (RBAC) and separation of sensitive information following the Bell-LaPadula (BLP) method.

What methods and tools do you know of that offer an automated solution for RBAC and BLP-like verification of existing software/source code?

Wrote about formal methods and security many years ago here -- http://www.tssci-security.com/archives/2007/11/23/formal-methods-and-security/ -- the basics of which is how to apply old-school Orange Book standards to modern software.

If I had to rewrite that blog post in 2015, some of the updates I'd add are that SMT-based model checkers have become a lot more diverse, integrated, and advanced than the simple ones I outlined (SPIN and JPF). These pages should lead you towards some of these advancements -- http://kind2-mc.github.io/kind2/ -- http://smtlib.cs.uiowa.edu -- http://www.persistencelabs.com/research/

DARPA is working on a Crowd-Sourced Formal Verification (CSFV) project here -- http://www.darpa.mil/program/crowd-sourced-formal-verification

While I'm all for automation, it would be interesting to hear more about the problem domain to make secondary recommendations around manual testing. Is this for e-commerce web and mobile based authorization problems? Which domain(s) are involved?


How to preform black-box (no source) vulnerability testing/fuzzing? How would I (or) what software would I use to conduct local application (stored on the PC) black-box (no source/closed source) fuzzing or vulnerability testing for Windows? I've just been using common sense, like using negative numbers and such, directory traversal strings, all that. I'm comfortable with using Linux if necessary.

Also, what exactly is fuzzing? From my understanding, its inputting massive amounts of random data to a program, but I cannot find any usable "fuzzers" for local applications.

Fuzzing refers to random input testing. Contrast this to a scenario where you subject a program to a set of known inputs, which you might otherwise call unit testing. The basic idea is that you programmatically generate a large number of inputs to a program in hopes of finding some combination of inputs that causes incorrect behavior- either to detect bugs or to look for the basis of constructing an attack. There aren't really any general purpose fuzzing tools because fuzzing tends to be application specific and the inputs can't be completely random.

For example, suppose you've got a program that reads an XML file, performs some computation on that file, and then produces another file as output. To fuzz that program you could randomly generate XML files and submit it to the program. You can't necessarily know what output your program should produce (or else you wouldn't have needed the program), but you might say:

The program should always terminate within 10 seconds
The program should not crash
The program should always produce an output file, even if we can't verify the output file is correct
You might be able to verify some attributes of the output- for example if the XML input file has 27 top level tags then your output file should have 27 lines.

So you randomly generate a million XML files run your program a million times, and every time one of those conditions is not met you record what inputs caused the apparent problem. Then a developer can use those inputs to hopefully find whatever condition caused them.

Note that we're using random XML files, not totally random files. A totally random input file would be a random sequence of characters. There are a huge number of totally random files that do not constitute valid XML and won't test your program in any productive way. A totally random fuzzer would likely never generate a valid XML file to actually test the program logic. This is the basic reason why there is no general fuzzing program- random inputs need to be meaningful rather than totally and truly random in most cases.

Generating totally random invalid inputs can be meaningful, especially if you want to ensure that your program doesn't crash on mal-formed inputs. But this is essentially testing input validation and not program logic. You can use fuzzing to test both things.


Should an admin user be able to edit passwords? For your typical web app, should an admin superuser have the right to edit a user's password, or should only that user have the right? (Even with edit ability, the admin would never see the current password).

I see three related questions:

Should an admin user be able to view a user's password? No.  This is a bad idea.  You should not expose (through the admin interface) a way for admin users to view other users' passwords.  Some users may re-use passwords on multiple sites.  Therefore, users should never be allowed to see the user's password.

Also, the only way to allow an admin user to view other users' passwords is to store those passwords in the clear (or, if any transformation is applied, it has to be reversible, in which case the passwords might as well be stored in the clear).  This is bad security practice.  Stored passwords should always be hashed, so that a breach of your database does not trivially reveal everyone's passwords -- and that means admin users won't be able to view other users' passwords.

Should an admin user be able to reset a user's password? Sure.  That's useful.  For instance, it is reasonable to give the admin user a way to reset the user's password, e.g., triggering an email to the user to allow them to log on and enter a new password, or generating a new password for the user and emailing it to the user.  However, the system should not display the new password to the admin user.  Also, in this case the user should get some notification that the admin reset their password (e.g., as part of the email that is sent to them), and preferably the action should be logged along with the identity of the admin user.

Should an admin user be able to set a user's password? This is useful and reasonable functionality to provide to an admin user.  For instance, when creating new users, it is sometimes useful for an admin user to be able to generate a password for the user, enter it into the system, and communicate the password to the user over an out-of-band channel (e.g., over the phone).  Similarly, it can also sometimes be useful if there's a way for the admin user to go to the screen to set a new password for the user, give the user the keyboard long enough to type in their preferred new password, and then click "ok" and set the user's password.  These are reasonable use cases which you could reasonably support, without incurring significant security risks.  In this case, the user should receive some notification that the admin reset their password (e.g., an email that is sent to them), and preferably the action should be logged along with the identity of the admin user.


Is it safe to open virus infected EXE with Telerik JustDecompile? My antivirus software has detected an EXE downloaded from Internet as infected with virus Malwr.Heur.MSILPerseus. It has quarantined it. However, I wanted to decompile & study it's code. Will it be safe to decompile the EXE using Telerik JustDecompile to view it's source code?

That depends on how advanced the malware is. Most likely it will be safe, although it may be highly obfuscated and difficult to understand in a decompiler. There is a small chance that it is intentionally designed to execute correctly on real hardware, but exploit a bug to escape sandboxes or gain extra privileges on a decompiler. If you are simply asking if a decompiler needs to execute a program in order to decompile it, no it does not. It is, in theory, completely safe.


Prevent local web application from copy Is there any way to prevent a local web application from being copied to another computer? I searched all over the web and whereas desktop applications have been replaced at a big extend by web application, i haven't find a way to prevent my application from being copied at least without a special effort. Is there any way to achieve this? Something like combine it with a specific mac or something else?

Once the HTML, css, and JavaScript have been downloaded to a browser, it's out there.

If your code is so amazing that you don't want anyone else even looking at it, you could send the entire page as an image, then every user interaction could send a separate http request and have your server render a new image back after each interaction. This would be a massive headache. It would probably have horrible performance.


Unsecure FTP with Encrypted file and Wireshark leakage Hi i was wandering if it is possible to have a password leaked to an encrypted file on an anon ftp server with r-x-w permissions.

So for example i have a file encrypted using gpg and when opened on the server i input my password would wireshark leak to password used? i know the data coming back would require a key to view, but would the password be leaked as its an unsercure FTP server?

You cannot open a remote file with GPG through FTP. Instead you would need to download the file to the local system and open it there. Because of this the decryption will be done only locally (and will be independent from that way the file arrived on the local system) and thus password for the file will thus stay local too.


Pentesting a Data Warehouse? One client has recently implemented AWS and has a EC2 instance running.

We have made one scoping call and further to that they provided me with a diagram that I have modified to avoid any issue:

The objective is to make sure there is not data leakage.

The instance will only be used by the company employees and to store orders or products specifications but doesn't fall under PCI DSS compliance requirements, it is a testing environment that they have.

The information I could find is that there are three areas when it comes to DWH testing: Unit, Integration and System Testing.

I also found here that there is a section that mentions testing under Testing Operational Environment, but it seems to be talking about a specific document that outlines the disallowed operations and devising tests for each, is that what I should test against?

Or should I check that the item protects data and maintains functionality as intended? In this case, I would test the ETL procedures, Database and Front-end?

Last but not least, is it the same to test a DWH in an AWS environment as opposed to another environment?

The methodology you are looking at is not designed for penetration testing.

From the same url at that website:

The aim of system test is to test all of the following areas.

Scheduling software
Day-to-day operational procedures
Backup recovery strategy
Management and scheduling tools
Overnight processing
Query performance

...and..

There are a number of aspects that need to be tested. These aspects are listed below.

Security - A separate security document is required for security testing. This document contains a list of disallowed operations and devising tests for each.

That said when performing penetration testing against a Data Warehouse the areas that are usually unique fall into the use of non-standard databases and nonstandard protocols. These are frequently, but not always, NoSQL databases like Hadoop, Apache Spark, Cassandra, MongoDB, Green Plum many of these have their own unique vulnerabilities or use very unique protocols or messaging systems which have to be tested separately. Likewise some of these like Hadoop tend to extend database administration rights to the attached systems due to the way some of the protocols work (deployments may vary). Testing and securing these systems is a huge issue beyond the scope this type of answer but hopefully this helps you with your testing process.

As a side note: Penetration testing AWS services, especially the server-less components like Lambda can be very unique so you'll have to do all that work as well. Again this is beyond the scope of your question but I thought I'd mention it as it's directly relevant to the details in the question you asked.


Is there any decompiled source code for the "Flame"/"Skywiper" malware? When searching for the source for Stuxnet, its relatively easy to come by in one form or another. Although I'm actually curious if anyone has done any work to comment the source and perhaps clean up variable naming and so on.

My real question is if anyone is aware of a source for the "Flame" virus source code. Its often mentioned as being the most advanced virus observed, so it would be interesting to see the source.

Thanks!

I can't find any (decompiled) source code of it, but I did find a rather thorough CrySys (Laboratory of Cryptography and System Security, Budapest) technical report (pdf). It covers pretty much all aspects of it, from how Skywiper works to how it propagates and infects. A short digest of it can be found in this blog (among many) and a few more links to other anti-virus labs' blogs here. I realize I didn't answer your question, though. I guess it's still too early for any of these labs to share their newly found lab pet and its thoroughly dissected innards with the rest of us. Their eyes probably roll not unlike the fruit slots machines do on a jackpot roll, and I wouldn't keep my hopes up that they'll release more on it until their eyes finally settle on banana. ;)

UPDATE: Found some downloadable samples but you'll have to ask for password, and another repository that requires registration. No reverse-engineered code yet...


How do I report new malware? I have a new piece of malware that isn't detected by current anti-virus vendors.  How do I report it to them?

I want to do a good turn and help protect as many people as possible.   What is the best and easiest way to get it to as many anti-virus vendors as possible, to help them detect it?  Is there a list of sites where I should upload the sample, or email addresses where I should send it to?

I know about Virustotal.  I could submit the sample to Virustotal.  Will that be sufficient?   Currently few or no antivirus engines detect this malware.  Will submitting the sample be enough for antivirus engines to know that it is malicious and should have been detected, and trigger them to analyze it and develop a signature/detector for it?

(It's not obvious to me how anti-virus vendors would know that my sample is malicious, just because it was uploaded to Virustotal.  I didn't see any user interface in Virustotal where I indicate "yes, this really is malicious, even though no one detected it", so I wonder if it will get lost in amongst all the other benign samples.   I've heard of plenty cases of malware that had been uploaded to Virustotal for months or years before any antivirus engine started detecting it.  So it makes me wonder whether uploading it to Virustotal is enough.)

I've looked, but I haven't found an answer on this site.  Here's what I found:

Where to report malicious URLs, phishing, and malicious web sites? provides a list of where to report phishing web sites and other malicious web sites, but it doesn't say where to submit malware samples.
Unknown malware, how to report it and whom to report it to? asks a related question in a more specific situation.  One answer mentions Virustotal, but it doesn't answer my question of whether submitting to Virustotal actually works, in terms of notifying A/V vendors to trigger analysis.  Another answer gives links to forms where you can upload malware samples to two anti-virus vendors, but that's just two of the dozens of vendors out there -- if I need to submit directly to A/V vendors, I am hoping for a more comprehensive list that is easy to refer to.

Note: All the information on this post has been copied from the TechSupport article here.

Every major antimalware vendor has a dedicated E-mail address through which new samples can be submitted. The procedure is as follows:

Configure your Email client
Make a password protected archive and add the sample to it. The
password should be "infected".
Send the sample to the following email addresses, with the subject "The password is infected":

Ahnlab Antivirus - v3sos@ahnlab.com
AVAST Antivirus - virus@avast.com
Avira Antivirus - virus@avira.com
Bit Defender - virus_submission@bitdefender.com
Bluepoint Security - samples@bluepointsecurity.com
Comodo Antivirus - malwaresubmit@avlab.comodo.com
Dr Web - vms@drweb.com
EMCO Antivirus - malware@emcosoftware.com
Emsisoft Antivirus - submit@emsisoft.com
eSafe Security - virus@esafe.com
eScan Antivirus - samples@escanav.com
Fortinet Antivirus - submitvirus@fortinet.com
Spy Emergency - research@spy-emergency.com
F-PROT Antivirus - viruslab@f-prot.com
FSB Antivirus - labs@fsb-antivirus.com
F-Secure - vsamples@f-secure.com
Orbitech Hazard Shield - virus@orbitech.org
IKARUS Security Software - samples@ikarus.at
Immunet Antivirus - submit@samples.immunet.com
K7 Antivirus - k7viruslab@labs.k7computing.com
Kaspersky - newvirus@kaspersky.com
Jiangmin Antivirus - support@jiangmin.com
Lavasoft Antivirus and Antimalware - research@lavasoft.com
McAfee Avert Stinger - virus_research@avertlabs.com
Micropoint Anrivirus - virus@micropoint.com.cn
Microsoft Security Essentials - avsubmit@submit.microsoft.com
Nano Antivirus - virus@nanoav.ru
ESET Antivirus - samples@eset.com
Noralabs Norascan Antivirus - support@noralabs.com
Norman Security Suite - analysis@norman.no
enter link description herenProtect - virus_info@inca.co.kr
Panda Security - virus@pandasecurity.com
Psafe Total - psafe@psafe.com
360Safe - kefu@360.cn
Rubus Ozone Antivirus - support@rubus.co.in
Smartcop Antivirus - virus@s-cop.com
Sophos - samples@sophos.com
Spybot Search and Destroy - detections@spybot.info
SRN Micro Antivirus - vlab@srnmicro.com
Symantec Antivirus - avsubmit@symantec.com
Moosoft Antivirus - trojans@moosoft.com
Hacksoft Antivirus - virus@hacksoft.com.pe
Thirtyseven4 Antivirus - virus@thirtyseven4.com
CA Technologies - virus@ca.com
Trojan Hunter - submit@trojanhunter.com
Simply Super Trojan Remover - support@simplysup.com
Filseclab Antivirus - virus@filseclab.com
ThreatTrack Security - malware-cruncher@sunbelt-software.com
ViRobot Antivirus - viruslab@hauri.co.kr
Virus Block Ada - newvirus@anti-virus.by
Webroot Antivirus - esupport@webroot.com
Zillya! Antivirus - virus@zillya.com
Kingsoft Antivirus - huangruimin@kingsoft.com
MKS - pomoc@mks.com.pl
Aegislab Antivirus - support@aegislab.com
Quick Heal Antivirus - viruslab@quickheal.com
Outpost Antivirus - trojans@agnitum.com
Baidu Antivirus - bav@baidu.com


What does a hash output (a fingerprint) can be truncated mean? From Public key fingerprint (Wikipedia) :

Creating public key fingerprints
...
3. If desired, the hash function output can be truncated to provide a
shorter, more convenient fingerprint.

and

Security of public key fingerprints
...
While it is acceptable to truncate hash function output for the sake of shorter, more usable fingerprints, the truncated fingerprints must be long enough to preserve the relevant properties of the hash function against brute-force search attacks.
...
In practice, most fingerprints commonly used today are based on non-truncated MD5 or SHA-1 hashes.
...
However, fingerprints based on SHA-256 and other hash functions with long output lengths are more likely to be truncated than (relatively short) MD5 or SHA-1 fingerprints

Why would I truncate the hash output? Where do you see truncated hash output? Won't it possibly result in some duplicated value if I truncated it unproperly?

Both your questions from the body are already answered in your question. You ask

  Why would I truncate the hash output? Where do you see truncated hash output?

and also cite:

    While it is acceptable to truncate hash function output for the sake of shorter, more usable fingerprints

This is exactly the answer as to why you would truncate hash outputs - modern hash functions do have extremely long outputs that are hard to compare, especially manually (because humans are not good at comparing 32 hexadecimal figures)

You then ask

  Won't it possibly result in some duplicated value if I truncated it unproperly?

and cite:

    the truncated fingerprints must be long enough to preserve the relevant properties of the hash function against brute-force search attacks.

Which can be a security concern if not honored. Hash Collisions (i.e. same hashes for different inputs) are hard to find for modern hash functions. Truncating hashes makes this easier; the bitcoin network for example shows that a certain prefix can be brute forced.

However, the use cases for truncating hashes are usually manual comparison in conjunction with structured data (for example, this might be thinkable for Public Key verification (hence why you found those remarks on that specific wikipedia page), although, gnupg doesn't do that and goes for the full hash, afaik). Finding collisions in structured data is harder than finding them in arbitrary data, choosing a sensible truncation length might preserve a comparable level of security in regards to the untruncated hash function and arbitrary data.

Your title asks

  What does a hash output (a fingerprint) can be truncated mean?

Whereas I'd like to cite wikionary:

  (transitive) To shorten (something) by, or as if by, cutting part of it off.

"Hash output (a fingerprint)" has two parts. The parenthesis seem to suggest that fingerprints are hash outputs, which is (afaik) always true, but could be conceived otherwise (for example by defining a truncated hash output to be the fingerprint, just to make confusion perfect). Nonetheless, usually fingerprints are hash outputs over the to-be-fingerprinted-data.

Truncating a fingerprint means truncating the hash output of the to-be-fingerprinted-data.


Why should the dh keylength match rsa length in tls? A few sources state that the DH keylength (bits of the prime) should match the keylength of rsa for TLS. For example SSL_set_tmp_dh(3) from openssl has example code on how to match the dh parameters to the key being used.

Obviously, one doesn't want DH to be the weakest link in the chain. Using AES-256 and only securing the key-exchange with DH-512 is stupid, of course.

Is there any other reason for matching keylengths? Especially, is there anything to the protocols, that requires this?

The corollary question would be: If I always use DH-2048 (and everything else is either comparably secure or weaker), would this hurt anything (except maybe performance)?

In the "DHE_RSA" cipher suite, security is relative to both that offered by Diffie-Hellman, and that offered by RSA. "In general", the overall security will be that of the weakest of the two; so:

it is harmful if the DH key is weaker than the RSA key, because then overall security is lowered (compared to what the RSA key alone offers);
it is harmful if the DH key is stronger than the RSA key, because you do not get actual extra security (it is limited by that of the RSA key), but you still have to pay for the extra large key (larger messages, higher computational cost, and loss of interoperability with limited clients).

It so happens that DH and RSA seem to offer similar strength when used with keys of similar sizes, i.e. DH modulo a 1024-bit prime can be said to be somewhat as strong as RSA with a 1024-bit modulus (but a non-prime modulus, of course). So this gives the rule that the DH key and the RSA key should have the same length.

When you look at the details, things are less clear-cut:

In a DHE_RSA cipher suite, DH and RSA are used for different purposes. RSA is for a signature and its security target is limited to the present. Suppose that you do a SSL connection today. The attacker records it. Then he sets out to break the connection. Five years from now, after extensive computations and thanks to technology improvements, the attacker succeeds to break the DH key: the attacker can then decrypt the recorded connection and learn your secrets. However, suppose that instead of concentrating on DH, the attacker broke the server's RSA key. The attacker then... has nothing ! Breaking the RSA key gives him power to impersonate the server for future connection, but it won't help him a bit with the decryption of past connections. Meanwhile, you renewed your server's certificate at least once or twice, with a new key each time, so all the attacker's efforts went to naught.

For this reason, the security of RSA and the security of DH in a "DHE_RSA" cipher suite cannot be readily compared; they don't have the same scope or target level, and, overall, the security of RSA is less important than that of the DH.
DH and RSA have comparable security for the same modulus length only in a rough sense. The known best algorithm for breaking RSA is the General Number Field Sieve, and the known best algorithm for breaking DH is also GNFS. However, for big modulus (say, 1024 bits or more), the bottleneck of GNFS is the "linear algebra" phase, which is last in the algorithm: it is a mathematically trivial computation on a matrix of extremely non-trivial size. This is very hard to compute in parallel, and requires a machine with a tremendously huge amount of very fast RAM. In fact there is no existing computer which would be up to the task for 1024-bit RSA or DH (a dedicated machine can be envisioned without breaking laws of physics, but it would cost a pretty penny).

It turns out that the GNFS variant which breaks DH has the same linear algebra step, but with a "bigger" matrix; not with more elements, but the elements are now integers modulo p (the prime modulus) instead of mere bits. This means that the matrix for breaking DH is a thousand times bigger (conceptually) than the matrix for breaking RSA with a similar key size. This implies that, in practice, 1024-bit DH is harder to break than 1024-bit RSA.

(Also in practice, 1024-bit DH and 1024-bit RSA are unbroken within the current economico-technological context, so any robustness comparison must be considered with a grain of salt; an algorithm cannot be less broken than not broken.)
You cannot necessarily choose the DH modulus as you would like. Existing implementations can be limited, for a variety of historical reasons. Some clients may have trouble using a DH modulus longer than 1024 bits, even if they have no problem with a 2048-bit RSA key. Equality of robustness and security balance are fine things, but data must flow nonetheless. A failure to establish a connection is very secure but not very useful.

So while a systematic 2048-bit DH modulus will not hurt anything security wise, and will incur only moderate overhead (over a 1024-bit DH, this means 250 to 500 extra bytes per full handshake, and some extra CPU, but nothing critical), it may break compatibility with existing, old clients, so this calls for tests. At least, from the point of view of the standard, 2048-bit DH is fine, regardless of the size of any RSA key involved in the mix.


Weird URLs in Fiddler I was browsing the web and suddenly I started seeing "Waiting for available sockets" error in Chrome with the page showing "Network Unavailable".

I thought that was weird so I opened up Fiddler and saw these strange URLs. Is this something someone has already seen?

Thanks.

Chrome sends requests to a handful of randomly-generated domain names to detect things like ISPs that return search pages rather than NXDOMAIN, hotspot paywalls (that do much the same) and similar behavior.  The theory is that the 3 random hostnames are unlikely to actually be valid hostnames, and if you get responses to them, something in the middle of your connection is behaving differently than expected.  There's a bug related to this behavior here: https://code.google.com/p/chromium/issues/detail?id=47262


Is it secure to wipe a file in a Virtualbox disk if the vbox disk file is on an ssd? Preface

I searched for an answer to my question and found related questions which do not cover my question completely. Like:
On SSD deleting:
Can Widped SSD Data be recovered
How to securely delete inside Virtual Machine

The second question gets close to what I want to know. And I already know that due to features of an ssd it is not easy secure erasing single files on SSD. But I wonder if there is a missing link between vbox disk and ssd to prevent recovering files deleted inside a virtualbox OS.

my scenario: Windows host running VirtualBox on an SSD. VirtualBox client is linux/ubuntu

tl;dr my question:
If I securely wipe a file in my virtual machine with an appropriate tool (wipe or the like) is it reasonably well deleted?

Some more thoughts

My thinking is: Possibly: The VBox hard disk emulation might overwrite the correct "logical" bytes on the vbox disk. Even though that the real bytes on the SSD are not overwritten they do not have any information on where the bits belong to because only the VBox hard disk driver could make links from its file system. And this information might be destroyed.

Anyone know if this would work?

Another option would be:
What if I overwrite free space inside virtualbox with zeros and then shrink the virtualbox Disk?

No, it's not secure.

Wiping a file in a virtual machine will wipe out the corresponding bytes in the virtual disk file: every VM I'm aware of does a 1-to-1 mapping* between virtual disk sectors and parts of the disk file.  However, that doesn't mean the data will be wiped out on the underlying disk: solid-state drives perform wear leveling, so successive writes to the same logical sector will almost never result in writes to the same physical sector.

* Actually, most use sparse files, where never-used parts of the disk simply aren't present in the file, but this doesn't change the situation.


Smart-Screen filter still complains, despite I signed the executable, why? First and foremost, this is my very first experience with Code Signing.

I bought Standard Code Signing from Certum for 3 years.

I intend to publish applications in Czech republic mostly.

But to the point, on Windows 10, when I download the signed executable, I get bumped by Smart-Screen filter which blocks the application.

I don't know what to think. I used SHA256 and a time stamp. I signed it on Windows 8.1 fully updated.

Here is a code snippet I used to sign the EXE file:

SignTool sign /fd SHA256 /a /tr http://time.certum.pl "Barvy.exe"

Did I do something wrong?

Here is a picture detail of the signature of the EXE file:

Applications that are signed with a standard code signing certificates need to have a positive reputation in order to pass the Smart Screen filter. Microsoft establishes the reputation of an executable based upon the number of installations world wide of the same application. Since you haven't published your application as yet (and therefore the reputation hasn't been established as yet), the Smart Screen will continue to flag the application.

There are two solutions: either wait till the application has a large user base and its reputation will be adjusted by the Smart Screen. However, the current working status might prevent users from installing and trusting the application. The second option is to sign it with an EV (Extended Validation) code signing certificate. Applications signed with an EV certificate establishes its reputation right away. To quote Microsoft:

  Programs signed by an EV code signing certificate can immediately
  establish reputation with SmartScreen reputation services even if no
  prior reputation exists for that file or publisher.

You can find further details at Microsoft SmartScreen & Extended Validation (EV) Code Signing Certificates blogpost.


What are the repercussions of a DDoS attack on a website? First of all, I'd like to know what exactly a DDoS attack is- my understanding is that it's a collection of infected or "zombie" computers, all controlled by a central computer, with the intent of overloading the website, and making it inaccessible and / or slowing the service down to 90's dial up levels (a.k.a. unusable).

How can one prevent it? I understand that those annoying CAPTCHAs are used, but is there actually a way to prevent one manually?

How well do third-party security services, such as cloudflare or fire eye, work? Are there ways to beat them?

What are the repercussions of a DDoS attack? If a website is DDoS'd, are passwords / credit card / bank data stored in the database compromised? Are certain pieces of encrypted data now at risk of exposure?

Thanks, everyone!

All a denial of service attack (of which a DDoS is a specific type) does is deny legitimate users access to the site. Anything further is a separate attack. Any repercussions are just those arising from the site no longer being accessible to legitimate users for a time (availability being one of the three pillars of security, which is why this is a security issue even though there is no data breach and no malicious users get control of the site).


Triangulate a MAC address Last Sunday my iMac was stolen by a burglar. On Monday it showed up on 'find my mac'. Good police work and a lot of luck ended up in me retrieving my device that was on a location more than 50 meter from the 'find my mac' location.
I think it would be possible to make an app that after 'find my mac' sends you to the right neighborhood, sniffs for the Wi-Fi MAC address on three devices, share the these measurements and triangulate for the exact position. This would make an outstanding tool for police and security services and every Smartphone has the hardware to do it.

Is there already an app to do this? (won't spent months of programming to make something that already exists).
Is there a sniffing app for iPhone or Android that also sniffs packages without connecting to the network (only the MAC address, not what is in the package) and detects the signal strength?
Does someone know a simple triangulation algorithm?
How about bluetooth to do the same?

Rather than use triangulation, which would work, it's probably much easier to use a directional antenna. This and a tool like Kismet which can show you signal strength is a far quicker way to locate these devices. For bluetooth you would use an ubertooth and a directional antenna for the appropriate frequency.

https://www.kismetwireless.net/

https://en.wikipedia.org/wiki/Directional_antenna

https://greatscottgadgets.com/ubertoothone/

What you mentioned would work but it requires more equipment and more setup to work well. Both are valid solutions but I think because directional antenna's are cheap and easy to use they tend to be the solution of choice.

Note: If you wanted continuous monitoring, without a human involved to move a directional antenna, then triangulation would be the way to go.

Per your question about the app. You don't need to sniff packets but you do need signal strength there are lots of app's that either show signal strength as a bar graph and there are some which measure it in decibels either could work but you'd have to move around a lot more because the built-in antenna isn't directional. It could still be done but probably not nearly as quickly.


How fast is it to bruteforce a 48-bit key with current technology? Say you have a truly random hexadecimal key formatted as 1234.5678.ABCD, with 48-bit entropy. Assuming the key is stored with no hashing/salting, how fast/easy would it be to brute force it with current hardware? I'm interested in 2 different scenarios:

Attacker with $1000 budget
Attacker with $1M budget

Bonus points if you can provide sources.

A day, instantly.

48 bits are not an awful lot, also merely generating (which per se does not make a lot of sense) that many keys is very fast.
Even a naive single-threaded CPU implementation on a cheapish (not even remotely close to $1000) desktop computer could do that in a day or two.

In order to be meaningful, you must do something with these keys to verify them. It is explicitly mentioned "no hashing/salting" in the question, so one can safely assume that no expensive key derivation (think beecrypt or such) which artificially slows us down needs to be done.
I will therefore assume that you need to decrypt a block of AES and compare the result to a known plaintext.

This article claimed 11Gbps on a CUDA implementation 6 years ago, which would boil down to about 4 days for brute-forcing your 48-bit key. Assume that a rig with a current upper middleclass or high-class GPU is 3-5 times as fast, and we are at approximately one day for your $1000 budget (give or take a few hours, it makes no difference).

A $1M budget attacker could naively just do that same attack with 1000 machines, which would require a minuscule amount of communication between nodes (add some milliseconds) and place him at around 1 1/2 minutes, give or take a few secs.

If you however assume that an attacker with such a budget is serious about the attack, you must assume that something better is used. A HPC cluster comes to mind as the next naive solution, but why not invest in FPGAs?
If you are serious, you can easily get 10 or 100 times as fast than the "simply use 1000 desktop computers" solution for the same money.
Let's just assume 100 times faster, and we're at 0.9 seconds. Why assume? Well, because it no longer makes a difference at this point.

Practically, it doesn't matter at all whether an attack takes 9 seconds, 0.9 seconds, or 0.00009 seconds. They all fall under instantly. Anything you can crack in 9 seconds is doomed.


Cryptography protocol suitable for two-way radio communications Specifically talking about walkie talkie radio networks. Suppose there is a group of up to 16 persons, each equipped with such a unit. Typically, one person will be talking with one another (one-to-one), or one person will be broadcasting to all the others members (one-to-all). The goal is to secure and authenticate all the communication between them.

I thought about the following:

1) Each user will have a predefined public/private key (e.g. RSA).
2) There will be a predefined symmetric key (e.g. AES-128 bit).

Voice streams will be divided into 128-bit segments. Each segment will first be encrypted using AES 128, then hashed using SHA-256, and the hash will be encrypted using user's private key, and this signature will be sent along with the encrypted message. The reciever will first hash the message, and then decrypt the signature using any of the 16-1 public keys he have. Ideally, one of them will 'work', authenticating the message. Then he proceed to decrypt the message.

Is there any "clear" vulnerability in this protocol?

P.S. I am aware of other used protocols, e.g. P25, but will prefer to implement my own.

First thing to do is define what you mean by "secure and authenticate". You need to put into words who the attackers are, what they can do, and what they should be prevented from doing.

On example of such an attack model is the following:

Attackers are outsiders. They eavesdrop on the common channel (the radio waves). They want to obtain the confidential data that the group members exchange with each other. The group members trust each other.

If that is the attack model, then it suffices to come up with a shared secret K, that all group members but no attacker knows, and then encrypt packets with some symmetric encryption algorithm (say, AES in a suitable mode) using K as key. Initial distribution of K can be done by having each group member own a RSA key pair; one group member generates K randomly, encrypts it with the public key of each group member, and broadcasts that.

Now let's extend that attack model into another one:

Attackers are outsiders. They eavesdrop on the common channel, but will also attempt to send fake messages, sometimes replaying previous messages, with or without alterations. Such fake/replayed message instances shall be reliably detected and dropped by group members.

Now you also need a MAC for each packet (so that the attackers can only replay previous packets, not create new ones or alter existing packets), and some sort of connection context so that replay attacks are detected. This can be done by embedding a sort of time stamp or counter in each packet: each participant remembers the counter values for the last packets received, rejecting packets which have already been seen or which have a "too old" counter value. Such mechanisms are often called window-based and there is some balance to strike between replay attack prevention, memory requirements (to remember past packets), and tolerance to packet loss due to the unreliable nature of the transport medium. Peruse DTLS as an illustration of how the SSL/TLS protocol can be adapted to packet-based unreliable mediums.

If the attacker is allowed to try to send fake messages, then he might also be able to advertise a fake RSA public key. Distribution of public keys is a matter of Public Key Infrastructure, with certificates being the usual solution.

Maybe we want more ? E.g., what about the following:

Group members are attackers too. Each group member will try to eavesdrop on and/or interfere with one-to-one communications between other group members.

In that case, you will need pairwise key exchanges. For any pair of group members A and B, there must be a shared secret KA,B that other group members and outsiders do not know. This can still be leveraged from pre-distributed RSA Key pairs: when A wants to talk to B and they don't already have a shared secret (or they forgot a previously shared secret, e.g. B rebooted his computer and that shared secret was in RAM only), then A generates a new random key KA,B and encrypts it with B's public key.

There again, read up the complete TLS and DTLS standards: they are quite readable, and that will show you what you have to think about.


Secure HttpOnly Cookie or Header field for auth token securing an API? I have an API to secure. There will potentially be two types of consumers of this API - our own Single Page Application, and third party services that will integrate with it.

I have read that in general cookies are not favoured for REST APIs, it is better to use header fields. Perhaps this is just convention.

Secure cookies are a better place to hold the auth token in an SPA. It prevents them from being obtained by a cross-site script attack. Also, if the SPA opens a new window/tab, the sessionStorage does not flow accross, causing the user to have to log in again. You can use localStorage, but not a good idea to keep auth tokens there, as it persists.

Should I make the authentication filter on the server side accept either a cookie or a header field? Try the cookie first, and if it is not there then try the header field? Cookies would be used by SPAs, and header fields by other API consumers. Or, would it be better to go with only one way of transmitting the auth token?

I don't think there is a big difference in security between cookies or headers, if properly used.

Cookies are meant to maintain server state. So if you have a login call which starts a session, cookies make sense. If you use an API token that is distributed outside of the API, cookies don't make sense.

In the end, cookies are also sent in headers, so there is little distinction between how they are transmitted. The difference is in how browsers handle cookies:

It is possible to set cookies as HttpOnly, making them inaccessible from JavaScript;
Cookies are included in every request by the browser.

HttpOnly provide some protection against XSS. However, an attacker can call your API any way he wants when he gets XSS, even if he doesn't obtain the cookie.

That cookies are included in every request makes it vulnerable to cross-site request forgery (CSRF): another webpage can trigger a request to your API, and the cookies are included by default.

In a SPA, an alternative to store the token is in a JavaScript variable. This is only kept while the tab is open, and may be secure against XSS if the variable is limited in scope.

Storing tokens in localStorage keeps them there forever, since localStorage is not cleared when the application is closed. However, this isn't so bad, since you can expire tokens on the server. Even if the token is exposed after a while because it was kept in localStorage, the token won't be valid anymore.

There is also the possibility to use two tokens, one in a cookie and one in a header. You would need both tokens to successfully use the API. Since the cookie is HttpOnly, you are protected against XSS. Since the header is not sent on every request, you are protected against CSRF.


Can I block viruses from a USB stick by scanning it before opening its folder? I inserted my USB stick into a friend's PC which was full of viruses, malwares and adwares. Therefore I suppose they attacked my USB device as well. Now I want to use my USB device on my PC without running the risk of being infected by the viruses on it.

Can I avoid such risk by previously scanning the device (with Bitdefender, Malwarebytes and Spybot S&D) without opening the folder? In other terms: given that my device (D:) contains some viruses, do they immediately attack a PC when the device is inserted into its USB port, even when I don't open the D: folder?

Referring to my answer to this question (before it was migrated):
No, scanning the drive without "opening the folder" isn't a secure way to protect against viruses on the drive. It's very risky to insert what you believe to be a compromised USB device into your PC, no matter what AV you have installed.
If you desperately need files from the drive (to quote myself):

you should attempt to only insert the drive into a secondary PC running some live version of a linux distro, preferably one you wouldn't mind completely wiping afterwards.
If not, just cut your losses and physically destroy the pendrive. USB viruses are extremely efficient these days, and are more frequently able to persist in hardware between wipes (either on small partitions on the pendrive, or by loading themselves into the firmware of the infected machines hardware).

The point is, there is no guaranteed way to insert that drive without risking further contamination.


Why CORS is still securing an open api where all requests have a wildcard (*)? In case of an open API, the only possible value for Access-Control-Allow-Origin is a wildcard (*), since you can't have a list of allowed domains.

Still, this seems not to bug developpers and appears to keep the system secure. How is that possible? Isn't allowing all domains to make every request the same as not having SOP or CORS Policy?

It might be that I don't really get the security provided by CORS, but as I understood it, it avoid an unwanted domain to use session cookies of a user without his consent. Still, I don't get why it protect the user to see his account used for unwanted purposes once a data modifying route is opened to this domain.

In case of an open API, the only possible value for Access-Control-Allow-Origin is a wildcard (*), since you can't have a list of allowed domains.

Having a static * is one way. Other ways are to dynamically return the currently requesting origin inside the Access-Control-Allow-Origin header. These options slightly differ in semantics, specifically regarding handling credentials like cookies.

  Still, this seems not to bug developpers and appears to keep the system secure.

Since there are no actual security requirements for the API (i.e. everybody should be able to use it, even cross-origin) CORS does not keep the system secure. What the wildcard Access-Control-Allow-Origin instead does is to make the system working cross-origin in the first place: without any CORS header in the HTTP response any XHR interaction (i.e. write request and read response) could only be done to the same origin because of the default SOP for XHR.

  ... but as I understood it, it avoid an unwanted domain to use session cookies of a user without his consent.

CORS does not forbid things that are possible without CORS. It is still possible to send simple requests cross-origin with credentials (cookies ...) included, both with XHR and by including images cross-origin, sending forms cross-origin etc.

But CORS makes it possible to not only send simple requests but also non-simple requests (with additional headers, different content-types etc) and to read the responses for simple and non-simple requests. And when credentials are used not only Access-Control-Allow-Origin is relevant but also Access-Control-Allow-Origin: if this is not explicitly set to true the response will not be available to the script in the browser, similar to how it was done without CORS.


Does WPA2 use TKIP or not? I am writing my master's thesis about WLANs, and there is something what I don't really understand. This may be a dumb question but I didn't find a clear explanation.
WPA uses encryption TKIP. WPA2 uses encryption AES. So far so good. What I don't understand is, that during my research I found a lot of articles describing a mode WPA2-AES/TKIP or sometimes called mixed mode.

Does this mean that WPA2 can also operate using TKIP as well, or does this mean that WPA2 is downgraded to WPA, and then WPA uses TKIP?

Thanks in advance!

There is indeed a lot of unclear information out there. Your first idea was correct, to the best of my knowledge. While I can't seem to find an authoritative source right now, this DD-WRT wiki page explains it the way I understand it:

  TKIP vs AES-based CCMP

  Defines the algorithm used for message integrity and confidentiality.

  WPA was designed to be used with TKIP (and WPA2 designed to use
  stronger AES-based).

  However, some devices allow WPA (not WPA2) with AES (and WPA2 with
  TKIP).

  AES is optional in WPA; in WPA2 both AES is mandatory, but TKIP is
  optional.

  Note that TKIP is not directly comparable to AES; TKIP is an integrity
  check, AES is an encryption algorithm. In the context of wireless
  security this actually means TKIP vs "AES-based CCMP" (not just AES).

  TKIP is a lower end encryption protocol (WEP2) and AES is a higher end
  (WPA2/802.11i) encryption protocol. AES is preferred.

  TKIP+AES

  This is what the encryption standards are for WEP2 (TKIP) and
  WPA2/802.11i (AES). It will attempt to use AES if available and fall
  back to TKIP if not. This setting offers the most compatability but
  won't guarentee a higher level of encryption if a device falls back to
  TKIP.

It gets even more confusing; my access point running OpenWRT supports the following modes, among others:

WPA with CCMP, TKIP, or both
WPA2 with CCMP, TKIP, or both
Mixed WPA/WPA2 with CCMP, TKIP, or both

Nowadays, the only relevant option is WPA2 with CCMP (or WPA3, of course).


Best practices for relatively simple API for our clients I've been reading a lot about many API security considerations, the differences in terminology, OAUTH, OpenID, etc. Although I understand their absolute necessity when it comes to securing an API properly, I am confronted with my (perhaps naive) vision of how things could be. I was hoping you could tell me how wrong or right I am and point me in the right direction. That would certainly be appreciated.

So, what exactly was I asked to do? -- The company I work for, called Company X, has lots of data stored internally. We now finally have an external PostgreSQL db in place and a webserver using Amazon EC2. This works really well. Now, I use Slim Framework to create routes, handle GET/POST/PUT/DELETE requests, send out queries using PDO and so on. Now I've come to the point where Company X asks me how their clients will be able to communicate with the API. Now of course I wouldn't hand over grant access to everyone, so I was initially thinking of an API key per client. I've used Instagram and other similar APIs and they seem to work on a similar way. However, I am also reading that "API keys are not enough". I can understand why this method may be too simplistic for a delicate issue of exchanging information, but I don't know if the other options are WAY to complex for the goals I am facing.

So, again to be clear, what I would like to accomplish is the following task: I want users to GET (let's say) notes from our server, I want them to be able to POST notes, updates them and delete them as well.

My question is how I can do this on a secure manner, without having to dive into dozens of protocol documentation. Of course, if that is the way to go then fine, but I am sure that there might be other ways that can prove to be just as safe.

Thanks for reading and especially if you decide to help me or at least tell me how far off I am from thinking with the right frame of mind. :-)

Edit: Clarified based on use case

First off, no system is perfect. Engineering is the art of making the best tradeoffs.

For backend-to-backend APIs (e.g. your server app and 3rd party API service) - API keys are really good. Most issues with API keys comes from developers neglecting how they store them (in code => commit to github public repos etc). API keys are

high entropy strings
can be revoked instantly
don't auto-expire (great for machine automation I.e. APIs)

Many security companies like Amazon (cloud provider), Stripe (payments) or Crypteron (data security as a service) use API keys. If you're the API creator, you absolutely must design-in

a proper API key lifecycle management (customer developers can refresh API keys without much intervention) and
should strictly enforce TLS.

As a consumer of API keys, ideally you want separate API keys for development vs production, so your dev team doesn't see production data. Basically have dev resource/instances vs production resources/instances

Things change for end-user to back-end communications i.e. mobile phone app => your server app. In this case, you really don't want to use API keys because you're technically authenticating end users - not an API itself. If you use a static API key, anyone can disassemble the mobile app binary and scan for the API key. You won't know when that happens, but even if you knew, you instantly need to update all clients with a new API key - and you're back at square 1.

Basically, never use API keys in client apps like mobile apps or browser apps. Ever. It's as bad as having clients directly connect to your DB rather than having a web/app server in the middle.

You're better off with cached credentials + basic authentication + TLS for a two party system (user, your service). If one is using a 3rd party to verify identity (e.g. Facebook), OAuth is another option to orchestrate between the three parties (user, Facebook, your service). Based on your concern, I'm assuming your end-user clients (mobile or browser) are directly connecting to Slim Framework's REST end points? Slim Framework seems to supports basic authentication so that plus TLS should be a good starting point. If you have specific concerns, clarify them in the question.

Disclosure: I work for Crypteron. Check us out!


Credit card data - sharing and storage What is the industry standard for sharing credit card data between client (thin & thick) and server?

Not sure why he didn't put it as an answer, but John Downey is correct, the PCI-DSS is what you are looking for.  It is the industry standard for protection of PCI (credit card details) in transit and at rest (in storage).


Why does the linux XRDP module use a 512 bit RSA key? Why does the linux XRDP module use a 512 bit RSA key? 512 bit RSA keys are broken by now. How can this be safe?

Basically it is not safe. As far as I know, they use 512-bit RSA because they mimic what Microsoft's RDP server used to do, which indeed implied a 512-bit RSA key; using something bigger would risk breaking compatibility with existing clients. Biggest issue, though, is not that the 512-bit key is weak because too short; the main problem is that, as a client, you have no way to make sure that the key is see is indeed the one from the genuine server. Man-in-the-Middle attacks are a plausible possibility, and increasing the key size to 2048 bits would not help in any way.

Relationship of RDP with security is complicated and convoluted. The protocol has historically used its own embedded security system, something roughly SSL-like, but never analysed with any decent level of detail. Previously it did not even encrypt anything, or just the user password. If you want security with RDP, you should use it within a VPN; on Linux, consider SSH as a way to initiate cheap but robust tunnels. Microsoft pushes their own mechanism, called Remote Desktop Gateway -- basically wrapping the complete protocol into a regular SSL tunnel.


Does it defeat the purpose to create an OpenPGP authentication subkey that is not password-protected? I'd like to be able to log into and out of my ssh servers freely without entering a password. Previously, I did this with ssh-keygen, storing the key file under my ~/.ssh directory.

Since I also have an OpenPGP key, I thought it might be nice to have one less private key to keep track of, and use my OpenPGP key for SSH authentication. The documentation is sparse, but after a whole day of fussing with it, I've finally gotten it to work. It appears that a best practice is to create a separate authentication-only subkey for this purpose, so that's what I've done.

The authentication-only subkey can be protected with a password, in which case it's required upon login (which defeats the purpose, convenience-wise). In the interest of extreme convenience (and because my security needs are low atm), I'd like to do without the password altogether.

(I'm aware that gpg-agent can cache the password for a set amount of time, so that it's not required on subsequent logins, but the question remains:)

What are the theoretical security risks posed by using an authentication-only subkey with no password? Apart from the possibility that my private keys are stolen and someone could use them to log into my SSH servers (or anywhere else I have authorized it), is there any way that using a passwordless authentication-only subkey might compromise the security of my other subkeys, or the originating secret key?

Password-protection of OpenPGP keys means they are encrypted symmetrically with the passphrase used. As you already stated, this is especially helpful if the encrypted copy of the key is stolen.

  Is there any way that using a passwordless authentication-only subkey might compromise the security of my other subkeys, or the originating secret key?

No. The authentication subkey can be used for exactly one specific operation: authentication. It is linked with the primary key by pairwise binding signatures (in the primary key's binding signature on the subkey, also the allowed key usage is configured). Most importantly, a subkey cannot be used to bind new subkeys to the primary key, only the primary key is allowed to perform this operation.

As all subkeys and also the primary key are cryptographically completely distinct keys, a broken/stolen subkey does not harm the others.


How a packed malware runs the unpacked code? When we run a packed malware it will unpack the code in dynamically allocated heap memory and heap can be kept non executable and I find no purpose to make heap executable. So, how the malware eventually runs the packed binary?

Packed malware has a an unpacking stub that will decrypt the obfuscated code and save it to another region. Then it will change that region to executable permissions and then adjust the instruction pointer or jump to the start of the newly written executable code region.

So in order to execute the malware it's basically the equivalent of a jump in assembly to a new like of code or a go to statement to another line or a function call in a higher level language to another area of code.


nessus scan against metasploit exploits I am thinking about launching wide nessus scans (in the "IP range" sense) against exploits present in metasploit. The idea is to limit the number of plugins so that that the scan finishes in a reasonable time. (As a side note nessus 5.0 comes with a set of filters which allow to chose for instance "critical" vulnerabilities but, this is unfathomable to me, it is not possible to save such a configuration, ie. you have to do this manually before each scan if you want to catch the newest vulnerabilities)

This would be in essence an exercise to match the relevant plugins in nessus with the current vulnerability list in metasploit.
I know it is possible to do the reverse (import into metasploit the results of nessus scans).

Nessus Filter Options:

"exploit available" = true (filters plug-ins to those with public exploits)
"metasploit exploit framework" = true (filters plug-ins to those with Metasploit vulnerabilities)

The explanations of these filters can be found in the user guide.

But, I assume that you also want the plugin list to automatically update when the Nessus plugins update. I do not have any info on how to do that, but I think you would need to generate a new policy with the appropriate filters after each plugin update.

Here is Tenable's guide to running scans from within Metasploit.


Ways to verify Data Integrity I've had looks to existing subjects but it usually gets heavily complicated while I'm new to this kind of stuff and I'd prefer to understand concepts first in order to understand better concrete solution.

I have a client/server application and I'm wondering about its design since every client will be able to generate files (through an interface) to send them to server, but I want the server to be able to say whether or not the file was created with the interface or handly-crafted by a malicious user.

Any existing commons methods? I wondered about hashing the file or using creating my own blockchain but I'm not familiar with this kind of data structure yet, and I've heard it needs some starting time before it really gets kind of "unbreakable", otherwise it's too easy to break.

I've found a page which is about "data tampering", it says the best may to protect from tampering is to restrict access, and that I should use a firewall, but my application will have an online and an offline mode as well, and I need to make sure every file created with connection being established is detected as "corrupted" by the server when the client connects and try to send the file to the server.

As long as you have a proper SSL in place 95% of your risk factors are eliminated.  Because your data-stream is encrypted, a MiM cannot read what you are sending or modify any data in it without completely corrupting what is received on the other side.  In order for the file to be intercepted for modification, the attacker would need some manner of malware on your local machine at which point, most origen validation processes become a moot point if your attacker knows what he is doing.

That said, your best bet to prevent externally modified files from being opened by your program is to add tracking codes for each file.  The tracking code could be some product of the file's Hash and a verification key generated by your program.  That way, even if an end user tries to figure out how to sidestep your upload procedure and push his own file, it won't have a valid key and your program will know not to allow it to be opened. But, as Anders pointed out, this is not a full proof method.


IDS and IPS placement in network? What is the good practice for the placement of IDS (NIDS) and IPS? Before the firewall or after the firewall? and why?

The answer is: it depends.

If you need to see all the crap hitting you from the Internet, IDS should be outside the firewall. Although it is not recommended because you literally get flooded with useless data and gives the machine lots of load. If not, just put it in.

IPS should be inside the firewall because it consumes more time per packet to inspect than the firewall.


VoIP protocols security I have read a lot of papers about VoIP security issues. The main focus is on SIP protocol. You can find hundred of papers about securing SIP. Even though other signaling protocols like H.323 and IAX or even media protocols like Real-time Transport Protocol (RTP) have security problems that have been described in enter link description here, there is almost no paper about them. I want to start a beneficial work on VoIP security and I am confused about this.

It basically depends on signaling protocol, since it controls encryptions and so on.
For example, H.323 supports the using of SRTP, TLS, or even IPsec via its H.235 standard. While SIP uses other methods.
So I think before you start working on security of VoIP, you should go through a comparison between signaling protocols. Although I advise of using SIP for your researches.


Restrict access to public URL many times I have such situation. Imagine there is a public service (URL). What we don't want, is for someone, to be able to access this URL many times in short period of time, because they will be able to block our database (essentially a DDOS attack, I presume?).

Is there a way to effectively protect against this type of attack? Technology we use is Spring Security (java).

you can try implementing Throttling  in your code.
You can also use a Proxy Firewall or LoadBalancer to limit the rate of requests.

There are open-source proxies like HAProxy and Nginx which can be used.
there are also factory made proxy firewalls available.

There are Cloud Proxies like Cloudflare which can be used.(my money is on these)
If you are running your Web Application in a Public Cloud, your cloud provider may also provide some security measures .
some kind of Caching may also help, depending on the scenario. refer HTTP-Caching


storage of client credential on OAuth2 server I'm developing an API and used a recommended implementation of OAuth2 protocol: PHP OAuth2 Server.

This library stores client ID and client secret as plain text in a database table.

Note that I mean the API clients' credential, not users' credentials.

I'm concerned about the case of an attacker gains access to the database, he will be able to use obtained data at will, unlike hashed+salted stored passwords that take a long time to be made useful.

This is really a security risk? How could security be improved, beside firewall and user permissions?

PS: Checked this question but my application run on *nix servers

I wouldn't consider this a major security issue as the values are limited to only your system's access to the third party sites.  It is less desirable, but the values can be easily invalidated without any bleeding in to other systems that access the same services.  It certainly doesn't hurt, and is even wise, to encrypt it, but you would have to encrypt it with a value found on the server anyway, so it only adds a mild amount of difficulty in gaining access to the keys.  You can't hash them like you would a password since they are just a token value that has no relation to any user input you ever see.

Depending on your use case, you could use the user's password for your system to encrypt the values (if you aren't using oAuth for your system's authentication), and you could only grab and hold the tokens while the user is logged in (if using oAuth for authentication), but that limits things like your ability to do any interactions while the user is offline, which may not be a viable constraint in your system.

Use of those keys should be restricted to your applications access to the third party systems and may well be limited to just your server's access to those systems as well, depending on how things are setup.

They are of pretty low value to an attacker.  It is a good idea to take what measures you can to protect them, but I wouldn't classify them as nearly as sensitive as a password (which is highly likely to be used elsewhere and gives direct access to the account).


How to encrypt the data such that only the user (owner) can decrypt them Here is the system:
The client side of our system generates confidential data that needs to be encrypted. Only the user should be able to read them, by that, I mean that even us who managed the data base and the whole application should not be able to decrypt this data.
I cannot think of a good strategy for the key here. In anycase, it seems like more than the user can decrypt the data.
I was thinking to generate the key in two part, we store one on our data base, but we would need the other half to decrypt. ok But how to create the 2nd half ? It is not possible from the user's password because we store it somewhere as well, which mean we would still be able to decrypt the data...
If anyone has a suggestion?
I am definitely not an expert in this type of problem...

Knowledge is power. In other words, if the user must be able to perform some action and nobody else should be able to do the same action, then there must be some value (a "key") that only the user knows, and nobody else.

Moreover, use of a value necessarily means having that value at hand; when you decrypt with a key, then you have that key, at least as long as you decrypt. If the key must be known to the user only, ever, then this implies that decryption shall occur only on a system that is under exclusive control of the user. To put things simply, decryption will have to happen on the user's machine (desktop system, laptop, tablet...) and not on any system that should never see the key (e.g. your server).

You thus have two issues to solve:

How to store the key such that the user can access it, but only that user may access it.
How to make the decryption happen on the client system in a way that you cannot easily circumvent.

The first problem can be dealt with using a local file or storage area. To some extent, you can help the client with some server-side storage and password-based encryption: if you have some piece of data D, then you can store on the server Ep(D), which is the encryption of D with a password p that the  server does NOT know. Password-based encryption is hard in general; begin by reading this answer. In that model, the really user-specific knowledge is the password p, that the user transports in his head.

The second issue is more problematic. You won't solve it in pure JavaScript (in a Web context) because whatever JavaScript is executed by the client will be sent by your server, so your server always has the conceptual ability to send, one time, a malicious JavaScript that grabs the password/key/whatever and sends it back to you. I suppose that your problem here is not only to give the ability to decrypt data to the user alone, but also to do it so convincingly, i.e. to be able to demonstrate to third parties that you really cannot access the data. At the best of times, this is difficult; a possible strategy is to make the client use some local application code that can handle the decryption, and is signed by you, and is amenable to easy reverse-engineering (C#/.NET and Java come to mind here). If there is such a client application, then you can claim that you cannot discreetly plunder the user's data because it would entail pushing a malicious application on their system, that could later on be reverse-engineered, the signature incriminating you.

In pure Web without such a local application, forget it. The Java applet model could have been applicable, but will be hard to do in practice because not many people support Java applets nowadays (and .NET+SilverLight is even less widely deployed).


MAC overflow (flooding) On a recent switch, is MAC flooding still a vulnerability to be careful of? If that attack is patched on most of them, then on which type of switch is it still vulnerable?

Yes, this it still is a threat and this is why:

MAC flooding is based on the overflow of the CAM Table (Content Access Memory). The CAM table assigns physical ports to MAC addresses. The CAM table has a limited size and if you manage to exceed that size the switch isn't able anymore to assign new MAC addresses to a physical port. In this situation the switch can do one of three things:

Go to Fail Open mode, which turns the switch into a hub, which means that everyone gets to see everything. One could then sniff the traffic of all connected clients.
Go to Fail Off mode, which causes the switch to keep the existing MAC-Addresses in the CAM-Table but wont add new which will result in new clients being locked out of the network.
The switch uses the CAM table like a ring memory, which means that the addresses that haven't been seen for the longest period get droped. This can be a practical solution for home switches because it's unlikely that you connect some thousand hosts to a DSL router

I also had a situation where a switch crashed complely after I caused an overflow of the CAM-Table. But this was a relativly cheap switch for the home envirnment to be honest.

Though this vulnerablity is kind of system inherent it can't be fixed like other system inherent vulnerabilities. You can prevent it by using port security, which I suggest you to do. If you're the attacker in a pentest you can attack this vulnerablity by using the tool macoff, which generates loads of ethernet packages with randomly generated MAC addresses to cause an overflow in the CAM table.

I tested it successfully on some Cisco switches, a Netgear switch and some usual desktop switches.


How to make an undeletable, hidden file, which persists after formatting an SD card? My SD card was stolen some weeks ago. I can't know which SD card is mine, because the thief formatted it. As such, I bought a new one.

In order to prevent such situations in the future, I thought of creating a hidden, undeletable file, which would persist, even in the event of the SD card being formatted.

Is this possible? How can I create such a file?

It's not possible to make an "un-deletable" file, because formatting an SD card doesn't delete the file. Formatting the SD card removes the data structure that tells you that the file ever existed.

Even if you were to use forensic tools to examine the SD card, the thief could simply overwrite the entire SD card with zeroes, random data or whatnot, and you would be out of luck again.

What you can do however is physically mark the SD card. Non-erasable pen with your initials should work just fine. This should physically mark your SD card as yours. While it doesn't prevent theft outright, it might cause someone like a classmate to hesitate from taking your SD card.

Other than that, I would recommend taking better care of your removable media.

Don't leave your SD card unattended. Always have an eye on it. If you have to lend it to someone, get it back as soon as possible.
Always have backups of critical data. The more "spread-out" your data is, the less likely it is to disappear in case of theft, damage to the SD card, accidental deletion, etc.
Don't transport potentially sensitive data unencrypted. Always use strong encryption with a long, random passphrase to ensure the confidentiality of your data.